Barry,
I'm not totally sure to have the full picture of what you
deploy/distribute. I'd assume the main difficulty for the end users of
your Java component is to get the GDAL native library, and probably even
more tricky, the libgdaljni.so/dll/dylib. If you assume they have
managed libgdal itself, then you could distribute gdal.jar +
libgdaljni.so/dll/dylib (possibly in several CPU architectures depending
on what you target...) of the minimum GDAL version you want to support
(in theory you should be able to use libgdal native 3.X against
gdal.jar/libgdaljni 3.Y if X >= Y as it relies only on the C API which
we normally guaranteed to be ABI backwards compatible in the 3.x
series). If you want to support GDAL >= 3.8 and < 3.8, I'm afraid you'll
have to provide a gdal.jar + libgdaljni combo of let's say GDAL 3.0 (or
a later release), and another one of 3.8
By the way, I've seen use of Panama
(https://openjdk.org/projects/panama/) to avoid the need of JNI at all:
https://github.com/apache/sis/tree/main/optional/src/org.apache.sis.storage.gdal/main/org/apache/sis/storage/panama
. So in theory that could makes things simpler (at least you wouldn't
need the libgdalalljni.so/dll/dylib native code). Haven't tried it /
can't comment on the appropriateness of that particular code. Perhaps
at some point someone will need to reboot the GDAL Java bindings to be a
Panama project if JNI is abandonned (and that would likely be totally
disconnected from SWIG. At least
https://github.com/search?q=repo%3Aswig%2Fswig%20panama&type=code
doesn't show any sign)
Even
Le 07/11/2024 à 20:45, Barry DeZonia via gdal-dev a écrit :
Hey all,
I hope this is the right place for this email. I am a developer that
has written a java component that interfaces with the java bindings
and allows my app users to access gdal data.
The problem I have is that gdal seems to release somewhat often. I
wrote my code initially for 3.7 but later used 3.8 (and abandoned 3.7)
due to some new features present in the java bindings. Since then
there have been gdal releases for 3.9 and 3.10.
How should I release my (java jar) component? One release version per
gdal release? Then am I forcing a similar fork in all downstream
projects that use my components? It seems so.
Now also imagine my component relies on something else that also has
multiple versions. I could get a combinatorial explosion in the number
of versions of my plugin.
And I also seem to need to make a decision on how to nicely target
older gdals that don't have the new java niceties of 3.8. Many people
are using gdal versions older than 3.8.
This whole topic is making my head spin a little. Any advice?
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is
just about bytes.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
