I think maybe consider an option (d) to support Java 21, but when
compiling with 21 we change the minimum version to something higher like
9 or 11. So we still support compiling from source on Java 21 without
any warnings, but you get class files that Java 21 is going to be more
happy about.
And if you are compiling from source, then I think it is a case of buyer
beware and you have to be more aware of compatibility issues. We'll
default to something that will be compatible with what you're compiling
with and maybe older (e.g. Java 11), but no guarantees.
I would suggest as long as our official binary releases are compatible
with Java 8+ (which I think includes 21 since it still supports loading
Java 8 classes, just not creating), then I don't think we need a major
version bump. Once we change the minimum supported java version of our
official releases, then we definitely do need a major version bump.
And as long as we depend on the latest version of scala in our pom
files, and package it in our RPM/tar/zip, then we should work with the
the latest version of Java (at the time of release). Which we do with
the aid of scala steward. A frequent release schedule should ensure we
don't have any problems. Older versions of Daffodil might not work with
much newer versions of Java, but nothing we can do about that.
So I'm not sure we have any compatibility issues with our current
official releases that requires a version bump.
I do agree it's probably about time to move away from Java 8 though. If
someone is stuck on Java 8, then they'll just have to be stuck on
Daffodil 3.5.0 or 3.6.0. Current versions of Daffodil have enough
functionality that it should be fine.
That said, I don't think we are in a rush to bump to 4.0.0 and a newer
version of Java. Our next release was planned to be primarily bug fixes.
Maybe 3.6.0 is the last one that supports Java 8, and we can do some
major changes for 4.0.0 (e.g. new minimum version, new layer API, remove
deprecated stuff)?
On 2023-10-03 10:16 AM, Mike Beckerle wrote:
So Java 21 deprecates, but does not eliminate, Java 8 compatibility.
You get an unavoidable warning. To support Java 21, a LTS Java release, we
either need to
(a) turn off fatal warnings for Java and Scala compilation when compiling
with Java 21.
or
(b) we need to set the release compatibility higher. Our choices here are
Java 11, 17, or 21.
or
(c) don't support Java21 officially yet
I suggest (c) is the right thing, but our next release should be Daffodil
4.0.0 and it should require Java 11 across the board, eliminating Java 8.
Java 8 is still in use by some, but is clearly past what anyone wants to
support any more.
A few comments people can agree or disagree with.
1) We should avoid Daffodil releases that require two different sets of
Class files - one for say, Java 8, and one for a more modern JVM.
2) Requiring a new JVM beyond Java 8 is a big deal, and motivates a bump to
version 4.0.0 of Daffodil.
3) Java 21 is new now, so while we can put in changes to eventually support
it, we are not forced to support it yet. It also requires Scala 2.12.18 for
example, which we're now compiling with.
4) In general, I think we've not moved major versions often enough to
signal the incompatibilities. Support for Java 17 required using Scala
2.12.15 at least, and that was probably enough to motivate a major release
number bump. Certainly the package renaming from Daffodil 3.4.0 to Daffodil
3.5.0 was a mistake and should have been a bump of major version to 4.0.0
5) We should "in effect" deprecate 3.5.0 and suggest people jump to 4.0.0
instead, and that means releasing 4.0.0 very soon. 3.5.0 should be our last
release which supports Java 8 JVMs.
Thoughts?
Mike Beckerle
Apache Daffodil PMC | daffodil.apache.org
OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl
Owl Cyber Defense | www.owlcyberdefense.com
