Re: [EXTERNAL] [Numbers][All] Separate Java target version for "src/test"

[Ralph Goers]

I don’t understand this. Log4j2 was one of the first adopters of multi-release 
jars. 
There were problems in the beginning but those have virtually all been 
resolved. 
We haven’t had any complaints in ages. Log4j 2 2.14.1 supports Java 8. 

Fully supporting JPMS (i.e. - adding a module-info.java file) while trying to 
support 
Java 8 is another thing entirely. I gave up on that and the minimum JDK version 
for that will be Java 11.

Ralph

> On Jun 13, 2021, at 3:37 PM, John Patrick  wrote:
> 
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a pure JPMS solution.
> 
> Potentially someone raise an enhancement to drop support for Java 1.8 which
> isn't happening for Java 17, but for Java 18 which is only 8 month away it
> could happen. So at that point it might be a shock for commons projects as
> you might be blocking open source projects, or they roll off commons
> projects... just a thought.
> 
> I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
> anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...
> 
> John
> 
> 
> On Thu, 10 Jun 2021 at 14:07, Gilles Sadowski  wrote:
> 
>> Le jeu. 10 juin 2021 à 14:42, John Patrick  a
>> écrit :
>>> 
>>> If the tests are valid and useful once post Java 1.8, what about
>>> starting the next release branch where the min version bumps to Java
>>> 11.
>> 
>> [Numbers] and related components were meant to replace and
>> improve some functionalities provided in [Math] v3.6.1 whose
>> target was Java 5 (!).
>> A few years ago, the bump to Java 8 was considered a bold move
>> (for "Commons"). :-}
>> 
>> If we are sure that Java 11 is no problem for anyone who'd go
>> through the upgrade effort, then indeed why not?
>> 
>> Gilles
>> 
>>> As Java 17 starting ramp down starts today I believe so in 3 months we
>>> will have 3 LTS (1.8, 11 and 17) releases. So technically Java 18
>>> development starts tomorrow and I expect 1.8 will be dropped shortly
>>> from backwards support as they want to get off the classpath fully and
>>> onto the modules path.
>>> 
>>> Anyway, just a thought.
>>> 
>>> John
>>> 
>>> On Thu, 10 Jun 2021 at 12:05, sebb  wrote:
 
 Thanks.
 
 I've updated the RELEASE-NOTES accordingly (feel free to tweak the
>> text)
 
 On Thu, 10 Jun 2021 at 00:58, Alex Herbert 
>> wrote:
> 
> I have removed the requirement for Java 9 from the build. It is
>> still used
> in the performance testing module.
> 
> Alex
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Hi Benedikt,

*Per the JDK 17 schedule , we are in Rampdown Phase One [1].*

**Please advise if you find any issues while testing the latest Early 
Access builds**.**


 * Schedule:
 o *2021/06/10   Rampdown Phase One*
 o 2021/07/15    Rampdown Phase Two
 o 2021/08/05    Initial Release Candidate
 o 2021/08/19    Final Release Candidate
 o 2021/09/14    General Availability

The overall feature set is frozen. No further JEPs will be targeted to 
this release.


**

 * Important JEPs have been integrated – Attention Required!
 * *JEP 411: **Deprecate the Security Manager for
   Removal*
 o Deprecate, for removal, most Security Manager related classes
   and methods.
 o Warning message at startup if the Security Manager is enabled on
   the command line.
 o Warning message at run time if a Java application or library
   installs a Security Manager dynamically.
 o Deprecation is in concert with the legacy Applet API (JEP 398).
 * *JEP 407: **Remove RMI Activation*
 o Removal the Remote Method Invocation (RMI) Activation mechanism,
   while preserving the rest of RMI.
 o It was deprecated for removal by JEP
   385in Java SE 15.
 * *JEP 403: **Strongly Encapsulate JDK
   Internals*
 o Strongly encapsulate all internal elements of the JDK, except
   for critical internal APIs such as /sun.misc.Unsafe/.
 o It will no longer be possible to relax the strong encapsulation
   of internal elements via a single command-line option.

 * Other features integrated in JDK 17:
 o *JEP 306: **Restore Always-Strict Floating-Point
   Semantics*
 o JEP 356: Enhanced Pseudo-Random Number
   Generators
 o JEP 382: New macOS Rendering
   Pipeline
 o JEP 391: macOS/AArch64 Port
 o JEP 398: Deprecate the Applet API for
   Removal
 o *JEP 406: **Pattern Matching for switch
   (Preview)*
 o JEP 409: Sealed Classes
 o JEP 410: Remove the Experimental AOT and JIT
   Compiler
 o JEP 412: Foreign Function & Memory API
   (Incubator)
 o *JEP 414: **Vector API (Second
   Incubator)*
 o *JEP 415: **Context-Specific Deserialization
   Filters*

