All active components already are compatible with Java 8 (except one maybe).
Gary
On Wed, May 31, 2023, 15:29 Glavo wrote:
> Java 8 jars can include module-info.class even if they are not
> multi-release.
> Java 8 does not load module-info.class, so there is no need to use MR for
> isolation.
>
Java 8 jars can include module-info.class even if they are not
multi-release.
Java 8 does not load module-info.class, so there is no need to use MR for
isolation.
I hope to make our components compatible with Java 8 for 2-4 years.
During this period, we can compile module-info.java separately and
I prefer to lead a simpler life Matt ;-)
MR jars are an abomination IMO.
Gary
On Wed, May 31, 2023, 11:51 Matt Sicker wrote:
> How about using multi-release jars? That way we can include module-info
> files and version-specific additions while still supporting Java 8 for a
> while. It could re
How about using multi-release jars? That way we can include module-info files
and version-specific additions while still supporting Java 8 for a while. It
could require a newer Java compiler while still targeting the Java 8 bytecode
version.
—
Matt Sicker
> On Apr 23, 2023, at 08:46, Gary Grego
Le 23/04/2023 à 19:40, Glavo a écrit :
If only for JPMS, we can compile module-info.java separately, which is
still compatible with Java 8.
If we really need to give up compatibility with Java 8, then I still
recommend skipping Java 11 and using Java 17.
+1
This should be decided component by
If only for JPMS, we can compile module-info.java separately, which is
still compatible with Java 8.
If we really need to give up compatibility with Java 8, then I still
recommend skipping Java 11 and using Java 17.
Glavo
On Mon, Apr 24, 2023 at 1:32 AM Ralph Goers
wrote:
> The primary reason
The primary reason for moving to Java 11 is to fully support JPMS. Most
libraries have added an automatic module name to the Manifest but that doesn’t
really make it fully JPMS enabled.
To be honest, the number of people I’ve seen asking for full JPMS support is
quite small though.
Ralph
>
I don't think upgrading to Java 11 is a very attractive proposition.
There are not many language features introduced in Java 9~11,
so there are not enough benefits to upgrade to Java 11.
The lifecycle of Java 11 is much shorter than that of Java 8.
Premier support for Java 11 will end this year, a
Waiting until 2030? Surely you must be joking.
Gary
On Sun, Apr 23, 2023, 11:37 Alex Herbert wrote:
> Free commercial support for JDK 8 from Oracle ended in 2022.
> Non-commercial and extended commercial support ends in 2030. Other
> providers have free support for longer than 2023 [1]. I would
On Sun, 23 Apr 2023 at 16:37, Alex Herbert wrote:
>
> Free commercial support for JDK 8 from Oracle ended in 2022.
> Non-commercial and extended commercial support ends in 2030. Other
> providers have free support for longer than 2023 [1]. I would rather
> maintain Java 8 support when JDK 8 still
Free commercial support for JDK 8 from Oracle ended in 2022.
Non-commercial and extended commercial support ends in 2030. Other
providers have free support for longer than 2023 [1]. I would rather
maintain Java 8 support when JDK 8 still has broad support and usage.
Alex
[1] https://en.wikipedia.
Gary,
A few years ago I migrated commons crypto onto Java 11 in my local
environment. I haven't kept the code, but it wasn't a heavy lift and I'm
happy to do it again for the community version. Let me know how you'd like
me to proceed.
Alex
On Sun, Apr 23, 2023 at 9:47 AM Gary Gregory wrote:
Hi All,
In the year 2023, and with Java 21 in EA (https://jdk.java.net/21/), I
think it is time to start migrating our components from Java 8 to Java
11. I imagine this to happen slowly and surely over the course of this
whole year.
In addition, originally, it should also be time to update our Gi
13 matches
Mail list logo
