Bug 66394 - Implement validator
Summary: Implement validator
Status: NEW
Alias: None
Product: POI
Classification: Unclassified
Component: POI Overall (show other bugs)
Version: 5.2.2-FINAL
Hardware: PC All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-17 11:27 UTC by Asbjørn S.
Modified: 2022-12-20 16:01 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Asbjørn S. 2022-12-17 11:27:03 UTC
Open XML SDK has a validator component, so you can check if your word, spreadsheet or presentation file is valid according to the standard.

Open XML SDK is however in C# language.

Apache POI is the Java equivalent and it seems to be missing a validator component to support the full data lifecycle from creation to either deletion or archiving (you have to validate before you can archive), if you want to archive the functionality of the data instead of making a static image file, which would only preserve information.

I file this has an enhancement.
Comment 1 PJ Fanning 2022-12-17 12:04:13 UTC
I'm afraid that noone is likely to volunteer to write this. POI is not the Java equivalent of Open XML SDK. POI is an OSS volunteer project. Open XML SDK appears to be built by Microsoft employees who are paid for the work they do. Possibly, you might be better off asking Microsoft to create a Java version of Open XML SDK.

With POI, all you can so is to use one of the existing APIs to parse the file and see if there are any exceptions.
Comment 2 PJ Fanning 2022-12-17 12:08:07 UTC
In a Microservices architecture, you can run some services in .NET and some in Java - so you could have a web service that uses Open XML SDK to validate files - while also having Java based web services that use POI if that's what is needed.
Comment 3 sfisque 2022-12-20 16:01:18 UTC
depending on their pipeline, it should be possible to wrap the binary with a JNI call interface if it needs to be embedded in a java execution context.

additionally, C# and java are close enough that porting the lib (if the OP has the resources to do such) should be "non-terrible"