From daniel.daugherty at oracle.com Wed Apr 1 01:26:24 2015
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 31 Mar 2015 19:26:24 -0600
Subject: CFV: New JDK 9 Committer: Fredrik Arvidsson
In-Reply-To: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
References: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
Message-ID: <551B4940.9000306@oracle.com>
Vote: yes
Dan
On 3/30/15 1:47 AM, Staffan Larsen wrote:
> I hereby nominate Fredrik Arvidsson to JDK 9 Committer.
>
> Fredrik is member of the Java Serviceability team at Oracle and has contributed 13 changesets to date. These include a new diagnostic command for listing loaded shared libraries, fixes to the serviceability agent and JVMTI for anonymous classes, adding support for large heaps in the serviceability agent?s hprof handling as well as various bug fixes in many places.
>
> Here is a list of Fredrik's changesets:
>
> 8031304: Add dcmd to print all loaded dynamic libraries.
> 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
> 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value
> 8025638: jmap returns 0 instead of 1 when it fails.
> 8056242: Add function to return structured information about loaded libraries.
> 8055755: Information about loaded dynamic libraries is wrong on MacOSX
> 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump
> 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed
> 6313383: SA: Update jmap to support HPROF binary format
> 8016845: SA is unable to use hsdis on windows
> 8059105: Add better failure reporting to com/sun/jdi/RunToExit.java test
> 8034203: Change JavaDoc for com.sun.jdi.request.EventRequest.setEnabled(boolean val)
> 4515292: ReferenceType.isStatic() returns true for arrays
>
> Votes are due by 2015-04-13.
>
> Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Staffan Larsen
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From sundararajan.athijegannathan at oracle.com Wed Apr 1 01:27:27 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 01 Apr 2015 06:57:27 +0530
Subject: CFV: New JDK 9 Committer: Fredrik Arvidsson
In-Reply-To: <551B4940.9000306@oracle.com>
References: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
<551B4940.9000306@oracle.com>
Message-ID: <551B497F.3060408@oracle.com>
Vote: yes
Sundar
On Wednesday 01 April 2015 06:56 AM, Daniel D. Daugherty wrote:
> Vote: yes
>
> Dan
>
>
> On 3/30/15 1:47 AM, Staffan Larsen wrote:
>> I hereby nominate Fredrik Arvidsson to JDK 9 Committer.
>>
>> Fredrik is member of the Java Serviceability team at Oracle and has
>> contributed 13 changesets to date. These include a new diagnostic
>> command for listing loaded shared libraries, fixes to the
>> serviceability agent and JVMTI for anonymous classes, adding support
>> for large heaps in the serviceability agent?s hprof handling as well
>> as various bug fixes in many places.
>>
>> Here is a list of Fredrik's changesets:
>>
>> 8031304: Add dcmd to print all loaded dynamic libraries.
>> 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
>> 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> failed with unexpected exit value
>> 8025638: jmap returns 0 instead of 1 when it fails.
>> 8056242: Add function to return structured information about loaded
>> libraries.
>> 8055755: Information about loaded dynamic libraries is wrong on MacOSX
>> 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump
>> 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> Compilation failed
>> 6313383: SA: Update jmap to support HPROF binary format
>> 8016845: SA is unable to use hsdis on windows
>> 8059105: Add better failure reporting to com/sun/jdi/RunToExit.java test
>> 8034203: Change JavaDoc for
>> com.sun.jdi.request.EventRequest.setEnabled(boolean val)
>> 4515292: ReferenceType.isStatic() returns true for arrays
>>
>> Votes are due by 2015-04-13.
>>
>> Only current JDK 9 Committers [1] are eligible to vote on this
>> nomination. Votes must be cast in the open by replying to this
>> mailing list.
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Staffan Larsen
>>
>> [1] http://openjdk.java.net/census
>> [2] http://openjdk.java.net/projects/#committer-vote
>>
>
From magnus.ihse.bursie at oracle.com Wed Apr 1 08:33:12 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Apr 2015 10:33:12 +0200
Subject: FYI: Build system rewrite in Ant
Message-ID: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
The Build Team has therefore decided to rewrite the current build system from scratch in Ant. The old Makefiles will be put in maintenance mode while the new Ant scripts are being developed. To facilitate a speedy switch, all new build enhancements must be expressed in Ant logic, starting today. No modifications in the old Makefiles will be accepted by the Build Team.
To increase the robustness of the code base, the new build system will automatically check the integrity of all source code files before compilation. Each source file therefore must be accompanied by a Integrity Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have an Object.java.Integ_Manif.xml. This is a simple xml file, describing the purpose of the source code file, and a log of mercurial changeset id:s. An example file could looks like this:
net.java.openjdk.build.ant.manifest.integrity
Object.java
Class Object is the root of the class hierarchy.
541a8cef4e0d
mercurial
458adf31ad5b
mercurial
0846eddb56d5
mercurial
Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit.
But fear not! To assist developers in preserving the integrity of the source files, an addition to jcheck has been developed. If the subsequent commit does not properly describe the previous changeset ID, the original changeset will be automatically reverted, so no untracked changes will be stored permanently in the revision control system.
Finally, to fully utilize the promise of portability that the Ant and Java? technology brings, platforms with portability issues will be removed from the supported platform matrix. Currently, this only includes non-POSIX-compliant operating systems, since these have been known to cause various platform issues in the build system. The only known non-POSIX-compliant OS that the OpenJDK build system currently supports is the Windows OS family, so this reduction in support is hopefully not too burdensome.
These changes will take immediate effect of today, April 1 2015.
That's all for today, folks! :-)
/Magnus
From thomas.stuefe at gmail.com Wed Apr 1 08:35:17 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 1 Apr 2015 10:35:17 +0200
Subject: RFR(xxs): 8074547: libjli, get_cpuid() implementation missing for
MacOs, breaks libjli.so build in slowdebug
Message-ID:
Hi,
please review this tiny change. It fixes a build error on MacOS when
building jdk without optimization.
bug: https://bugs.openjdk.java.net/browse/JDK-8074547
webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8074547/webrev.00/webrev/
Thank you!
..Thomas Stuefe
From neugens.limasoftware at gmail.com Wed Apr 1 08:41:30 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 1 Apr 2015 10:41:30 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
2015-04-01 10:33 GMT+02:00 Magnus Ihse Bursie :
> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>
> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
To be honest, I'm pretty disappointed by this move. In 2015 and with
the advancements in the JVM technology, I would have expected that
OpenJDK would be able to know how to build itself *without* a build
tool!!
:)
Mario
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
http://endsoftpatents.org/
From volker.simonis at gmail.com Wed Apr 1 08:49:34 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 1 Apr 2015 10:49:34 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
Why not starting with the easiest part of your proposal which you've
sketched in the last paragraph and just remove the "only known
non-POSIX-compliant OS".
I'm preparing a webrev if you don't mind:)
Rgards,
Volker
On Wed, Apr 1, 2015 at 10:33 AM, Magnus Ihse Bursie
wrote:
> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>
> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
>
> The Build Team has therefore decided to rewrite the current build system from scratch in Ant. The old Makefiles will be put in maintenance mode while the new Ant scripts are being developed. To facilitate a speedy switch, all new build enhancements must be expressed in Ant logic, starting today. No modifications in the old Makefiles will be accepted by the Build Team.
>
> To increase the robustness of the code base, the new build system will automatically check the integrity of all source code files before compilation. Each source file therefore must be accompanied by a Integrity Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have an Object.java.Integ_Manif.xml. This is a simple xml file, describing the purpose of the source code file, and a log of mercurial changeset id:s. An example file could looks like this:
>
>
> net.java.openjdk.build.ant.manifest.integrity
>
>
>
> Object.java
> Class Object is the root of the class hierarchy.
>
>
>
>
>
>
> 541a8cef4e0d
> mercurial
>
>
> 458adf31ad5b
> mercurial
>
>
> 0846eddb56d5
> mercurial
>
>
>
>
>
> Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit.
>
> But fear not! To assist developers in preserving the integrity of the source files, an addition to jcheck has been developed. If the subsequent commit does not properly describe the previous changeset ID, the original changeset will be automatically reverted, so no untracked changes will be stored permanently in the revision control system.
>
> Finally, to fully utilize the promise of portability that the Ant and Java? technology brings, platforms with portability issues will be removed from the supported platform matrix. Currently, this only includes non-POSIX-compliant operating systems, since these have been known to cause various platform issues in the build system. The only known non-POSIX-compliant OS that the OpenJDK build system currently supports is the Windows OS family, so this reduction in support is hopefully not too burdensome.
>
> These changes will take immediate effect of today, April 1 2015.
>
> That's all for today, folks! :-)
>
> /Magnus
From tomasz.kowalczewski at gmail.com Wed Apr 1 08:50:08 2015
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Wed, 1 Apr 2015 10:50:08 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To:
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID: <7377C00F-5B7F-4163-AD96-D7ADB85DF95C@gmail.com>
Whole community of dynamic language developers would benefit from a meta circular build system ;)
> On 01 Apr 2015, at 10:41, Mario Torre wrote:
>
> 2015-04-01 10:33 GMT+02:00 Magnus Ihse Bursie :
>> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>>
>> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
>
> To be honest, I'm pretty disappointed by this move. In 2015 and with
> the advancements in the JVM technology, I would have expected that
> OpenJDK would be able to know how to build itself *without* a build
> tool!!
>
> :)
>
> Mario
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
From forax at univ-mlv.fr Wed Apr 1 09:02:50 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 01 Apr 2015 11:02:50 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <7377C00F-5B7F-4163-AD96-D7ADB85DF95C@gmail.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
<7377C00F-5B7F-4163-AD96-D7ADB85DF95C@gmail.com>
Message-ID: <551BB43A.6010507@univ-mlv.fr>
On 04/01/2015 10:50 AM, Tomasz Kowalczewski wrote:
> Whole community of dynamic language developers would benefit from a meta circular build system ;)
yes, a meta-circular maven with the whole maven central in RAM !
R?mi
>
>> On 01 Apr 2015, at 10:41, Mario Torre wrote:
>>
>> 2015-04-01 10:33 GMT+02:00 Magnus Ihse Bursie :
>>> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>>>
>>> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
>> To be honest, I'm pretty disappointed by this move. In 2015 and with
>> the advancements in the JVM technology, I would have expected that
>> OpenJDK would be able to know how to build itself *without* a build
>> tool!!
>>
>> :)
>>
>> Mario
>>
>>
>> --
>> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
>> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>>
>> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
>> Proud GNU Classpath developer: http://www.classpath.org/
>> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>>
>> Please, support open standards:
>> http://endsoftpatents.org/
From david.katleman at oracle.com Wed Apr 1 09:21:19 2015
From: david.katleman at oracle.com (David Katleman (Oracle))
Date: Wed, 1 Apr 2015 02:21:19 -0700
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
+1
Please say were going to use the extension that predict build failures before they occur and provides an automated root cause analysis. I believe is called Ant predictive recursive interpreter language with Forensic object oriented linguistic syntax.
> On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie wrote:
>
> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>
> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
>
> The Build Team has therefore decided to rewrite the current build system from scratch in Ant. The old Makefiles will be put in maintenance mode while the new Ant scripts are being developed. To facilitate a speedy switch, all new build enhancements must be expressed in Ant logic, starting today. No modifications in the old Makefiles will be accepted by the Build Team.
>
> To increase the robustness of the code base, the new build system will automatically check the integrity of all source code files before compilation. Each source file therefore must be accompanied by a Integrity Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have an Object.java.Integ_Manif.xml. This is a simple xml file, describing the purpose of the source code file, and a log of mercurial changeset id:s. An example file could looks like this:
>
>
> net.java.openjdk.build.ant.manifest.integrity
>
>
>
> Object.java
> Class Object is the root of the class hierarchy.
>
>
>
>
>
>
> 541a8cef4e0d
> mercurial
>
>
> 458adf31ad5b
> mercurial
>
>
> 0846eddb56d5
> mercurial
>
>
>
>
>
> Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit.
>
> But fear not! To assist developers in preserving the integrity of the source files, an addition to jcheck has been developed. If the subsequent commit does not properly describe the previous changeset ID, the original changeset will be automatically reverted, so no untracked changes will be stored permanently in the revision control system.
>
> Finally, to fully utilize the promise of portability that the Ant and Java? technology brings, platforms with portability issues will be removed from the supported platform matrix. Currently, this only includes non-POSIX-compliant operating systems, since these have been known to cause various platform issues in the build system. The only known non-POSIX-compliant OS that the OpenJDK build system currently supports is the Windows OS family, so this reduction in support is hopefully not too burdensome.
>
> These changes will take immediate effect of today, April 1 2015.
>
> That's all for today, folks! :-)
>
> /Magnus
From thomas.stuefe at gmail.com Wed Apr 1 09:52:30 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 1 Apr 2015 11:52:30 +0200
Subject: RFR(xxs): 8074547: libjli, get_cpuid() implementation missing for
MacOs, breaks libjli.so build in slowdebug
In-Reply-To:
References:
Message-ID:
Added core-libs-dev. Sorry for the crosspost.
On Wed, Apr 1, 2015 at 10:35 AM, Thomas St?fe
wrote:
> Hi,
>
> please review this tiny change. It fixes a build error on MacOS when
> building jdk without optimization.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8074547
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8074547/webrev.00/webrev/
>
> Thank you!
>
> ..Thomas Stuefe
>
>
From martijnverburg at gmail.com Wed Apr 1 09:59:46 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 1 Apr 2015 10:59:46 +0100
Subject: FYI: Build system rewrite in Ant
In-Reply-To:
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
I'm personally willing to provide a ANT to MAVEN conversion tool which will
allow for a more verbose an rdable build system. It will also ensure that
dependencies are always downloaded at all times ensuring network pipes are
kept clean.
Cheers,
Martijn
On 1 April 2015 at 10:21, David Katleman (Oracle) wrote:
> +1
>
> Please say were going to use the extension that predict build failures
> before they occur and provides an automated root cause analysis. I believe
> is called Ant predictive recursive interpreter language with Forensic
> object oriented linguistic syntax.
>
>
> > On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
> >
> > The build system currently uses make to build OpenJDK. This is a
> technology that has been around for decades, and in places this legacy
> clearly shows.
> >
> > An alternative build tool, Ant, is based on cutting-edge technology.
> Compared to the native GNU Make, Ant is based on Java? technology, which
> makes portability issues a thing of the past. Ant is also directed using
> modern XML systems, with well-defined tags, compared to the aged and
> idiosyncratic Makefile syntax.
> >
> > The Build Team has therefore decided to rewrite the current build system
> from scratch in Ant. The old Makefiles will be put in maintenance mode
> while the new Ant scripts are being developed. To facilitate a speedy
> switch, all new build enhancements must be expressed in Ant logic, starting
> today. No modifications in the old Makefiles will be accepted by the Build
> Team.
> >
> > To increase the robustness of the code base, the new build system will
> automatically check the integrity of all source code files before
> compilation. Each source file therefore must be accompanied by a Integrity
> Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have
> an Object.java.Integ_Manif.xml. This is a simple xml file, describing the
> purpose of the source code file, and a log of mercurial changeset id:s. An
> example file could looks like this:
> >
> >
> > net.java.openjdk.build.ant.manifest.integrity
> >
> >
> >
> > Object.java
> > Class Object is the root of the class
> hierarchy.
> >
> >
> >
> >
> >
> >
> > 541a8cef4e0d
> >
> mercurial
> >
> >
> > 458adf31ad5b
> >
> mercurial
> >
> >
> > 0846eddb56d5
> >
> mercurial
> >
> >
> >
> >
> >
> > Each time a new version of the file is committed to the mercurial repo,
> the developer just has to add a new committed-change stanza to the block in
> the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand,
> the Integrity Manifest file must be updated in a subsequent commit.
> >
> > But fear not! To assist developers in preserving the integrity of the
> source files, an addition to jcheck has been developed. If the subsequent
> commit does not properly describe the previous changeset ID, the original
> changeset will be automatically reverted, so no untracked changes will be
> stored permanently in the revision control system.
> >
> > Finally, to fully utilize the promise of portability that the Ant and
> Java? technology brings, platforms with portability issues will be removed
> from the supported platform matrix. Currently, this only includes
> non-POSIX-compliant operating systems, since these have been known to cause
> various platform issues in the build system. The only known
> non-POSIX-compliant OS that the OpenJDK build system currently supports is
> the Windows OS family, so this reduction in support is hopefully not too
> burdensome.
> >
> > These changes will take immediate effect of today, April 1 2015.
> >
> > That's all for today, folks! :-)
> >
> > /Magnus
>
From james.laskey at oracle.com Wed Apr 1 10:18:14 2015
From: james.laskey at oracle.com (James Laskey)
Date: Wed, 1 Apr 2015 07:18:14 -0300
Subject: FYI: Build system rewrite in Ant
In-Reply-To:
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
I may have been misled, but I thought Ant was replaced by a non-deterministic build system called Termight.
Sent from my iPhone
> On Apr 1, 2015, at 6:59 AM, Martijn Verburg wrote:
>
> I'm personally willing to provide a ANT to MAVEN conversion tool which will
> allow for a more verbose an rdable build system. It will also ensure that
> dependencies are always downloaded at all times ensuring network pipes are
> kept clean.
>
> Cheers,
> Martijn
>
> On 1 April 2015 at 10:21, David Katleman (Oracle) > wrote:
>
>> +1
>>
>> Please say were going to use the extension that predict build failures
>> before they occur and provides an automated root cause analysis. I believe
>> is called Ant predictive recursive interpreter language with Forensic
>> object oriented linguistic syntax.
>>
>>
>>>> On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie <
>>> magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> The build system currently uses make to build OpenJDK. This is a
>> technology that has been around for decades, and in places this legacy
>> clearly shows.
>>>
>>> An alternative build tool, Ant, is based on cutting-edge technology.
>> Compared to the native GNU Make, Ant is based on Java? technology, which
>> makes portability issues a thing of the past. Ant is also directed using
>> modern XML systems, with well-defined tags, compared to the aged and
>> idiosyncratic Makefile syntax.
>>>
>>> The Build Team has therefore decided to rewrite the current build system
>> from scratch in Ant. The old Makefiles will be put in maintenance mode
>> while the new Ant scripts are being developed. To facilitate a speedy
>> switch, all new build enhancements must be expressed in Ant logic, starting
>> today. No modifications in the old Makefiles will be accepted by the Build
>> Team.
>>>
>>> To increase the robustness of the code base, the new build system will
>> automatically check the integrity of all source code files before
>> compilation. Each source file therefore must be accompanied by a Integrity
>> Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have
>> an Object.java.Integ_Manif.xml. This is a simple xml file, describing the
>> purpose of the source code file, and a log of mercurial changeset id:s. An
>> example file could looks like this:
>>>
>>>
>>> net.java.openjdk.build.ant.manifest.integrity
>>>
>>>
>>>
>>> Object.java
>>> Class Object is the root of the class
>> hierarchy.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 541a8cef4e0d
>> mercurial
>>>
>>>
>>> 458adf31ad5b
>> mercurial
>>>
>>>
>>> 0846eddb56d5
>> mercurial
>>>
>>>
>>>
>>>
>>>
>>> Each time a new version of the file is committed to the mercurial repo,
>> the developer just has to add a new committed-change stanza to the block in
>> the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand,
>> the Integrity Manifest file must be updated in a subsequent commit.
>>>
>>> But fear not! To assist developers in preserving the integrity of the
>> source files, an addition to jcheck has been developed. If the subsequent
>> commit does not properly describe the previous changeset ID, the original
>> changeset will be automatically reverted, so no untracked changes will be
>> stored permanently in the revision control system.
>>>
>>> Finally, to fully utilize the promise of portability that the Ant and
>> Java? technology brings, platforms with portability issues will be removed
>> from the supported platform matrix. Currently, this only includes
>> non-POSIX-compliant operating systems, since these have been known to cause
>> various platform issues in the build system. The only known
>> non-POSIX-compliant OS that the OpenJDK build system currently supports is
>> the Windows OS family, so this reduction in support is hopefully not too
>> burdensome.
>>>
>>> These changes will take immediate effect of today, April 1 2015.
>>>
>>> That's all for today, folks! :-)
>>>
>>> /Magnus
>>
From neugens.limasoftware at gmail.com Wed Apr 1 10:30:03 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 1 Apr 2015 12:30:03 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To:
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
2015-04-01 12:18 GMT+02:00 James Laskey :
> I may have been misled, but I thought Ant was replaced by a non-deterministic build system called Termight.
:)
I think that indeed Ant is obsolete already, and since we are in the
space exploration era, this may be more appropriate:
https://github.com/lhartikk/AstroBuild
Mario
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
http://endsoftpatents.org/
From neugens.limasoftware at gmail.com Wed Apr 1 10:41:50 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 1 Apr 2015 12:41:50 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To:
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
2015-04-01 11:59 GMT+02:00 Martijn Verburg :
> I'm personally willing to provide a ANT to MAVEN conversion tool which will
> allow for a more verbose an rdable build system. It will also ensure that
> dependencies are always downloaded at all times ensuring network pipes are
> kept clean.
Ok, I've had a discussion with the rest of my team and we are
convinced that real Free Software projects cannot live without
Makefiles.
So in order to give people choice I'm volunteering to restore the old
system used in IcedTea version 6 as a fork of the current ant based
build tool.
While there, we noticed that Mercurial is really leading to a very
high flow of patches, too difficult to work with and follow, so we
decide to move to RCS.
We think this is the only reasonable thing to do in a fast paced
project and the increased workflow will create less and more focused
commits, leading to a higher quality of them!
Cheers,
Mario
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
http://endsoftpatents.org/
From mandy.chung at oracle.com Wed Apr 1 18:12:45 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 01 Apr 2015 11:12:45 -0700
Subject: native2ascii to be removed from JDK
Message-ID: <551C351C.90701@oracle.com>
We're thinking about removing native2ascii from JDK because we think
very few people are using it.
There are several other convenient ways to do native-to-ascii
conversion. For example, IDEs like NetBeans and IntelliJ support the
transparent native-to-ascii conversion. There is also maven native 2
ascii plugin. These tools are better integration to the
build/development process than the standalone native2ascii CLI.
In addition, JEP 226 proposes to support UTF Properties file that will
address the original motivation of creating the native2ascii tool.
Any comment?
Mandy
From lana.steuck at oracle.com Wed Apr 1 20:08:06 2015
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 1 Apr 2015 13:08:06 -0700 (PDT)
Subject: jdk9-b57: dev
Message-ID: <201504012008.t31K86jn018991@sc11152554.us.oracle.com>
http://hg.openjdk.java.net/jdk9/jdk9/rev/f25ee9f62427
http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/3bcfcb13c234
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/ec977a00cecb
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c76339e86ea7
http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/17c4241395e9
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/2c417f7d7b0d
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a85ffe743d
http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/d8ebf1a5b18c
---
All the fixes will be tested during promotion (no PIT testing at this point):
List of all fixes:
===================
JDK-8075655 core-libs (bf) NIO test generation scripts have incorrect path to Spp.java
JDK-8071480 core-libs (process spec) ProcessBuilder.start spec linked to the wrong checkRead
JDK-8067796 core-libs (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout
JDK-8075039 core-libs (sctp) com/sun/nio/sctp/SctpMultiChannel/SendFailed.java fails on Sola
JDK-8075071 core-libs [TEST_BUG] TimSortStackSize2.java: OOME: Java heap space: MaxHeap shri
JDK-8073220 core-libs A typo in the documentation for class ProcessBuilder
JDK-8075824 core-libs Add default[Read|Write]Object to java.util.Date
JDK-8075173 core-libs DateFormat in german locale returns wrong value for month march
JDK-8012190 core-libs Global scope should be initialized lazily
JDK-8075362 core-libs j.u.Properties.load() methods have misaligned @throws clauses
JDK-8075240 core-libs Output of some tests contains platform specific line break
JDK-8075307 core-libs Pipeline calculating inconsistent flag state for parallel stateful ops
JDK-8075670 core-libs Remove intermittent keyword from some tests
JDK-8074839 core-libs Resolve disabled warnings for libunpack and the unpack200 binary
JDK-8074410 core-libs Startup time: Port shell.js to Java
JDK-8075623 core-libs Temporary patch to get fx imports working interim
JDK-8075927 core-libs toNumber(String) accepts illegal characters
JDK-8075560 core-libs Typo in Javadoc for java.util.Optional.equals()
JDK-8074948 core-svc javadoc typo in DiagnosticCommandMBean.java: {code instead of {@code
JDK-8075569 core-svc jmap test fails due to "ERROR: java.nio.file.NoSuchFileException: 2906
JDK-8074812 core-svc More specific error message when the .java_pid well-known file is not
JDK-8074041 core-svc sun/management/jmxremote/startstop/JMXStartStopTest.java fails with In
JDK-8075443 hotspot AARCH64: Missed L2I optimizations in C2
JDK-8073607 hotspot add trace events for inlining
JDK-8074869 hotspot C2 code generator can replace -0.0f with +0.0f on Linux
JDK-8073990 hotspot Deprecated "UseVectoredExceptions" VM options still defined in several
JDK-8073315 hotspot Enable gcc -Wtype-limits and fix upcoming issues.
JDK-8074312 hotspot Enable hotspot builds on 4.x Linux kernels
JDK-8074905 hotspot Exclude aarch64 from Visual Studio projectcreator.make
JDK-8073794 hotspot jdk/test/com/sun/jdi/BadHandshakeTest.java should retry if tcp port is
JDK-8074717 hotspot Merge interp_masm files for x86 _32 and _64
JDK-8061205 hotspot MetadataOnStackMark only needs to walk code cache during class redefin
JDK-6313046 hotspot Remove unused frame::native_param_addr code
JDK-8074552 hotspot SafeFetch32 and SafeFetchN do not work in error handling
JDK-8075573 other-libs Add jdk_other and jdk_svc to jdk tier 2 test definition
JDK-8074935 security-libs jdk8 keytool doesn't validate pem files for RFC 1421 correctness, as j
JDK-8075567 security-libs Mark intermittently failuring security-libs tests
JDK-8074531 security-libs Remove javax.security.cert.X509Certificate usage in internal networkin
JDK-8048618 security-libs Tests for PKCS12 write operations
JDK-8049238 tools Implement classfile tests for Signature attribute.
From kumar.x.srinivasan at oracle.com Wed Apr 1 20:18:22 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 01 Apr 2015 13:18:22 -0700
Subject: CFV: New JDK 9 Committer: Srikanth Adayapalam
In-Reply-To: <551A81B8.7080700@oracle.com>
References: <551A81B8.7080700@oracle.com>
Message-ID: <551C528E.6020608@oracle.com>
Vote: yes
On 3/31/2015 4:15 AM, Maurizio Cimadamore wrote:
> I hereby nominate Srikanth Adayapalam to JDK 9 Committer.
>
> Srikanth is a member of the Langtools team; before joining Oracle, he
> was the Eclipse compiler tech lead at IBM. Over the past few months,
> he has been hacking furiously on the javac code and already
> contributed to several changesets. These include, among others, the
> changes to support JEP 213 (Milling Project Coin [1]): support for
> private interface methods and support for diamond anonymous instance
> creation expressions.
>
> Here is a (partial) list of Srikanth's changesets:
>
> 7040592: Gen.java: fix code for handling 'null' literal when expected
> type is array
> 8062373: Project Coin: diamond and anonymous classes
> 8071453: Allow interface methods to be private
> 8074148: Attr.visitBinary flags error at wrong position
> 8071847: java.lang.NullPointerException at
> com.sun.tools.javac.code.Types.elemtype(Types.java:1870)
> 8050021: Improper "duplicate case label" error
> 8069265: ClassCastException when compiled with JDK 9b08+, JDK8
> compiles OK.
> 8046977: ClassCastException: typing information needed for method
> reference bridging not preserved
> 8076039: Remove the unused internal API
> sun.reflect.misc.FieldUtil.getDeclaredFields
> 8052070: javac crashes when there are duplicated type parameters
> 8027888: javac wrongly allows annotations in array-typed class literals
> 8068254: Method reference uses wrong qualifying type
> 8037546: javac -parameters does not emit parameter names for lambda
> expressions
> 8062358: ClassCastException in TransTypes.visitApply
> 8067914: Redundant type cast nodes in AST (follow up from JDK-8043741)
> 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch
> target
> 8043741: VerifyError due to missing checkcast
> 8066871: java.lang.VerifyError: Bad local variable type - local final
> String
>
> Votes are due by 2015-04-15.
>
> Only current JDK 9 Committers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Maurizio Cimadamore
>
> [1] http://openjdk.java.net/jeps/213
> [2]http://openjdk.java.net/census
> [3]http://openjdk.java.net/projects/#committer-vote
>
From sadhak001 at gmail.com Wed Apr 1 21:41:35 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Wed, 1 Apr 2015 22:41:35 +0100
Subject: FYI: Build system rewrite in Ant
In-Reply-To:
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID:
+1 to Martijn's gesture to a conversion tool, I'm personally driven to
explore these:
- Gradle
- Maven and its derivatives are a good option too
(see this article
http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608
)
- https://buildr.apache.org/
- https://facebook.github.io/buck/ - ultra fast ;)
You might not go for this immediately, but ideas from here are good for the
present and future of Java -
https://typesafe.com/blog/zinc-and-incremental-compilation
Here's a nice comparison -
https://www.symphonious.net/2010/01/11/comparing-build-systems/
I find XML hard to read compared to JSON or YAML - especially when your XML
file grows into a big huge monolith.
With this I hope I have made some friends and some will likely become
friends eventually.
Cheers,
Mani
On Wed, Apr 1, 2015 at 11:41 AM, Mario Torre wrote:
> 2015-04-01 11:59 GMT+02:00 Martijn Verburg :
> > I'm personally willing to provide a ANT to MAVEN conversion tool which
> will
> > allow for a more verbose an rdable build system. It will also ensure
> that
> > dependencies are always downloaded at all times ensuring network pipes
> are
> > kept clean.
>
> Ok, I've had a discussion with the rest of my team and we are
> convinced that real Free Software projects cannot live without
> Makefiles.
>
> So in order to give people choice I'm volunteering to restore the old
> system used in IcedTea version 6 as a fork of the current ant based
> build tool.
>
> While there, we noticed that Mercurial is really leading to a very
> high flow of patches, too difficult to work with and follow, so we
> decide to move to RCS.
>
> We think this is the only reasonable thing to do in a fast paced
> project and the increased workflow will create less and more focused
> commits, leading to a higher quality of them!
>
> Cheers,
> Mario
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>
--
@theNeomatrix369 * | **Blog
** | *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
* | **Bitbucket
* * | **Github
* * | **LinkedIn
*
*Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*
From robert.field at oracle.com Wed Apr 1 22:26:47 2015
From: robert.field at oracle.com (Robert Field)
Date: Wed, 01 Apr 2015 15:26:47 -0700
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID: <551C70A7.9090002@oracle.com>
On 04/01/15 01:33, Magnus Ihse Bursie wrote:
> Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit.
Please, tell me this is an April Fools joke!
Each time you edit a Java file you need to update the XML file. This is
a step back in usability not forward.
-Robert
From mark.reinhold at oracle.com Thu Apr 2 22:31:46 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 02 Apr 2015 15:31:46 -0700
Subject: JEPs proposed to target JDK 9 (2015/3/26)
In-Reply-To: <20150326145222.452009@eggemoggin.niobe.net>
References: <20150326145222.452009@eggemoggin.niobe.net>
Message-ID: <20150402153146.792831@eggemoggin.niobe.net>
2015/3/26 2:52 -0700, mark.reinhold at oracle.com:
> The following JEPs have been placed into the "Proposed to Target"
> state by their owners after discussion and review:
>
> 223: New Version-String Scheme http://openjdk.java.net/jeps/223
> 226: UTF-8 Property Files http://openjdk.java.net/jeps/226
>
> Feedback on these proposals is more than welcome, as are reasoned
> objections. If no such objections are raised by 22:00 UTC next
> Thursday, 2 April, or if they're raised and then satisfactorily
> answered, then per the JEP 2.0 process proposal [1] I'll target
> these JEPs to JDK 9.
Hearing no objections, I've targeted these JEPs to JDK 9.
- Mark
From mark.reinhold at oracle.com Thu Apr 2 22:32:09 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 02 Apr 2015 15:32:09 -0700
Subject: JEPs proposed to target JDK 9 (2015/4/2)
Message-ID: <20150402153209.528656@eggemoggin.niobe.net>
The following JEPs have been placed into the "Proposed to Target"
state by their owners after discussion and review:
240: Remove the JVM TI hprof Agent http://openjdk.java.net/jeps/240
241: Remove the jhat Tool http://openjdk.java.net/jeps/241
Feedback on these proposals is more than welcome, as are reasoned
objections. If no such objections are raised by 23:00 UTC next
Thursday, 9 April, or if they're raised and then satisfactorily
answered, then per the JEP 2.0 process proposal [1] I'll target
these JEPs to JDK 9.
(This information is also available on the JDK 9 Project Page [2]).
- Mark
[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
[2] http://openjdk.java.net/projects/jdk9/
From brian.goetz at oracle.com Fri Apr 3 18:55:54 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 03 Apr 2015 14:55:54 -0400
Subject: CFV: New JDK 9 Committer: Srikanth Adayapalam
In-Reply-To: <551A81B8.7080700@oracle.com>
References: <551A81B8.7080700@oracle.com>
Message-ID: <551EE23A.1020006@oracle.com>
Vote: yes
On 3/31/2015 7:15 AM, Maurizio Cimadamore wrote:
> I hereby nominate Srikanth Adayapalam to JDK 9 Committer.
>
> Srikanth is a member of the Langtools team; before joining Oracle, he
> was the Eclipse compiler tech lead at IBM. Over the past few months, he
> has been hacking furiously on the javac code and already contributed to
> several changesets. These include, among others, the changes to support
> JEP 213 (Milling Project Coin [1]): support for private interface
> methods and support for diamond anonymous instance creation expressions.
>
> Here is a (partial) list of Srikanth's changesets:
>
> 7040592: Gen.java: fix code for handling 'null' literal when expected
> type is array
> 8062373: Project Coin: diamond and anonymous classes
> 8071453: Allow interface methods to be private
> 8074148: Attr.visitBinary flags error at wrong position
> 8071847: java.lang.NullPointerException at
> com.sun.tools.javac.code.Types.elemtype(Types.java:1870)
> 8050021: Improper "duplicate case label" error
> 8069265: ClassCastException when compiled with JDK 9b08+, JDK8 compiles OK.
> 8046977: ClassCastException: typing information needed for method
> reference bridging not preserved
> 8076039: Remove the unused internal API
> sun.reflect.misc.FieldUtil.getDeclaredFields
> 8052070: javac crashes when there are duplicated type parameters
> 8027888: javac wrongly allows annotations in array-typed class literals
> 8068254: Method reference uses wrong qualifying type
> 8037546: javac -parameters does not emit parameter names for lambda
> expressions
> 8062358: ClassCastException in TransTypes.visitApply
> 8067914: Redundant type cast nodes in AST (follow up from JDK-8043741)
> 8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch
> target
> 8043741: VerifyError due to missing checkcast
> 8066871: java.lang.VerifyError: Bad local variable type - local final
> String
>
> Votes are due by 2015-04-15.
>
> Only current JDK 9 Committers [2] are eligible to vote on this
> nomination. Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [3].
>
> Maurizio Cimadamore
>
> [1] http://openjdk.java.net/jeps/213
> [2]http://openjdk.java.net/census
> [3]http://openjdk.java.net/projects/#committer-vote
>
From lana.steuck at oracle.com Fri Apr 3 22:40:14 2015
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 3 Apr 2015 15:40:14 -0700 (PDT)
Subject: jdk9-b58: dev
Message-ID: <201504032240.t33MeENe020877@sc11152554.us.oracle.com>
http://hg.openjdk.java.net/jdk9/jdk9/rev/6e78dd9b1210
http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/5096a7cca5f0
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/07ce89fec301
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/36fc65e80d81
http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/1e06b36bb396
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/270fb9a2dcb5
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ee878f3d6732
http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/86dd5de1f5cb
---
All the fixes will be tested during promotion (no PIT testing at this point):
List of all fixes:
===================
JDK-8076531 infra Switch default compiler on Windows to VS2013
From erik.helin at oracle.com Tue Apr 7 08:19:21 2015
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 7 Apr 2015 10:19:21 +0200
Subject: CFV: New JDK 9 Committer: Fredrik Arvidsson
In-Reply-To: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
References: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
Message-ID: <20150407081901.GA12262@ehelin.jrpg.bea.com>
Vote: yes
On 2015-03-30, Staffan Larsen wrote:
> I hereby nominate Fredrik Arvidsson to JDK 9 Committer.
>
> Fredrik is member of the Java Serviceability team at Oracle and has contributed 13 changesets to date. These include a new diagnostic command for listing loaded shared libraries, fixes to the serviceability agent and JVMTI for anonymous classes, adding support for large heaps in the serviceability agent?s hprof handling as well as various bug fixes in many places.
>
> Here is a list of Fredrik's changesets:
>
> 8031304: Add dcmd to print all loaded dynamic libraries.
> 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
> 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value
> 8025638: jmap returns 0 instead of 1 when it fails.
> 8056242: Add function to return structured information about loaded libraries.
> 8055755: Information about loaded dynamic libraries is wrong on MacOSX
> 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump
> 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed
> 6313383: SA: Update jmap to support HPROF binary format
> 8016845: SA is unable to use hsdis on windows
> 8059105: Add better failure reporting to com/sun/jdi/RunToExit.java test
> 8034203: Change JavaDoc for com.sun.jdi.request.EventRequest.setEnabled(boolean val)
> 4515292: ReferenceType.isStatic() returns true for arrays
>
> Votes are due by 2015-04-13.
>
> Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Staffan Larsen
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
From mikael.gerdin at oracle.com Tue Apr 7 08:20:06 2015
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 07 Apr 2015 10:20:06 +0200
Subject: CFV: New JDK 9 Committer: Fredrik Arvidsson
In-Reply-To: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
References: <4EF8BD0B-DF33-4C3E-A367-86CA4A869BC6@oracle.com>
Message-ID: <55239336.1080709@oracle.com>
Vote: yes
/Mikael
On 2015-03-30 09:47, Staffan Larsen wrote:
> I hereby nominate Fredrik Arvidsson to JDK 9 Committer.
>
> Fredrik is member of the Java Serviceability team at Oracle and has contributed 13 changesets to date. These include a new diagnostic command for listing loaded shared libraries, fixes to the serviceability agent and JVMTI for anonymous classes, adding support for large heaps in the serviceability agent?s hprof handling as well as various bug fixes in many places.
>
> Here is a list of Fredrik's changesets:
>
> 8031304: Add dcmd to print all loaded dynamic libraries.
> 8024423: JVMTI: GetLoadedClasses doesn't enumerate anonymous classes
> 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value
> 8025638: jmap returns 0 instead of 1 when it fails.
> 8056242: Add function to return structured information about loaded libraries.
> 8055755: Information about loaded dynamic libraries is wrong on MacOSX
> 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump
> 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed
> 6313383: SA: Update jmap to support HPROF binary format
> 8016845: SA is unable to use hsdis on windows
> 8059105: Add better failure reporting to com/sun/jdi/RunToExit.java test
> 8034203: Change JavaDoc for com.sun.jdi.request.EventRequest.setEnabled(boolean val)
> 4515292: ReferenceType.isStatic() returns true for arrays
>
> Votes are due by 2015-04-13.
>
> Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Staffan Larsen
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From erik.helin at oracle.com Tue Apr 7 11:15:52 2015
From: erik.helin at oracle.com (Erik Helin)
Date: Tue, 7 Apr 2015 13:15:52 +0200
Subject: Result: New jdk9 Committer: Kim Barrett
Message-ID: <20150407111552.GA22402@ehelin.jrpg.bea.com>
Voting for Kim Barrett [1] is now closed.
Yes: 26
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.
Erik Helin
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001994.html
From sean.mullan at oracle.com Tue Apr 7 12:23:42 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 07 Apr 2015 08:23:42 -0400
Subject: Result: New JDK 9 Committer: Jamil Nimeh
Message-ID: <5523CC4E.8070008@oracle.com>
Voting for Jamil Nimeh [1] is now closed.
Yes: 13
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.
Sean Mullan
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/002020.html
From alejandro.murillo at oracle.com Tue Apr 7 18:04:03 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Tue, 07 Apr 2015 12:04:03 -0600
Subject: jdk9-dev: HotSpot
Message-ID: <55241C13.3090500@oracle.com>
jdk9-hs-2015-04-02 has been integrated into jdk9-dev yesterday (4/6/2015) @ 12:38 PM
http://hg.openjdk.java.net/jdk9/dev/rev/24515a3f1da5
http://hg.openjdk.java.net/jdk9/dev/corba/rev/86dd5de1f5cb
http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/009d2d25b517
http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/80dd269612e2
http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/1e06b36bb396
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/27776337ac9e
http://hg.openjdk.java.net/jdk9/dev/langtools/rev/586b7ddbb42f
http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/862630898880
Component : VM
Status : Go for integration
Date : 04/06/2015 at 17:00 MSK
Tested By : VM SQE &dmitry.fazunenko at oracle.com
Bundles : 2015-03-26-210650.amurillo.jdk9-hs-2015-03-26-snapshot
Testing:
20 new failures, 2447 known failures, 329703 passed.
Issues and Notes:
No detailed analysis. No stoppers have been detected so far. Go for integration
CRs for testing:
8026047: [TESTBUG] add regression test for DisableExplicitGC flag
8027962: Per-phase timing measurements for strong roots processing
8057632: Remove auxiliary code used to handle the generations array
8061715: gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeException: heap decommit failed - after > before
8067891: Remove vestigal G1SATBCT barrier set kind
8073463: G1 does not mangle freed heap regions
8073944: Simplify ArgumentsExt and remove unneeded functionallity
8073994: STATIC_ASSERT use of __LINE__ is wrong
8074037: Refactor the G1GCPhaseTime logging to make it easier to add new phases
8074459: Flags handling memory sizes should be of type size_t
8075210: Refactor strong root processing in order to allow G1 to evolve separately from GenCollectedHeap
8075242: Remove SpecializationStats
8075247: Cleanup specialized_oop_closures.hpp
8075249: Cleanup forward_to_atomic and ClaimedForwardPtr
8075416: Cleanup GC include dependencies in memoryPool.hpp
8075420: Missing forward declarations in g1AllocationContext.hpp
8075511: Enable -Woverloaded-virtual C++ warning for HotSpot build
8075735: Missing include causes minimal build failure
8075803: Fix GC includes and forward declarations
8075807: Build without PCH on ARM is broken
8075809: Add missing includes of stack.inline.hpp
8075829: Move CSpaceCounters implementation to cSpaceCounters.cpp
8075860: aarch64: jdk9/dev fails to build
8076012: SA don't support flags of type size_t
--
Alejandro
From chachaparis at gmail.com Tue Apr 7 21:42:28 2015
From: chachaparis at gmail.com (chacha chacha)
Date: Wed, 8 Apr 2015 00:42:28 +0300
Subject: JCPP Project
Message-ID:
Hi
couldnt it be a good thing to provide with every JDK version a C++ API that
looks like what you can find in the following project
https://github.com/charb/jcpp
thank you for your time
From baiduzhyi.devel at gmail.com Wed Apr 8 08:44:37 2015
From: baiduzhyi.devel at gmail.com (Stanislav Baiduzhyi)
Date: Wed, 08 Apr 2015 10:44:37 +0200
Subject: JCPP Project
In-Reply-To:
References:
Message-ID: <1912897.uVxVrpbW8V@thinkpad.hell>
On Wednesday 08 April 2015 00:42:28 chacha chacha wrote:
> Hi
>
> couldnt it be a good thing to provide with every JDK version a C++ API that
> looks like what you can find in the following project
> https://github.com/charb/jcpp
>
> thank you for your time
Not answering for Oracle or anyone else, but I'm missing the point of the
project. It would be very nice to expand the readme file with following
points:
1. What problems are you trying to solve with this project.
2. Small sniplet of C++ code, before and after.
--
Regards,
Stas
From james.laskey at oracle.com Wed Apr 8 18:02:18 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 8 Apr 2015 15:02:18 -0300
Subject: RFR: 8076090: jimage extract + recreate broken again
Message-ID: <1C17B0E1-ED6E-461E-9EAA-554C5CBE5AD1@oracle.com>
The fix addresses problem with the jimage tool rebuilding meta data on windows systems (\ in path.) Including new test to verify that jimage tool does successfully extract and recreate.
JBS: https://bugs.openjdk.java.net/browse/JDK-8076090
Webrev: http://cr.openjdk.java.net/~jlaskey/8076090/webrev/index.html
From brett.bernstein at gmail.com Wed Apr 8 20:28:19 2015
From: brett.bernstein at gmail.com (Brett Bernstein)
Date: Wed, 8 Apr 2015 16:28:19 -0400
Subject: PriorityQueue
Message-ID:
To whom this may concern,
I apologize in advance if this isn't the correct place to ask something
like this, but I am interested in suggesting an addition to the
PriorityQueue class (namely adding a constructor that takes a Collection
and a Comparator), and want to know the correct channel to go through.
-Brett Bernstein
From mandy.chung at oracle.com Wed Apr 8 18:37:50 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 08 Apr 2015 11:37:50 -0700
Subject: RFR: 8076090: jimage extract + recreate broken again
In-Reply-To: <1C17B0E1-ED6E-461E-9EAA-554C5CBE5AD1@oracle.com>
References: <1C17B0E1-ED6E-461E-9EAA-554C5CBE5AD1@oracle.com>
Message-ID: <5525757E.9000501@oracle.com>
Forwarding to core-libs-dev for review (bcc jdk9-dev)
On 4/8/2015 11:02 AM, Jim Laskey (Oracle) wrote:
> The fix addresses problem with the jimage tool rebuilding meta data on windows systems (\ in path.) Including new test to verify that jimage tool does successfully extract and recreate.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8076090
> Webrev: http://cr.openjdk.java.net/~jlaskey/8076090/webrev/index.html
Looks fine to me.
The test will need to check if $JAVA_HOME is an exploded image
($JAVA_HOME/lib/modules not exists); if so, it should simply exit.
Otherwise the test will fail. Nit: line 24 is not unused.
FYI. jdk/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java could
be used.
Mandy
From martinrb at google.com Wed Apr 8 20:31:34 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Apr 2015 13:31:34 -0700
Subject: PriorityQueue
In-Reply-To:
References:
Message-ID:
[+ concurrency-interest]
Ask on the concurrency-interest mailing list.
jdk9-dev moved to cc:
On Wed, Apr 8, 2015 at 1:28 PM, Brett Bernstein
wrote:
> To whom this may concern,
> I apologize in advance if this isn't the correct place to ask something
> like this, but I am interested in suggesting an addition to the
> PriorityQueue class (namely adding a constructor that takes a Collection
> and a Comparator), and want to know the correct channel to go through.
>
> -Brett Bernstein
>
From brett.bernstein at gmail.com Wed Apr 8 20:41:40 2015
From: brett.bernstein at gmail.com (Brett Bernstein)
Date: Wed, 8 Apr 2015 16:41:40 -0400
Subject: PriorityQueue
In-Reply-To:
References:
Message-ID:
To whom it may concern:
I am hoping this is the correct venue for such a comment. My suggestion is
to add a constructor to the PriorityQueue class that takes a Collection and
a Comparator as arguments. If there is a good reason this isn't already in
the API I would love to know it. The benefit of such an addition is to
allow access for Comparator users to the quick heapify algorithm.
Thanks,
Brett Bernstein
On Wed, Apr 8, 2015 at 4:32 PM, Martin Buchholz wrote:
>
>
> On Wed, Apr 8, 2015 at 1:31 PM, Martin Buchholz
> wrote:
>
>>
>> jdk9-dev moved to cc:
>>
>
> Err ... bcc
>
From lana.steuck at oracle.com Wed Apr 8 22:31:16 2015
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 8 Apr 2015 15:31:16 -0700 (PDT)
Subject: jdk9-b59: dev
Message-ID: <201504082231.t38MVGG0007953@sc11152554.us.oracle.com>
http://hg.openjdk.java.net/jdk9/jdk9/rev/39e8a131289e
http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/ea4e794c3927
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/a598534d277e
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/48ee960f29df
http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/8a9ebae410bc
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/a1a9d9434469
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/96bcaec07cb1
http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/cda6ae062f85
---
All the fixes will be tested during promotion (no PIT testing at this point):
List of all fixes:
===================
JDK-8074668 client-libs [macosx] Mac 10.10: Application run with splash screen has focus issue
JDK-8075244 client-libs [macosx] The fix for JDK-8043869 should be reworked
JDK-8074807 client-libs Fix some tests unnecessary using internal API
JDK-8074954 client-libs ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
JDK-8040328 client-libs JSlider has wrong preferred size with Synth LAF
JDK-4473075 client-libs JTable header rendering problem (after setting preferred size)
JDK-8073008 client-libs press-and-hold input method for accented characters works incorrectly
JDK-8075717 client-libs Replace INTERNAL_BUILD with DEBUG in awt
JDK-8076644 core-libs (dc) MulticastSendReceiveTests.java fails with NumberFormatException d
JDK-7021006 core-libs (process) Remove disabled clone-exec feature
JDK-8075667 core-libs (tz) Support tzdata2015b
JDK-8075959 core-libs Change parameter names in some IOException subclasses
JDK-8076184 core-libs Cleanup compile/link warnings on Solaris
JDK-8076441 core-libs Dead code in java.time.chrono.Chronology.isLeapYear after fixing JDK-
JDK-8074578 core-libs Document memory visibility effects of Unsafe compareAndSwap methods
JDK-8071667 core-libs HashMap.computeIfAbsent() adds entry that HashMap.get() does not find.
JDK-8076105 core-libs java/util/zip/EntryCount64k.java failing after push for JDK-8073158
JDK-7113878 core-libs LogManager - namedLoggers should be ConcurrentHashMap instead of Hasht
JDK-8075810 core-libs LogManager.readConfiguration may throw undocumented IllegalArgumentExc
JDK-8076646 core-libs nashorn tests should avoid using package names used by nashorn sources
JDK-8073868 core-libs Regex matching causes java.lang.ArrayIndexOutOfBoundsException: 64
JDK-8076632 core-libs Remove duplicate tests: FDTest, MethodReferenceTest and more -- follow
JDK-8075304 core-libs Remove duplicate tests: FDTest, MethodReferenceTest and more
JDK-8076039 core-libs Remove the unused internal API sun.reflect.misc.FieldUtil.getDeclaredF
JDK-8075548 core-libs SimpleDateFormat formatting of "LLLL" in English is incorrect; should
JDK-8075366 core-libs Slow scope access to global let/const does not work
JDK-8075774 core-libs Small readability and performance improvements for zipfs
JDK-8075231 core-libs Typed array setters are very slow when index exceeds capacity
JDK-8073158 core-libs zip files with total entry count 0xFFFF need not be ZIP64 files
JDK-8074402 deploy Add DRS rules block to Java Usage Tracker records.
JDK-8000104 deploy default preloader fails to show progress dialog for webstart app
JDK-8075708 deploy Deploy netbeans project do not work on Windows
JDK-8074961 deploy Ensure JFR options could be passed to webstart app by specifying VM ar
JDK-8074105 deploy Remove support for downloaded JavaFX classes
JDK-8075179 deploy Test jnlp_file/applicationDesc/index.html#args fails with incorrect ar
JDK-8026047 hotspot [TESTBUG] add regression test for DisableExplicitGC flag
JDK-8075860 hotspot aarch64 fails to build
JDK-8075586 hotspot Add @modules as needed to the open hotspot tests
JDK-8075809 hotspot Add missing includes of stack.inline.hpp
JDK-8075249 hotspot Cleanup forward_to_atomic and ClaimedForwardPtr
JDK-8075416 hotspot Cleanup GC include dependencies in memoryPool.hpp
JDK-8075247 hotspot Cleanup specialized_oop_closures.hpp
JDK-8075511 hotspot Enable -Woverloaded-virtual C++ warning for HotSpot build
JDK-8075803 hotspot Fix GC includes and forward declarations
JDK-8074459 hotspot Flags handling memory sizes should be of type size_t
JDK-8073463 hotspot G1 does not mangle freed heap regions
JDK-8061715 hotspot gc/g1/TestShrinkAuxiliaryData15.java fails with java.lang.RuntimeExcep
JDK-8075735 hotspot Missing include causes minimal build failure
JDK-8075829 hotspot Move CSpaceCounters implementation to cSpaceCounters.cpp
JDK-8027962 hotspot Per-phase timing measurements for strong roots processing
JDK-8075210 hotspot Refactor strong root processing in order to allow G1 to evolve separat
JDK-8074037 hotspot Refactor the G1GCPhaseTime logging to make it easier to add new phases
JDK-8057632 hotspot Remove auxiliary code used to handle the generations array
JDK-8075242 hotspot Remove SpecializationStats
JDK-8067891 hotspot Remove vestigal G1SATBCT barrier set kind
JDK-8076012 hotspot SA don't support flags of type size_t
JDK-8073944 hotspot Simplify ArgumentsExt and remove unneeded functionallity
JDK-8073994 hotspot STATIC_ASSERT use of __LINE__ is wrong
JDK-8076060 infrastructure Improve make bootstrap process
JDK-8075277 infrastructure JDK is still building X11 related Java files on OSX
JDK-8072740 infrastructure move closed jvm.cfg files out of open repo
JDK-8061346 infrastructure Source changes needed to build JDK 9 with Mac OS 9 'Maverics' and clan
JDK-8056992 install [AU]The auto update window does not read the tag of au-desc
JDK-8058929 install [de, fr, it, ko, pt_BR, sv] Layout issue (truncation) in AUWelcome dia
JDK-8049608 install HtmlUI: "Change destination folder" checkbox in WelcomeDialog is not a
JDK-8049614 install HtmlUI: checkbox text labels should be clickable
JDK-8036770 install replace wrapper dialogs with HtmlU
JDK-8059588 security-libs deadlock in java/io/PrintStream when verbose java.security.debug flags
JDK-8076420 tools Consolidate javac file handling in javac.file package
JDK-8054220 tools Debugger doesn't show variables *outside* lambda
JDK-8058227 tools Debugger has no access to outer variables inside Lambda
JDK-8076026 tools DocTree should parse hyphenated attributes correctly
JDK-7040592 tools Gen.java: fix code for handling 'null' literal when expected type is a
JDK-8075610 tools java.desktop module dependency can be eliminated in tools/javac/generi
JDK-8075184 tools javac is mistakenly considering a missing enclosing instance error as
JDK-8075752 tools jdk.compiler dependency can be eliminated in MethodReferenceNullCheckT
JDK-8076583 tools move jdk.Exported from langtools to jdk
JDK-8062373 tools Project Coin: diamond and anonymous classes
JDK-8074840 tools Resolve disabled warnings for libjli and libjli_static
JDK-8073385 xml Bad error message on parsing illegal character in XML attribute
JDK-8076290 xml JCK test api/xsl/conf/string/string17 starts failing after JDK-8074297
JDK-8074297 xml substring in XSLT returns wrong character if string contains supplemen
From alexandr.scherbatiy at oracle.com Thu Apr 9 13:57:11 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 09 Apr 2015 16:57:11 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
Message-ID: <55268537.9090809@oracle.com>
I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
Semyon is a member of the Java Client team. He has made several
non-trivial contributions to the AWT and Swing areas.
Here is a list of Semyon's changesets:
http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
Votes are due by April 23, 2015.
Only current JDK 9 Committers [1] are eligible to vote
on this nomination. Votes must be cast in the open by replying
to this mailing list.
For Lazy Consensus voting instructions, see [2].
Thanks,
Alexandr.
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote
From yuri.nesterenko at oracle.com Thu Apr 9 13:59:39 2015
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Thu, 09 Apr 2015 16:59:39 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
In-Reply-To: <55268537.9090809@oracle.com>
References: <55268537.9090809@oracle.com>
Message-ID: <552685CB.40908@oracle.com>
Vote: yes
-yan
On 04/09/2015 04:57 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
>
> Semyon is a member of the Java Client team. He has made several
> non-trivial contributions to the AWT and Swing areas.
> Here is a list of Semyon's changesets:
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
>
> Votes are due by April 23, 2015.
>
> Only current JDK 9 Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From alexander.zvegintsev at oracle.com Thu Apr 9 14:00:10 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 09 Apr 2015 17:00:10 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
In-Reply-To: <55268537.9090809@oracle.com>
References: <55268537.9090809@oracle.com>
Message-ID: <552685EA.6080809@oracle.com>
Vote: yes
Thanks,
Alexander.
On 04/09/2015 04:57 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
>
> Semyon is a member of the Java Client team. He has made several
> non-trivial contributions to the AWT and Swing areas.
> Here is a list of Semyon's changesets:
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
>
> Votes are due by April 23, 2015.
>
> Only current JDK 9 Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From vadim.pakhnushev at oracle.com Thu Apr 9 14:40:58 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Thu, 09 Apr 2015 17:40:58 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
In-Reply-To: <55268537.9090809@oracle.com>
References: <55268537.9090809@oracle.com>
Message-ID: <55268F7A.2060104@oracle.com>
Vote: yes
On 09.04.2015 16:57, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
>
> Semyon is a member of the Java Client team. He has made several
> non-trivial contributions to the AWT and Swing areas.
> Here is a list of Semyon's changesets:
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
>
> Votes are due by April 23, 2015.
>
> Only current JDK 9 Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From artem.ananiev at oracle.com Thu Apr 9 14:42:20 2015
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Thu, 09 Apr 2015 17:42:20 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
In-Reply-To: <55268537.9090809@oracle.com>
References: <55268537.9090809@oracle.com>
Message-ID: <55268FCC.4060501@oracle.com>
Vote: yes
Artem
On 04/09/15 4:57 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
>
> Semyon is a member of the Java Client team. He has made several
> non-trivial contributions to the AWT and Swing areas.
> Here is a list of Semyon's changesets:
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
>
> Votes are due by April 23, 2015.
>
> Only current JDK 9 Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From alexandr.scherbatiy at oracle.com Thu Apr 9 15:39:05 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 09 Apr 2015 18:39:05 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
In-Reply-To: <55268537.9090809@oracle.com>
References: <55268537.9090809@oracle.com>
Message-ID: <55269D19.1000804@oracle.com>
Vote: yes
Thanks,
Alexandr.
On 4/9/2015 4:57 PM, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
>
> Semyon is a member of the Java Client team. He has made several
> non-trivial contributions to the AWT and Swing areas.
> Here is a list of Semyon's changesets:
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
>
> Votes are due by April 23, 2015.
>
> Only current JDK 9 Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
From mark.reinhold at oracle.com Thu Apr 9 20:22:44 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 09 Apr 2015 13:22:44 -0700
Subject: JEP proposed to target JDK 9 (2015/4/9)
Message-ID: <20150409132244.429814@eggemoggin.niobe.net>
The following JEP has been placed into the "Proposed to Target"
state by its owner after discussion and review:
243: Java-Level JVM Compiler Interface http://openjdk.java.net/jeps/243
Feedback on this proposals is more than welcome, as are reasoned
objections. If no such objections are raised by 21:00 UTC next
Thursday, 16 April, or if they're raised and then satisfactorily
answered, then per the JEP 2.0 process proposal [1] I'll target
these JEPs to JDK 9.
(This information is also available on the JDK 9 Project Page [2]).
- Mark
[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
[2] http://openjdk.java.net/projects/jdk9/
From Sergey.Bylokhov at oracle.com Thu Apr 9 22:08:15 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 10 Apr 2015 01:08:15 +0300
Subject: CFV: New JDK 9 Committer: Semyon Sadetsky
In-Reply-To: <55268537.9090809@oracle.com>
References: <55268537.9090809@oracle.com>
Message-ID: <5526F84F.5070705@oracle.com>
Vote: Yes
On 09.04.15 16:57, Alexander Scherbatiy wrote:
>
> I hereby nominate Semyon Sadetsky (ssadetsky) to JDK 9 Committer.
>
> Semyon is a member of the Java Client team. He has made several
> non-trivial contributions to the AWT and Swing areas.
> Here is a list of Semyon's changesets:
> http://hg.openjdk.java.net/jdk9/client/jdk/log?rev=ssadetsky
>
> Votes are due by April 23, 2015.
>
> Only current JDK 9 Committers [1] are eligible to vote
> on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> Alexandr.
>
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/projects/#committer-vote
>
--
Best regards, Sergey.
From john.r.rose at oracle.com Thu Apr 9 22:42:25 2015
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 9 Apr 2015 15:42:25 -0700
Subject: JCPP Project
In-Reply-To:
References:
Message-ID: <174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
For C++ bridging, look at:
https://github.com/bytedeco/javacpp
A great C bridging solution is:
https://github.com/jnr
For discussions of something better than JNI for the JDK, I offer this:
https://blogs.oracle.com/jrose/entry/the_isthmus_in_the_vm
Project Panama will eventually create standard ways to work with C++ APIs in Java syntax.
For the reverse direction (using Java APIs in C++ syntax) I don't have any suggestions.
It is unlikely that the JDK will supply tools for programming in C++, even if the APIs somehow relate to Java.
? John
From mark.reinhold at oracle.com Thu Apr 9 23:15:24 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 09 Apr 2015 16:15:24 -0700
Subject: JEPs proposed to target JDK 9 (2015/4/2)
In-Reply-To: <20150402153209.528656@eggemoggin.niobe.net>
References: <20150402153209.528656@eggemoggin.niobe.net>
Message-ID: <20150409161524.797869@eggemoggin.niobe.net>
2015/4/2 3:32 -0700, mark.reinhold at oracle.com:
> The following JEPs have been placed into the "Proposed to Target"
> state by their owners after discussion and review:
>
> 240: Remove the JVM TI hprof Agent http://openjdk.java.net/jeps/240
> 241: Remove the jhat Tool http://openjdk.java.net/jeps/241
>
> Feedback on these proposals is more than welcome, as are reasoned
> objections. If no such objections are raised by 23:00 UTC next
> Thursday, 9 April, or if they're raised and then satisfactorily
> answered, then per the JEP 2.0 process proposal [1] I'll target
> these JEPs to JDK 9.
Hearing no objections, I've targeted these JEPs to JDK 9.
- Mark
From chachaparis at gmail.com Fri Apr 10 12:48:00 2015
From: chachaparis at gmail.com (Chacha Chacha)
Date: Fri, 10 Apr 2015 15:48:00 +0300
Subject: JCPP Project
In-Reply-To: <174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
References:
<174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
Message-ID:
Hi John,
The listed project solve the following problem: I am a Java developer, I
need a C/C++ functionality that doesn't exist in Java how can I use it
The problem that I am trying to solve is different and the following.
Imagine a 30 years old financial software company. Initially it started
with C development and few developers. With time and success, they got more
market, more money, more developers, more millions of line of C code.
In the early 2000, Java becomes a serious technology for the front end and
the back end. So they decide to inject Java in their software, for the
front end and some few multi-threaded servers. Currently, 90% of their
software is developed with C/C++ with 200 developers, and 10% developed
with Java with few dozens developers.
The majority of developers and management would like to use Java, but
reality catches up.
In that context, it is very hard to say just rewrite everything from
scratch in Java.
Several strategies were tried with little success:
1. In pure C/C++ process call through jni Java methods. Not scalable,
hard to debug and maintain
2. Isolate some modules developed in C++ and redevelop them in Java
In that case, how process developed in Java and in C++ should call
each other?
Using different kind of RPC technologies, different kind of protocols.
None of tried solutions during the last decade was scalable and efficient
enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
The bulk that is in C/C++ is forbidding them to have solutions where Java
is involved and has a bigger place in the product.
My approach was to say, among the C/C++ code, we can inject some Java
related technologies and concepts that will allow the following:
1. C/C++ developers willing to move to Java will be happy to have that
technology in their ecosystem as it is like Java
2. It is a step closer to shift everything to Java
3. Best way to implement interoperability between C/C++ and Java
I understand that I am describing a special case where the legacy code is
so important that it cant be redeveloped using Java.
We don't encounter such thing every day, only in big companies maybe...
It would be a pity if Oracle and the Java engineers don't take that into
account at certain moment.
Of course, tell me if something that I described is not clear.
From neugens.limasoftware at gmail.com Fri Apr 10 13:14:22 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 10 Apr 2015 15:14:22 +0200
Subject: JCPP Project
In-Reply-To:
References:
<174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
Message-ID:
2015-04-10 14:48 GMT+02:00 Chacha Chacha :
> Hi John,
>
> The listed project solve the following problem: I am a Java developer, I
> need a C/C++ functionality that doesn't exist in Java how can I use it
>
> The problem that I am trying to solve is different and the following.
> Imagine a 30 years old financial software company. Initially it started
> with C development and few developers. With time and success, they got more
> market, more money, more developers, more millions of line of C code.
>
> In the early 2000, Java becomes a serious technology for the front end and
> the back end. So they decide to inject Java in their software, for the
> front end and some few multi-threaded servers. Currently, 90% of their
> software is developed with C/C++ with 200 developers, and 10% developed
> with Java with few dozens developers.
> The majority of developers and management would like to use Java, but
> reality catches up.
>
> In that context, it is very hard to say just rewrite everything from
> scratch in Java.
> Several strategies were tried with little success:
>
> 1. In pure C/C++ process call through jni Java methods. Not scalable,
> hard to debug and maintain
>
> 2. Isolate some modules developed in C++ and redevelop them in Java
> In that case, how process developed in Java and in C++ should call
> each other?
> Using different kind of RPC technologies, different kind of protocols.
> None of tried solutions during the last decade was scalable and efficient
> enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
>
>
> The bulk that is in C/C++ is forbidding them to have solutions where Java
> is involved and has a bigger place in the product.
>
> My approach was to say, among the C/C++ code, we can inject some Java
> related technologies and concepts that will allow the following:
>
> 1. C/C++ developers willing to move to Java will be happy to have that
> technology in their ecosystem as it is like Java
>
> 2. It is a step closer to shift everything to Java
>
> 3. Best way to implement interoperability between C/C++ and Java
>
>
> I understand that I am describing a special case where the legacy code is
> so important that it cant be redeveloped using Java.
> We don't encounter such thing every day, only in big companies maybe...
>
> It would be a pity if Oracle and the Java engineers don't take that into
> account at certain moment.
> Of course, tell me if something that I described is not clear.
Maybe I'm not following you, but you can very well replace portions of
your application with Java and keep most of it running as native code,
and John Rose gave you exactly the pointers needed to help out in this
task (you can even start a virtual machine from a C application btw -
this is so flexible that you could in theory even never write a line
of java code and execute everything via JNI! [1])
Now, a nice native API that maps 1-to-1 with Java maybe be nice to
have, however there are valid alternatives that expose similar
concepts, look at QT, or the Objective C libraries.
Your project seems to be something like that, but as much as a nice
and even interesting idea, I think it's entirely off-topic for Java.
This is something perhaps more interesting from a Java perspective
that you may want to look (and perhaps contribute!):
http://openjdk.java.net/jeps/191
Cheers,
Mario
[1] And yes, I've seen that too!! :S
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
http://endsoftpatents.org/
From tomasz.kowalczewski at gmail.com Fri Apr 10 13:21:40 2015
From: tomasz.kowalczewski at gmail.com (Tomasz Kowalczewski)
Date: Fri, 10 Apr 2015 15:21:40 +0200
Subject: JCPP Project
In-Reply-To:
References:
<174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
Message-ID:
Maybe you can use in memory IPC provided by open source libraries such as
openhft.net? Or you can extract java microservices and use Aeron for low
latency communication (don't know what is the state of C++ implementation).
In both cases you can use SBE (
https://github.com/real-logic/simple-binary-encoding) for fast, allocation
free encoding (much faster than protobuf).
Cheers,
Tomasz
On Fri, Apr 10, 2015 at 3:14 PM, Mario Torre wrote:
> 2015-04-10 14:48 GMT+02:00 Chacha Chacha :
> > Hi John,
> >
> > The listed project solve the following problem: I am a Java developer, I
> > need a C/C++ functionality that doesn't exist in Java how can I use it
> >
> > The problem that I am trying to solve is different and the following.
> > Imagine a 30 years old financial software company. Initially it started
> > with C development and few developers. With time and success, they got
> more
> > market, more money, more developers, more millions of line of C code.
> >
> > In the early 2000, Java becomes a serious technology for the front end
> and
> > the back end. So they decide to inject Java in their software, for the
> > front end and some few multi-threaded servers. Currently, 90% of their
> > software is developed with C/C++ with 200 developers, and 10% developed
> > with Java with few dozens developers.
> > The majority of developers and management would like to use Java, but
> > reality catches up.
> >
> > In that context, it is very hard to say just rewrite everything from
> > scratch in Java.
> > Several strategies were tried with little success:
> >
> > 1. In pure C/C++ process call through jni Java methods. Not scalable,
> > hard to debug and maintain
> >
> > 2. Isolate some modules developed in C++ and redevelop them in Java
> > In that case, how process developed in Java and in C++ should call
> > each other?
> > Using different kind of RPC technologies, different kind of
> protocols.
> > None of tried solutions during the last decade was scalable and efficient
> > enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
> >
> >
> > The bulk that is in C/C++ is forbidding them to have solutions where Java
> > is involved and has a bigger place in the product.
> >
> > My approach was to say, among the C/C++ code, we can inject some Java
> > related technologies and concepts that will allow the following:
> >
> > 1. C/C++ developers willing to move to Java will be happy to have
> that
> > technology in their ecosystem as it is like Java
> >
> > 2. It is a step closer to shift everything to Java
> >
> > 3. Best way to implement interoperability between C/C++ and Java
> >
> >
> > I understand that I am describing a special case where the legacy code is
> > so important that it cant be redeveloped using Java.
> > We don't encounter such thing every day, only in big companies maybe...
> >
> > It would be a pity if Oracle and the Java engineers don't take that into
> > account at certain moment.
> > Of course, tell me if something that I described is not clear.
>
> Maybe I'm not following you, but you can very well replace portions of
> your application with Java and keep most of it running as native code,
> and John Rose gave you exactly the pointers needed to help out in this
> task (you can even start a virtual machine from a C application btw -
> this is so flexible that you could in theory even never write a line
> of java code and execute everything via JNI! [1])
>
> Now, a nice native API that maps 1-to-1 with Java maybe be nice to
> have, however there are valid alternatives that expose similar
> concepts, look at QT, or the Objective C libraries.
>
> Your project seems to be something like that, but as much as a nice
> and even interesting idea, I think it's entirely off-topic for Java.
>
> This is something perhaps more interesting from a Java perspective
> that you may want to look (and perhaps contribute!):
>
> http://openjdk.java.net/jeps/191
>
> Cheers,
> Mario
>
> [1] And yes, I've seen that too!! :S
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>
--
Tomasz Kowalczewski
From dmitry.samersoff at oracle.com Fri Apr 10 14:03:00 2015
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 10 Apr 2015 17:03:00 +0300
Subject: JCPP Project
In-Reply-To:
References: <174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
Message-ID: <5527D814.3010306@oracle.com>
Chacha,
> The problem that I am trying to solve is different and the following.
> Imagine a 30 years old financial software company. Initially it
> started with C development and few developers. With time and
> success, they got more market, more money, more developers, more
> millions of line of C code.
Just FYI.
I was involved into similar project in a bank some years ago (prior
Oracle). We successfully partition our application and use CORBA to
communicate C++, Java and Python parts together.
-Dmitry
On 2015-04-10 15:48, Chacha Chacha wrote:
> Hi John,
>
> The listed project solve the following problem: I am a Java developer, I
> need a C/C++ functionality that doesn't exist in Java how can I use it
>
> The problem that I am trying to solve is different and the following.
> Imagine a 30 years old financial software company. Initially it started
> with C development and few developers. With time and success, they got more
> market, more money, more developers, more millions of line of C code.
>
> In the early 2000, Java becomes a serious technology for the front end and
> the back end. So they decide to inject Java in their software, for the
> front end and some few multi-threaded servers. Currently, 90% of their
> software is developed with C/C++ with 200 developers, and 10% developed
> with Java with few dozens developers.
> The majority of developers and management would like to use Java, but
> reality catches up.
>
> In that context, it is very hard to say just rewrite everything from
> scratch in Java.
> Several strategies were tried with little success:
>
> 1. In pure C/C++ process call through jni Java methods. Not scalable,
> hard to debug and maintain
>
> 2. Isolate some modules developed in C++ and redevelop them in Java
> In that case, how process developed in Java and in C++ should call
> each other?
> Using different kind of RPC technologies, different kind of protocols.
> None of tried solutions during the last decade was scalable and efficient
> enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
>
>
> The bulk that is in C/C++ is forbidding them to have solutions where Java
> is involved and has a bigger place in the product.
>
> My approach was to say, among the C/C++ code, we can inject some Java
> related technologies and concepts that will allow the following:
>
> 1. C/C++ developers willing to move to Java will be happy to have that
> technology in their ecosystem as it is like Java
>
> 2. It is a step closer to shift everything to Java
>
> 3. Best way to implement interoperability between C/C++ and Java
>
>
> I understand that I am describing a special case where the legacy code is
> so important that it cant be redeveloped using Java.
> We don't encounter such thing every day, only in big companies maybe...
>
> It would be a pity if Oracle and the Java engineers don't take that into
> account at certain moment.
> Of course, tell me if something that I described is not clear.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From chachaparis at gmail.com Fri Apr 10 14:05:12 2015
From: chachaparis at gmail.com (Chacha Chacha)
Date: Fri, 10 Apr 2015 17:05:12 +0300
Subject: JCPP Project
In-Reply-To:
References:
<174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
Message-ID:
The code is composed of several millions line of code.
1. Rewriting everything in one shot is not possible, we would be forced
to stop evolving it and be only in maintenance mode (bug fixes)
2. That means that the only way is to move parts of it. These parts
should be self descriptive, autonomous to form a module, to be moved to Java
As we still have the other parts in C/C++, how can we interact with
the new part.
Either using RPC in another process or in the same process using
JNI/JNA/FFI.
The later was used during years and was not scalable:
+ hard to debugg when you have stacks that go both side C/Java.
Needs 2 IDEs, debuggers,...
+ error prone and when it crashed not easy to know why
It makes sense when you have a JVM running 99% of the functionalities
and the remaining 1% developed in C/C++ are accessed via FFI.
Not in my case where we have 99% of a process developed using C/C++
trying to have a very rich interaction (both direct calls) with the
remaining 1% developed in Java.
Also looked at QT and Objective C and decided to go in that direction for
the following reasons:
+ explicitly wanted to have an API very close to Java so that the move
from C/C++ to Java would be easy and automated
+ offer to the C/C++ developers same open sources that once could find
in Java
Hope it is clearer.
2015-04-10 16:14 GMT+03:00 Mario Torre :
> 2015-04-10 14:48 GMT+02:00 Chacha Chacha :
> > Hi John,
> >
> > The listed project solve the following problem: I am a Java developer, I
> > need a C/C++ functionality that doesn't exist in Java how can I use it
> >
> > The problem that I am trying to solve is different and the following.
> > Imagine a 30 years old financial software company. Initially it started
> > with C development and few developers. With time and success, they got
> more
> > market, more money, more developers, more millions of line of C code.
> >
> > In the early 2000, Java becomes a serious technology for the front end
> and
> > the back end. So they decide to inject Java in their software, for the
> > front end and some few multi-threaded servers. Currently, 90% of their
> > software is developed with C/C++ with 200 developers, and 10% developed
> > with Java with few dozens developers.
> > The majority of developers and management would like to use Java, but
> > reality catches up.
> >
> > In that context, it is very hard to say just rewrite everything from
> > scratch in Java.
> > Several strategies were tried with little success:
> >
> > 1. In pure C/C++ process call through jni Java methods. Not scalable,
> > hard to debug and maintain
> >
> > 2. Isolate some modules developed in C++ and redevelop them in Java
> > In that case, how process developed in Java and in C++ should call
> > each other?
> > Using different kind of RPC technologies, different kind of
> protocols.
> > None of tried solutions during the last decade was scalable and efficient
> > enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
> >
> >
> > The bulk that is in C/C++ is forbidding them to have solutions where Java
> > is involved and has a bigger place in the product.
> >
> > My approach was to say, among the C/C++ code, we can inject some Java
> > related technologies and concepts that will allow the following:
> >
> > 1. C/C++ developers willing to move to Java will be happy to have
> that
> > technology in their ecosystem as it is like Java
> >
> > 2. It is a step closer to shift everything to Java
> >
> > 3. Best way to implement interoperability between C/C++ and Java
> >
> >
> > I understand that I am describing a special case where the legacy code is
> > so important that it cant be redeveloped using Java.
> > We don't encounter such thing every day, only in big companies maybe...
> >
> > It would be a pity if Oracle and the Java engineers don't take that into
> > account at certain moment.
> > Of course, tell me if something that I described is not clear.
>
> Maybe I'm not following you, but you can very well replace portions of
> your application with Java and keep most of it running as native code,
> and John Rose gave you exactly the pointers needed to help out in this
> task (you can even start a virtual machine from a C application btw -
> this is so flexible that you could in theory even never write a line
> of java code and execute everything via JNI! [1])
>
> Now, a nice native API that maps 1-to-1 with Java maybe be nice to
> have, however there are valid alternatives that expose similar
> concepts, look at QT, or the Objective C libraries.
>
> Your project seems to be something like that, but as much as a nice
> and even interesting idea, I think it's entirely off-topic for Java.
>
> This is something perhaps more interesting from a Java perspective
> that you may want to look (and perhaps contribute!):
>
> http://openjdk.java.net/jeps/191
>
> Cheers,
> Mario
>
> [1] And yes, I've seen that too!! :S
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>
From gitne at gmx.de Fri Apr 10 14:11:17 2015
From: gitne at gmx.de (Jacob Wisor)
Date: Fri, 10 Apr 2015 16:11:17 +0200
Subject: JCPP Project
In-Reply-To:
References: <174749D8-CCE9-47A3-826C-47F1F65A6D73@oracle.com>
Message-ID: <5527DA05.9070501@gmx.de>
Hello Chacha,
Am 10.04.2015 um 14:48 schrieb Chacha Chacha:
> Hi John,
>
> The listed project solve the following problem: I am a Java developer, I
> need a C/C++ functionality that doesn't exist in Java how can I use it
>
> The problem that I am trying to solve is different and the following.
> Imagine a 30 years old financial software company. Initially it started
> with C development and few developers. With time and success, they got more
> market, more money, more developers, more millions of line of C code.
>
> In the early 2000, Java becomes a serious technology for the front end and
> the back end. So they decide to inject Java in their software, for the
> front end and some few multi-threaded servers. Currently, 90% of their
> software is developed with C/C++ with 200 developers, and 10% developed
> with Java with few dozens developers.
> The majority of developers and management would like to use Java, but
> reality catches up.
>
> In that context, it is very hard to say just rewrite everything from
> scratch in Java.
> Several strategies were tried with little success:
>
> 1. In pure C/C++ process call through jni Java methods. Not scalable,
> hard to debug and maintain
>
> 2. Isolate some modules developed in C++ and redevelop them in Java
> In that case, how process developed in Java and in C++ should call
> each other?
> Using different kind of RPC technologies, different kind of protocols.
> None of tried solutions during the last decade was scalable and efficient
> enough (Corba, SOAP, WebServices, REST, ProtoBuf, ...)
>
>
> The bulk that is in C/C++ is forbidding them to have solutions where Java
> is involved and has a bigger place in the product.
>
> My approach was to say, among the C/C++ code, we can inject some Java
> related technologies and concepts that will allow the following:
>
> 1. C/C++ developers willing to move to Java will be happy to have that
> technology in their ecosystem as it is like Java
>
> 2. It is a step closer to shift everything to Java
>
> 3. Best way to implement interoperability between C/C++ and Java
>
>
> I understand that I am describing a special case where the legacy code is
> so important that it cant be redeveloped using Java.
> We don't encounter such thing every day, only in big companies maybe...
>
> It would be a pity if Oracle and the Java engineers don't take that into
> account at certain moment.
> Of course, tell me if something that I described is not clear.
>
I have come to usually ignoring such stuff by now but I cannot resist the urge
to comment on this, simply because I have been through similar stuff.
All of this reads to me like you are trying to fix bad management decisions
with technology. The thing you are looking for is called JNI and there are good
reasons for the way it has been designed. But actually, you are neither looking
for JNI nor JCPP. You are looking for a master plan in your company to fully
transition to Java. If your company has the resources to hire 200 C/C++
developers plus 10 Java developers, and obviously has the money and potential to
do so, your management is apparently still not sure whether they want to make a
move to Java or not. Unfortunately, most non-developers or non-geeks do not
understand that Java is far more than just a programming language and what its
true benefits are. It's a platform, an entire computing ecosystem. Another often
inhibiting factor is the fact that companies start developing internal software
without being aware of having partially become a software company too. Man, I
have seen people really denying this although their service relied on thousands
of lines of custom code.
In my experience, there does not exist code that cannot get reimplemented. When
it comes to transitioning to a new technology 99% of the so called "problems"
can be attributed to the fact that people just do not want to take the hard
walk, they chose the quick and easy path. Indeed, the larger the company or code
base that a service relies on the more rewarding is a clean cut afterwards, yes
even when it costs a lot of money initially. I have experienced this myself
first hand, in a company that already had a quite successful product with about
a million lines of code. However, I must admit that they have been very eager to
really make use of the benefits Java has to offer. Instead of just
transitioning, they developed an entirely new Java-only product. And, they have
become far more successful with the new product than they have even been or
could have ever been with their old product. But, one major reason for their
success is the fact that they have made a clear decision very early on not to
bother with the legacy product anymore and redevelop the product in Java as
quickly as possible.
My advice, especially with regards to (2.) is to keep on reimplementing modules
or perhaps consolidating code pieces and functionality into new modules. Try not
to bother about legacy support or as little as possible. Put all efforts into
developing in Java. If a module seems to be lacking support for legacy code then
you should start looking at it differently: It is not lacking anything, it
simply is not ready for deployment yet and needs additional coding or other
modules reimplemented. Adding support for legacy code in every new Java module
is often just a waste of time, effort, and money. Just go with Java and be patient.
Regards,
Jacob
From joe.darcy at oracle.com Fri Apr 10 18:34:01 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 10 Apr 2015 11:34:01 -0700
Subject: Diamond syntax with anonymous class constructors now available in
JDK 9 build 59
Message-ID: <55281799.1000005@oracle.com>
Hello,
Thanks to efforts by Srikanth and Dan, on the javac and JLS fronts,
respectively, anonymous classes constructors can now use diamond syntax
(in many cases) as of JDK 9 build 59:
https://jdk9.java.net/download/
The summary of the change is that when the inferred type for the diamond
is denotable (no intersection types, no capture variables, etc.), then
diamond can be used for anonymous classes. For more technical details, see:
JDK-8062373: Project Coin: diamond and anonymous classes,
https://bugs.openjdk.java.net/browse/JDK-8062373
JDK-8073593: 15.9: Allow diamond to be used with anonymous classes,
https://bugs.openjdk.java.net/browse/JDK-8073593
Please give the feature a try and report any issues to any issues to
compiler-dev.
Thanks,
-Joe
From staffan.larsen at oracle.com Tue Apr 14 07:19:29 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 14 Apr 2015 09:19:29 +0200
Subject: Result: New JDK 9 Committer: Fredrik Arvidsson
Message-ID: <0855B3BF-A2DD-488B-9CB6-FCDE46CE162B@oracle.com>
Voting for Fredrik Arvidsson [1] is now closed.
Yes: 23
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.
Staffan Larsen
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/002041.html
From lana.steuck at oracle.com Wed Apr 15 22:13:43 2015
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 15 Apr 2015 15:13:43 -0700 (PDT)
Subject: jdk9-b60: dev
Message-ID: <201504152213.t3FMDh8i028963@sc11152554.us.oracle.com>
http://hg.openjdk.java.net/jdk9/jdk9/rev/9fa2185bee17
http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/c55ce3738888
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/81bdc4545337
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/84c5527f742b
http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/f31835b59035
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/c12db18748da
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/9c916db4bf3b
http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/caa330b275f3
---
All the fixes will be tested during promotion (no PIT testing at this point):
List of all fixes:
===================
JDK-8031744 core-libs Annotations on many Language Model elements are not returned
JDK-8076442 core-libs Cannot fully read BitSet.stream() if bit Integer.MAX_VALUE is set
JDK-8067215 core-libs Disable dual fields when not using optimistic types
JDK-8076641 core-libs getNextEntry throws ArrayIndexOutOfBoundsException when unzipping file
JDK-8076972 core-libs Several nashorn tests failing
JDK-8076294 hotspot Cleanup of CollectedHeap::kind()
JDK-8076055 hotspot cms: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from sour
JDK-8017462 hotspot G1: guarantee fails with UseDynamicNumberOfGCThreads
JDK-8076054 hotspot g1: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from sourc
JDK-8076076 hotspot Move SharedHeap::print_size_transition() into G1 code
JDK-8076225 hotspot Move the thread claim parity from SharedHeap to Thread
JDK-8076071 hotspot parallelScavenge: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be remo
JDK-8076072 hotspot parNew: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from s
JDK-8075957 hotspot Reduce calls to the GC specific object visitors in oopDesc
JDK-8065358 hotspot Refactor G1s usage of save_marks and reduce related races
JDK-8075401 hotspot Remove DiscoveredListIterator::update_discovered()
JDK-8075635 hotspot Remove GenerationSpec array
JDK-8076237 hotspot Remove unused _collector_policy field in SharedHeap
JDK-8076231 hotspot Remove unused is_in_partial_collection()
JDK-8076241 hotspot Remove unused methods mod_card_iterate() and non_clean_card_iterate_se
JDK-8076073 hotspot shared: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from s
JDK-8076173 hotspot VirtualSpaceNode container_count() and container_count_slow() have dif
JDK-8073634 infrastructure Improve clean targets
JDK-8076465 infrastructure New Init.gmk needs improvements
JDK-8050123 other-libs Incorrect property name documented in CORBA InputStream API
JDK-8039440 other-libs Tidy warnings cleanup for org/omg
JDK-8047789 security-libs auth.login.LoginContext needs to be updated to work with modules
JDK-8064546 security-libs CipherInputStream throws BadPaddingException if stream is not fully re
JDK-8077273 security-libs Disable the PKCS11 NSS tests on Windows
JDK-8077374 security-libs Put PerfOfKlimaOnRSAPremaster.java on the problem list
JDK-8076223 security-libs rest of tidy warning in javax.security / java.security
JDK-8076549 xml Update JAX-WS RI integration to latest version (2.2.11-b150402.1412)
From mark.reinhold at oracle.com Thu Apr 16 22:21:05 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 16 Apr 2015 15:21:05 -0700
Subject: JEP proposed to target JDK 9 (2015/4/9)
In-Reply-To: <20150409132244.429814@eggemoggin.niobe.net>
References: <20150409132244.429814@eggemoggin.niobe.net>
Message-ID: <20150416152105.846729@eggemoggin.niobe.net>
2015/4/9 1:22 -0700, mark.reinhold at oracle.com:
> The following JEP has been placed into the "Proposed to Target"
> state by its owner after discussion and review:
>
> 243: Java-Level JVM Compiler Interface http://openjdk.java.net/jeps/243
>
> Feedback on this proposal is more than welcome, as are reasoned
> objections. If no such objections are raised by 21:00 UTC next
> Thursday, 16 April, or if they're raised and then satisfactorily
> answered, then per the JEP 2.0 process proposal [1] I'll target
> this JEP to JDK 9.
Hearing no objections, I've targeted this JEP to JDK 9.
- Mark
From mark.reinhold at oracle.com Thu Apr 16 22:21:27 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 16 Apr 2015 15:21:27 -0700
Subject: JEPs proposed to target JDK 9 (2015/4/16)
Message-ID: <20150416152127.416588@eggemoggin.niobe.net>
The following JEPs have been placed into the "Proposed to Target"
state by their owners after discussion and review:
215: Tiered Attribution for javac http://openjdk.java.net/jeps/215
221: Simplified Doclet API http://openjdk.java.net/jeps/221
Feedback on these proposals is more than welcome, as are reasoned
objections. If no such objections are raised by 23:00 UTC next
Thursday, 23 April, or if they're raised and then satisfactorily
answered, then per the JEP 2.0 process proposal [1] I'll target
these JEPs to JDK 9.
(This information is also available on the JDK 9 Project Page [2]).
- Mark
[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
[2] http://openjdk.java.net/projects/jdk9/
From ullenboom at googlemail.com Fri Apr 17 09:18:37 2015
From: ullenboom at googlemail.com (Christian Ullenboom)
Date: Fri, 17 Apr 2015 11:18:37 +0200
Subject: Windows missing
Message-ID:
Is there a reason why Windows is missing among
https://jdk9.java.net/download/?
Regards
Christian
From maurizio.cimadamore at oracle.com Mon Apr 20 10:23:54 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Apr 2015 11:23:54 +0100
Subject: Result: New Committer: Srikanth Adayapalam
Message-ID: <5534D3BA.20102@oracle.com>
|Voting for Srikanth Adayapalam [1] is now closed.
Yes: 15
Veto: 0
Abstain: 0
According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.
Maurizio
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/002060.html|
From dalibor.topic at oracle.com Mon Apr 20 14:28:36 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Mon, 20 Apr 2015 16:28:36 +0200
Subject: Windows missing
In-Reply-To:
References:
Message-ID: <55350D14.90907@oracle.com>
Yes. I assume that the toolchain update [0] on Windows [1] had some side
effects - that's not unheard of for toolchain updates.
Note that the download page says "Windows bundles are not yet available
for this build, bundles for Windows will be made available shortly", so
I would expect the issue to be worked out soon.
cheers,
dalibor topic
[0] https://bugs.openjdk.java.net/browse/JDK-8076531
[1] http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014690.html
On 17.04.2015 11:18, Christian Ullenboom wrote:
> Is there a reason why Windows is missing among
> https://jdk9.java.net/download/?
>
> Regards
>
> Christian
>
--
Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961
ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher
Oracle is committed to developing
practices and products that help protect the environment
From alexander.potochkin at oracle.com Mon Apr 20 14:49:35 2015
From: alexander.potochkin at oracle.com (Alexander Potochkin)
Date: Mon, 20 Apr 2015 17:49:35 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
Message-ID: <553511FF.2090005@oracle.com>
I hereby nominate Alexey Ivanov to jdk9 Committer.
Alexey is a member of the Java SE sustaining team.
He has spent most of that time working on the GUI and deployment issues.
He has contributed 13 changes to jdk9 so far:
http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
Votes are due by May 4, 2015.
Only current JDK9 Committers [1] are eligible to vote on this
nomination.
For Lazy Consensus voting instructions, see [2].
Thanks,
alexp
[1] http://openjdk.java.net/census#jdk9
[2] http://openjdk.java.net/projects#committer-vote
From yuri.nesterenko at oracle.com Mon Apr 20 14:59:37 2015
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Mon, 20 Apr 2015 17:59:37 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <55351459.6000505@oracle.com>
Vote: yes
-yan
On 04/20/2015 05:49 PM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From aleksej.efimov at oracle.com Mon Apr 20 15:35:40 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 20 Apr 2015 18:35:40 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <55351CCC.3010709@oracle.com>
Vote: yes
On 04/20/2015 05:49 PM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From artem.ananiev at oracle.com Mon Apr 20 15:52:28 2015
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 20 Apr 2015 08:52:28 -0700
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <553520BC.8030800@oracle.com>
Vote: yes
Artem
On 04/20/15 7:49 AM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From Sergey.Bylokhov at oracle.com Mon Apr 20 15:54:20 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 20 Apr 2015 18:54:20 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <5535212C.9030706@oracle.com>
Vote: Yes
On 20.04.15 17:49, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
--
Best regards, Sergey.
From andrew.brygin at oracle.com Mon Apr 20 15:54:51 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Mon, 20 Apr 2015 18:54:51 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <5535214B.8030104@oracle.com>
Vote: yes
Thanks,
Andrew
On 4/20/2015 5:49 PM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From david.katleman at oracle.com Mon Apr 20 16:15:56 2015
From: david.katleman at oracle.com (David Katleman)
Date: Mon, 20 Apr 2015 09:15:56 -0700
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <5535263C.6050700@oracle.com>
Vote: Yes
On 4/20/2015 7:49 AM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From abhi.saha at oracle.com Mon Apr 20 17:36:19 2015
From: abhi.saha at oracle.com (Abhi Saha)
Date: Mon, 20 Apr 2015 10:36:19 -0700
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <55353913.3010907@oracle.com>
Vote: Yes
Thanks
Abhijit
On 4/20/2015 7:49 AM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
--
Lead, Java SE Updates
Java Platform Group
Oracle Corporation.
(408)276-7564
From ivan.gerasimov at oracle.com Mon Apr 20 22:16:55 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 21 Apr 2015 01:16:55 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <55357AD7.9080707@oracle.com>
Vote: yes
On 20.04.2015 17:49, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
>
>
From huizhe.wang at oracle.com Tue Apr 21 02:04:05 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 20 Apr 2015 19:04:05 -0700
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <5535B015.7030805@oracle.com>
Vote: yes
On 4/20/2015 7:49 AM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From dmitry.markov at oracle.com Tue Apr 21 07:39:55 2015
From: dmitry.markov at oracle.com (dmitry markov)
Date: Tue, 21 Apr 2015 10:39:55 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <5535FECB.7000803@oracle.com>
Vote: yes
Thanks,
Dmitry
On 20/04/2015 17:49, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From volker.simonis at gmail.com Tue Apr 21 08:17:08 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 21 Apr 2015 12:17:08 +0400
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID:
Vote: yes
On 4/20/15, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
>
From anton.litvinov at oracle.com Tue Apr 21 10:08:59 2015
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Tue, 21 Apr 2015 13:08:59 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <553621BB.4000300@oracle.com>
Vote: yes
Thank you,
Anton
On 4/20/2015 5:49 PM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From alexander.zvegintsev at oracle.com Tue Apr 21 11:38:06 2015
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 21 Apr 2015 14:38:06 +0300
Subject: CFV: New JDK9 Committer: Alexey Ivanov
In-Reply-To: <553511FF.2090005@oracle.com>
References: <553511FF.2090005@oracle.com>
Message-ID: <5536369E.8060303@oracle.com>
Vote: yes
Thanks,
Alexander.
On 04/20/2015 05:49 PM, Alexander Potochkin wrote:
> I hereby nominate Alexey Ivanov to jdk9 Committer.
>
> Alexey is a member of the Java SE sustaining team.
> He has spent most of that time working on the GUI and deployment issues.
>
> He has contributed 13 changes to jdk9 so far:
>
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/38d385715177
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/c867d4d46b58
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d7f7f205f986
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1afa10d86648
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/1c5fdc74803d
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/48ef2c904d10
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/ff2112f3ae6b
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d2c998b7e553
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/8769d70bec49
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/5553ba6d75a2
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/3170baa4ab3c
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/85b7ff7d0ba7
> http://hg.openjdk.java.net/jdk9/client/jdk/rev/2153a7725a4a
>
> Votes are due by May 4, 2015.
>
> Only current JDK9 Committers [1] are eligible to vote on this
> nomination.
>
> For Lazy Consensus voting instructions, see [2].
>
> Thanks,
> alexp
>
> [1] http://openjdk.java.net/census#jdk9
> [2] http://openjdk.java.net/projects#committer-vote
>
From kubota.yuji at gmail.com Tue Apr 21 15:31:54 2015
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Wed, 22 Apr 2015 00:31:54 +0900
Subject: Potential infinite waiting at JMXConnection#createConnection
Message-ID:
Hi all,
I found an infinite waiting at TCPChannel#createConnection.
This method flushes the DataOutputStream without the socket timeout settings
when choose stream protocol [1].
If connection lost (the destination server do no return response)
during the flush,
this method has possibilities to take long time beyond the expectations
at java.net.SocketInputStream.socketRead0 as following stack trace.
stack trace :
at java.net.SocketInputStream.socketRead0(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java)
at java.net.SocketInputStream.read(SocketInputStream.java)
at sun.security.ssl.InputRecord.readFully(InputRecord.java)
at sun.security.ssl.InputRecord.read(InputRecord.java)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java)
at java.io.DataOutputStream.flush(DataOutputStream.java)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient
at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java)
When create connection, we cannot set the timeout by properties.
Therefore, JMX sets
the default value of SO_TIMEOUT, i.e., infinite. So I wrote a patch to
fix this infinite
waiting by using property-configured value:
sun.rmi.transport.tcp.responseTimeout.
Please review this patch. :)
Note: My OCA has been processed a few hour ago, so my name may take a
short time to
appear on the OCA signatories page.
Thanks,
KUBOTA Yuji
[1]: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/c5b5d9045728/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java#l191
diff --git a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
--- a/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
+++ b/src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java
@@ -222,20 +222,34 @@
// choose protocol (single op if not reusable socket)
if (!conn.isReusable()) {
out.writeByte(TransportConstants.SingleOpProtocol);
} else {
out.writeByte(TransportConstants.StreamProtocol);
+
+ int usableSoTimeout = 0;
+ try {
+ /*
+ * If socket factory had set a zero timeout on its own,
+ * then set the property-configured value to prevent
+ * an infinite waiting.
+ */
+ usableSoTimeout = sock.getSoTimeout();
+ if (usableSoTimeout == 0) {
+ usableSoTimeout = responseTimeout;
+ }
+ sock.setSoTimeout(usableSoTimeout);
+ } catch (Exception e) {
+ // if we fail to set this, ignore and proceed anyway
+ }
out.flush();
/*
* Set socket read timeout to configured value for JRMP
* connection handshake; this also serves to guard against
* non-JRMP servers that do not respond (see 4322806).
*/
- int originalSoTimeout = 0;
try {
- originalSoTimeout = sock.getSoTimeout();
sock.setSoTimeout(handshakeTimeout);
} catch (Exception e) {
// if we fail to set this, ignore and proceed anyway
}
@@ -279,18 +293,11 @@
* connection. NOTE: this timeout, if configured to a
* finite duration, places an upper bound on the time
* that a remote method call is permitted to execute.
*/
try {
- /*
- * If socket factory had set a non-zero timeout on its
- * own, then restore it instead of using the property-
- * configured value.
- */
- sock.setSoTimeout((originalSoTimeout != 0 ?
- originalSoTimeout :
- responseTimeout));
+ sock.setSoTimeout(usableSoTimeout);
} catch (Exception e) {
// if we fail to set this, ignore and proceed anyway
}
out.flush();
From ullenboom at googlemail.com Tue Apr 21 09:15:52 2015
From: ullenboom at googlemail.com (Christian Ullenboom)
Date: Tue, 21 Apr 2015 11:15:52 +0200
Subject: [RE] Windows missing
Message-ID:
What is the issue here: Windows is not missing from the binaries
http://download.java.net/jdk9/archive/b59/binaries/?q=download/jdk9/archive/b59/binaries/
The JVM works fine:
C:\Windows\System32>java -version
java version "1.9.0-ea"
Java(TM) SE Runtime Environment (build 1.9.0-ea-b59)
Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b59, mixed mode)
It's just missing on the website.
Regards
Christian
From lana.steuck at oracle.com Thu Apr 23 02:05:29 2015
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 22 Apr 2015 19:05:29 -0700 (PDT)
Subject: jdk9-b61: dev
Message-ID: <201504230205.t3N25T4w000375@sc11152554.us.oracle.com>
http://hg.openjdk.java.net/jdk9/jdk9/rev/ea38728b4f4b
http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/89937bee80bd
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/0eb91327db5a
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/da84dcac1b0b
http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/77f44848c44c
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/f4a4a5462037
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/715d2da5801c
http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/d690f489ca0b
---
All the fixes will be tested during promotion (no PIT testing at this point):
List of all fixes:
===================
JDK-8071668 client-libs [macosx] Clipboard does not work with 3rd parties Clipboard Managers
JDK-8075314 client-libs All the InternalFrames will be maximized after maximizing only one of
JDK-8013566 client-libs Failure of GroupLayout in combination of addPreferredGap and addGroup'
JDK-8075081 client-libs Fix missing doclint warnings in java.awt
JDK-8076286 client-libs Fix missing doclint warnings in javax.swing.{colorchooser, event, file
JDK-8076520 client-libs Fix missing doclint warnings in javax.swing.{table, tree, undo, plaf.{
JDK-8075956 client-libs Fix some tidy warnings for java.awt
JDK-8075934 client-libs Fix some tidy warnings/errors for javax/imageio
JDK-8041642 client-libs Incorrect paint of JProgressBar in Nimbus LF
JDK-8074500 client-libs java.awt.Checkbox.setState() call causes ItemEvent to be filed
JDK-6921687 client-libs Mnemonic disappears after repeated attempts to open menu items using m
JDK-8033000 client-libs No Horizontal Mouse Wheel Support In BasicScrollPaneUI
JDK-8076182 client-libs Open Source Java Access Bridge - Create Patch for JEP C127 8055831
JDK-8076419 client-libs Path2D copy constructors and clone method propagate size of arrays fro
JDK-6894632 client-libs Removing rows from a DefaultTableModel with a RowSorter deselectes las
JDK-8072769 client-libs System tray icon title freezes java
JDK-7044727 core-libs (tz) TimeZone.getDefault() call returns incorrect value in Windows ter
JDK-8077640 core-libs DateTimeFormatter does not parse/accept the era.toString() result from
JDK-8077955 core-libs Undeclared globals in eval code should not be handled as fast scope
JDK-8077923 core-svc Add missing doclint in javax.management
JDK-8077408 core-svc javax/management/remote/mandatory/notif/NotSerializableNotifTest.java
JDK-8074481 deploy [macosx] Menu items are appearing on top of other windows
JDK-8074482 deploy [macosx] Menu items disappear and redrawn quickly when moving mouse in
JDK-8059622 deploy Java Console GUI is irresponsive in JRE 8u20 on OS X
JDK-8047738 deploy Radio button lables for JCP security level setting should be clickabl
JDK-8056979 deploy Roaming user profiles by USER_JPI_PROFILE env variables doesn't work a
JDK-8074544 deploy webstart app fails with CouldNotLoadArgumentException when account in
JDK-8076467 hotspot AARCH64: assertion fail with -XX:+UseG1GC
JDK-8077814 infrastructure Add .DELETE_ON_ERROR to makefiles
JDK-8077847 infrastructure Better handling of Windows executable manifest version
JDK-8077824 infrastructure Introduce DefineNativeToolchain to handle toolchain configurations
JDK-8077419 infrastructure Launcher mapfile fails linking with SS12u4
JDK-8077912 infrastructure Turn on doclint checking for more modules
JDK-8077991 other-libs Missing javadoc in exceptions types in javax.transaction
JDK-8068721 other-libs RMI-IIOP communication fails when ConcurrentHashMap is passed to remot
JDK-8076221 security-libs Disable RC4 cipher suites
JDK-8076117 security-libs EndEntityChecker should not process custom extensions after PKIX valid
JDK-8077915 security-libs Fix doclint issues in javax.smartcardio
JDK-8077622 tools Add sources from jdk/src/jdk.deploy.osx/macosx/classes/ to unshuffle s
JDK-8077786 tools Check varargs access against inferred signature
JDK-8043984 tools Confusing (incorrect) error message on repeatable annotations
JDK-8073534 tools Confusing / incorrect error message regarding annotations on non-decla
JDK-8072945 tools Javadoc should generate valid and compliant HTML5 output
JDK-8075520 tools Varargs access check mishandles capture variables
JDK-8071968 xml javax/xml/ws/8046817/GenerateEnumSchema.java failed on Windows platfor
JDK-8042244 xml Re-examine the supportedness of non-SE org.w3c.dom.** API
JDK-8078057 xml Reapply fixes for 8073361, 8073374, 8073696
From ninghua at linux.vnet.ibm.com Thu Apr 23 05:19:06 2015
From: ninghua at linux.vnet.ibm.com (ninghua at linux.vnet.ibm.com)
Date: Thu, 23 Apr 2015 01:19:06 -0400
Subject: Remove redundant package name in
src/java.desktop/share/classes/sun/java2d/Disposer.java
Message-ID: <20150423011906.Horde.ghiYsc_IWSvv8VQ-vVvHvA4@ltc.linux.ibm.com>
A. The problem to be resolve or feature to be added
The class name includes package name java.security/java.lang.ref
though they were already imported
B. The solution proposed by this patch
Remove package name java.security/java.lang.ref from class name
C: Modified file
src/java.desktop/share/classes/sun/java2d/Disposer.java
D:Patch
It is attached as webrev-OJDK-943-OpenJDK9.zip
Regards,
NingHua
From Roger.Riggs at Oracle.com Thu Apr 23 14:12:32 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 23 Apr 2015 10:12:32 -0400
Subject: Remove redundant package name in
src/java.desktop/share/classes/sun/java2d/Disposer.java
In-Reply-To: <20150423011906.Horde.ghiYsc_IWSvv8VQ-vVvHvA4@ltc.linux.ibm.com>
References: <20150423011906.Horde.ghiYsc_IWSvv8VQ-vVvHvA4@ltc.linux.ibm.com>
Message-ID: <5538FDD0.4090705@Oracle.com>
Hi NingHua,
This topic might be most appropriate for the 2d-dev at openjdk.java.net alias
This email strips attachments so an inline patch might be the easiest
way to propose the change.
Roger
On 4/23/2015 1:19 AM, ninghua at linux.vnet.ibm.com wrote:
> A. The problem to be resolve or feature to be added
> The class name includes package name java.security/java.lang.ref
> though they were already imported
>
> B. The solution proposed by this patch
> Remove package name java.security/java.lang.ref from class name
>
> C: Modified file
> src/java.desktop/share/classes/sun/java2d/Disposer.java
>
> D:Patch
> It is attached as webrev-OJDK-943-OpenJDK9.zip
>
>
> Regards,
>
> NingHua
>
From volker.simonis at gmail.com Thu Apr 23 15:24:06 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 23 Apr 2015 17:24:06 +0200
Subject: RFR (S): 8078520: [TESTBUG] fix
'test/tools/launcher/ExecutionEnvironment.java'
to run on arbitrary *nix systems
Message-ID:
Hi,
could somebody please review the following little change which
improves 'test/tools/launcher/ExecutionEnvironment.java':
https://bugs.openjdk.java.net/browse/JDK-8078520
http://cr.openjdk.java.net/~simonis/webrevs/2015/8078520/
The test 'test/tools/launcher/ExecutionEnvironment.java' needs a
special handling on Solaris. But instead of doing:
if (TestHelper.isSolaris) { ... } else { ... }
it currently goes the other way round:
if (TestHelper.isLinux || TestHelper.isMacOSX || TestHelper.isAIX) {
... } else { /* Solaris */ ... }
I've fixed the test to explicitly check for Solaris. This will make it
possible to also run the test on other operating systems without the
need to explicitly name them.
Thank you and best regards,
Volker
From kumar.x.srinivasan at oracle.com Thu Apr 23 17:22:54 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 23 Apr 2015 10:22:54 -0700
Subject: RFR (S): 8078520: [TESTBUG] fix
'test/tools/launcher/ExecutionEnvironment.java'
to run on arbitrary *nix systems
In-Reply-To:
References:
Message-ID: <55392A6E.60807@oracle.com>
Hi Volker,
Looks fine.
You can put me (ksrini) down as reviewer.
Thanks
Kumar
On 4/23/2015 8:24 AM, Volker Simonis wrote:
> Hi,
>
> could somebody please review the following little change which
> improves 'test/tools/launcher/ExecutionEnvironment.java':
>
> https://bugs.openjdk.java.net/browse/JDK-8078520
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8078520/
>
> The test 'test/tools/launcher/ExecutionEnvironment.java' needs a
> special handling on Solaris. But instead of doing:
>
> if (TestHelper.isSolaris) { ... } else { ... }
>
> it currently goes the other way round:
>
> if (TestHelper.isLinux || TestHelper.isMacOSX || TestHelper.isAIX) {
> ... } else { /* Solaris */ ... }
>
> I've fixed the test to explicitly check for Solaris. This will make it
> possible to also run the test on other operating systems without the
> need to explicitly name them.
>
> Thank you and best regards,
> Volker
From volker.simonis at gmail.com Fri Apr 24 07:40:06 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 24 Apr 2015 09:40:06 +0200
Subject: RFR (S): 8078520: [TESTBUG] fix
'test/tools/launcher/ExecutionEnvironment.java'
to run on arbitrary *nix systems
In-Reply-To: <55392A6E.60807@oracle.com>
References:
<55392A6E.60807@oracle.com>
Message-ID:
Great!
Thanks a lot,
Volker
On Thu, Apr 23, 2015 at 7:22 PM, Kumar Srinivasan
wrote:
> Hi Volker,
>
> Looks fine.
>
> You can put me (ksrini) down as reviewer.
>
> Thanks
> Kumar
>
>
> On 4/23/2015 8:24 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> could somebody please review the following little change which
>> improves 'test/tools/launcher/ExecutionEnvironment.java':
>>
>> https://bugs.openjdk.java.net/browse/JDK-8078520
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8078520/
>>
>> The test 'test/tools/launcher/ExecutionEnvironment.java' needs a
>> special handling on Solaris. But instead of doing:
>>
>> if (TestHelper.isSolaris) { ... } else { ... }
>>
>> it currently goes the other way round:
>>
>> if (TestHelper.isLinux || TestHelper.isMacOSX || TestHelper.isAIX) {
>> ... } else { /* Solaris */ ... }
>>
>> I've fixed the test to explicitly check for Solaris. This will make it
>> possible to also run the test on other operating systems without the
>> need to explicitly name them.
>>
>> Thank you and best regards,
>> Volker
>
>
From alexandr.scherbatiy at oracle.com Fri Apr 24 08:18:51 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 24 Apr 2015 11:18:51 +0300
Subject: Result: New JDK 9 Committer: Semyon Sadetsky
Message-ID: <5539FC6B.7040003@oracle.com>
Voting for Semyon Sadetsky [1] is now closed.
Yes: 6
Veto: 0
Abstain: 0
According to the Bylaws definition of Three-Vote Consensus, this is
sufficient to approve the nomination.
Thanks,
Alexandr.
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-April/002114.html
From michal.slonina at gmail.com Mon Apr 27 19:34:30 2015
From: michal.slonina at gmail.com (=?UTF-8?B?TWljaGHFgiBTxYJvbmluYQ==?=)
Date: Mon, 27 Apr 2015 21:34:30 +0200
Subject: strange behavior of future.cancel() with
Executors.newWorkStealingPool()
Message-ID:
Hello folks,
I've noticed a strange behavior of future.cancel() when using work stealing
thread pool.
The JDK docs state that calling future.cancel(true) should result in task
being interrupted.
"Parameters: mayInterruptIfRunning - true if the thread executing this task
should be interrupted..." [1]
This works correctly with any executor other then work stealing pool. The
behavior is consistent on JDK8 and JDK9.
Can someone please enlighten me, did I miss something in the docs or is
this a bug ?
--- CUT HERE ---
public class Test {
public static void main(String[] args) throws InterruptedException {
ExecutorService executor = args[0].equalsIgnoreCase("UGLY")
? Executors.newWorkStealingPool() :
Executors.newFixedThreadPool(666);
Future> future = executor.submit(new Runnable() {
@Override
public void run() {
try {
System.out.println("STARTED");
Thread.sleep(500);
System.out.println("FINISHED. Is interrupted: " +
Thread.interrupted());
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
Thread.sleep(100);
boolean cancelResult = future.cancel(true);
System.out.println("Cancel result:" + cancelResult);
Thread.sleep(1000);
System.exit(0);
}
}
--- CUT HERE ---
af1n executortest/src ? java -cp . Test NICE
STARTED
Cancel result:true
java.lang.InterruptedException: sleep interrupted
at java.lang.Thread.sleep(Native Method)
at Test$1.run(Test.java:21)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:265)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
af1n executortest/src ? java -cp . Test UGLY
STARTED
Cancel result:true
FINISHED. Is interrupted: false
af1n executortest/src ? java -version
openjdk version "1.9.0_00"
OpenJDK Runtime Environment (build 1.9.0_00-b60)
OpenJDK 64-Bit Server VM (build 1.9.0_00-b60, mixed mode)
af1n executortest/src ? uname -a
Linux af1n.2r-media.de 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44
UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
--
[1]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html#cancel-boolean-
Kind Regards,
Michal Slonina
From martinrb at google.com Mon Apr 27 19:51:43 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 27 Apr 2015 12:51:43 -0700
Subject: strange behavior of future.cancel() with
Executors.newWorkStealingPool()
In-Reply-To:
References:
Message-ID:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinTask.html#cancel-boolean-
Parameters:
mayInterruptIfRunning - this value has no effect in the default
implementation because interrupts are not used to control cancellation.
Admittedly,
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Executors.html#newWorkStealingPool-int-
doesn't promise that it's using ForkJoinPool/ForkJoinTask.
On Mon, Apr 27, 2015 at 12:34 PM, Micha? S?onina
wrote:
> Hello folks,
>
> I've noticed a strange behavior of future.cancel() when using work stealing
> thread pool.
>
> The JDK docs state that calling future.cancel(true) should result in task
> being interrupted.
> "Parameters: mayInterruptIfRunning - true if the thread executing this task
> should be interrupted..." [1]
>
> This works correctly with any executor other then work stealing pool. The
> behavior is consistent on JDK8 and JDK9.
> Can someone please enlighten me, did I miss something in the docs or is
> this a bug ?
>
> --- CUT HERE ---
>
> public class Test {
> public static void main(String[] args) throws InterruptedException {
> ExecutorService executor = args[0].equalsIgnoreCase("UGLY")
> ? Executors.newWorkStealingPool() :
> Executors.newFixedThreadPool(666);
> Future> future = executor.submit(new Runnable() {
> @Override
> public void run() {
> try {
> System.out.println("STARTED");
> Thread.sleep(500);
> System.out.println("FINISHED. Is interrupted: " +
> Thread.interrupted());
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> }
> });
> Thread.sleep(100);
> boolean cancelResult = future.cancel(true);
> System.out.println("Cancel result:" + cancelResult);
> Thread.sleep(1000);
> System.exit(0);
> }
> }
>
> --- CUT HERE ---
>
> af1n executortest/src ? java -cp . Test NICE
> STARTED
> Cancel result:true
> java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at Test$1.run(Test.java:21)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:265)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> af1n executortest/src ? java -cp . Test UGLY
> STARTED
> Cancel result:true
> FINISHED. Is interrupted: false
>
> af1n executortest/src ? java -version
> openjdk version "1.9.0_00"
> OpenJDK Runtime Environment (build 1.9.0_00-b60)
> OpenJDK 64-Bit Server VM (build 1.9.0_00-b60, mixed mode)
>
> af1n executortest/src ? uname -a
> Linux af1n.2r-media.de 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44
> UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
>
> --
> [1]
>
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Future.html#cancel-boolean-
>
> Kind Regards,
> Michal Slonina
>
From lana.steuck at oracle.com Wed Apr 29 18:39:38 2015
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 29 Apr 2015 11:39:38 -0700 (PDT)
Subject: jdk9-b62: dev
Message-ID: <201504291839.t3TIdcdA003625@sc11152554.us.oracle.com>
http://hg.openjdk.java.net/jdk9/jdk9/rev/105d045a6917
http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/1b5604bc81a6
http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/40058141a4ec
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/49118e68fbd4
http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/cd0cf72b2cbf
http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/3bcf83c1bbc1
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1eab877142cc
http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/d27f7e0a7aca
---
All the fixes will be tested during promotion (no PIT testing at this point):
List of all fixes:
===================
JDK-8078276 core-libs add copyright header to IPv6NameserverPlatformParsingTest
JDK-8078174 core-libs Add few FX and parser API samples for nashorn
JDK-8074761 core-libs Empty optional parameters of LDAP query are not interpreted as empty
JDK-8071928 core-libs Instance properties with getters returning wrong values
JDK-6991580 core-libs IPv6 Nameservers in resolv.conf throws NumberFormatException
JDK-8073846 core-libs Javascript for-in loop returned extra keys
JDK-8075139 core-libs Restore java.protocol.handler.pkgs to work as a fallback for migration
JDK-8048264 core-libs StringBuffer's codePoint methods throw unspecified IndexOutOfBoundsExc
JDK-8038764 core-libs Tidy warnings cleanup for javax.activation
JDK-8078467 core-libs Update core libraries to use diamond with anonymous classes
JDK-8074146 core-svc jdb has succeded to read an unreadable file
JDK-8077952 core-svc sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh should be qu
JDK-8078263 hotspot AARCH64: Volatile fields should be accessed with ldar and stlr
JDK-8078348 security-libs [TEST_BUG] sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java fails
JDK-7194452 security-libs Remove "Reverse" PKIX CertPathBuilder implementation
JDK-8048138 security-libs Tests for JAAS callbacks
JDK-8078389 tools Add test for -Xdoclint + -XDcompletionDeps
JDK-8068737 tools ArrayType prints element type post order
JDK-8042947 tools Implement classfile tests for AnnotationDefault attribute.
JDK-8078261 tools Initialization of DocLint triggers out of order initialization of Depe
JDK-8078024 tools javac, several incorporation steps are silently failing when an error
JDK-8078433 tools javac, some tests are failing after JDK-8078024 because of golden file
JDK-8078560 tools The crash reporting URL listed by javac needs to be updated
JDK-8078139 xml jdk.xml.dom should be loaded by the ext class loader
JDK-8073357 xml schema1.xsd has wrong content. Sequence of the enum values has been ch
JDK-8077332 xml tidy warnings from javax/xml
From joe.darcy at oracle.com Thu Apr 30 00:12:31 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 29 Apr 2015 17:12:31 -0700
Subject: Proposed new policies for JDK 9 regression tests: tiered testing,
intermittent failures, and randomness
In-Reply-To: <550A1BBF.5020504@oracle.com>
References: <550A1BBF.5020504@oracle.com>
Message-ID: <5541736F.1030905@oracle.com>
A follow-up,
The tiered testing definitions have been added to the jdk repository
(JDK-8075544). Two new jtreg keywords were defined and added to
appropriate jdk regression tests, "intermittent" (JDK-8075565) and
"randomness" (JDK-8078334).
Tests that are observed to fail intermittently should be tagged with the
"intermittent" keyword until such time as the flakiness of the test's
behavior is resolved.
Going forward, when a new regression test is written or an existing test
updated, the presence or absence of the "randomness" keyword should be
kept up-to-date with the behavior of the test. As explained in the
TEST.ROOT file,
> # The "randomness" keyword marks tests using randomness with test
> # cases differing from run to run. (A test using a fixed random seed
> # would not count as "randomness" by this definition.) Extra care
> # should be taken to handle test failures of intermittent or
> # randomness tests.
If a "randomness" test fails, and especially if it fails intermittently,
the seed value in force during the failing run should be included in a
bug report about the failure. One part of investigating the failure is
to see if the intermittent failure becomes reproducible if the seed is
set to the value observed during a failing run.
There is now a random number utility library for regression testing in
the jdk repository (JDK-8078672); the facility is located at
test/lib/testlibrary/jdk/testlibrary/RandomFactory.java
and can be accessed via jtreg @library facility with jtreg tags like
* ...
* @library /lib/testlibrary
* @build jdk.testlibrary.*
* ...
Calls to
new Random()
in regression tests can be replaced with
RandomFactory.getRandom()
In brief, requesting a random number generator from the factory outputs
the seed it is using and a test run can be made to use a particular seed
by passing in a -Dseed=X option to the jtreg test run.
Cheers,
-Joe
On 3/18/2015 5:43 PM, joe darcy wrote:
> Hello,
>
> Over the last several years, there has been a background thread of
> activity to improve the robustness and reliability of JDK regression
> testing. In a effort to further improve testing of JDK 9, I have a few
> proposals to put forward for discussion:
>
> * Tiered testing
> * Marking tests which fail intermittently
> * Marking tests which use randomness
>
> Some portions of the JDK regression tests are more stable that others;
> that is, some portions are less prone to intermittent test failures.
> Some aspects of the JDK are also more fundamental than others. For
> example, javac and the core libraries are necessary for any kind of
> Java development work while jaxp is not.
>
> With those considerations in mind and taking into account the graph of
> integration forests for JDK 9 [1], I propose an initial definition of
> two tiers of tests:
>
> * Tier 1: stable tests for fundamental parts of the platform. Failures
> in tier 1 tests are treated as urgent issues to resolve, on par with a
> build failure.
>
> * Tier 2: tests which may be less stable or less fundamental parts of
> the platform. Resolving failures in tier 2 tests is important, but not
> as urgent as resolving a tier 1 failure.
>
> The initial proposed population of tier 1 and tier 2 regression tests is:
>
> Tier 1 tests:
> jdk/test: jdk_lang, jdk_util, jdk_math
> langtools/test
>
> Tier 2 tests:
> jdk/test: jdk_io, jdk_nio, jdk_net, jdk_rmi, jdk_time,
> jdk_security, jdk_text, core_tools, jdk_other, jdk_svc
> nashorn/test
> jaxp/test:jaxp_all
>
> The regression tests for client areas are not run as commonly as other
> regression tests; client tests could be added as a third tier or
> incorporated into tier 2 over time. Given how HotSpot integrates in
> jdk9/dev after going through its own set of integration forests, the
> current definitions of tiered testing is aimed at langtools and
> libraries work.
>
> Some of the areas included in tier 2 above are very fundamental, such
> as jdk_io, but still have some testing issues. Once those issues are
> resolved, a test set like jdk_io could be promoted from tier 2 to tier 1.
>
> These definitions of tiered tests can be implemented as entries in the
> TEST.group files used by jtreg in the various Hg component
> repositories, jdk, langtools, jaxp, and nashorn.
>
> One goal of this explicit tiered testing policy is that all the tier 1
> tests would always pass on the master. In other words, in the
> steady-state situation, integrations from dev into master should not
> introduce tier 1 test failures on mainline platforms.
>
> Resolving a new persistent test failure could be accomplished in
> multiple ways. If there there a flaw in new code or the new test, the
> new code or test could be fixed. If developing a full fix would take a
> while, the test could be @exclude-d or put on the problem list while
> the full fix is being tracked in another bug. Finally, if the testing
> situation is sufficient bad, the changeset which introduced the
> problem can be anti-delta-ed out.
>
> Currently it is difficult to know what set of JDK regression tests
> intermittently fail. To make this determination easier, I propose
> defining for use in the JDK repositories a new jtreg keyword , say
> "intermittent-failure", that would be added to tests known or
> suspected to fail intermittently. The jtreg harness supports defining
> a set a keywords for a set of tests in the TEST.ROOT file. The
> affected (or afflicted) tests would get a
>
> @key intermittent-failure
>
> line as one of their jtreg tags. Besides documenting the problems of
> the test in the test itself, a command like
>
> jtreg -keywords:intermittent-failure ...
>
> could be used to run the intermittently tailing tests as a group, such
> as in a dedicated attempt to gather more failure information about the
> tests.
>
> Some tests want to explore a large space a inputs, often a space of
> inputs so large is is impractical or undesirable to exhaustively
> explore the space in routine testing. One way to get better test
> coverage in this kind of situation over time is for a test of the area
> to use randomness to explore a different subset of the input space of
> different runs. This use of randomness can be a valid testing
> technique, but it must be used with care.
>
> If such a random-using test fails intermittently, it may be because it
> is encountering a real flaw in the product, but a flaw that is only
> visited rarely. If such a failure is observed, it should be added to
> the bug database along with the seed value that can be used to
> reproduce the situation. As a corollary, all such random-using tests
> should print out the seed value they are using a provide a way to set
> the seed value on a given run.
>
> To aid those analyzing the failure of a random-using test, a new jtreg
> keyword like "uses-randomness" should be added.
>
> Thanks to Alan Bateman, Stuart Marks, and Stefan S?rne for many
> conversations leading up to these proposals.
>
> Comments?
>
> -Joe
>
> [1] "Proposal to revise forest graph and integration practices for JDK
> 9,"
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2013-November/000000.html
From mark.reinhold at oracle.com Thu Apr 30 22:39:09 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 30 Apr 2015 15:39:09 -0700
Subject: JEPs proposed to target JDK 9 (2015/4/16)
In-Reply-To: <20150416152127.416588@eggemoggin.niobe.net>
References: <20150416152127.416588@eggemoggin.niobe.net>
Message-ID: <20150430153909.742405@eggemoggin.niobe.net>
2015/4/16 3:21 -0700, mark.reinhold at oracle.com:
> The following JEPs have been placed into the "Proposed to Target"
> state by their owners after discussion and review:
>
> 215: Tiered Attribution for javac http://openjdk.java.net/jeps/215
> 221: Simplified Doclet API http://openjdk.java.net/jeps/221
>
> Feedback on these proposals is more than welcome, as are reasoned
> objections. If no such objections are raised by 23:00 UTC next
> Thursday, 23 April, or if they're raised and then satisfactorily
> answered, then per the JEP 2.0 process proposal [1] I'll target
> these JEPs to JDK 9.
Hearing no objections, I've targeted these JEPs to JDK 9.
- Mark
From mark.reinhold at oracle.com Thu Apr 30 22:39:24 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 30 Apr 2015 15:39:24 -0700
Subject: JEPs proposed to target JDK 9 (2015/4/30)
Message-ID: <20150430153924.942430@eggemoggin.niobe.net>
The following JEPs have been placed into the "Proposed to Target"
state by their owners after discussion and review:
232: Improve Secure Application Performance http://openjdk.java.net/jeps/232
245: Validate JVM Command-Line Flag Arguments http://openjdk.java.net/jeps/245
Feedback on these proposals is more than welcome, as are reasoned
objections. If no such objections are raised by 23:00 UTC next
Thursday, 7 May, or if they're raised and then satisfactorily
answered, then per the JEP 2.0 process proposal [1] I'll target
these JEPs to JDK 9.
(This information is also available on the JDK 9 Project Page [2]).
- Mark
[1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
[2] http://openjdk.java.net/projects/jdk9/