Re: Discuss when to drop Java 8 compatibility, and release numbering
I'd prefer we don't suppress warnings. Seeing this warning is what led to this discussion and is allowing us to plan the next steps while things are only deprecated and not fully removed. On 2023-10-03 11:06 AM, Mike Beckerle wrote: Update. I said the first choice was: "(a) turn off fatal warnings for Java and Scala compilation when compiling with Java 21." Turns out, one can do "-Xlint:-options" to suppress warnings about command line options only. So choice (a) becomes: (a) turn off "--release 8 " warnings for Java and Scala compilation when compiling with Java 21. This is a more attractive alternative now. On Tue, Oct 3, 2023 at 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
Re: Discuss when to drop Java 8 compatibility, and release numbering
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
Re: Discuss when to drop Java 8 compatibility, and release numbering
Update. I said the first choice was: "(a) turn off fatal warnings for Java and Scala compilation when compiling with Java 21." Turns out, one can do "-Xlint:-options" to suppress warnings about command line options only. So choice (a) becomes: (a) turn off "--release 8 " warnings for Java and Scala compilation when compiling with Java 21. This is a more attractive alternative now. On Tue, Oct 3, 2023 at 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 > > >
Discuss when to drop Java 8 compatibility, and release numbering
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
