Hello Martin
Indeed, we use multi-release JAR files for other projects. But in Apache
SIS case, upgrade from Java 8 to 11 implies changes pervasive enough to
make uncertain that multi-release JAR would be easier than a branch. But
anyway, the decision to bump the minimum Java version is up to the
community, which includes the users. If a user (could be Sedona) objects
against a future bump, this is taken in account.
One thing about the timing is that a migration (if desired) may require
more work as time passes. For example a recent request on this mailing
list was about fetching values in a GeoTIFF file. Apache SIS already
supports that on GeoTIFF and netCDF among others, handling the CRS
issues, in N-dimensions when the format supports it, and efficiently on
large files when the format supports tilings (geospatial softwares do
some big data on their own since they work with space agencies). Work
developed on top of a different library would probably be done
differently, making an eventual migration more unlikely.
Whether a migration would be desirable or not depends on the technical
merits of libraries, but also licensing is maybe not a negligible
aspect. Given that Sedona is all about bringing geospatial
functionalities to Spark, it seems a little bit surprising that
"referencing by coordinates" services and "grid coverages" (a.k.a.
rasters) are not core to Sedona?
But anyway, I understand that for making a migration proposal receivable
for consideration, we need a prototype that can be evaluated for
functionalities and performances. I will not have the time to work on a
Sedona branch for the next few months however (especially if acceptance
is uncertain), but maybe in spring some experiment would be possible.
Martin
Le 18/01/2023 à 15:37, Martin Andersson a écrit :
I think that Sedona and SIS joining forces would be great. But maybe the
timing isn't right.
I don't think a maintenance branch is going to work. Once the big data
community drops java 8, in a few years, and Sedona is ready to upgrade SIS
you will already be several java releases ahead and we'll be stuck on a new
maintenance branch.
If you are interested in joining the big data community I would advice you
to look into multi release jars and be very conservative when it comes to
bumping minimum java version.
Multi release jars would not only help you with backwards compatibility. It
would also help you take advantage of new java features, for those running
on newer runtimes, before you bump the minimum java version.
For instance jackson runs on java 8 but supports records on new java
runtimes. All from the same build and jar file.
