You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Rory O'Donnell <ro...@oracle.com> on 2018/07/02 09:29:10 UTC
JDK 11 is now in Rampdown Phase one
Hi Ralph,
*JDK 11 is now in Rampdown Phase one***
The overall feature set is frozen. No further JEPs will be targeted to
this release.We’ve forked the main-line source repository, jdk/jdk, to
the jdk/jdk11 stabilization repository. Any changes pushed to jdk/jdk or
jdk/client are now bound for JDK 12.
* For more details , see Mark Reinhold's email to jdk-dev mailing list
[1]
* The Rampdown Phase one process [2].
*Note: -* Early-Access build archive format on Windows has changed to zip.
Since our last email the following JEPs have been targeted to JDK 11 :
* 181: Nest-Based Access Control
* 315: Improve Aarch64 Intrinsics
* 330: Launch Single-File Source-Code Programs
* 331: Low-Overhead Heap Profiling
* 332: Transport Layer Security (TLS) 1.3
* 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
* 335: *Deprecate the Nashorn JavaScript Engine*
* 336: *Deprecate the Pack200 Tools and API*
Other important changes since last email:
Build 19:
JDK-8205043 <https://bugs.openjdk.java.net/browse/JDK-8205043> : G1
enables adaptive parallel reference processing by default
Build 18:
JDK-8196141 <https://bugs.openjdk.java.net/browse/JDK-8196141> : Add
GoDaddy root certificates
JDK-8204243 <https://bugs.openjdk.java.net/browse/JDK-8204243> :
*remove Thread.destroy() and Thread.stop(Throwable)*
JDK-8202088 <https://bugs.openjdk.java.net/browse/JDK-8202088> :
Japanese New Era Implementation
Build 17:
JDK-8189949 <https://bugs.openjdk.java.net/browse/JDK-8189949> :
Remove Baltimore Cybertrust Code Signing CA
JDK-8191031 <https://bugs.openjdk.java.net/browse/JDK-8191031> :
Remove several Symantec Root CAs
JDK-8072996 <https://bugs.openjdk.java.net/browse/JDK-8072996> :
Deprecate stream-based GSSContext methods
Build 16:
JDK-8191844 <https://bugs.openjdk.java.net/browse/JDK-8191844> :
Remove SECOM root
Rgds, Rory
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001509.html
[2] http://openjdk.java.net/projects/jdk/11/#Schedule
Re: JDK 11 is now in Rampdown Phase one
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t believe they are removing ScriptEngine support, only the JavaScript engine being there by default. I wouldn’t have recommended using it anyway since it doesn’t compile the scripts.
Ralph
> On Jul 2, 2018, at 8:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> On Mon, 2 Jul 2018 at 04:29, Rory O'Donnell <ro...@oracle.com>
> wrote:
>
>> * 335: *Deprecate the Nashorn JavaScript Engine*
>>
>
> Hooray, more built in features going away! So first we have the issue of
> XML APIs being removed from the base (which, as far as I can tell, means
> you either have to add special command line flags to re-enable or you need
> to include the XML API libraries on the classpath/modulepath manually
> anyways), and now we have no standard javax.script engine to use, either,
> unless I missed something and now you can use Java itself as a scripting
> engine. I'm starting to think that with Log4j 3, we'll need to move some
> features that depend on non-base APIs into separate modules where possible,
> or we're going to need to get creative with our build system to avoid third
> party dependencies in log4j-core (jar shading is always an option). The
> script family of plugins may be one such plugin. We already had several
> pain points around things like JNDI with Android in the past, and I think
> this will only get worse with future Java releases and further
> modularization.
>
>
>> JDK-8202088 <https://bugs.openjdk.java.net/browse/JDK-8202088> :
>> Japanese New Era Implementation
>>
>
> We had locale-related date test failures in the past when JDK 9 was in
> development. Is this anything to worry about?
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: JDK 11 is now in Rampdown Phase one
Posted by Matt Sicker <bo...@gmail.com>.
On Mon, 2 Jul 2018 at 04:29, Rory O'Donnell <ro...@oracle.com>
wrote:
> * 335: *Deprecate the Nashorn JavaScript Engine*
>
Hooray, more built in features going away! So first we have the issue of
XML APIs being removed from the base (which, as far as I can tell, means
you either have to add special command line flags to re-enable or you need
to include the XML API libraries on the classpath/modulepath manually
anyways), and now we have no standard javax.script engine to use, either,
unless I missed something and now you can use Java itself as a scripting
engine. I'm starting to think that with Log4j 3, we'll need to move some
features that depend on non-base APIs into separate modules where possible,
or we're going to need to get creative with our build system to avoid third
party dependencies in log4j-core (jar shading is always an option). The
script family of plugins may be one such plugin. We already had several
pain points around things like JNDI with Android in the past, and I think
this will only get worse with future Java releases and further
modularization.
> JDK-8202088 <https://bugs.openjdk.java.net/browse/JDK-8202088> :
> Japanese New Era Implementation
>
We had locale-related date test failures in the past when JDK 9 was in
development. Is this anything to worry about?
--
Matt Sicker <bo...@gmail.com>