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.