A few Java questions to be discussed

[Rolf Krahl]

Dear all,

while preparing the snapshots, see other posts, I got some questions
that may be worth discussing:

Viktor and Alan did most of the work upgrading the components to
Payara 6 and also upgraded the GitHub actions for the CI tests.
(Thanks again for that!) The new tests run with Java 11 and Java 17
and I was pleased to see that everything just works also with Java
17.

That leads to the question: what do you think would be the recommended
Java version for (a) production deployment and (b) for building
release distributions? Are there any known caveats with upgrading
straight ahead to Java 17 or pros and cons for either version?

I could imagine that even if we upgrade to Java 17 for production, it
could still make sense to stick to Java 11 for building the releases,
just to make sure that the releases will work with either version.
Any opinions on that?


A somewhat related question: we also have ids.plugin (that defines the
interface for IDS plugins and is used to build both, the plugins and
ids.server) and ids.storage_file (the reference implementation of an
IDS plugin). They do not require JavaEE or JakartaEE and have not
been upgraded. The (old) releases are built with Java 8, but seem to
just work like that in the Payara 6 environment. Should we make
releases built with and for Java 11 (or Java 17) anyway, just to have
everything in one line and to get rid of Java 8 entirely? Any
opinions?


I will not be available for the next monthly meeting, but maybe you
want to discuss that in my absence anyway. I'd be happy to find a
conclusion in the minutes. Comments on this list would be welcome as
well.

Best regards,
Rolf

--
Rolf Krahl <rolf....@helmholtz-berlin.de>
Helmholtz-Zentrum Berlin für Materialien und Energie (HZB)
Albert-Einstein-Str. 15, 12489 Berlin
Tel.: +49 30 8062 12122

[Will Taylor]

Hi, just wanted to throw in some anecdotal experience. We maintain another (non-ICAT) EE web service which we recently migrated from 8->11->17, and going from 11->17 required no changes at all (besides changing the compiler version) - everything was completely compatible. 17 obviously gives another 3 years of support, and there are lots of nice little features for development, so I think aiming to move to it fairly quickly is probably reasonable.

Cheers,

Will

[Alan Kyffin]

Hi,

When me and Viktor updated components, we configured the maven-compiler-plugin to use the --release 11 flag, which ensures that the compiled classes use Java 11 bytecode and also that they only use the Java 11 API. Therefore the builds should be consistent regardless of which version is used.

For production, Payara supports 11, 17 and 21 (which is the next LTS version that will be released in September). Since there are no major changes between 11 and 21 like there were between 8 and 11, we can support all 3 just by testing on GitHub Actions. I would recommend using 17, because we may want to drop support for 11 at some point in order to take advantage of newer features.

The components built with Java 8 don't need to be rebuilt.

Alan