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/