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

2021-11-22 Thread Richard N. Hillegas (Jira)


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

Richard N. Hillegas commented on DERBY-7126:


Attaching derby-7126-03-aa-mention-java.security.manager.diff. This patch adds 
a new server diagnostic message which is raised when the SecurityManager cannot 
be installed. The message appears when the user tries to boot a server (on JDK 
18) according to our current documentation:

{noformat}
Mon Nov 22 12:01:21 PST 2021 : Could not install a SecurityManager. You may 
need to set -Djava.security.manager=allow on your java command line:
 The Security Manager is deprecated and will be removed in a future release
{noformat}

I will run tests on JDK 11 to make sure that there are no surprises. 

Touches the following files:

{noformat}
M   
java/org.apache.derby.server/org/apache/derby/drda/NetworkServerControl.java
M   
java/org.apache.derby.server/org/apache/derby/loc/drda/messages.properties
{noformat}


> Make it possible to build and test Derby cleanly with OpenJDK 18
> 
>
> Key: DERBY-7126
> URL: https://issues.apache.org/jira/browse/DERBY-7126
> 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_7126_A.java, DERBY_7126_B.java, dcl_emc2sm.jar, 
> derby-7126-01-aa-regenerateSignedJars.diff, 
> derby-7126-02-aa-suppressDeprecationWarnings.diff, 
> derby-7126-03-aa-mention-java.security.manager.diff
>
>
> Releases of Open JDK 18 can be found at https://jdk.java.net/178. 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.20.1#820001)


[jira] [Updated] (DERBY-7126) Make it possible to build and test Derby cleanly with OpenJDK 18

2021-11-22 Thread Richard N. Hillegas (Jira)


 [ 
https://issues.apache.org/jira/browse/DERBY-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard N. Hillegas updated DERBY-7126:
---
Attachment: derby-7126-03-aa-mention-java.security.manager.diff

> Make it possible to build and test Derby cleanly with OpenJDK 18
> 
>
> Key: DERBY-7126
> URL: https://issues.apache.org/jira/browse/DERBY-7126
> 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_7126_A.java, DERBY_7126_B.java, dcl_emc2sm.jar, 
> derby-7126-01-aa-regenerateSignedJars.diff, 
> derby-7126-02-aa-suppressDeprecationWarnings.diff, 
> derby-7126-03-aa-mention-java.security.manager.diff
>
>
> Releases of Open JDK 18 can be found at https://jdk.java.net/178. 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.20.1#820001)


Re: [External] : Re: JDK 18 Early-Access builds 23 are available

2021-11-22 Thread Rick Hillegas

Hi David and Deepak,

The Derby community has not figured out how we are going to handle this 
latest release of the Open JDK. Please see the discussion on 
https://issues.apache.org/jira/browse/DERBY-7126 for more details.


At this time, we cannot recommend that Derby-powered applications use 
any version of the JDK from JDK 18 onward. This is true for all versions 
of Derby going back 15 years. This is due to recent security regressions 
introduced into the JDK. The latest regression, introduced into build 
18-ea+23-1525, is discussed in a security-dev email thread titled "new 
hurdle for applications which programatically install a 
SecurityManager". It is possible that these regressions will be 
backported to previous JDK release families. In that case, we will not 
be able to recommend that Derby-powered applications use those JDKs 
either. We can only hope that these regressions are not backported to 
JDK 8 and JDK 11.


I am afraid that we cannot provide you any more feedback until we sort 
this out.


Regards,
-Rick


On 11/16/21 8:48 PM, Deepak Damodaran wrote:

Hi Rick,

Link to the latest builds was specified in the email as [5].
This is the link - https://jdk.java.net/18/

Thanks,
Deepak


On 17/11/21, 2:30 AM, "Rick Hillegas"  wrote:

 Thanks for the heads-up, David. The JEP 411 work will almost certainly
 be a disruption for Derby. Is there a particular build which you want us
 to test? I didn't see a link to the latest builds in your email. Rory
 used to include those links.

 Thanks,
 -Rick

 On 11/16/21 3:01 AM, david.delabas...@oracle.com wrote:
 > Hi Rick,
 >
 > I’m happy to announce that moving forward Oracle’s Java DevRel Team
 > will manage the Quality Outreach Program. I would like to thank Rory
 > for all the efforts he's put into this program and wish him all the
 > joy and happiness that retirement can bring! We have big shoes to fill
 > but we’re excited to continue building off the amazing structure Rory
 > has put in place.
 >
 >
 > The JDK 18 schedule is now known [1] with a feature freeze date
 > (Rampdown Phase One) less than 4 weeks away! This time, we have 2
 > important heads-ups, one related to JEP 411 (Deprecate the Security
 > Manager for Removal), and one related to JEP 416 (Reimplement Core
 > Reflection with Method Handles). We're asking your help to test and
 > confirm that your project works seamlessly now that those 2 JEPs are
 > integrated in the JDK 18 Early-Access builds.
 >
 > [1] https://openjdk.java.net/projects/jdk/18/
 >
 >
 > # JEP 411 - Deprecate the Security Manager for Removal
 >
 > Starting JDK 18 b21 [2], the default value of the
 > 'java.security.manager' system property is set to "disallow". This
 > means that any application or library that enables the Security
 > Manager by calling `System.setSecurityManager` will now have to
 > specify `-Djava.security.manager=allow` on the command-line in order
 > for that code to continue working as expected. This change was
 > originally targeted for JDK 17, but after some discussion/feedback
 > from the community, the change was delayed until JDK 18 [3].
 >
 > [2] https://bugs.openjdk.java.net/browse/JDK-8270380
 > [3] https://openjdk.java.net/jeps/411#Description
 >
 >
 > # JEP 416 - Reimplement Core Reflection with Method Handles
 >
 > JEP 416 [4] reimplements `java.lang.reflect.Method`,
 > `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` on top
 > of `java.lang.invoke` method handles. Making method handles the
 > underlying mechanism for reflection will reduce the maintenance and
 > development cost of both the `java.lang.reflect` and
 > `java.lang.invoke` APIs. This is solely an implementation change but
 > we encourage you to test your project to identify any behavior or
 > performance regressions.
 >
 > [4] https://openjdk.java.net/jeps/416
 >
 >
 > OpenJDK 18 Early-Access builds 23 are now available [5], and are
 > provided under the GNU General Public License v2, with the Classpath
 > Exception. The Release Notes are available [6].
 >
 > [5] 
https://urldefense.com/v3/__https://jdk.java.net/18/__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrOivCiqLQ$
 > [6] 
https://urldefense.com/v3/__https://jdk.java.net/18/release-notes__;!!ACWV5N9M2RV99hQ!Y2uUgfv_-S-aylTlnPXfoUTvzE0apOEYF1ZhBZM83KKhauMdDa-nqOxJ21WtGrN-iaadaQ$
 >
 >
 > # JEPs integrated to JDK 18, so far:
 >
 > - JEP 400: UTF-8 by Default https://openjdk.java.net/jeps/400
 > - JEP 408: Simple Web Server https://openjdk.java.net/jeps/408
 > - JEP 413: Code Snippets in Java API Documentation
 > https://openjdk.java.net/jeps/413
 > - JEP 416: Reimplement Core Reflection with Method Handles
 > https://openjdk.jav