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

From: Rick Hillegas 
Sent: Friday, June 18, 2021 7:19:09 PM
To: Rory Odonnell ; derby-dev@db.apache.org 
; d...@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 
>
> 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*
>>>  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 R

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*

[jira] [Commented] (DERBY-7110) Make it possible to build and test Derby cleanly with OpenJDK 17

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365646#comment-17365646
 ] 

ASF subversion and git services commented on DERBY-7110:


Commit 1890895 from Richard N. Hillegas in branch 'code/trunk'
[ https://svn.apache.org/r1890895 ]

DERBY-7110: Suppress warnings introduced by JEP 411; commit 
derby-7110-02-ab-suppressWarnings.diff.

> Make it possible to build and test Derby cleanly with OpenJDK 17
> 
>
> Key: DERBY-7110
> URL: https://issues.apache.org/jira/browse/DERBY-7110
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7110-01-aa-removeAngleBrackets.diff, 
> derby-7110-02-aa-suppressWarnings.diff
>
>
> Releases of Open JDK 17 can be found at https://jdk.java.net/17/. We should 
> adjust Derby as necessary so that it builds cleanly (including javadoc) and 
> tests cleanly with this version of the platform.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DERBY-7110) Make it possible to build and test Derby cleanly with OpenJDK 17

[Richard N. Hillegas (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365645#comment-17365645
 ] 

Richard N. Hillegas commented on DERBY-7110:


Tests passed cleanly against derby-7110-02-ab-suppressWarnings.diff on jar 
files compiled using Open JDK 17-ea+26-2439. The javadoc built cleanly too. The 
following experiments were run on those jars:

o Full tests with the classpath run on JDK 17.
o Full tests with the modulepath run on JDK 17.
o Full tests with the classpath run on JDK 11.
o Full tests with the modulepath run on JDK 11.


> Make it possible to build and test Derby cleanly with OpenJDK 17
> 
>
> Key: DERBY-7110
> URL: https://issues.apache.org/jira/browse/DERBY-7110
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7110-01-aa-removeAngleBrackets.diff, 
> derby-7110-02-aa-suppressWarnings.diff
>
>
> Releases of Open JDK 17 can be found at https://jdk.java.net/17/. We should 
> adjust Derby as necessary so that it builds cleanly (including javadoc) and 
> tests cleanly with this version of the platform.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DERBY-7110) Make it possible to build and test Derby cleanly with OpenJDK 17

[Richard N. Hillegas (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365540#comment-17365540
 ] 

Richard N. Hillegas commented on DERBY-7110:


Thanks, Jaikiran, that looks like the culprit.

> Make it possible to build and test Derby cleanly with OpenJDK 17
> 
>
> Key: DERBY-7110
> URL: https://issues.apache.org/jira/browse/DERBY-7110
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7110-01-aa-removeAngleBrackets.diff, 
> derby-7110-02-aa-suppressWarnings.diff
>
>
> Releases of Open JDK 17 can be found at https://jdk.java.net/17/. We should 
> adjust Derby as necessary so that it builds cleanly (including javadoc) and 
> tests cleanly with this version of the platform.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (DERBY-7110) Make it possible to build and test Derby cleanly with OpenJDK 17

[Jaikiran Pai (Jira)]

[ 
https://issues.apache.org/jira/browse/DERBY-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365510#comment-17365510
 ] 

Jaikiran Pai commented on DERBY-7110:
-

> 3) Adds a -quiet directive to the javadoc targets for the public API and the 
> demo docs. Some other change in 17-ea+26-2439 caused javadoc to spew extra 
> informational noise.

 

Perhaps this is the same thing as 
[https://mail.openjdk.java.net/pipermail/javadoc-dev/2021-June/003075.html?]

 

 

> Make it possible to build and test Derby cleanly with OpenJDK 17
> 
>
> Key: DERBY-7110
> URL: https://issues.apache.org/jira/browse/DERBY-7110
> Project: Derby
>  Issue Type: Task
>  Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Richard N. Hillegas
>Assignee: Richard N. Hillegas
>Priority: Major
> Attachments: derby-7110-01-aa-removeAngleBrackets.diff, 
> derby-7110-02-aa-suppressWarnings.diff
>
>
> Releases of Open JDK 17 can be found at https://jdk.java.net/17/. We should 
> adjust Derby as necessary so that it builds cleanly (including javadoc) and 
> tests cleanly with this version of the platform.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)