JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Hi Mark,

*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] 
htt

Re: JDK 17 is now in Rampdown Phase One

[Martin Grigorov]

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439 on
Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
wrote:

>
> Hi Mark,
>
> *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/15Rampdown Phase Two
>   o 2021/08/05Initial Release Candidate
>   o 2021/08/19Final Release Candidate
>   o 2021/09/14General 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<
> 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 thi

Re: JDK 17 is now in Rampdown Phase One

[Martin Grigorov]

Same for JDK 18-ea+1-7 !

Regards,
Martin

On Mon, Jun 14, 2021 at 2:35 PM Martin Grigorov 
wrote:

> Hi Rory,
>
> Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439
> on Linux x86_64 and aarch64 !
>
> Regards,
> Martin
>
> On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
> wrote:
>
>>
>> Hi Mark,
>>
>> *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/15Rampdown Phase Two
>>   o 2021/08/05Initial Release Candidate
>>   o 2021/08/19Final Release Candidate
>>   o 2021/09/14General 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<
>> 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 e

Re: JDK 17 is now in Rampdown Phase One

[Rick Hillegas]

Hi Rory,

Copying the Tomcat developer community since this issue probably affects 
them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation 
of Security Manager classes and methods, undoubtedly the consequence of 
JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, 
embraced the Security Manager early on. Permissions checks were 
rototilled across the whole code base. Our distributions ship with 
several template policy files, which we encourage users to customize for 
their environments. The "Configuring Java Security" section of our 
Security Guide explains how to do this 
(https://db.apache.org/derby/docs/10.15/security/index.html).


My build only reported the first 100 warnings. It is likely that there 
are many more.


Having read the summary of JEP 411, I understand the motivation for this 
change. However, I don't understand how applications like Tomcat and 
Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
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 J

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Thanks again Martin!

On 14/06/2021 12:35, Martin Grigorov wrote:

Hi Rory,

Apache Tomcat's build and tests pass successfully with JDK 17-ea+26-2439 on
Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell 
wrote:


Hi Mark,

*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/15Rampdown Phase Two
   o 2021/08/05Initial Release Candidate
   o 2021/08/19Final Release Candidate
   o 2021/09/14General 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://urldefense.com/v3/__https://jdk.java.net/17*__;Kg!!GqivPVa7Brio!J84U6mJZmIe4LbezWVAJTgpq7Y_V-wJ6iBFuaYtDcLJJeYcpN9y2Vb4L8fs3H4Ac_kk$
 


   * 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://urldefense.com/v3/__https://jdk.java.net/17/release-notes__;!!GqivPVa7Brio!J84U6mJZmIe4LbezWVAJTgpq7Y_V-wJ6iBFuaYtDcLJJeYcpN9y2Vb4L8fs3bMx3XlI$
 <
https://urldefense.com/v3/__https://jdk.java.net/17/release-notes__;!!GqivPVa7Brio!J84U6mJZmIe4LbezWVAJTgpq7Y_V-wJ6iBFuaYtDcLJJeYcpN9y2Vb4L8fs3bMx3XlI$
 >

   * 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 a

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Excellent, thank you.
On 14/06/2021 13:47, Martin Grigorov wrote:

Same for JDK 18-ea+1-7 !

Regards,
Martin

On Mon, Jun 14, 2021 at 2:35 PM Martin Grigorov > wrote:


Hi Rory,

Apache Tomcat's build and tests pass successfully with
JDK 17-ea+26-2439 on Linux x86_64 and aarch64 !

Regards,
Martin

On Mon, Jun 14, 2021 at 12:56 PM Rory O'Donnell
mailto:rory.odonn...@oracle.com>> wrote:


Hi Mark,

*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
        385>in 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 Classp

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory O'Donnell]

Hi Rick,

Excellent feedback , I suggest you send this information to the 
security-dev [1] mailing list to demonstrate the impact

it is having on you and others. Make sure to subscribe first.

Rgds,Rory

[1] security-...@openjdk.java.net 

On 14/06/2021 16:43, Rick Hillegas wrote:

Hi Rory,

Copying the Tomcat developer community since this issue probably 
affects them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the deprecation 
of Security Manager classes and methods, undoubtedly the consequence 
of JEP 411 (https://openjdk.java.net/jeps/411). Derby, like Tomcat, 
embraced the Security Manager early on. Permissions checks were 
rototilled across the whole code base. Our distributions ship with 
several template policy files, which we encourage users to customize 
for their environments. The "Configuring Java Security" section of our 
Security Guide explains how to do this 
(https://urldefense.com/v3/__https://db.apache.org/derby/docs/10.15/security/index.html__;!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBh9kcdocM$ 
).


My build only reported the first 100 warnings. It is likely that there 
are many more.


Having read the summary of JEP 411, I understand the motivation for 
this change. However, I don't understand how applications like Tomcat 
and Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
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://urldefense.com/v3/__https://jdk.java.net/17*__;Kg!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBhLKySzR0$ 



 * These early-access , open-source builds are provided under the
 o GNU Ge

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rick Hillegas]

Hi Rory,

Derby builds and tests cleanly against Open JDK 17-ea+26-2439 after 
suppressing the deprecation warnings introduced by JEP 411. Our 
experience is documented in a security-...@openjdk.java.net email thread 
titled "blizzard of deprecation warnings related to JEP 411" and in 
comments dated between 2021-06-15 and 2021-06-18 on 
https://issues.apache.org/jira/browse/DERBY-7110.


On 6/14/21 11:20 AM, Rory O'Donnell wrote:

Hi Rick,

Excellent feedback , I suggest you send this information to the 
security-dev [1] mailing list to demonstrate the impact

it is having on you and others. Make sure to subscribe first.

Rgds,Rory

[1] security-...@openjdk.java.net 

On 14/06/2021 16:43, Rick Hillegas wrote:

Hi Rory,

Copying the Tomcat developer community since this issue probably 
affects them as well.


When I tried to build Derby with the Rampdown Phase One build of open 
JDK 17 (17-ea+26-2439), I saw many warnings related to the 
deprecation of Security Manager classes and methods, undoubtedly the 
consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby, 
like Tomcat, embraced the Security Manager early on. Permissions 
checks were rototilled across the whole code base. Our distributions 
ship with several template policy files, which we encourage users to 
customize for their environments. The "Configuring Java Security" 
section of our Security Guide explains how to do this 
(https://urldefense.com/v3/__https://db.apache.org/derby/docs/10.15/security/index.html__;!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBh9kcdocM$ 
).


My build only reported the first 100 warnings. It is likely that 
there are many more.


Having read the summary of JEP 411, I understand the motivation for 
this change. However, I don't understand how applications like Tomcat 
and Derby are supposed to respond to the new blizzard of deprecation 
warnings. For instance, is there a replacement for the deprecated 
AccessController.doPrivileged() method? Or are we supposed to simply 
disable this deprecation check? Is there some security expert whom we 
should contact about this change and how to mitigate its effects?


Thanks,
-Rick


On 6/14/21 2:18 AM, Rory O'Donnell wrote:


Hi Rick,
*
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*

Re: [External] : Re: JDK 17 is now in Rampdown Phase One

[Rory Odonnell]

Many thanks Rick, glad to hear all is well again!

Reds,Rory

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Rick Hillegas 
Sent: Friday, June 18, 2021 7:19:09 PM
To: Rory Odonnell ; derby-...@db.apache.org 
; dev@tomcat.apache.org 
Cc: Dalibor Topic ; Balchandra Vaidya 
; Deepak Damodaran 
Subject: Re: [External] : Re: JDK 17 is now in Rampdown Phase One

Hi Rory,

Derby builds and tests cleanly against Open JDK 17-ea+26-2439 after
suppressing the deprecation warnings introduced by JEP 411. Our
experience is documented in a security-...@openjdk.java.net email thread
titled "blizzard of deprecation warnings related to JEP 411" and in
comments dated between 2021-06-15 and 2021-06-18 on
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/DERBY-7110__;!!GqivPVa7Brio!McghnfCCxtVZFIPEzbD7Uxb10QRjioV2hX5tYh3mbMhBIjtXLOkYmBVY53aFPl8BDjs$
 .

On 6/14/21 11:20 AM, Rory O'Donnell wrote:
> Hi Rick,
>
> Excellent feedback , I suggest you send this information to the
> security-dev [1] mailing list to demonstrate the impact
> it is having on you and others. Make sure to subscribe first.
>
> Rgds,Rory
>
> [1] security-...@openjdk.java.net <mailto:security-...@openjdk.java.net>
>
> On 14/06/2021 16:43, Rick Hillegas wrote:
>> Hi Rory,
>>
>> Copying the Tomcat developer community since this issue probably
>> affects them as well.
>>
>> When I tried to build Derby with the Rampdown Phase One build of open
>> JDK 17 (17-ea+26-2439), I saw many warnings related to the
>> deprecation of Security Manager classes and methods, undoubtedly the
>> consequence of JEP 411 (https://openjdk.java.net/jeps/411). Derby,
>> like Tomcat, embraced the Security Manager early on. Permissions
>> checks were rototilled across the whole code base. Our distributions
>> ship with several template policy files, which we encourage users to
>> customize for their environments. The "Configuring Java Security"
>> section of our Security Guide explains how to do this
>> (https://urldefense.com/v3/__https://db.apache.org/derby/docs/10.15/security/index.html__;!!GqivPVa7Brio!Ir7H5RCIuIIcRhganretmYcvHoP432X-jV4dVUNlqO1EmvYkTvkdZvEBdtBh9kcdocM$
>> ).
>>
>> My build only reported the first 100 warnings. It is likely that
>> there are many more.
>>
>> Having read the summary of JEP 411, I understand the motivation for
>> this change. However, I don't understand how applications like Tomcat
>> and Derby are supposed to respond to the new blizzard of deprecation
>> warnings. For instance, is there a replacement for the deprecated
>> AccessController.doPrivileged() method? Or are we supposed to simply
>> disable this deprecation check? Is there some security expert whom we
>> should contact about this change and how to mitigate its effects?
>>
>> Thanks,
>> -Rick
>>
>>
>> On 6/14/21 2:18 AM, Rory O'Donnell wrote:
>>>
>>> Hi Rick,
>>> *
>>> 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/15Rampdown Phase Two
>>>  o 2021/08/05Initial Release Candidate
>>>  o 2021/08/19Final Release Candidate
>>>  o 2021/09/14General 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*<https://openjdk.java.net/jeps/411>
>>>  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*<https://openjdk.java.net/jeps/407>
>>>  o Removal the Remote Method Invocation (RMI) Activation mechanism,
>>>while preserving the rest of RMI.
>>>  o It was deprecated for removal by JEP
>>>385<https://openjdk.java.net/jeps/385>in Java SE 15.
>>>  * *JEP 403: **Strongly Encapsulate JDK
>