JDK 9 EA Build 170 is available on jdk.java.net

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

JDK 9 EA Build 170 is available on jdk.java.net

Rory O'Donnell Oracle, Dublin Ireland

Hi Mark, *

JDK 9 Early Access*  build 170  is available at the new location : -
jdk.java.net/9/

A summary of all the changes in this build are listed here
<http://download.java.net/java/jdk9/changes/jdk-9+170.html>.

Changes which were introduced since the last availability email that may
be of interest :

  * b168 - JDK-8175814: Update default HttpClient protocol version and
    optional request version
      o related to JEP 110  : HTTP/2 Client.
  * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
      o changes in command line options
  * b170 - JDK-8177153  : LambdaMetafactory has default
    constructorIncompatible change,
      o release note:  JDK-8180035

*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
mailing list *[1]

  * Proposal: Allow illegal reflective access by default in JDK 9

    In short, the existing "big kill switch" of the `--permit-illegal-access`
    option [1] will become the default behavior of the JDK 9 run-time system,
    though without as many warnings.  The current behavior of JDK 9, in which
    illegal reflective-access operations from code on the class path are not
    permitted, will become the default in a future release.  Nothing will
    change at compile time.


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

Reply | Threaded
Open this post in threaded view
|

Re: JDK 9 EA Build 170 is available on jdk.java.net

Rémy Maucherat
On Fri, May 19, 2017 at 5:03 AM, Rory O'Donnell <[hidden email]>
wrote:

>
> Hi Mark, *
>
> JDK 9 Early Access*  build 170  is available at the new location : -
> jdk.java.net/9/
>
> A summary of all the changes in this build are listed here <
> http://download.java.net/java/jdk9/changes/jdk-9+170.html>.
>
> Changes which were introduced since the last availability email that may
> be of interest :
>
>  * b168 - JDK-8175814: Update default HttpClient protocol version and
>    optional request version
>      o related to JEP 110  : HTTP/2 Client.
>  * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
>      o changes in command line options
>  * b170 - JDK-8177153  : LambdaMetafactory has default
>    constructorIncompatible change,
>      o release note:  JDK-8180035
>
> *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
> mailing list *[1]
>
>  * Proposal: Allow illegal reflective access by default in JDK 9
>
>    In short, the existing "big kill switch" of the
> `--permit-illegal-access`
>    option [1] will become the default behavior of the JDK 9 run-time
> system,
>    though without as many warnings.  The current behavior of JDK 9, in
> which
>    illegal reflective-access operations from code on the class path are not
>    permitted, will become the default in a future release.  Nothing will
>    change at compile time.
>
>
> Rgds,Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
>
> I got a message that Tomcat was again broken on Java 9. Indeed, testing
175, Tomcat 9 now needs JAVA_OPTS="--add-modules java.xml.ws" to run
(otherwise that module isn't available).

Also, although "illegal" access is enabled by default, it now outputs this:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.catalina.loader.WebappClassLoaderBase
(file:/home/remm/Work/jbossweb/apache-tomcat-trunk/output/build/lib/catalina.jar)
to field java.lang.Thread.threadLocals
WARNING: Please consider reporting this to the maintainers of
org.apache.catalina.loader.WebappClassLoaderBase
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release

We've had to add workarounds for years due to the JDK having issues, and
some still being there (direct byte buffers still won't GC properly and
need creative reflection tricks).

Rémy