Move Java wrappers to FFM using jextract and java 25

[byrnHDF]

Closes #5712 Issue
Closes #5927 PR
FFM build requires Java 25, Jextract 25.
Generates FFM bindings during configure.
JNI is default when the requirements are not met or can be forced.
Presets added for maven and FFM - JNI is default selection.
Enhanced Maven options will work with either JNI or FFM
New Workflows for testing and maven uploads.
Extensive documentation changes for java.

[mattjala]

Unused methods should be removed from VLDataConverter.java

• convertSingleElementFromHVL
• readVLStrings
• readVLStringsFromAttribute

convertSingleElementImmediately should have the deprecated tag removed and the comment changed, because "the two-phase approach" (convertFromHVL) internally uses this routine. (convertFromHVL -> convertRawDataToArrayList -> convertRawDataToNestedVLList -> convertNestedVLImmediately -> convertSingleElementImmediately).

This entire file should be more closely examined in the future, since it seems to have been written under false ideas about H5Treclaim, but this minimal set of simple changes should be done now.

[byrnHDF]

This entire file should be more closely examined in the future, since it seems to have been written under false ideas about H5Treclaim, but this minimal set of simple changes should be done now.

Agreed. VL usage with FFM is complicated.

I have a lot more archive docs about this, I will review it to see what was done and the thinking behind this before making a decision.

Oh there is one issue here that is being ignored, which we need to decide; H5A/D has implemented write_VLStrings functions but not read_VLStrings. That is what those functions are for. I guess instead i=of deleting the unused functions I should implement the read functions that use them.

[byrnHDF]

since it seems to have been written under false ideas about H5Treclaim

What false ideas in particular?

[mattjala]

since it seems to have been written under false ideas about H5Treclaim

What false ideas in particular?

Multiple comments indicate that it's written 'defensively' with regards to vlen memory, as though the library itself were at risk of calling H5Treclaim at any time. As I understand it, this isn't true, since H5Treclaim() would pass through the java wrappers like everything else.

[byrnHDF]

Multiple comments indicate that it's written 'defensively' with regards to vlen memory

I think you need to consider it from the FFM viewpoint - direct memory access is the problem after H5Treclaim is called. That is the reason for copying the data to a Java container and not assuming the raw memory will still be accessible.