Adql2.1jakarta

[pahjbo]

updates to be able to use with modern Java (>=9) where all the XML is now under the jakarta package

[gmantele]

This topic seems to be in the spirit of the times 😄 See #161

You are perfectly right. As I said in the linked PullRequest, I have already performed this update in the branch adql-2.1. This branch is still not stable ; TAP is not yet working in this branch, but I am currently working actively on it. I am doing my best so that it is ready by the end of this year, ideally the Autumn IVOA Interop.

With this branch will come the following updates/changes:

• the dependency for the Jakarta package
• use exclusively Gradle (instead of Ant)
• new GitHub repository (see branch adql-2.1 for a preview)

However, we have to stay with Java 8 because of TOPCAT currently limited to this version due to its user community (some users are still under Java 8). TOPCAT uses the ADQL-Library. I may see later for a solution using Gradle sub-projects regarding this issue.

[pahjbo]

Note that these changes are onto the adql-2.1 branch.

I have added my thoughts on trying to maintain Java 8 compatibility here - basically do not try - it is too difficult! If the current version of the ADQLLib is published to maven central #148 then TOPCAT can depend on that until it wants to move beyond Java 8.

We will be actively trying to use the UWS and TAP libraries from this branch, so might well be adding new PRs to fix things too.

[bourgesl]

As I am an OpenJDK maintainer & share interest in long-term support on taplib/vollt ... for jmmc/eso,, I can make it for you = adopt multi-release jars (8, 11, 17, 21, 25).

We could talk about this task during VO days...

[gmantele]

Thank you @pahjbo for your remarks. I agree with what you say, except for the way TOPCAT has to fetch VOLLT compiled in Java 8. Unless if I misunderstood, your solution means that TOPCAT cannot benefit from new features/fixes and ADQL language improvements because it will be stuck with an old version of VOLLT. My point is that it is fairly easy to change the Java version in build.gradle to the desired version. Going for a newer version is generally harmless, but not the contrary. That's why I try to keep the minimal version of Java to 8.

Ideally, it would be nice if I can do that only for the ADQL Library, but let the other libraries upgrade their Java version to 9+. I do not know whether it is possible, but I'd like to try few ideas before penalizing an entire community (TOPCAT and STILTS users). Until now, I keep this PullRequest open.

[gmantele]

@pahjbo , @bourgesl , @vforchi , and others : there will be some VO events (in France, in the US, ...) this year. I would really like to have a chat together and think about the future of VOLLT. I am actually preparing myself for the OV France meeting next week and probably for the next interop as well. I have a lot of ideas and I think it is time to share all of them and see what good ideas we can have all together. I hope it is fine with you too.

Unfortunately, it is hard to make an important decision on several major topics in the same time (while minimizing backward compatibility issues). So, for the moment, I keep focusing entirely on finishing the support of ADQL-2.1 and TAP-1.1 in this branch adql-2.1 (which makes already a huge amount of changes for ADQL and TAP libraries that you do not see yet in this branch because it does not compile yet). I also have a lot of ideas to improve the HTTP exchanges as well as the thread and job management and persistence for UWS and TAP, which I hope will improve compatibility with frameworks like Spring, Quarkus, .... while helping to design correct tests. But let's speak about all of that another time.... [I am already off-topic here :D]

[mbtaylor]

@gmantele, thank you for your consideration for topcat users. To keep entry and upgrade barriers as low as possible for topcat I would like to keep to a target platform of Java 8 while I can, and I've seen almost nothing in JDK 9+ that would benefit me or my users. However I appreciate that VOLLT has its own constraints to consider, so if you decide you have to target a later Java version I'll work with it one way or another (stick with an earlier VOLLT version or bump my target platform).

I'm interested in @bourgesl suggestion of MRJARs, which I hadn't heard of before. But I wonder if there's a more straightforward solution. Could you use JDK 9 for the build, but (at least for the ADQL lib) cross-compile to java 8 classes (-source 8 -target 8)? The UWS and TAP libraries still couldn't be used from Java 8 because of the missing javax.servlet classes, but I'm only interested in the ADQL library, which I'm guessing does not have a servlet dependency.

[bourgesl]

Hi Mark,
To illustrate MR-JAR, here is an example I made to build JIDE-oss library on jdk8 / 9+ using the multi-release jar (special class implementations for 8 & 9), see this patch to fix maven build on 8/9:
bourgesl/jide-oss@3636dd0

Cheers!

[pahjbo]

@gmantele, thank you for your consideration for topcat users. To keep entry and upgrade barriers as low as possible for topcat I would like to keep to a target platform of Java 8 while I can, and I've seen almost nothing in JDK 9+ that would benefit me or my users. However I appreciate that VOLLT has its own constraints to consider, so if you decide you have to target a later Java version I'll work with it one way or another (stick with an earlier VOLLT version or bump my target platform).

I'm interested in @bourgesl suggestion of MRJARs, which I hadn't heard of before. But I wonder if there's a more straightforward solution. Could you use JDK 9 for the build, but (at least for the ADQL lib) cross-compile to java 8 classes (-source 8 -target 8)? The UWS and TAP libraries still couldn't be used from Java 8 because of the missing javax.servlet classes, but I'm only interested in the ADQL library, which I'm guessing does not have a servlet dependency.

That is probably the solution - the ADQL library should be in its own source repository (or the gradle build properly segregated) - it does not suffer from the jakarta issue that the UWS and TAP libraries do

[tsdower]

At MAST, we have been using the vollt library by working from a fork with our own build scripts only for the ‘adql’ portion, which we wrap in a small microservice we’ve recently updated including the Jakarta changes. (This gets called by the rest of our TAP stack in Python.) As such I would like to note my support of suggestions for a separate ADQL build; it’s what we’ve been doing in a hacky way for some time.