From ioi.lam at oracle.com Tue Sep 3 15:53:20 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 3 Sep 2019 08:53:20 -0700 Subject: Result: New JDK Reviewer: Yumin Qi In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com> References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com> Message-ID: <4c43e357-ba39-ea64-5669-f0a893a6d27e@oracle.com> Voting for Yumin Qi [1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks - Ioi [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003265.html From stanislav.smirnov at oracle.com Fri Sep 6 19:10:02 2019 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Fri, 6 Sep 2019 15:10:02 -0400 Subject: jdk/submit repo reset In-Reply-To: <2702D8EE-C3C9-43CC-947D-ED8B391ED311@oracle.com> References: <2702D8EE-C3C9-43CC-947D-ED8B391ED311@oracle.com> Message-ID: <2F83CD7F-48DC-44F7-B4D0-DE2DBE5E0AB2@oracle.com> Hello, The jdk/submit repository was reset. A new repository was created today with no branches except from the default one. http://hg.openjdk.java.net/jdk/submit/ In order to continue using the submit repo please make a fresh clone and run ?hg out? before push. Also an archive of the old jdk/submit was created http://hg.openjdk.java.net/jdk/submit-archive-2019-09-06/ Please continue using the system and report any issues/ask questions related to the jdk/submit repo using ops at openjdk.java.net . Best regards, Stanislav Smirnov > On Jul 10, 2019, at 5:49 PM, Stanislav Smirnov wrote: > > Hello, > > The jdk/submit repository was reset. > Back in December 2018 [1] it was decided to start resetting it regularly. > > A new repository was created today with no branches except from the default one. > > http://hg.openjdk.java.net/jdk/submit/ > > In order to continue using the submit repo please make a fresh clone and run ?hg out? before push. > > Also an archive of the old jdk/submit was created > > http://hg.openjdk.java.net/jdk/submit-archive-2019-07-10/ > > Please continue using the system and report any issues/ask questions related to the jdk/submit repo using ops at openjdk.java.net . > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002319.html > > > Best regards, > Stanislav Smirnov > > > > From alex.buckley at oracle.com Fri Sep 6 21:58:51 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 6 Sep 2019 14:58:51 -0700 Subject: Preview APIs for preview features -- JDK 14+ In-Reply-To: References: Message-ID: <3d10ebdc-9a35-2942-5c80-b10b6f10f3b6@oracle.com> On 8/5/2019 11:23 AM, Alex Buckley wrote: > Preview language features such as text blocks (JEP 355) sometimes depend > on associated APIs in `java.*` (e.g. String::stripIndent). If a > developer enables preview features at compile time and explicitly calls > APIs associated with the preview feature, then all is well; but if a > developer _doesn't_ enable preview features and still calls those APIs, > then Java compilers need to shout loudly about how the API could change > or disappear in future, depending on the fate of the preview feature. ... > Joe Darcy has proposed that associated APIs are annotated explicitly > (e.g. @java.lang.annotation.PreviewFeature) so that their use can be > detected at compile time. Further internal discussion led us to question if it's appropriate to indicate associated APIs via an annotation, even a Java SE annotation like @java.lang.annotation.PreviewFeature. The short answer is "no". It will be a compile-time error to call an associated API when preview features are disabled, and the authority for such an error should start and end with the JLS. We do not want the presence of an annotation on one piece of code to appear responsible for the generation of a compile-time error in another piece of code -- avoiding that slippery slope is probably the most consistent piece of stewardship on these lists over the years. Part of the justification for an annotation was documentary -- to trigger javadoc into rendering the annotated API in some striking "SUBJECT TO CHANGE! USE WITH CAUTION!" way. However, a new javadoc tag, `@preview`, can do this just fine. The tag even has an advantage of sorts over the annotation: the tag, while not technically limited to doc comments for Java SE APIs, will be hard to use outside the JDK because of the need to configure javadoc just right; the annotation, in contrast, could be applied easily to any code on the planet, with misleading results. Platform enthusiasts will know that the Java SE 13 Edition of the JLS recently shared with the JSR-388 Expert Group [1] includes a new section, 1.5 "Preview Features". For the Java SE 14 Edition onwards, JLS 1.5 will enumerate the relevant APIs as well as the preview features themselves. It will also specify the compile-time error and the non-suppressible warning that are due, respectively, when said APIs are used with preview features disabled and with preview features enabled. Alex [1] https://mail.openjdk.java.net/pipermail/java-se-spec-experts/2019-August/000150.html From shade at redhat.com Sat Sep 7 06:52:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 7 Sep 2019 08:52:23 +0200 Subject: jdk/submit repo reset In-Reply-To: <2F83CD7F-48DC-44F7-B4D0-DE2DBE5E0AB2@oracle.com> References: <2702D8EE-C3C9-43CC-947D-ED8B391ED311@oracle.com> <2F83CD7F-48DC-44F7-B4D0-DE2DBE5E0AB2@oracle.com> Message-ID: <7131de43-3f49-8a99-8dad-1d02fb6ec156@redhat.com> On 9/6/19 9:10 PM, Stanislav Smirnov wrote: > The jdk/submit repository was reset. > A new repository was created today with no branches except from the default one. > > http://hg.openjdk.java.net/jdk/submit/ > > In order to continue using the submit repo please make a fresh clone and run ?hg out? before push. As usual, workspace tarball regenerated here: https://builds.shipilev.net/workspaces/jdk-submit.tar.xz -- Thanks, -Aleksey From ksrinifmt at gmail.com Sun Sep 8 22:18:09 2019 From: ksrinifmt at gmail.com (Kumar Srinivasan) Date: Sun, 8 Sep 2019 15:18:09 -0700 Subject: CFV: New JDK Reviewer: Yumin Qi In-Reply-To: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com> References: <180998e7-b0b2-8339-d8c4-9d00f8e629cc@oracle.com> Message-ID: Vote:yes On Thu, Aug 15, 2019, 5:11 PM Ioi Lam wrote: > I hereby nominate Yumin Qi (minqi) to JDK Project Reviewer. > > Yumin is currently a JDK Project Committer and a member of the HotSpot > Group [3]. He has contributed over 50 changesets [1]. > > Yumin has primarily worked on Hotspot Runtime and Serviceability areas. > He is now working on the JWarmup JEP [2] to help improve application > peak load time performance. Yumin also worked on AppCDS (Application > Class Data Sharing) and made contribution to the feature. He is an > active member in the OpenJDK community. > > Only current JDK Reviewers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [4]. > > [1] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=author%28minqi%29+and+not+merge%28%29 > [2] http://openjdk.java.net/jeps/8203832 > [3] http://openjdk.java.net/census > [4] http://openjdk.java.net/projects/#reviewer-vote > From paulcane at gmail.com Mon Sep 9 12:57:31 2019 From: paulcane at gmail.com (Paul Cane) Date: Mon, 9 Sep 2019 13:57:31 +0100 Subject: Openjdk 13 RC2 Message-ID: Any news on the RC2 pre-release that was due late in August? Please point me at another list if I should be looking elsewhere for this type of information. From mark.reinhold at oracle.com Mon Sep 9 17:19:18 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 09 Sep 2019 10:19:18 -0700 Subject: Openjdk 13 RC2 In-Reply-To: References: Message-ID: <20190909101918.923064727@eggemoggin.niobe.net> 2019/9/9 5:57:31 -0700, paulcane at gmail.com: > Any news on the RC2 pre-release that was due late in August? Please point > me at another list if I should be looking elsewhere for this type of > information. We only publish new Release Candidate builds if they?re needed, in order to fix a super-critical bug. The ?Final Release Candidate? milestone in the schedule [1] simply means that whatever RC build that we have at that time will be the final GA (General Availability) build unless something goes fantastically wrong, in which case the GA date would be at risk. So, at this point, we expect the GA build for JDK 13 to be the first and only RC build, 33, which was promoted on 9 August [2][3]. I?ll make a note to clarify this in JEP 3 [4]. - Mark [1] https://openjdk.java.net/projects/jdk/13/#Schedule [2] https://hg.openjdk.java.net/jdk/jdk13/log?rev=tag%28%22jdk-13%2B33%22%29 [3] https://jdk.java.net/13/ [4] https://openjdk.java.net/jeps/3 From goetz.lindenmaier at sap.com Tue Sep 10 10:01:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Sep 2019 10:01:54 +0000 Subject: [ping]: 8227717: Give more helpful NullPointerException messages and add flag -XX:ShowCodeDetailsInExceptionMessages Message-ID: Hi Joe, could you please give advice how to proceed with the CSR? Thanks, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 5. August 2019 10:00 > To: Joe Darcy > Cc: jdk-dev ; Coleen Phillimore > (coleen.phillimore at oracle.com) > Subject: 8227717: Give more helpful NullPointerException messages and add > flag -XX:ShowCodeDetailsInExceptionMessages > > Hi Joe, > > I have changed the naming of the flag. > > What else should I add to the CSR? What is still missing? > > > Not that the CSR covers a particular snapshot of a change so if there > > are specific interfaces being modified, just referring to a JEP is not > > sufficient since the JEP can be changed independently of the CSR. > > In particular, a JEP can be modified after a CSR is approved. > Shouldn't the CSR cover what is submitted to the code base? I.e., > the final state? > What should I add to the text to cover this? Do you want to know more > about the message texts that will be generated? Should I explain > in more detail which exceptions will get a message added? Should > I describe the changes to NullPointerException.java? > > Best regards, > Goetz. From shade at redhat.com Tue Sep 10 16:24:37 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Sep 2019 18:24:37 +0200 Subject: JDK-8010500 Message-ID: Hi, Is there any reason why this issue is confidential today? https://bugs.openjdk.java.net/browse/JDK-8010500 Changeset implies this is a simple NULL check fix: https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 -- Thanks, -Aleksey From philip.race at oracle.com Tue Sep 10 16:30:21 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 10 Sep 2019 09:30:21 -0700 Subject: JDK-8010500 In-Reply-To: References: Message-ID: <5D77CF9D.3070804@oracle.com> Yes. Unfortunately confidential information was put in the description field and that can't be hidden if public. -phil. On 9/10/19, 9:24 AM, Aleksey Shipilev wrote: > Hi, > > Is there any reason why this issue is confidential today? > https://bugs.openjdk.java.net/browse/JDK-8010500 > > Changeset implies this is a simple NULL check fix: > https://hg.openjdk.java.net/jdk/jdk/rev/4d686766ac23 > From shade at redhat.com Tue Sep 10 16:37:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 10 Sep 2019 18:37:51 +0200 Subject: JDK-8010500 In-Reply-To: <5D77CF9D.3070804@oracle.com> References: <5D77CF9D.3070804@oracle.com> Message-ID: <32ca978b-80d0-186b-e9fc-36ec3191ad46@redhat.com> On 9/10/19 6:30 PM, Philip Race wrote: > Yes. Unfortunately confidential information was put in the description field and that can't be > hidden if public. Pity. Thanks for looking into it. -- Thanks, -Aleksey From somkadam76 at gmail.com Thu Sep 12 06:43:15 2019 From: somkadam76 at gmail.com (Somshekar C Kadam) Date: Thu, 12 Sep 2019 12:13:15 +0530 Subject: Java Httpurlconnection In-Reply-To: References: <87r25ehi61.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Joe and Fransteik, FLoran. wanted to share this information with you, as the normal standard java 1.8 implements older HttpURLConnection API has lot design issues, see below link, newer HTTP CLient is implemented in Java 11 and is standard. http://openjdk.java.net/jeps/110#Motivation Also attached PDF for the same. This adds to reason to the delay what I am seeing. @Joe this may help others so mailing this. Regards Somshekar C Kadam 9036660538 From mark.reinhold at oracle.com Tue Sep 17 17:11:04 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 17 Sep 2019 10:11:04 -0700 (PDT) Subject: Java 13 / JDK 13: General Availability Message-ID: <20190917171104.773292C0010@eggemoggin.niobe.net> JDK 13, the reference implementation of Java 13, is now Generally Available. We?ve identified no P1 bugs since we promoted build 33 over five weeks ago so that?s the official GA release, ready for production use. GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/13 Builds from other implementors will no doubt be available soon. This release includes five features [1]: 350: Dynamic CDS Archives 351: ZGC: Uncommit Unused Memory 353: Reimplement the Legacy Socket API 354: Switch Expressions (Preview) 355: Text Blocks (Preview) along with, as usual, hundreds of smaller enhancements and thousands of bug fixes. Thanks to everyone who contributed to JDK 13, whether by creating features or enhancements, fixing bugs, or downloading and testing the early-access builds. - Mark [1] https://openjdk.java.net/projects/jdk/13 From paulcane at gmail.com Wed Sep 18 14:19:10 2019 From: paulcane at gmail.com (Paul Cane) Date: Wed, 18 Sep 2019 15:19:10 +0100 Subject: Java 13 / JDK 13: General Availability Message-ID: So is the GA literally build 33 or has it been rebuilt for labelling whatever? From mark.reinhold at oracle.com Wed Sep 18 17:45:04 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 18 Sep 2019 10:45:04 -0700 Subject: Java 13 / JDK 13: General Availability In-Reply-To: References: Message-ID: <20190918104504.127198578@eggemoggin.niobe.net> 2019/9/18 7:19:10 -0700, Paul Cane : > So is the GA literally build 33 or has it been rebuilt for labelling > whatever? The GA release is, precisely, build 33. There was no rebuild; if there had been, then the GA release would have been build 34. We don?t call any build a ?release candidate? unless we think, at the time it?s published, that those exact bits have a good chance of being the final GA release. - Mark From sam.thomas at broadcom.com Wed Sep 18 18:47:09 2019 From: sam.thomas at broadcom.com (Sam Thomas) Date: Wed, 18 Sep 2019 11:47:09 -0700 Subject: Bytecode Instrumentation and Class Loading. Message-ID: Hi, I'm trying to understand if a class will load as soon as all the transformers return. The aim is to get a class reference of a class I have seen in my transformer. I'm currently using Class.forName(). Also if there is way to get the same without triggering class loading - if the class is not loaded return a null reference. I ask this because there is a scenario where there are two agents on JBoss where one asks for the class reference using Class.forName() and the other went and performed a redefineClass() on it and I end up getting a Failed to define class. Thanks ./Sam From daniel.daugherty at oracle.com Wed Sep 18 20:26:15 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 18 Sep 2019 16:26:15 -0400 Subject: Bytecode Instrumentation and Class Loading. In-Reply-To: References: Message-ID: <02f974fc-37cb-ca65-0596-30b2a1fd3feb@oracle.com> Forwarding this to the serviceability-dev at ... alias and Bcc'ing jdk-dev at ... which is a really broad alias... Dan On 9/18/19 2:47 PM, Sam Thomas wrote: > Hi, > > I'm trying to understand if a class will load as soon as all the > transformers return. The aim is to get a class reference of a class I have > seen in my transformer. > I'm currently using Class.forName(). > > Also if there is way to get the same without triggering class loading - if > the class is not loaded return a null reference. I ask this because there > is a scenario where there are two agents on JBoss where one asks for the > class reference using Class.forName() and the other went and performed a > redefineClass() on it and I end up getting a Failed to define class. > > Thanks > ./Sam From mark.reinhold at oracle.com Tue Sep 24 19:37:02 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Sep 2019 12:37:02 -0700 (PDT) Subject: Proposed schedule for JDK 14 Message-ID: <20190924193702.39FB4307BCB@eggemoggin.niobe.net> With JDK 13 out the door, here?s a proposed schedule for JDK 14: 2019/12/12 Rampdown Phase One 2020/01/16 Rampdown Phase Two 2020/02/06 Initial Release Candidate 2020/02/20 Final Release Candidate 2020/03/17 General Availability The phases are defined in JEP 3 [1]. Comments on this proposal from JDK Committers and Reviewers [2] are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Tuesday, 1 October, or if they?re raised and satisfactorily answered, then per the JEP 2.0 process proposal [3] this will be the schedule for JDK 14. - Mark [1] https://openjdk.java.net/jeps/3 [2] https://openjdk.java.net/census#jdk [3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From alex.buckley at oracle.com Tue Sep 24 22:54:57 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 24 Sep 2019 15:54:57 -0700 Subject: Preview APIs for preview features -- JDK 14+ In-Reply-To: <3d10ebdc-9a35-2942-5c80-b10b6f10f3b6@oracle.com> References: <3d10ebdc-9a35-2942-5c80-b10b6f10f3b6@oracle.com> Message-ID: <613dd6ab-5bb3-c5e6-9e06-8fe97acdfebf@oracle.com> On 9/6/2019 2:58 PM, Alex Buckley wrote: > Platform enthusiasts will know that the Java SE 13 Edition of the JLS > recently shared with the JSR-388 Expert Group includes a new > section, 1.5 "Preview Features". For the Java SE 14 Edition onwards, JLS > 1.5 will enumerate the relevant APIs as well as the preview features > themselves. It will also specify the compile-time error and the > non-suppressible warning that are due, respectively, when said APIs are > used with preview features disabled and with preview features enabled. I have updated JEP 12 "Preview Language and VM Features" to embody the error / non-suppressible-warning policy for use of "essential" APIs: http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs There is a corresponding JLS change, and a CSR for javac's new behavior: https://bugs.openjdk.java.net/browse/JDK-8231433 https://bugs.openjdk.java.net/browse/JDK-8231411 In the JDK sandbox, Jan and Jon have been working on the `@preview` tag for javadoc, and using it to replace `@Deprecated(forRemoval=true, since="13")` on API elements like String::stripIndent that are essential for text blocks: http://hg.openjdk.java.net/jdk/sandbox/rev/ee07de0d2c16 Everything is coming together to support whichever preview features are deemed worthy for JDK 14! Alex From bruno.borges at gmail.com Wed Sep 25 06:22:38 2019 From: bruno.borges at gmail.com (Bruno Borges) Date: Tue, 24 Sep 2019 23:22:38 -0700 Subject: Proposed schedule for JDK 14 In-Reply-To: <20190924193702.39FB4307BCB@eggemoggin.niobe.net> References: <20190924193702.39FB4307BCB@eggemoggin.niobe.net> Message-ID: March 17, 2020 is St. Patrick's Day. That'd be a perfect day to celebrate a GA release :-) On Tue, Sep 24, 2019 at 12:38 PM wrote: > With JDK 13 out the door, here?s a proposed schedule for JDK 14: > > 2019/12/12 Rampdown Phase One > 2020/01/16 Rampdown Phase Two > 2020/02/06 Initial Release Candidate > 2020/02/20 Final Release Candidate > 2020/03/17 General Availability > > The phases are defined in JEP 3 [1]. > > Comments on this proposal from JDK Committers and Reviewers [2] are > welcome, as are reasoned objections. If no such objections are raised by > 23:00 UTC next Tuesday, 1 October, or if they?re raised and satisfactorily > answered, then per the JEP 2.0 process proposal [3] this will be the > schedule for JDK 14. > > - Mark > > > [1] https://openjdk.java.net/jeps/3 > [2] https://openjdk.java.net/census#jdk > [3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From mark.reinhold at oracle.com Wed Sep 25 22:22:20 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 25 Sep 2019 15:22:20 -0700 (PDT) Subject: JEP proposed to target JDK 14: 358: Helpful NullPointerExceptions Message-ID: <20190925222220.8DCD03084DA@eggemoggin.niobe.net> The following JEP is proposed to target JDK 14: 358: Helpful NullPointerExceptions https://openjdk.java.net/jeps/358 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Wednesday, 2 October, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 14. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From bradford.wetmore at oracle.com Wed Sep 25 23:34:06 2019 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 25 Sep 2019 16:34:06 -0700 Subject: Java Httpurlconnection In-Reply-To: References: <87r25ehi61.fsf@oldenburg2.str.redhat.com> Message-ID: To follow up on JDK-8230704[1], this is 99% caused by lack of entropy in the system when initializing a SHA1PRNG SecureRandom PRNG instance (i.e. sun.security.provider.SecureRandom), which uses by default the following entropy source: securerandom.source=file:/dev/random and is a very well known problem[2]. Look closely to see if you are using a sun.security.provider.SecureRandom. This will block until it can complete. If you're ok with using /dev/urandom to initialize the seeder for SHA1PRNG, one workaround is to set: securerandom.source=file:/dev/./urandom Another is to use NativePRNG. Not sure if it's available on your ARMv7 impl. Good luck, Brad [1] https://bugs.openjdk.java.net/browse/JDK-8230704 [2] https://stackoverflow.com/questions/137212/how-to-solve-slow-java-securerandom There's a few bits of incorrect/misleading information here, but much of it is correct. On 9/11/2019 11:43 PM, Somshekar C Kadam wrote: > Hi Joe and Fransteik, FLoran. > > wanted to share this information with you, as the normal standard java 1.8 > implements older HttpURLConnection API has lot design issues, see below > link, > newer HTTP CLient is implemented in Java 11 and is standard. > > http://openjdk.java.net/jeps/110#Motivation > > Also attached PDF for the same. > This adds to reason to the delay what I am seeing. > @Joe this may help others so mailing this. > Regards > Somshekar C Kadam > 9036660538 > From somkadam76 at gmail.com Thu Sep 26 05:47:06 2019 From: somkadam76 at gmail.com (Somshekar C Kadam) Date: Thu, 26 Sep 2019 11:17:06 +0530 Subject: Java Httpurlconnection In-Reply-To: References: <87r25ehi61.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Brad, Thanks for the info will get back to you after verify Regards Somshekar On Thu, Sep 26, 2019, 5:04 AM Bradford Wetmore wrote: > To follow up on JDK-8230704[1], this is 99% caused by lack of entropy in > the system when initializing a SHA1PRNG SecureRandom PRNG instance (i.e. > sun.security.provider.SecureRandom), which uses by default the following > entropy source: > > securerandom.source=file:/dev/random > > and is a very well known problem[2]. Look closely to see if you are > using a sun.security.provider.SecureRandom. This will block until it > can complete. > > If you're ok with using /dev/urandom to initialize the seeder for > SHA1PRNG, one workaround is to set: > > securerandom.source=file:/dev/./urandom > > Another is to use NativePRNG. Not sure if it's available on your ARMv7 > impl. > > Good luck, > > Brad > > [1] https://bugs.openjdk.java.net/browse/JDK-8230704 > [2] > > https://stackoverflow.com/questions/137212/how-to-solve-slow-java-securerandom > There's a few bits of incorrect/misleading information here, but much > of it is correct. > > > > > On 9/11/2019 11:43 PM, Somshekar C Kadam wrote: > > Hi Joe and Fransteik, FLoran. > > > > wanted to share this information with you, as the normal standard java > 1.8 > > implements older HttpURLConnection API has lot design issues, see below > > link, > > newer HTTP CLient is implemented in Java 11 and is standard. > > > > http://openjdk.java.net/jeps/110#Motivation > > > > Also attached PDF for the same. > > This adds to reason to the delay what I am seeing. > > @Joe this may help others so mailing this. > > Regards > > Somshekar C Kadam > > 9036660538 > > > From mark.reinhold at oracle.com Fri Sep 27 14:58:17 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 27 Sep 2019 07:58:17 -0700 (PDT) Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports Message-ID: <20190927145817.0A366308904@eggemoggin.niobe.net> https://openjdk.java.net/jeps/362 - Mark From ChrisPhi at LGonQn.Org Fri Sep 27 16:39:37 2019 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Fri, 27 Sep 2019 12:39:37 -0400 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <20190927145817.0A366308904@eggemoggin.niobe.net> References: <20190927145817.0A366308904@eggemoggin.niobe.net> Message-ID: <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> On 27/09/19 10:58 AM, mark.reinhold at oracle.com wrote: > https://openjdk.java.net/jeps/362 > > - Mark > > Sad. Had to check to make sure it wasn't April 1. Chris From daniel.daugherty at oracle.com Fri Sep 27 16:41:49 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 27 Sep 2019 12:41:49 -0400 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> References: <20190927145817.0A366308904@eggemoggin.niobe.net> <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> Message-ID: On 9/27/19 12:39 PM, "Chris Phillips"@T O wrote: > On 27/09/19 10:58 AM, mark.reinhold at oracle.com wrote: >> https://openjdk.java.net/jeps/362 >> >> - Mark >> >> > Sad.? Had to check to make sure it wasn't April 1. > > Chris +1 ... :-( Dan From glaubitz at physik.fu-berlin.de Sat Sep 28 09:31:36 2019 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 28 Sep 2019 11:31:36 +0200 Subject: Taking up maintainership for SPARC - JEP-362 Message-ID: <7a270e82-b84f-c470-7bb0-86c2f7891b64@physik.fu-berlin.de> Hello! I have just been notified about JEP-362 [1] and would like to offer to be the official maintainer of the SPARC ports of OpenJDK. We're still using the Linux/SPARC port in Debian and therefore I would like to help keeping the port in as long as possible. There might also be users in the BSD world who are interested in the SPARC port. Thanks, Adrian > [1] https://openjdk.java.net/jeps/362 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From peter.firmstone at zeus.net.au Sat Sep 28 10:02:07 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 28 Sep 2019 20:02:07 +1000 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: References: <20190927145817.0A366308904@eggemoggin.niobe.net> <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> Message-ID: <5D8F2F9F.3040600@zeus.net.au> Crazy idea, builds should be tested on as many architectures as possible for debugging. I hope this gets downvoted. I've actually solved a lot of Java concurrency bugs using Solaris Sparc I couldn't with other architectures. That means without it, we would still be trying to solve those bugs. I don't know why Oracle doesn't release a developer workstation, with affordable developer licensing, so we can continue using Solaris for this purpose. There are just so many tools on Solaris develpers can utilise. Oracle really should start up the OpenSolaris project again too. Regards, Peter. On 28/09/2019 2:41 AM, Daniel D. Daugherty wrote: > On 9/27/19 12:39 PM, "Chris Phillips"@T O wrote: >> On 27/09/19 10:58 AM, mark.reinhold at oracle.com wrote: >>> https://openjdk.java.net/jeps/362 >>> >>> - Mark >>> >>> >> Sad. Had to check to make sure it wasn't April 1. >> >> Chris > > +1 ... :-( > > Dan From rfscholte at apache.org Sun Sep 29 13:08:19 2019 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 29 Sep 2019 15:08:19 +0200 Subject: Reproducible Properties Message-ID: Hi, the Maven team gets quite some requests regarding reproducible builds. Depending on the source we're able to fix it ourselves. However, in case of writing properties via Properties.store() we'll get unreproducible properties, because it includes the current Date().[1]. The only option we have right now is writing our own Properties writer. I'm kind of surprised not to find any related issue, but does it make sense to make the inclusion of the date optional? thanks, Robert Scholte [1] https://hg.openjdk.java.net/jdk/jdk/file/4107e5a422b6/src/java.base/share/classes/java/util/Properties.java#l924 From Alan.Bateman at oracle.com Sun Sep 29 14:57:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 29 Sep 2019 15:57:33 +0100 Subject: Reproducible Properties In-Reply-To: References: Message-ID: <235542e7-1b5d-0e42-19ac-1ef83dfd4710@oracle.com> On 29/09/2019 14:08, Robert Scholte wrote: > Hi, > > the Maven team gets quite some requests regarding reproducible builds. > Depending on the source we're able to fix it ourselves. > However, in case of writing properties via Properties.store() we'll > get unreproducible properties, because it includes the current > Date().[1]. The only option we have right now is writing our own > Properties writer. > I'm kind of surprised not to find any related issue, but does it make > sense to make the inclusion of the date optional? The Properties.store methods have always been specified to write a comment line with the current date and time. It wouldn't be unreasonable to look at changing it to not specify a date/time comment when the comment is provided by the user of the API but changing it after 20+ years would need effort to understand the impact. I think the bigger issue with reproducibility is that the ordering that the properties are written is not specified. Reproducible builds are important but maybe it needs Maven tooling or plugin to do smart comparisons. I think this is something that the Skara project was looking into at one point. -Alan From rfscholte at apache.org Sun Sep 29 16:46:12 2019 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 29 Sep 2019 18:46:12 +0200 Subject: Reproducible Properties In-Reply-To: <235542e7-1b5d-0e42-19ac-1ef83dfd4710@oracle.com> References: <235542e7-1b5d-0e42-19ac-1ef83dfd4710@oracle.com> Message-ID: On Sun, 29 Sep 2019 16:57:33 +0200, Alan Bateman wrote: > On 29/09/2019 14:08, Robert Scholte wrote: >> Hi, >> >> the Maven team gets quite some requests regarding reproducible builds. >> Depending on the source we're able to fix it ourselves. >> However, in case of writing properties via Properties.store() we'll get >> unreproducible properties, because it includes the current Date().[1]. >> The only option we have right now is writing our own Properties writer. >> I'm kind of surprised not to find any related issue, but does it make >> sense to make the inclusion of the date optional? > The Properties.store methods have always been specified to write a > comment line with the current date and time. It wouldn't be unreasonable > to look at changing it to not specify a date/time comment when the > comment is provided by the user of the API but changing it after 20+ > years would need effort to understand the impact. I think the bigger > issue with reproducibility is that the ordering that the properties are > written is not specified. Reproducible builds are important but maybe it > needs Maven tooling or plugin to do smart comparisons. I think this is > something that the Skara project was looking into at one point. > > -Alan The order of properties and the line-endings are indeed important too, but these are less hard to solve. As far as I understand, reproducible builds is not about comparison, but being able to get the same checksum value because the content will stay exactly same for one specific build, byte per byte. This is a challenge not just for Maven, but for any tool that generates output. I wasn't expecting a complete replacement of the Date(), but more a way to either set the date or skip the date in the comment( like setCommentDate(Date date) ). As one might see in the code, writing properties is not that easy. My concern is that any third party attempt to do this on its own will not be as good as the original implementation. Robert From Ed.Munoz at microfocus.com Sun Sep 29 22:29:34 2019 From: Ed.Munoz at microfocus.com (Ed Munoz) Date: Sun, 29 Sep 2019 22:29:34 +0000 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports Message-ID: Does JEP 362 mean that Oracle will stop producing the Solaris and SPARC builds of Oracle's own BCL-licensed JDK? Or does JEP 362 just apply to OpenJDK, and not mean anything one way or the other about Oracle's plans for its own BCL-licensed JDK? ----------------------------------------------------- Date: Fri, 27 Sep 2019 07:58:17 -0700 (PDT) From: mark.reinhold at oracle.com Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports https://openjdk.java.net/jeps/362 From adinn at redhat.com Mon Sep 30 08:22:38 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 30 Sep 2019 09:22:38 +0100 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <5D8F2F9F.3040600@zeus.net.au> References: <20190927145817.0A366308904@eggemoggin.niobe.net> <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> <5D8F2F9F.3040600@zeus.net.au> Message-ID: <5b06afa4-0141-7780-50d2-fb839db07531@redhat.com> On 28/09/2019 11:02, Peter Firmstone wrote: > Crazy idea, builds should be tested on as many architectures as possible > for debugging.? I hope this gets downvoted. That seems to me to be a very one-sided perspective you are offering and an unwarranted if not extreme conclusion (insanity? really?). Whatever the benefits to this project of being able to run on SPARC (and ignoring, for now, the likelihood that the benefits of maintaining the port are probably better gauged in terms of the value to users) your conclusion ignores the cost of maintaining the port, not just the maintenance outlay itself but the consequent lost opportunity cost. I think a more thoughtful and balanced judgement is needed here. > I've actually solved a lot of Java concurrency bugs using Solaris Sparc > I couldn't with other architectures.?? That means without it, we would > still be trying to solve those bugs. I'd be interested to hear why those concurrency bugs do not (or even cannot) manifest on Intel or AArch64, particularly the latter. > I don't know why Oracle doesn't release a developer workstation, with > affordable developer licensing, so we can continue using Solaris for > this purpose.?? There are just so many tools on Solaris develpers can > utilise. > > Oracle really should start up the OpenSolaris project again too. Arguments about what Oracle should or should not do with Solaris and SPARC hardware are not appropriate for this thread, indeed not even for this list or project. Please keep your comments on topic. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From peter.firmstone at zeus.net.au Sun Sep 29 09:41:46 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 29 Sep 2019 19:41:46 +1000 Subject: Taking up maintainership for SPARC - JEP-362 In-Reply-To: <7a270e82-b84f-c470-7bb0-86c2f7891b64@physik.fu-berlin.de> References: <7a270e82-b84f-c470-7bb0-86c2f7891b64@physik.fu-berlin.de> Message-ID: <5D907C5A.6090604@zeus.net.au> On 28/09/2019 7:31 PM, John Paul Adrian Glaubitz wrote: > Hello! > > I have just been notified about JEP-362 [1] and would like to offer to be > the official maintainer of the SPARC ports of OpenJDK. > > We're still using the Linux/SPARC port in Debian and therefore I would like > to help keeping the port in as long as possible. There might also be users > in the BSD world who are interested in the SPARC port. > > Thanks, > Adrian > >> [1] https://openjdk.java.net/jeps/362 I'll help for a good cause, Fujitsu are still developing sparc, and it's also still being used actively in research. I've been using Sparc since the 32 bit Classic in the 90's, I still have a Blade 1000 and T5240 I can develop on. Regards, Peter. From magnus.ihse.bursie at oracle.com Mon Sep 30 09:51:12 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 30 Sep 2019 11:51:12 +0200 Subject: Reproducible Properties In-Reply-To: References: <235542e7-1b5d-0e42-19ac-1ef83dfd4710@oracle.com> Message-ID: On 2019-09-29 18:46, Robert Scholte wrote: > On Sun, 29 Sep 2019 16:57:33 +0200, Alan Bateman > wrote: > >> On 29/09/2019 14:08, Robert Scholte wrote: >>> Hi, >>> >>> the Maven team gets quite some requests regarding reproducible builds. >>> Depending on the source we're able to fix it ourselves. >>> However, in case of writing properties via Properties.store() we'll >>> get unreproducible properties, because it includes the current >>> Date().[1]. The only option we have right now is writing our own >>> Properties writer. >>> I'm kind of surprised not to find any related issue, but does it >>> make sense to make the inclusion of the date optional? >> The Properties.store methods have always been specified to write a >> comment line with the current date and time. It wouldn't be >> unreasonable to look at changing it to not specify a date/time >> comment when the comment is provided by the user of the API but >> changing it after 20+ years would need effort to understand the >> impact. I think the bigger issue with reproducibility is that the >> ordering that the properties are written is not specified. >> Reproducible builds are important but maybe it needs Maven tooling or >> plugin to do smart comparisons. I think this is something that the >> Skara project was looking into at one point. >> >> -Alan > > The order of properties and the line-endings are indeed important too, > but these are less hard to solve. > As far as I understand, reproducible builds is not about comparison, > but being able to get the same checksum value because the content will > stay exactly same for one specific build, byte per byte. This is a > challenge not just for Maven, but for any tool that generates output. > > I wasn't expecting a complete replacement of the Date(), but more a > way to either set the date or skip the date in the comment( like > setCommentDate(Date date) ). > As one might see in the code, writing properties is not that easy. My > concern is that any third party attempt to do this on its own will not > be as good as the original implementation. Being in a situation to trying to get reproducible builds to OpenJDK itself, I understand your pain and fully support the idea that it should be at least *possible* for the standard methods to produce reproducible output. Adding an additional property to ignore the date, or set it to a given fixed date, seems like a very good idea to me. Ordering is important as well, though. If properties files are written in the order found using an internal structure of a hash map, then you cannot rely in reproducibility. I've found that when doing that, even for very simple programs, *most of the time* the file stays the same, but at some occasions, the structure changes. I've spent some time trying to figure out what makes this non-deterministic, but failed. One could be excused for believing that a really trivial, non-concurrent program that just adds a few entries to a hash map would have deterministic output, but that is not the case. Possibly, the internal structure of the hash map is ultimately dependent on available memory, or some external factor like that. So I'd strongly recommend adding a second property to enforce sorted (or "stable" by some other definition) output, to be fully certain to achieve reproducibility. /Magnus > > Robert From matthias.baesken at sap.com Mon Sep 30 10:26:55 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 30 Sep 2019 10:26:55 +0000 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <5b06afa4-0141-7780-50d2-fb839db07531@redhat.com> References: <20190927145817.0A366308904@eggemoggin.niobe.net> <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> <5D8F2F9F.3040600@zeus.net.au> <5b06afa4-0141-7780-50d2-fb839db07531@redhat.com> Message-ID: Hello, looks like AdoptOpenJDK stopped to provide Solaris (Sparc + x86) builds of OpenJDK a while ago for JDK11 or higher , see : https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot It might be interesting to hear from them about user questions / reactions on this . I would like to see Solaris/Sparc still supported in OpenJDK until at least next LTS / JDK17 , but without knowing more about number of users / usage It is hard to give good arguments . Best regards, Matthias > > On 28/09/2019 11:02, Peter Firmstone wrote: > > Crazy idea, builds should be tested on as many architectures as possible > > for debugging.? I hope this gets downvoted. > > That seems to me to be a very one-sided perspective you are offering and > an unwarranted if not extreme conclusion (insanity? really?). > > Whatever the benefits to this project of being able to run on SPARC (and > ignoring, for now, the likelihood that the benefits of maintaining the > port are probably better gauged in terms of the value to users) your > conclusion ignores the cost of maintaining the port, not just the > maintenance outlay itself but the consequent lost opportunity cost. I > think a more thoughtful and balanced judgement is needed here. > > > I've actually solved a lot of Java concurrency bugs using Solaris Sparc > > I couldn't with other architectures.?? That means without it, we would > > still be trying to solve those bugs. > > I'd be interested to hear why those concurrency bugs do not (or even > cannot) manifest on Intel or AArch64, particularly the latter. > > > I don't know why Oracle doesn't release a developer workstation, with > > affordable developer licensing, so we can continue using Solaris for > > this purpose.?? There are just so many tools on Solaris develpers can > > utilise. > > > > Oracle really should start up the OpenSolaris project again too. > Arguments about what Oracle should or should not do with Solaris and > SPARC hardware are not appropriate for this thread, indeed not even for > this list or project. Please keep your comments on topic. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martijnverburg at gmail.com Mon Sep 30 11:18:43 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 30 Sep 2019 12:18:43 +0100 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: References: <20190927145817.0A366308904@eggemoggin.niobe.net> <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> <5D8F2F9F.3040600@zeus.net.au> <5b06afa4-0141-7780-50d2-fb839db07531@redhat.com> Message-ID: Hi all, We've asked our Solaris user community if any of them are willing to step up and maintain the port. The illumos folks have indicated they may wish to start an alternative port but no takers on the solaris port as of yet. We'll work with the illumos folks to help them submit a full port project for review once they've worked through the commitment levels etc it will take. Cheers, Martijn On Mon, 30 Sep 2019 at 11:28, Baesken, Matthias wrote: > Hello, > looks like AdoptOpenJDK stopped to provide Solaris (Sparc + x86) > builds of OpenJDK a while ago for JDK11 or higher , see : > > https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot > > It might be interesting to hear from them about user questions / > reactions on this . > > I would like to see Solaris/Sparc still supported in OpenJDK until at > least next LTS / JDK17 , but without knowing more about number of > users / usage > It is hard to give good arguments . > > Best regards, Matthias > > > > > > > On 28/09/2019 11:02, Peter Firmstone wrote: > > > Crazy idea, builds should be tested on as many architectures as > possible > > > for debugging. I hope this gets downvoted. > > > > That seems to me to be a very one-sided perspective you are offering and > > an unwarranted if not extreme conclusion (insanity? really?). > > > > Whatever the benefits to this project of being able to run on SPARC (and > > ignoring, for now, the likelihood that the benefits of maintaining the > > port are probably better gauged in terms of the value to users) your > > conclusion ignores the cost of maintaining the port, not just the > > maintenance outlay itself but the consequent lost opportunity cost. I > > think a more thoughtful and balanced judgement is needed here. > > > > > I've actually solved a lot of Java concurrency bugs using Solaris Sparc > > > I couldn't with other architectures. That means without it, we would > > > still be trying to solve those bugs. > > > > I'd be interested to hear why those concurrency bugs do not (or even > > cannot) manifest on Intel or AArch64, particularly the latter. > > > > > I don't know why Oracle doesn't release a developer workstation, with > > > affordable developer licensing, so we can continue using Solaris for > > > this purpose. There are just so many tools on Solaris develpers can > > > utilise. > > > > > > Oracle really should start up the OpenSolaris project again too. > > Arguments about what Oracle should or should not do with Solaris and > > SPARC hardware are not appropriate for this thread, indeed not even for > > this list or project. Please keep your comments on topic. > > > > regards, > > > > > > Andrew Dinn > > ----------- > > Senior Principal Software Engineer > > Red Hat UK Ltd > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From peter.firmstone at zeus.net.au Mon Sep 30 10:07:13 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Mon, 30 Sep 2019 20:07:13 +1000 Subject: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports In-Reply-To: <5b06afa4-0141-7780-50d2-fb839db07531@redhat.com> References: <20190927145817.0A366308904@eggemoggin.niobe.net> <3447336b-3f6e-29f3-cdb7-5317577de429@LGonQn.Org> <5D8F2F9F.3040600@zeus.net.au> <5b06afa4-0141-7780-50d2-fb839db07531@redhat.com> Message-ID: <5D91D3D1.1000706@zeus.net.au> On 30/09/2019 6:22 PM, Andrew Dinn wrote: >> I've actually solved a lot of Java concurrency bugs using Solaris Sparc >> > I couldn't with other architectures. That means without it, we would >> > still be trying to solve those bugs. > I'd be interested to hear why those concurrency bugs do not (or even > cannot) manifest on Intel or AArch64, particularly the latter. > Me too, perhaps there are some experts on the list that will be able to answer that. We tested on AArch64 as well, and we found bugs on Arm that didn't manifest on Intel, Sparc or PowerPC. Testing on multiple architectures was very helpful. A lot of our code predated the Java 1.5 JMM, so we had a lot of cleaning up to make it JMM compliant after Java 5 came out and we were late to the party, Java 6 was already out and we were still on 1.4. We also, used static analysis, and visually inspected the code to clean up these bugs. I saw there was a volunteer to manage the port, I'd be prepared to assist also. Regards, Peter.