*OpenJDK 17 Early Access build 26 is available at 
**https://jdk.java.net/17*


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception

 * Release Notes are available at
   https://jdk.java.net/17/release-notes

 * Changes in recent builds that maybe of interest:
 * *Build 26:*
 o JDK-8268241: deprecate JVM TI Heap functions 1.0
 o JDK-8266846: Add java.time.InstantSource
 o JDK-8248268: Support KWP in addition to KW
 o JDK-8204686: Dynamic parallel reference processing support for
   Parallel GC
 o JDK-8259530: Generated docs contain MIT/GPL-licenced works
   without reproducing the licence [*Reported by Apache Maven*]
 o JDK-8266766: Arrays of types that cannot be an annotation member
   do not yield exceptions [*Reported by ByteBuddy*]
 o JDK-8266598: Exception values for
   AnnotationTypeMismatchException are not always informative
   [*Reported by ByteBuddy*]
 * *Build 25*
 o JDK-8266653: Change update mode for JDK rpm/deb installers as it
   breaks "yum update" for JDK11+
 o JDK-8263202: Update Hebrew/Indonesian/Yiddish ISO 639 language
   codes to current
 o JDK-8229517: Support for optional asynchronous/buffered logging
 o JDK-8182043: Access to Windows Large Icons


*OpenJDK 18 Early Access build 1 is now available at 
**https://jdk.java.net/18* 


 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception 
 * Issues addressed in this build - here
   

*Other Topics which might be of Interest: *

**

 * Java Cryptographic Roadmap [2] has been updated.
 * Inside Java Newscast #6 [3]
 o a closer look at the list of JEPs of JDK 17 as well as the
   development process
 * Inside Java Newscast #7 [4]
 o discusses in greater detail `pattern matching for switch`,
   previewed in JDK 17

Rgds,Rory

[1] 

Re: [EXTERNAL] Re: [Numbers][All] Separate Java target version for "src/test"

[Gilles Sadowski]

Hello.

Le lun. 14 juin 2021 à 00:37, John Patrick  a écrit :
>
> So I want to start using Java 11 and take advantage of Java Modules. But
> with a bug in Java Multi-Jar not supporting 1.8 as base and 11 upon that,
> and most dependencies I want to upgrade eventually get stuck on a commons
> project holding a pure JPMS solution.
>
> Potentially someone raise an enhancement to drop support for Java 1.8 which
> isn't happening for Java 17, but for Java 18 which is only 8 month away it
> could happen. So at that point it might be a shock for commons projects as
> you might be blocking open source projects, or they roll off commons
> projects... just a thought.
>
> I've tried to do a seamless upgrade, or suggest a roadmap, but haven't got
> anywhere, but think I might just raise a JEP to drop 1.8 in Java 18...

I'm not sure I don't understand what you mean.  If it's about the possiblity
to use JPMS: "Commons RNG" project has an example[1] showing that it
seems to work when the code is used within a Java 9+ environment, even
though the component itself is still targetted at Java 1.6.

Regards,
Gilles

[1] 
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=tree;f=commons-rng-examples/examples-jpms;h=64999d7bd370e374fbe801d8bc376ba17ea55970;hb=HEAD

>>> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org