From george.marrows at ge.com Tue Aug 5 09:02:15 2014 From: george.marrows at ge.com (Marrows, George A (GE Energy Management)) Date: Tue, 5 Aug 2014 09:02:15 +0000 Subject: Jigsaw/OSGi interoperability requirements In-Reply-To: References: Message-ID: I'm certainly keen to see interoperability between the two solutions. It would be perverse for Jigsaw to introduce fundamental problems for OSGi, which is after all the current de facto standard Java module system. (Backgound: we are using OSGi to help structure our port of General Electic's Smallworld product line to the JVM. We are intending to map Smallworld's own module system, which is specific to the Magik programming language, to OSGi bundles and probably ultimately Jigsaw modules. http://www.infoq.com/news/2012/12/magik-jvm-port ) Yours, George -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Neil Bartlett Sent: 30 July 2014 12:38 To: jigsaw-dev at openjdk.java.net Subject: Jigsaw/OSGi interoperability requirements Hello, I asked the following question at the beginning of July when the re-relaunch of Jigsaw was announced, but didn?t get a response. Probably it was unintentionally overlooked with all the other traffic, but I would very much appreciate an answer so I?ll ask again: The previous draft requirements dated 19 April 2011?(?Draft 12?) stated the following with respect to OSGi: ?It must be demonstrated by prototype to be feasible to modify an OSGi micro-kernel such that OSGi bundles running in that kernel can depend upon Java modules. The kernel must be able to load Java modules directly and resolve them using its own resolver, except for core system modules. Core system modules can only be loaded using the module system?s reification API.? Can you confirm that this requirement will still apply in the new phase, or has it been deliberately dropped? Regards, Neil? From njbartlett at gmail.com Tue Aug 5 10:49:45 2014 From: njbartlett at gmail.com (Neil Bartlett) Date: Tue, 5 Aug 2014 11:49:45 +0100 Subject: Jigsaw/OSGi interoperability requirements In-Reply-To: References: Message-ID: Hi George, Bear in mind that if Java 9 + Jigsaw actually *breaks* OSGi in any way, it would have to be a considered a non-backwards-compatible release of Java, since OSGi does nothing that could be considered non-standard or illegal for a Java program to do. I agree this would be perverse, as many other valid Java programs (e.g. JavaEE application servers) would likely be broken as well. However, ?not breaking? is rather a low bar? lower than that set by the previous revisions of the requirements which demanded some form of real interoperability between the module systems. Neil On 5 August 2014 at 10:02:51, Marrows, George A (GE Energy Management) (george.marrows at ge.com) wrote: I'm certainly keen to see interoperability between the two solutions. It would be perverse for Jigsaw to introduce fundamental problems for OSGi, which is after all the current de facto standard Java module system. (Backgound: we are using OSGi to help structure our port of General Electic's Smallworld product line to the JVM. We are intending to map Smallworld's own module system, which is specific to the Magik programming language, to OSGi bundles and probably ultimately Jigsaw modules. http://www.infoq.com/news/2012/12/magik-jvm-port ) Yours, George -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Neil Bartlett Sent: 30 July 2014 12:38 To: jigsaw-dev at openjdk.java.net Subject: Jigsaw/OSGi interoperability requirements Hello, I asked the following question at the beginning of July when the re-relaunch of Jigsaw was announced, but didn?t get a response. Probably it was unintentionally overlooked with all the other traffic, but I would very much appreciate an answer so I?ll ask again: The previous draft requirements dated 19 April 2011?(?Draft 12?) stated the following with respect to OSGi: ?It must be demonstrated by prototype to be feasible to modify an OSGi micro-kernel such that OSGi bundles running in that kernel can depend upon Java modules. The kernel must be able to load Java modules directly and resolve them using its own resolver, except for core system modules. Core system modules can only be loaded using the module system?s reification API.? Can you confirm that this requirement will still apply in the new phase, or has it been deliberately dropped? Regards, Neil? From mark.reinhold at oracle.com Tue Aug 5 16:49:07 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 5 Aug 2014 09:49:07 -0700 (PDT) Subject: JEP 201: Modular Source Code Message-ID: <20140805164907.7EF17329BF@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/201 - Mark From mark.reinhold at oracle.com Tue Aug 5 16:49:05 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 5 Aug 2014 09:49:05 -0700 (PDT) Subject: JEP 200: The Modular JDK Message-ID: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/200 - Mark From eric at tibco.com Tue Aug 5 17:26:05 2014 From: eric at tibco.com (Eric Johnson) Date: Tue, 5 Aug 2014 10:26:05 -0700 Subject: JEP 200: The Modular JDK In-Reply-To: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> Message-ID: Thanks for sharing that with the jigsaw-dev mailing list. Quick question: Why does this JEP need to make assumptions 4, 5, and 6? Seems like assuming existing classpath semantics is good enough for this JEP. Seems like these additional constraints just bring in a lot of text about re-exporting, when, for the purposes of modularizing the JRE & JDK, such technical details could be left to the module system, rather than here. Did I miss something? Eric. On Tue, Aug 5, 2014 at 9:49 AM, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/200 > > - Mark > From mark.reinhold at oracle.com Tue Aug 5 18:07:44 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Aug 2014 11:07:44 -0700 Subject: JEP 200: The Modular JDK In-Reply-To: References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, Message-ID: <20140805110744.697966@eggemoggin.niobe.net> 2014/8/5 10:26 -0700, eric at tibco.com: > Quick question: Why does this JEP need to make assumptions 4, 5, and 6? > Seems like assuming existing classpath semantics is good enough for this > JEP. Seems like these additional constraints just bring in a lot of text > about re-exporting, when, for the purposes of modularizing the JRE & JDK, > such technical details could be left to the module system, rather than > here. Did I miss something? These assumptions are driven by the goal of making the platform more secure and maintainable: http://openjdk.java.net/projects/jigsaw/goals-reqs/03#security--maintainability - Mark From mark.reinhold at oracle.com Tue Aug 5 20:41:49 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Aug 2014 13:41:49 -0700 Subject: Staging forest for JEP 201: Modular Source Code Message-ID: <20140805134149.630957@eggemoggin.niobe.net> FYI, here is the staging forest for JEP 201: http://hg.openjdk.java.net/jigsaw/stage/ - Mark From mandy.chung at oracle.com Tue Aug 5 23:13:36 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Aug 2014 16:13:36 -0700 Subject: CFV: New Jigsaw Committer: Erik Joelsson Message-ID: <53E16520.1010707@oracle.com> I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer. Erik is one of the main contributors to the new build system in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project. Erik has already contributed many change sets in this project modularizing the JDK source and enhancing the build system to compile modules: http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk Votes are due by: Aug 19, 2014, 16:15 PDT. Only current Jigsaw 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]. Mandy [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From mandy.chung at oracle.com Tue Aug 5 23:14:06 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 05 Aug 2014 16:14:06 -0700 Subject: CFV: New Jigsaw Committer: Mike Duigou Message-ID: <53E1653E.3000104@oracle.com> I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer. Mike has been a long time contributor to the JDK, making changes and reviewing in jdk8, jdk9, lambda projects. Mike has also been contributing many patches in the build infrastructure area and the Code Tools. http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou Votes are due by: Aug 19, 2014, 16:15 PDT. Only current Jigsaw 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]. Mandy [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From jonathan.gibbons at oracle.com Tue Aug 5 23:23:55 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 05 Aug 2014 16:23:55 -0700 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <53E1678B.70200@oracle.com> Vote: yes On 08/05/2014 04:13 PM, Mandy Chung wrote: > I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer. > > Erik is one of the main contributors to the new build system > in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project. > Erik has already contributed many change sets in this project > modularizing the JDK source and enhancing the build system > to compile modules: > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk > http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From jonathan.gibbons at oracle.com Tue Aug 5 23:24:10 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 05 Aug 2014 16:24:10 -0700 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <53E1679A.2070102@oracle.com> Vote: yes On 08/05/2014 04:14 PM, Mandy Chung wrote: > I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer. > > Mike has been a long time contributor to the JDK, making changes > and reviewing in jdk8, jdk9, lambda projects. Mike has also been > contributing many patches in the build infrastructure area and > the Code Tools. > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From mark.reinhold at oracle.com Tue Aug 5 23:24:24 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Aug 2014 16:24:24 -0700 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <20140805162424.48294@eggemoggin.niobe.net> Vote: yes - Mark From mark.reinhold at oracle.com Tue Aug 5 23:24:30 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Aug 2014 16:24:30 -0700 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <20140805162430.747848@eggemoggin.niobe.net> Vote: yes - Mark From weijun.wang at oracle.com Wed Aug 6 02:04:43 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 06 Aug 2014 10:04:43 +0800 Subject: JEP 201: Modular Source Code In-Reply-To: <20140805164907.7EF17329BF@eggemoggin.niobe.net> References: <20140805164907.7EF17329BF@eggemoggin.niobe.net> Message-ID: <53E18D3B.6010304@oracle.com> "modules.xml... Changes to this file will require review by Committers to Project Jigsaw". Shouldn't it be "Reviewers"? "there is still a minor risk that the relationship between the new and old locations of a file will not properly be recorded". Could this happen? --Max On 8/6/2014 0:49, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/201 > > - Mark > From chris.hegarty at oracle.com Wed Aug 6 06:27:54 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Aug 2014 07:27:54 +0100 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: Vote: yes -Chris > On 6 Aug 2014, at 00:13, Mandy Chung wrote: > > I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer. > > Erik is one of the main contributors to the new build system > in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project. > Erik has already contributed many change sets in this project > modularizing the JDK source and enhancing the build system > to compile modules: > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk > http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From chris.hegarty at oracle.com Wed Aug 6 06:28:23 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 6 Aug 2014 07:28:23 +0100 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <1BAABA95-9180-4DD9-926A-CC3EA3206458@oracle.com> Vote: yes -Chris > On 6 Aug 2014, at 00:14, Mandy Chung wrote: > > I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer. > > Mike has been a long time contributor to the JDK, making changes > and reviewing in jdk8, jdk9, lambda projects. Mike has also been > contributing many patches in the build infrastructure area and > the Code Tools. > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From dalibor.topic at oracle.com Wed Aug 6 10:01:24 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 06 Aug 2014 12:01:24 +0200 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <53E1FCF4.8050401@oracle.com> Vote: Yes. -- 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 Gesch?ftsf?hrer: J?rgen Kunz 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 dalibor.topic at oracle.com Wed Aug 6 10:01:43 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 06 Aug 2014 12:01:43 +0200 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <53E1FD07.5030905@oracle.com> Vote: Yes. -- 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 Gesch?ftsf?hrer: J?rgen Kunz 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 paul.sandoz at oracle.com Wed Aug 6 10:30:28 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Aug 2014 12:30:28 +0200 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <4E54EF1D-48F0-493C-98CA-0DB0ED52D14D@oracle.com> Vote: yes Paul. From paul.sandoz at oracle.com Wed Aug 6 10:30:55 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 Aug 2014 12:30:55 +0200 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: Vote: yes Paul. From vincent.x.ryan at oracle.com Wed Aug 6 10:35:53 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 6 Aug 2014 11:35:53 +0100 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <3DD95C5A-840C-4990-81D0-1C26F88842FC@oracle.com> Vote: yes On 6 Aug 2014, at 00:13, Mandy Chung wrote: > I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer. > > Erik is one of the main contributors to the new build system > in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project. > Erik has already contributed many change sets in this project > modularizing the JDK source and enhancing the build system > to compile modules: > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk > http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From vincent.x.ryan at oracle.com Wed Aug 6 10:36:16 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 6 Aug 2014 11:36:16 +0100 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: Vote: yes On 6 Aug 2014, at 00:14, Mandy Chung wrote: > I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer. > > Mike has been a long time contributor to the JDK, making changes > and reviewing in jdk8, jdk9, lambda projects. Mike has also been > contributing many patches in the build infrastructure area and > the Code Tools. > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From Alan.Bateman at oracle.com Wed Aug 6 11:36:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Aug 2014 12:36:06 +0100 Subject: JEP 201: Modular Source Code In-Reply-To: <53E18D3B.6010304@oracle.com> References: <20140805164907.7EF17329BF@eggemoggin.niobe.net> <53E18D3B.6010304@oracle.com> Message-ID: <53E21326.1010702@oracle.com> On 06/08/2014 03:04, Weijun Wang wrote: > "modules.xml... Changes to this file will require review by Committers > to Project Jigsaw". > > Shouldn't it be "Reviewers"? > From the Bylaws: "Projects that do not require any formal change review will not have any Reviewers" and Project Jigsaw is one of those. So Committers is right here but of course any changes going into jdk9/dev requires at least one of the reviewers to be a jdk9 Reviewer. -Alan. From Alan.Bateman at oracle.com Wed Aug 6 11:36:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Aug 2014 12:36:26 +0100 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <53E2133A.8020305@oracle.com> Vote: yes From Alan.Bateman at oracle.com Wed Aug 6 11:36:38 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Aug 2014 12:36:38 +0100 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <53E21346.5040108@oracle.com> Vote: yes From sean.mullan at oracle.com Wed Aug 6 12:29:25 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 06 Aug 2014 08:29:25 -0400 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <53E21FA5.8020709@oracle.com> Vote: yes --Sean On 08/05/2014 07:14 PM, Mandy Chung wrote: > I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer. > > Mike has been a long time contributor to the JDK, making changes > and reviewing in jdk8, jdk9, lambda projects. Mike has also been > contributing many patches in the build infrastructure area and > the Code Tools. > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From sean.mullan at oracle.com Wed Aug 6 12:30:16 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 06 Aug 2014 08:30:16 -0400 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <53E21FD8.9010107@oracle.com> Vote: yes --Sean On 08/05/2014 07:13 PM, Mandy Chung wrote: > I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer. > > Erik is one of the main contributors to the new build system > in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project. > Erik has already contributed many change sets in this project > modularizing the JDK source and enhancing the build system > to compile modules: > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk > http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From karen.kinnear at oracle.com Wed Aug 6 13:35:52 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 6 Aug 2014 09:35:52 -0400 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <3679D784-11EB-4DF0-8C2F-78D39055CFC9@oracle.com> vote: yes thanks, Karen On Aug 5, 2014, at 7:13 PM, Mandy Chung wrote: > I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer. > > Erik is one of the main contributors to the new build system > in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project. > Erik has already contributed many change sets in this project > modularizing the JDK source and enhancing the build system > to compile modules: > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk > http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From karen.kinnear at oracle.com Wed Aug 6 13:36:03 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 6 Aug 2014 09:36:03 -0400 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <8E97A4F2-7BA4-47F1-A5BB-8E1315EFDB6D@oracle.com> Vote: yes thanks, Karen On Aug 5, 2014, at 7:14 PM, Mandy Chung wrote: > I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer. > > Mike has been a long time contributor to the JDK, making changes > and reviewing in jdk8, jdk9, lambda projects. Mike has also been > contributing many patches in the build infrastructure area and > the Code Tools. > http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou > > Votes are due by: Aug 19, 2014, 16:15 PDT. > > Only current Jigsaw 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]. > > Mandy > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From scolebourne at joda.org Wed Aug 6 14:08:19 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 6 Aug 2014 15:08:19 +0100 Subject: JEP 201: Modular Source Code In-Reply-To: <20140805164907.7EF17329BF@eggemoggin.niobe.net> References: <20140805164907.7EF17329BF@eggemoggin.niobe.net> Message-ID: Just wanted to express my surprise that java files are still to be located in "src/.../classes". For me, most open source projects and most users of Maven and other build systems, "classes" is the name of the *output* directory containing ".class" files. Having the ".java" files in there is very confusing. As such, could I request that consideration is given to using "src/.../java" as per the Maven inspired standard directory layout. If that is not deemed acceptable (because of the root package name of java for example) I'd be happy with other sensible options ("src/.../javasrc"?), but please, not "classes"! Stephen On 5 August 2014 17:49, wrote: > New JEP Candidate: http://openjdk.java.net/jeps/201 > > - Mark From pbenedict at apache.org Wed Aug 6 14:14:42 2014 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 6 Aug 2014 09:14:42 -0500 Subject: JEP 201: Modular Source Code In-Reply-To: References: <20140805164907.7EF17329BF@eggemoggin.niobe.net> Message-ID: +1. Very sensible suggestion, I think. Cheers, Paul On Wed, Aug 6, 2014 at 9:08 AM, Stephen Colebourne wrote: > Just wanted to express my surprise that java files are still to be > located in "src/.../classes". For me, most open source projects and > most users of Maven and other build systems, "classes" is the name of > the *output* directory containing ".class" files. Having the ".java" > files in there is very confusing. > > As such, could I request that consideration is given to using > "src/.../java" as per the Maven inspired standard directory layout. > > If that is not deemed acceptable (because of the root package name of > java for example) I'd be happy with other sensible options > ("src/.../javasrc"?), but please, not "classes"! > > Stephen > > > > > On 5 August 2014 17:49, wrote: > > New JEP Candidate: http://openjdk.java.net/jeps/201 > > > > - Mark > From mandy.chung at oracle.com Wed Aug 6 17:17:30 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 06 Aug 2014 10:17:30 -0700 Subject: CFV: New Jigsaw Committer: Erik Joelsson In-Reply-To: <53E16520.1010707@oracle.com> References: <53E16520.1010707@oracle.com> Message-ID: <53E2632A.4080507@oracle.com> Vote: yes Mandy From mandy.chung at oracle.com Wed Aug 6 17:17:49 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 06 Aug 2014 10:17:49 -0700 Subject: CFV: New Jigsaw Committer: Mike Duigou In-Reply-To: <53E1653E.3000104@oracle.com> References: <53E1653E.3000104@oracle.com> Message-ID: <53E2633D.4080406@oracle.com> Vote: yes Mandy From mandy.chung at oracle.com Wed Aug 6 17:23:13 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 06 Aug 2014 10:23:13 -0700 Subject: Result: New Jigsaw Committer: Erik Joelsson Message-ID: <53E26481.6050506@oracle.com> Voting forErik Joelsson [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-August/003440.html From mandy.chung at oracle.com Wed Aug 6 17:23:23 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 06 Aug 2014 10:23:23 -0700 Subject: Result: New Jigsaw Committer: Mike Duigou Message-ID: <53E2648B.9090202@oracle.com> Voting forMike Duigou [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-August/003441.html From Alan.Bateman at oracle.com Thu Aug 7 13:29:48 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Aug 2014 14:29:48 +0100 Subject: JEP 201: Modular Source Code In-Reply-To: References: <20140805164907.7EF17329BF@eggemoggin.niobe.net> Message-ID: <53E37F4C.4040403@oracle.com> On 06/08/2014 15:08, Stephen Colebourne wrote: > Just wanted to express my surprise that java files are still to be > located in "src/.../classes". For me, most open source projects and > most users of Maven and other build systems, "classes" is the name of > the *output* directory containing ".class" files. Having the ".java" > files in there is very confusing. > > As such, could I request that consideration is given to using > "src/.../java" as per the Maven inspired standard directory layout. > > If that is not deemed acceptable (because of the root package name of > java for example) I'd be happy with other sensible options > ("src/.../javasrc"?), but please, not "classes"! > A historical note, going way back then the java sources were in a "java" directory (as in java/java/lang/Object.java). It changed to using "classes" in JDK 1.2. I don't know the full history/rational but perhaps "java/java" was confusing then. Using "classes" might seem strange to someone approaching the code base for the first time but I haven't observed anyone being confused by it (at least in the 7 years to date of OpenJDK). So the name might not matter too much but no harm considering whether it's worth trying to find a better name. Just to mention that anyone expecting to see "classes" in the intermediate build output directory is going to be disappointed as that is proposed to go away. I doubt that many will notice this. -Alan. From chris.hegarty at oracle.com Fri Aug 8 10:18:48 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Aug 2014 10:18:48 +0000 Subject: hg: jigsaw/stage/jdk: Move package descriptions to their correct location Message-ID: <201408081018.s78AImxe001671@aojmv0008> Changeset: ffc07c4dc2fd Author: chegar Date: 2014-08-07 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/ffc07c4dc2fd Move package descriptions to their correct location - src/java.base/share/classes/java/lang/instrument/package.html - src/java.base/share/classes/java/lang/management/package.html - src/java.base/share/classes/java/util/logging/package.html - src/java.base/share/classes/java/util/prefs/package.html + src/java.instrument/share/classes/java/lang/instrument/package.html + src/java.logging/share/classes/java/util/logging/package.html + src/java.management/share/classes/java/lang/management/package.html + src/java.prefs/share/classes/java/util/prefs/package.html From chris.hegarty at oracle.com Fri Aug 8 10:28:36 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Aug 2014 10:28:36 +0000 Subject: hg: jigsaw/stage/hotspot: Restore original jcheck configuration Message-ID: <201408081028.s78ASab4003525@aojmv0008> Changeset: 58ecb26d3514 Author: chegar Date: 2014-08-08 11:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/58ecb26d3514 Restore original jcheck configuration ! .jcheck/conf From chris.hegarty at oracle.com Fri Aug 8 15:20:05 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Aug 2014 15:20:05 +0000 Subject: hg: jigsaw/stage: Script to aid back-porting of patches from JDK 9 to 8u Message-ID: <201408081520.s78FK6FA020979@aojmv0008> Changeset: 7b9fd78f2381 Author: chegar Date: 2014-08-08 16:19 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/7b9fd78f2381 Script to aid back-porting of patches from JDK 9 to 8u + common/bin/unshuffle_list.txt + common/bin/unshuffle_patch.sh From erik.joelsson at oracle.com Fri Aug 8 15:57:09 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 08 Aug 2014 15:57:09 +0000 Subject: hg: jigsaw/stage: Moved oracle.accessbridge to its own module. Reorginized CopyFiles.gmk Message-ID: <201408081557.s78Fv9vE026446@aojmv0008> Changeset: a3a652668c22 Author: erikj Date: 2014-08-08 17:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/a3a652668c22 Moved oracle.accessbridge to its own module. Reorginized CopyFiles.gmk ! make/CompileJavaModules.gmk ! make/Main.gmk From erik.joelsson at oracle.com Fri Aug 8 15:58:38 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 08 Aug 2014 15:58:38 +0000 Subject: hg: jigsaw/stage/jdk: Moved oracle.accessbridge to its own module. Reorginized CopyFiles.gmk Message-ID: <201408081558.s78Fwci5026845@aojmv0008> Changeset: cc9c120c9321 Author: erikj Date: 2014-08-08 17:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/cc9c120c9321 Moved oracle.accessbridge to its own module. Reorginized CopyFiles.gmk - make/CopyFiles.gmk ! make/CreateJars.gmk + make/copy/Copy-java.base.gmk + make/copy/Copy-java.desktop.gmk + make/copy/Copy-java.logging.gmk + make/copy/Copy-java.management.gmk + make/copy/Copy-jdk.hprof.agent.gmk + make/copy/Copy-jdk.jdwp.agent.gmk + make/copy/CopyCommon.gmk ! make/lib/PlatformLibraries.gmk From chris.hegarty at oracle.com Sun Aug 10 20:17:04 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:17:04 +0000 Subject: hg: jigsaw/stage: 7 new changesets Message-ID: <201408102017.s7AKH4UQ004715@aojmv0008> Changeset: d2c492570bd9 Author: mikael Date: 2014-07-16 15:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/d2c492570bd9 8050802: Update jprt runthese test suite to jck-8 Reviewed-by: dholmes, kvn ! make/jprt.properties Changeset: a3350d68c12f Author: sspitsyn Date: 2014-07-23 12:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/a3350d68c12f Merge Changeset: 782deb57da19 Author: amurillo Date: 2014-07-24 13:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/782deb57da19 Merge Changeset: 9f7e3458a6b6 Author: mikael Date: 2014-07-31 11:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/9f7e3458a6b6 8054009: Support SKIP_BOOT_CYCLE=false when invoked from JPRT Reviewed-by: dholmes, erikj ! make/Jprt.gmk Changeset: d3ec8d048e6c Author: lana Date: 2014-08-04 15:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/d3ec8d048e6c Merge Changeset: 309471e3084e Author: chegar Date: 2014-08-08 19:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/309471e3084e Merge ! make/Jprt.gmk ! make/jprt.properties Changeset: 25616745e0c0 Author: chegar Date: 2014-08-10 19:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/25616745e0c0 Fix up jdk9-b26 changes ! make/CompileJavaModules.gmk ! make/common/SetupJava.gmk From chris.hegarty at oracle.com Sun Aug 10 20:17:18 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:17:18 +0000 Subject: hg: jigsaw/stage/jaxp: 6 new changesets Message-ID: <201408102017.s7AKHIx7004824@aojmv0008> Changeset: 86f7146ceafe Author: henryjen Date: 2014-07-02 14:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/86f7146ceafe 8049109: Add @since 1.9 to new packages added in jaxp Reviewed-by: darcy, joehw ! src/org/w3c/dom/ranges/DocumentRange.java ! src/org/w3c/dom/ranges/Range.java ! src/org/w3c/dom/ranges/RangeException.java ! src/org/w3c/dom/traversal/DocumentTraversal.java ! src/org/w3c/dom/traversal/NodeFilter.java ! src/org/w3c/dom/traversal/NodeIterator.java ! src/org/w3c/dom/traversal/TreeWalker.java Changeset: 47cf7edd100d Author: joehw Date: 2014-07-29 20:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/47cf7edd100d 8035467: Xerces Update: Move to Xalan based DOM L3 serializer. Deprecate Xerces' native serializer. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java ! src/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java ! src/com/sun/org/apache/xml/internal/serialize/DOMSerializer.java ! src/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java ! src/com/sun/org/apache/xml/internal/serialize/ElementState.java ! src/com/sun/org/apache/xml/internal/serialize/EncodingInfo.java ! src/com/sun/org/apache/xml/internal/serialize/Encodings.java ! src/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java ! src/com/sun/org/apache/xml/internal/serialize/IndentPrinter.java ! src/com/sun/org/apache/xml/internal/serialize/LineSeparator.java ! src/com/sun/org/apache/xml/internal/serialize/Method.java ! src/com/sun/org/apache/xml/internal/serialize/OutputFormat.java ! src/com/sun/org/apache/xml/internal/serialize/Printer.java ! src/com/sun/org/apache/xml/internal/serialize/Serializer.java ! src/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java ! src/com/sun/org/apache/xml/internal/serialize/SerializerFactoryImpl.java ! src/com/sun/org/apache/xml/internal/serialize/TextSerializer.java ! src/com/sun/org/apache/xml/internal/serialize/XML11Serializer.java ! src/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java + src/com/sun/org/apache/xml/internal/serializer/DOM3Serializer.java ! src/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java ! src/com/sun/org/apache/xml/internal/serializer/Encodings.java ! src/com/sun/org/apache/xml/internal/serializer/SerializationHandler.java ! src/com/sun/org/apache/xml/internal/serializer/Serializer.java ! src/com/sun/org/apache/xml/internal/serializer/SerializerBase.java ! src/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java ! src/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOM3SerializerImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorHandlerImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOMLocatorImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOMOutputImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/DOMStringListImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java + src/com/sun/org/apache/xml/internal/serializer/dom3/NamespaceSupport.java ! src/com/sun/org/apache/xml/internal/serializer/utils/MsgKey.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ca.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_cs.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java Changeset: 5e1cfe5f2ec3 Author: joehw Date: 2014-07-30 10:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/5e1cfe5f2ec3 8053965: Xerces update breaks profile build Reviewed-by: lancea, alanb ! src/com/sun/org/apache/xml/internal/serializer/dom3/DOMOutputImpl.java Changeset: ad9b12140e6c Author: aefimov Date: 2014-07-31 11:34 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/ad9b12140e6c 8032908: getTextContent doesn't return string in JAXP Reviewed-by: joehw ! src/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java Changeset: a5aea8318ae4 Author: lana Date: 2014-08-04 15:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/a5aea8318ae4 Merge Changeset: fc498f10aa7e Author: chegar Date: 2014-08-08 19:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/fc498f10aa7e Merge ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/ElementState.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/EncodingInfo.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/IndentPrinter.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/LineSeparator.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Method.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/OutputFormat.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Printer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Serializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/TextSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/XML11Serializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/DOM3Serializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializationHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Serializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3SerializerImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMConstants.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorHandlerImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMErrorImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMLocatorImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMOutputImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOMStringListImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/LSSerializerImpl.java + src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/NamespaceSupport.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/MsgKey.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ca.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_cs.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java ! src/java.xml/share/classes/org/w3c/dom/ranges/DocumentRange.java ! src/java.xml/share/classes/org/w3c/dom/ranges/Range.java ! src/java.xml/share/classes/org/w3c/dom/ranges/RangeException.java ! src/java.xml/share/classes/org/w3c/dom/traversal/DocumentTraversal.java ! src/java.xml/share/classes/org/w3c/dom/traversal/NodeFilter.java ! src/java.xml/share/classes/org/w3c/dom/traversal/NodeIterator.java ! src/java.xml/share/classes/org/w3c/dom/traversal/TreeWalker.java From chris.hegarty at oracle.com Sun Aug 10 20:17:28 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:17:28 +0000 Subject: hg: jigsaw/stage/jaxws: 3 new changesets Message-ID: <201408102017.s7AKHSkv004886@aojmv0008> Changeset: 1b90914c37b8 Author: henryjen Date: 2014-06-19 15:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxws/rev/1b90914c37b8 8047724: @since tag cleanup in jaxws Reviewed-by: alanb, mkos ! src/share/jaf_classes/javax/activation/CommandMap.java ! src/share/jaf_classes/javax/activation/MailcapCommandMap.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/api/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/DOMScanner.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/unmarshaller/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/util/AttributesImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java ! src/share/jaxws_classes/javax/annotation/Generated.java ! src/share/jaxws_classes/javax/annotation/PostConstruct.java ! src/share/jaxws_classes/javax/annotation/PreDestroy.java ! src/share/jaxws_classes/javax/annotation/Resource.java ! src/share/jaxws_classes/javax/annotation/Resources.java ! src/share/jaxws_classes/javax/jws/HandlerChain.java ! src/share/jaxws_classes/javax/jws/Oneway.java ! src/share/jaxws_classes/javax/jws/WebMethod.java ! src/share/jaxws_classes/javax/jws/WebParam.java ! src/share/jaxws_classes/javax/jws/WebResult.java ! src/share/jaxws_classes/javax/jws/WebService.java ! src/share/jaxws_classes/javax/jws/soap/InitParam.java ! src/share/jaxws_classes/javax/jws/soap/SOAPBinding.java ! src/share/jaxws_classes/javax/jws/soap/SOAPMessageHandler.java ! src/share/jaxws_classes/javax/jws/soap/SOAPMessageHandlers.java ! src/share/jaxws_classes/javax/xml/bind/Binder.java ! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java ! src/share/jaxws_classes/javax/xml/bind/Element.java ! src/share/jaxws_classes/javax/xml/bind/JAXB.java ! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java ! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java ! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java ! src/share/jaxws_classes/javax/xml/bind/MarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Marshaller.java ! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java ! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PropertyException.java ! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java ! src/share/jaxws_classes/javax/xml/bind/ValidationException.java ! src/share/jaxws_classes/javax/xml/bind/Validator.java ! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlInlineBinaryData.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMimeType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java ! src/share/jaxws_classes/javax/xml/bind/annotation/package.html ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/package.html ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java ! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java ! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java ! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java ! src/share/jaxws_classes/javax/xml/soap/AttachmentPart.java ! src/share/jaxws_classes/javax/xml/soap/Detail.java ! src/share/jaxws_classes/javax/xml/soap/DetailEntry.java ! src/share/jaxws_classes/javax/xml/soap/MessageFactory.java ! src/share/jaxws_classes/javax/xml/soap/MimeHeader.java ! src/share/jaxws_classes/javax/xml/soap/MimeHeaders.java ! src/share/jaxws_classes/javax/xml/soap/Name.java ! src/share/jaxws_classes/javax/xml/soap/Node.java ! src/share/jaxws_classes/javax/xml/soap/SAAJMetaFactory.java ! src/share/jaxws_classes/javax/xml/soap/SAAJResult.java ! src/share/jaxws_classes/javax/xml/soap/SOAPBody.java ! src/share/jaxws_classes/javax/xml/soap/SOAPBodyElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnection.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConnectionFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPConstants.java ! src/share/jaxws_classes/javax/xml/soap/SOAPElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPElementFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPEnvelope.java ! src/share/jaxws_classes/javax/xml/soap/SOAPException.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFactory.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFault.java ! src/share/jaxws_classes/javax/xml/soap/SOAPFaultElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPHeader.java ! src/share/jaxws_classes/javax/xml/soap/SOAPHeaderElement.java ! src/share/jaxws_classes/javax/xml/soap/SOAPMessage.java ! src/share/jaxws_classes/javax/xml/soap/SOAPPart.java ! src/share/jaxws_classes/javax/xml/soap/Text.java ! src/share/jaxws_classes/javax/xml/ws/Action.java ! src/share/jaxws_classes/javax/xml/ws/AsyncHandler.java ! src/share/jaxws_classes/javax/xml/ws/Binding.java ! src/share/jaxws_classes/javax/xml/ws/BindingProvider.java ! src/share/jaxws_classes/javax/xml/ws/BindingType.java ! src/share/jaxws_classes/javax/xml/ws/Dispatch.java ! src/share/jaxws_classes/javax/xml/ws/Endpoint.java ! src/share/jaxws_classes/javax/xml/ws/EndpointContext.java ! src/share/jaxws_classes/javax/xml/ws/EndpointReference.java ! src/share/jaxws_classes/javax/xml/ws/FaultAction.java ! src/share/jaxws_classes/javax/xml/ws/Holder.java ! src/share/jaxws_classes/javax/xml/ws/LogicalMessage.java ! src/share/jaxws_classes/javax/xml/ws/ProtocolException.java ! src/share/jaxws_classes/javax/xml/ws/Provider.java ! src/share/jaxws_classes/javax/xml/ws/RequestWrapper.java ! src/share/jaxws_classes/javax/xml/ws/RespectBinding.java ! src/share/jaxws_classes/javax/xml/ws/RespectBindingFeature.java ! src/share/jaxws_classes/javax/xml/ws/Response.java ! src/share/jaxws_classes/javax/xml/ws/ResponseWrapper.java ! src/share/jaxws_classes/javax/xml/ws/Service.java ! src/share/jaxws_classes/javax/xml/ws/ServiceMode.java ! src/share/jaxws_classes/javax/xml/ws/WebEndpoint.java ! src/share/jaxws_classes/javax/xml/ws/WebFault.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceClient.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceContext.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceException.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceFeature.java ! src/share/jaxws_classes/javax/xml/ws/WebServicePermission.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceProvider.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceRef.java ! src/share/jaxws_classes/javax/xml/ws/WebServiceRefs.java ! src/share/jaxws_classes/javax/xml/ws/handler/Handler.java ! src/share/jaxws_classes/javax/xml/ws/handler/HandlerResolver.java ! src/share/jaxws_classes/javax/xml/ws/handler/LogicalHandler.java ! src/share/jaxws_classes/javax/xml/ws/handler/LogicalMessageContext.java ! src/share/jaxws_classes/javax/xml/ws/handler/MessageContext.java ! src/share/jaxws_classes/javax/xml/ws/handler/PortInfo.java ! src/share/jaxws_classes/javax/xml/ws/handler/soap/SOAPHandler.java ! src/share/jaxws_classes/javax/xml/ws/handler/soap/SOAPMessageContext.java ! src/share/jaxws_classes/javax/xml/ws/http/HTTPBinding.java ! src/share/jaxws_classes/javax/xml/ws/http/HTTPException.java ! src/share/jaxws_classes/javax/xml/ws/soap/Addressing.java ! src/share/jaxws_classes/javax/xml/ws/soap/AddressingFeature.java ! src/share/jaxws_classes/javax/xml/ws/soap/MTOM.java ! src/share/jaxws_classes/javax/xml/ws/soap/MTOMFeature.java ! src/share/jaxws_classes/javax/xml/ws/soap/SOAPBinding.java ! src/share/jaxws_classes/javax/xml/ws/soap/SOAPFaultException.java ! src/share/jaxws_classes/javax/xml/ws/spi/Invoker.java ! src/share/jaxws_classes/javax/xml/ws/spi/Provider.java ! src/share/jaxws_classes/javax/xml/ws/spi/ServiceDelegate.java ! src/share/jaxws_classes/javax/xml/ws/spi/WebServiceFeatureAnnotation.java ! src/share/jaxws_classes/javax/xml/ws/spi/http/HttpContext.java ! src/share/jaxws_classes/javax/xml/ws/spi/http/HttpExchange.java ! src/share/jaxws_classes/javax/xml/ws/spi/http/HttpHandler.java ! src/share/jaxws_classes/javax/xml/ws/spi/http/package-info.java ! src/share/jaxws_classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java ! src/share/jaxws_classes/javax/xml/ws/wsaddressing/W3CEndpointReferenceBuilder.java Changeset: 9b43f3993b96 Author: lana Date: 2014-08-04 15:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxws/rev/9b43f3993b96 Merge Changeset: 052d549a9fe4 Author: chegar Date: 2014-08-08 19:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxws/rev/052d549a9fe4 Merge ! src/java.activation/share/classes/javax/activation/CommandMap.java ! src/java.activation/share/classes/javax/activation/MailcapCommandMap.java ! src/java.annotations.common/share/classes/javax/annotation/Generated.java ! src/java.annotations.common/share/classes/javax/annotation/PostConstruct.java ! src/java.annotations.common/share/classes/javax/annotation/PreDestroy.java ! src/java.annotations.common/share/classes/javax/annotation/Resource.java ! src/java.annotations.common/share/classes/javax/annotation/Resources.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/api/Messages.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/Messages.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/unmarshaller/DOMScanner.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/unmarshaller/Messages.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/util/AttributesImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/XMLWriter.java ! src/java.xml.bind/share/classes/javax/xml/bind/Binder.java ! src/java.xml.bind/share/classes/javax/xml/bind/DataBindingException.java ! src/java.xml.bind/share/classes/javax/xml/bind/DatatypeConverter.java ! src/java.xml.bind/share/classes/javax/xml/bind/DatatypeConverterImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/DatatypeConverterInterface.java ! src/java.xml.bind/share/classes/javax/xml/bind/Element.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXB.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBContext.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBElement.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBException.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBIntrospector.java ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBPermission.java ! src/java.xml.bind/share/classes/javax/xml/bind/MarshalException.java ! src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/NotIdentifiableEvent.java ! src/java.xml.bind/share/classes/javax/xml/bind/ParseConversionEvent.java ! src/java.xml.bind/share/classes/javax/xml/bind/PrintConversionEvent.java ! src/java.xml.bind/share/classes/javax/xml/bind/PropertyException.java ! src/java.xml.bind/share/classes/javax/xml/bind/SchemaOutputResolver.java ! src/java.xml.bind/share/classes/javax/xml/bind/TypeConstraintException.java ! src/java.xml.bind/share/classes/javax/xml/bind/UnmarshalException.java ! src/java.xml.bind/share/classes/javax/xml/bind/Unmarshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/UnmarshallerHandler.java ! src/java.xml.bind/share/classes/javax/xml/bind/ValidationEvent.java ! src/java.xml.bind/share/classes/javax/xml/bind/ValidationEventHandler.java ! src/java.xml.bind/share/classes/javax/xml/bind/ValidationEventLocator.java ! src/java.xml.bind/share/classes/javax/xml/bind/ValidationException.java ! src/java.xml.bind/share/classes/javax/xml/bind/Validator.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/DomHandler.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/W3CDomHandler.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAccessOrder.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAccessType.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAccessorOrder.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAccessorType.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAnyAttribute.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAnyElement.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAttachmentRef.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlAttribute.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlElement.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlElementDecl.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlElementRef.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlElementRefs.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlElementWrapper.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlElements.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlEnum.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlEnumValue.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlID.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlIDREF.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlInlineBinaryData.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlList.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlMimeType.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlMixed.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlNs.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlNsForm.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlRegistry.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlRootElement.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlSchema.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlSchemaType.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlSchemaTypes.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlSeeAlso.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlTransient.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlType.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlValue.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/XmlAdapter.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/attachment/AttachmentMarshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/attachment/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/ParseConversionEventImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/PrintConversionEventImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/ValidationEventImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java ! src/java.xml.bind/share/classes/javax/xml/bind/util/JAXBResult.java ! src/java.xml.bind/share/classes/javax/xml/bind/util/JAXBSource.java ! src/java.xml.bind/share/classes/javax/xml/bind/util/ValidationEventCollector.java ! src/java.xml.soap/share/classes/javax/xml/soap/AttachmentPart.java ! src/java.xml.soap/share/classes/javax/xml/soap/Detail.java ! src/java.xml.soap/share/classes/javax/xml/soap/DetailEntry.java ! src/java.xml.soap/share/classes/javax/xml/soap/MessageFactory.java ! src/java.xml.soap/share/classes/javax/xml/soap/MimeHeader.java ! src/java.xml.soap/share/classes/javax/xml/soap/MimeHeaders.java ! src/java.xml.soap/share/classes/javax/xml/soap/Name.java ! src/java.xml.soap/share/classes/javax/xml/soap/Node.java ! src/java.xml.soap/share/classes/javax/xml/soap/SAAJMetaFactory.java ! src/java.xml.soap/share/classes/javax/xml/soap/SAAJResult.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPBody.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPBodyElement.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPConnection.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPConnectionFactory.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPConstants.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPElement.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPElementFactory.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPEnvelope.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPException.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPFactory.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPFault.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPFaultElement.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPHeader.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPHeaderElement.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPMessage.java ! src/java.xml.soap/share/classes/javax/xml/soap/SOAPPart.java ! src/java.xml.soap/share/classes/javax/xml/soap/Text.java ! src/java.xml.ws/share/classes/javax/jws/HandlerChain.java ! src/java.xml.ws/share/classes/javax/jws/Oneway.java ! src/java.xml.ws/share/classes/javax/jws/WebMethod.java ! src/java.xml.ws/share/classes/javax/jws/WebParam.java ! src/java.xml.ws/share/classes/javax/jws/WebResult.java ! src/java.xml.ws/share/classes/javax/jws/WebService.java ! src/java.xml.ws/share/classes/javax/jws/soap/InitParam.java ! src/java.xml.ws/share/classes/javax/jws/soap/SOAPBinding.java ! src/java.xml.ws/share/classes/javax/jws/soap/SOAPMessageHandler.java ! src/java.xml.ws/share/classes/javax/jws/soap/SOAPMessageHandlers.java ! src/java.xml.ws/share/classes/javax/xml/ws/Action.java ! src/java.xml.ws/share/classes/javax/xml/ws/AsyncHandler.java ! src/java.xml.ws/share/classes/javax/xml/ws/Binding.java ! src/java.xml.ws/share/classes/javax/xml/ws/BindingProvider.java ! src/java.xml.ws/share/classes/javax/xml/ws/BindingType.java ! src/java.xml.ws/share/classes/javax/xml/ws/Dispatch.java ! src/java.xml.ws/share/classes/javax/xml/ws/Endpoint.java ! src/java.xml.ws/share/classes/javax/xml/ws/EndpointContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/EndpointReference.java ! src/java.xml.ws/share/classes/javax/xml/ws/FaultAction.java ! src/java.xml.ws/share/classes/javax/xml/ws/Holder.java ! src/java.xml.ws/share/classes/javax/xml/ws/LogicalMessage.java ! src/java.xml.ws/share/classes/javax/xml/ws/ProtocolException.java ! src/java.xml.ws/share/classes/javax/xml/ws/Provider.java ! src/java.xml.ws/share/classes/javax/xml/ws/RequestWrapper.java ! src/java.xml.ws/share/classes/javax/xml/ws/RespectBinding.java ! src/java.xml.ws/share/classes/javax/xml/ws/RespectBindingFeature.java ! src/java.xml.ws/share/classes/javax/xml/ws/Response.java ! src/java.xml.ws/share/classes/javax/xml/ws/ResponseWrapper.java ! src/java.xml.ws/share/classes/javax/xml/ws/Service.java ! src/java.xml.ws/share/classes/javax/xml/ws/ServiceMode.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebEndpoint.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebFault.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceClient.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceException.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceFeature.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServicePermission.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceProvider.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java ! src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRefs.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/Handler.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/HandlerResolver.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/LogicalHandler.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/LogicalMessageContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/MessageContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/PortInfo.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPHandler.java ! src/java.xml.ws/share/classes/javax/xml/ws/handler/soap/SOAPMessageContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/http/HTTPBinding.java ! src/java.xml.ws/share/classes/javax/xml/ws/http/HTTPException.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/Addressing.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/AddressingFeature.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/MTOM.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/MTOMFeature.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPBinding.java ! src/java.xml.ws/share/classes/javax/xml/ws/soap/SOAPFaultException.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/Invoker.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/Provider.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/ServiceDelegate.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/WebServiceFeatureAnnotation.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/http/HttpContext.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/http/HttpExchange.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/http/HttpHandler.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/http/package-info.java ! src/java.xml.ws/share/classes/javax/xml/ws/wsaddressing/W3CEndpointReference.java ! src/java.xml.ws/share/classes/javax/xml/ws/wsaddressing/W3CEndpointReferenceBuilder.java From chris.hegarty at oracle.com Sun Aug 10 20:17:37 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:17:37 +0000 Subject: hg: jigsaw/stage/langtools: 7 new changesets Message-ID: <201408102017.s7AKHbTc004964@aojmv0008> Changeset: af5e8c248039 Author: mcimadamore Date: 2014-07-24 13:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/af5e8c248039 8048890: Add option to keep track of symbol completion dependencies Summary: Generate dot file with representation of javac on-demand symbol completion dependencies Reviewed-by: jjg, jlahoda ! src/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/main/Main.java + src/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java Changeset: a4c3e1a02a31 Author: anazarov Date: 2014-07-24 15:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/a4c3e1a02a31 8050979: Provide javadoc for "framework" classes in langtools tests Reviewed-by: jjg ! test/tools/javac/classfiles/attributes/LocalVariableTable/LocalVariableTestBase.java ! test/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase.java ! test/tools/javac/classfiles/attributes/lib/TestBase.java Changeset: efad946b1330 Author: mcimadamore Date: 2014-07-29 15:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/efad946b1330 8051958: Cannot assign a value to final variable in lambda Summary: Remove Attr.owner and refactor code for detecting forward field references Reviewed-by: vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/8051958/T8051958.java Changeset: b57166d59a4d Author: kizune Date: 2014-07-30 20:31 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/b57166d59a4d 8047072: javap OOM on fuzzed classfile Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/resources/javap.properties + test/tools/javap/BadAttributeLength.java Changeset: d2b75f318fea Author: jlahoda Date: 2014-08-01 11:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/d2b75f318fea 8043643: Add an crules analyzer avoiding string concatenation in messages of Assert checks. Summary: Generalizing the crules infrastructure, adding a new analyzer to check String concatenation in Assert calls. Reviewed-by: jjg, vromero ! make/build.properties ! make/build.xml + make/test/crules/CodingRulesAnalyzerPlugin/Test.java + make/test/crules/CodingRulesAnalyzerPlugin/Test.out + make/test/crules/MutableFieldsAnalyzer/Test.java + make/test/crules/MutableFieldsAnalyzer/Test.out ! make/tools/crules/AbstractCodingRulesAnalyzer.java + make/tools/crules/AssertCheckAnalyzer.java + make/tools/crules/CodingRulesAnalyzerPlugin.java ! make/tools/crules/MutableFieldsAnalyzer.java ! make/tools/crules/resources/crules.properties ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/util/Assert.java ! src/share/classes/com/sun/tools/javac/util/Bits.java + test/tools/all/RunCodingRules.java Changeset: 5b20a93f8db0 Author: lana Date: 2014-08-04 15:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/5b20a93f8db0 Merge Changeset: 0d53d540203f Author: chegar Date: 2014-08-08 19:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/0d53d540203f Merge ! make/build.xml ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Assert.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Bits.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javap/resources/javap.properties From chris.hegarty at oracle.com Sun Aug 10 20:18:21 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:18:21 +0000 Subject: hg: jigsaw/stage/jdk: 70 new changesets Message-ID: <201408102018.s7AKIOXq005066@aojmv0008> Changeset: 1254df1151d2 Author: mduigou Date: 2014-07-24 09:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/1254df1151d2 8048209: Collections.synchronizedNavigableSet().tailSet(Object,boolean) synchronizes on wrong object Reviewed-by: psandoz, chegar ! src/share/classes/java/util/Collections.java + test/java/util/Collections/SyncSubMutexes.java Changeset: 8c7eee281a64 Author: robm Date: 2014-07-24 22:22 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/8c7eee281a64 8044659: Java SecureRandom on SPARC T4 much slower than on x86/Linux Reviewed-by: mullan Contributed-by: Bradford Wetmore ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: 5b31f39ccbe3 Author: weijun Date: 2014-07-25 17:11 +0800 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/5b31f39ccbe3 8051953: Add Unreachable.java test to ProblemList on Windows Reviewed-by: chegar ! test/ProblemList.txt Changeset: 39b09fc36115 Author: jbachorik Date: 2014-07-25 15:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/39b09fc36115 8049194: com/sun/tools/attach/StartManagementAgent.java start failing after JDK-8048193 Reviewed-by: dfuchs, egahlin, olagneau ! test/com/sun/jdi/ExclusiveBind.java ! test/javax/management/monitor/StartStopTest.java ! test/lib/testlibrary/jdk/testlibrary/ProcessThread.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/lib/testlibrary/jdk/testlibrary/Utils.java Changeset: 5255186a7f4d Author: prappo Date: 2014-07-28 16:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/5255186a7f4d 8051422: Remove JNDI dependency on java.applet.Applet Reviewed-by: alanb, chegar ! src/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java ! src/share/classes/com/sun/naming/internal/ResourceManager.java ! src/share/classes/javax/naming/Context.java ! src/share/classes/javax/naming/InitialContext.java ! src/share/classes/javax/naming/ldap/LdapContext.java ! src/share/classes/javax/naming/spi/NamingManager.java + test/javax/naming/InitialContext/AppletIsNotUsed.java ! test/javax/naming/InitialContext/NoApplet.java Changeset: 7c9c6876aa09 Author: darcy Date: 2014-07-28 23:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/7c9c6876aa09 8030942: Explicitly state floating-point summation requirements on non-finite inputs Reviewed-by: psandoz ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/stream/DoubleStream.java Changeset: 607b15cdc425 Author: jbachorik Date: 2014-07-29 10:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/607b15cdc425 8030115: [parfait] warnings from b119 for jdk.src.share.native.sun.tracing.dtrace: JNI exception pending Reviewed-by: dholmes, dsamersoff, sspitsyn ! src/share/native/sun/tracing/dtrace/JVM.c Changeset: 2b1a17af5308 Author: dsamersoff Date: 2014-07-29 13:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/2b1a17af5308 8053902: Fix for 8030115 breaks build on Windows and Solaris Summary: Move variable definition to top of function Reviewed-by: prr ! src/share/native/sun/tracing/dtrace/JVM.c Changeset: 928621062f51 Author: avstepan Date: 2014-07-08 16:01 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/928621062f51 8043126: move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository Reviewed-by: pchelko + test/java/awt/event/KeyEvent/ExtendedModifiersTest/ExtendedModifiersTest.java + test/java/awt/event/KeyEvent/KeyMaskTest/KeyMaskTest.java + test/java/awt/event/MouseEvent/MouseButtonsAndKeyMasksTest/MouseButtonsAndKeyMasksTest.java + test/java/awt/event/MouseEvent/MouseButtonsTest/MouseButtonsTest.java + test/java/awt/event/MouseEvent/MultipleMouseButtonsTest/MultipleMouseButtonsTest.java + test/java/awt/event/helpers/lwcomponents/LWButton.java + test/java/awt/event/helpers/lwcomponents/LWComponent.java + test/java/awt/event/helpers/lwcomponents/LWList.java Changeset: 128190321f5d Author: anashaty Date: 2014-07-08 16:42 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/128190321f5d 8047066: Test test/sun/awt/image/bug8038000.java fails with ClassCastException Reviewed-by: bae, prr ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! test/sun/awt/image/bug8038000.java Changeset: 2b77aad998b0 Author: smarks Date: 2014-07-08 09:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/2b77aad998b0 8047025: Fix raw and unchecked lint warnings in generated nimbus files Reviewed-by: henryjen, prr ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/plaf/nimbus/StateImpl.template Changeset: 051285a4490c Author: avstepan Date: 2014-07-09 12:56 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/051285a4490c 8047367: move awt automated tests from AWT_Modality to OpenJDK repository - part 2 Reviewed-by: pchelko + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFAppModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFDocModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFModelessTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFNonModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDWFTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsAppModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsDocModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsModelessTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsNonModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferDialogsTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWAppModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWDocModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWModelessTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWNonModalTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFDWTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDAppModal4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDDocModal4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDModeless4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDNonModal4Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferFWDTest.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFAppModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFDocModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFModeless3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal1Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal2Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFNonModal3Test.java + test/java/awt/Modal/ModalFocusTransferTests/FocusTransferWDFTest.java + test/java/awt/Modal/ModalitySettingsTest/ModalitySettingsTest.java + test/java/awt/Modal/NullModalityDialogTest/NullModalityDialogTest.java ! test/java/awt/Modal/helpers/TestDialog.java ! test/java/awt/Modal/helpers/TestFrame.java ! test/java/awt/Modal/helpers/TestWindow.java Changeset: dad130cfdaaa Author: ssides Date: 2014-07-09 15:14 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/dad130cfdaaa 8046597: fix doclint issues in swing classes, part 4 of 4 Reviewed-by: pchelko ! src/share/classes/javax/swing/AbstractAction.java ! src/share/classes/javax/swing/CellRendererPane.java ! src/share/classes/javax/swing/DebugGraphics.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/DesktopManager.java ! src/share/classes/javax/swing/GrayFilter.java ! src/share/classes/javax/swing/Icon.java ! src/share/classes/javax/swing/JApplet.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SpinnerModel.java ! src/share/classes/javax/swing/Timer.java Changeset: cc87c0d62651 Author: aeremeev Date: 2014-07-09 17:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/cc87c0d62651 8043968: Fix doclint warnings from javax.swing.plaf.basic package, 1 of 7 Reviewed-by: pchelko ! src/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicHTML.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPanelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRootPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToggleButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicViewportUI.java ! src/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java Changeset: 91fe43cc7c98 Author: henryjen Date: 2014-06-27 10:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/91fe43cc7c98 8044862: Fix raw and unchecked lint warnings in macosx specific code Reviewed-by: darcy, pchelko ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/macosx/classes/com/apple/laf/AquaBorder.java ! src/macosx/classes/com/apple/laf/AquaComboBoxButton.java ! src/macosx/classes/com/apple/laf/AquaComboBoxPopup.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java ! src/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/macosx/classes/com/apple/laf/AquaFocusHandler.java ! src/macosx/classes/com/apple/laf/AquaListUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/macosx/classes/com/apple/laf/AquaUtils.java ! src/macosx/classes/com/apple/laf/ClientPropertyApplicator.java ! src/macosx/classes/com/apple/laf/ScreenMenuBar.java ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 9fe87c9a16da Author: aeremeev Date: 2014-07-10 12:21 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/9fe87c9a16da 8049704: Fix doclint warnings from javax.swing.plaf.basic package, 2 of 7 Reviewed-by: pchelko ! src/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java Changeset: b2e756f77a2e Author: pchelko Date: 2014-07-10 15:08 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/b2e756f77a2e 8049830: Remove reflection from ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/laf/ScreenMenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/sun/awt/AWTAccessor.java Changeset: a13a49fc1810 Author: aeremeev Date: 2014-07-10 17:20 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/a13a49fc1810 8049808: Fix doclint warnings from javax.swing.plaf.basic package, 3 of 7 Reviewed-by: pchelko ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java Changeset: 6c875efda606 Author: mcherkas Date: 2014-07-10 18:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/6c875efda606 4991647: PNGMetadata.getAsTree() sets bitDepth to invalid value Reviewed-by: prr, bae ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/PngDitDepthTest.java Changeset: 802c5168d429 Author: darcy Date: 2014-07-10 15:27 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/802c5168d429 8049797: Fix raw and unchecked lint warnings in javax.swing.SortingFocusTraversalPolicy Reviewed-by: prr ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java Changeset: 0f61d05e28f1 Author: henryjen Date: 2014-06-23 10:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/0f61d05e28f1 8042872: Fix raw and unchecked warnings in sun.applet Reviewed-by: darcy, herrick ! src/share/classes/sun/applet/AppletClassLoader.java ! src/share/classes/sun/applet/AppletImageRef.java ! src/share/classes/sun/applet/AppletObjectInputStream.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/applet/AppletProps.java ! src/share/classes/sun/applet/AppletSecurity.java ! src/share/classes/sun/applet/AppletViewer.java ! src/share/classes/sun/applet/AppletViewerFactory.java ! src/share/classes/sun/applet/AppletViewerPanel.java ! src/share/classes/sun/applet/Main.java Changeset: fb3f4212427f Author: alexsch Date: 2014-07-11 12:08 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/fb3f4212427f 8049198: [macosx] Incorrect thread access when showing splash screen Reviewed-by: serb, pchelko ! src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m Changeset: d75c27eecdfe Author: avstepan Date: 2014-07-11 12:51 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/d75c27eecdfe 8037511: Tidy warnings cleanup for java.awt - 2d part Reviewed-by: prr ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Graphics.java ! src/share/classes/java/awt/Polygon.java ! src/share/classes/java/awt/Rectangle.java ! src/share/classes/java/awt/color/ColorSpace.java ! src/share/classes/java/awt/color/ICC_ColorSpace.java ! src/share/classes/java/awt/font/TextAttribute.java ! src/share/classes/java/awt/geom/Arc2D.java ! src/share/classes/java/awt/image/AffineTransformOp.java ! src/share/classes/java/awt/image/BufferedImageFilter.java ! src/share/classes/java/awt/image/ImageFilter.java ! src/share/classes/java/awt/image/WritableRaster.java ! src/share/classes/java/awt/print/PrinterJob.java ! src/share/classes/javax/imageio/package.html ! src/share/classes/javax/print/Doc.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/PrintServiceLookup.java ! src/share/classes/javax/print/ServiceUI.java ! src/share/classes/javax/print/ServiceUIFactory.java ! src/share/classes/javax/print/SimpleDoc.java ! src/share/classes/javax/print/StreamPrintServiceFactory.java ! src/share/classes/javax/print/attribute/Attribute.java ! src/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/share/classes/javax/print/attribute/DocAttribute.java ! src/share/classes/javax/print/attribute/DocAttributeSet.java ! src/share/classes/javax/print/attribute/EnumSyntax.java ! src/share/classes/javax/print/attribute/HashAttributeSet.java ! src/share/classes/javax/print/attribute/HashDocAttributeSet.java ! src/share/classes/javax/print/attribute/HashPrintJobAttributeSet.java ! src/share/classes/javax/print/attribute/HashPrintRequestAttributeSet.java ! src/share/classes/javax/print/attribute/HashPrintServiceAttributeSet.java ! src/share/classes/javax/print/attribute/IntegerSyntax.java ! src/share/classes/javax/print/attribute/PrintJobAttribute.java ! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/share/classes/javax/print/attribute/PrintRequestAttribute.java ! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/share/classes/javax/print/attribute/PrintServiceAttribute.java ! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/share/classes/javax/print/attribute/SetOfIntegerSyntax.java ! src/share/classes/javax/print/attribute/Size2DSyntax.java ! src/share/classes/javax/print/attribute/SupportedValuesAttribute.java ! src/share/classes/javax/print/attribute/TextSyntax.java ! src/share/classes/javax/print/attribute/URISyntax.java ! src/share/classes/javax/print/attribute/package.html ! src/share/classes/javax/print/attribute/standard/ColorSupported.java ! src/share/classes/javax/print/attribute/standard/Compression.java ! src/share/classes/javax/print/attribute/standard/CopiesSupported.java ! src/share/classes/javax/print/attribute/standard/DateTimeAtCompleted.java ! src/share/classes/javax/print/attribute/standard/DateTimeAtCreation.java ! src/share/classes/javax/print/attribute/standard/DateTimeAtProcessing.java ! src/share/classes/javax/print/attribute/standard/Destination.java ! src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java ! src/share/classes/javax/print/attribute/standard/DocumentName.java ! src/share/classes/javax/print/attribute/standard/JobHoldUntil.java ! src/share/classes/javax/print/attribute/standard/JobImpressions.java ! src/share/classes/javax/print/attribute/standard/JobImpressionsCompleted.java ! src/share/classes/javax/print/attribute/standard/JobImpressionsSupported.java ! src/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/share/classes/javax/print/attribute/standard/JobKOctetsProcessed.java ! src/share/classes/javax/print/attribute/standard/JobKOctetsSupported.java ! src/share/classes/javax/print/attribute/standard/JobMediaSheets.java ! src/share/classes/javax/print/attribute/standard/JobMediaSheetsCompleted.java ! src/share/classes/javax/print/attribute/standard/JobMediaSheetsSupported.java ! src/share/classes/javax/print/attribute/standard/JobMessageFromOperator.java ! src/share/classes/javax/print/attribute/standard/JobName.java ! src/share/classes/javax/print/attribute/standard/JobOriginatingUserName.java ! src/share/classes/javax/print/attribute/standard/JobPriority.java ! src/share/classes/javax/print/attribute/standard/JobPrioritySupported.java ! src/share/classes/javax/print/attribute/standard/JobSheets.java ! src/share/classes/javax/print/attribute/standard/JobState.java ! src/share/classes/javax/print/attribute/standard/JobStateReason.java ! src/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/share/classes/javax/print/attribute/standard/Media.java ! src/share/classes/javax/print/attribute/standard/MediaSize.java ! src/share/classes/javax/print/attribute/standard/NumberOfDocuments.java ! src/share/classes/javax/print/attribute/standard/NumberOfInterveningJobs.java ! src/share/classes/javax/print/attribute/standard/NumberUpSupported.java ! src/share/classes/javax/print/attribute/standard/OrientationRequested.java ! src/share/classes/javax/print/attribute/standard/OutputDeviceAssigned.java ! src/share/classes/javax/print/attribute/standard/PDLOverrideSupported.java ! src/share/classes/javax/print/attribute/standard/PagesPerMinute.java ! src/share/classes/javax/print/attribute/standard/PagesPerMinuteColor.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrintQuality.java ! src/share/classes/javax/print/attribute/standard/PrinterInfo.java ! src/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/share/classes/javax/print/attribute/standard/PrinterLocation.java ! src/share/classes/javax/print/attribute/standard/PrinterMakeAndModel.java ! src/share/classes/javax/print/attribute/standard/PrinterMessageFromOperator.java ! src/share/classes/javax/print/attribute/standard/PrinterMoreInfo.java ! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/share/classes/javax/print/attribute/standard/PrinterName.java ! src/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/share/classes/javax/print/attribute/standard/PrinterState.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/PrinterURI.java ! src/share/classes/javax/print/attribute/standard/QueuedJobCount.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/javax/print/attribute/standard/RequestingUserName.java ! src/share/classes/javax/print/attribute/standard/Severity.java ! src/share/classes/javax/print/attribute/standard/SheetCollate.java ! src/share/classes/javax/print/attribute/standard/package.html ! src/share/classes/javax/print/event/package.html ! src/share/classes/javax/print/package.html Changeset: 8a286e644c92 Author: serb Date: 2014-07-11 13:32 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/8a286e644c92 8049583: Test closed/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest fails on Window XP Reviewed-by: pchelko, anthony ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_List.cpp Changeset: b7d9f25bd883 Author: aeremeev Date: 2014-07-11 16:44 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/b7d9f25bd883 8049870: Fix doclint warnings from javax.swing.plaf.basic package, 4 of 7 Reviewed-by: pchelko ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java Changeset: 94f03bb92f78 Author: pchelko Date: 2014-07-11 18:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/94f03bb92f78 8049996: [macosx] test java/awt/image/ImageIconHang.java fails with NPE Reviewed-by: alexsch, azvegint ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 09a322666369 Author: prr Date: 2014-07-11 11:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/09a322666369 8048328: CUPS Printing does not report supported printer resolutions. Reviewed-by: bae, jgodinez ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt_headless/mapfile-vers ! make/mapfiles/libawt_xawt/mapfile-vers ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/native/sun/awt/CUPSfuncs.c + test/javax/print/attribute/PrintResAttr.java Changeset: 7a5d6ebf7da3 Author: aeremeev Date: 2014-07-14 18:44 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/7a5d6ebf7da3 8050009: Fix doclint warnings from javax.swing.plaf.basic package, 7 of 7 Reviewed-by: pchelko ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: cbf015c085d0 Author: darcy Date: 2014-07-14 09:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/cbf015c085d0 8047027: Fix raw and unchecked lint warnings in generated beaninfo files Reviewed-by: alanb, serb ! make/data/swingbeaninfo/SwingBeanInfo.template ! make/data/swingbeaninfo/javax/swing/SwingBeanInfoBase.java ! make/data/swingbeaninfo/sun/swing/BeanInfoUtils.java Changeset: 0f442062f306 Author: prr Date: 2014-07-14 09:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/0f442062f306 8049893: Replace uses of 'new Integer()' with appropriate alternative across client classes Reviewed-by: prr, pchelko Contributed-by: otaviojava at java.net ! src/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/java/awt/image/renderable/ParameterBlock.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/NameGenerator.java ! src/share/classes/javax/imageio/spi/PartiallyOrderedSet.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/swing/PrintingStatus.java Changeset: a9b0cd14e6e1 Author: prr Date: 2014-07-14 10:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/a9b0cd14e6e1 8040808: Uninitialised memory in OGLBufImgsOps.c, D3DBufImgOps.cpp Reviewed-by: serb, pchelko ! src/share/native/sun/java2d/opengl/OGLBufImgOps.c ! src/windows/native/sun/java2d/d3d/D3DBufImgOps.cpp Changeset: b03d9329401f Author: prr Date: 2014-07-14 11:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/b03d9329401f 8048583: CustomMediaSizeName class matching to standard media is too loose Reviewed-by: bae, jgodinez ! src/share/classes/sun/print/CustomMediaSizeName.java Changeset: 65a593687a88 Author: ddehaven Date: 2014-07-15 14:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/65a593687a88 8048337: Examine if macosx/bundle/JavaAppLauncher and JavaAppLauncher.java can be removed Reviewed-by: mchung ! make/lib/PlatformLibraries.gmk - src/macosx/bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj/project.pbxproj - src/macosx/bundle/JavaAppLauncher/resources/English.lproj/InfoPlist.strings - src/macosx/bundle/JavaAppLauncher/resources/JavaAppLauncher-Info.plist - src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h - src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch - src/macosx/bundle/JavaAppLauncher/src/main.m - src/macosx/classes/apple/launcher/JavaAppLauncher.java - src/macosx/classes/apple/launcher/appLauncherErrors.properties - src/macosx/native/apple/launcher/JavaAppLauncher.m Changeset: 8d2c47012056 Author: pchelko Date: 2014-07-16 15:35 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/8d2c47012056 8050465: Remove sun.audio package Reviewed-by: anthony, serb - src/share/classes/sun/audio/AudioData.java - src/share/classes/sun/audio/AudioDataStream.java - src/share/classes/sun/audio/AudioDevice.java - src/share/classes/sun/audio/AudioPlayer.java - src/share/classes/sun/audio/AudioSecurityAction.java - src/share/classes/sun/audio/AudioSecurityExceptionAction.java - src/share/classes/sun/audio/AudioStream.java - src/share/classes/sun/audio/AudioStreamSequence.java - src/share/classes/sun/audio/AudioTranslatorStream.java - src/share/classes/sun/audio/ContinuousAudioDataStream.java - src/share/classes/sun/audio/InvalidAudioFormatException.java - src/share/classes/sun/audio/NativeAudioStream.java Changeset: 8e8502b4b2be Author: pchelko Date: 2014-07-16 16:02 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/8e8502b4b2be 8047336: Read flavormap.properties as resource Reviewed-by: anthony, serb, alanb, mduigou ! make/CopyFiles.gmk ! make/CopyIntoClasses.gmk ! make/profile-includes.txt + src/macosx/classes/sun/awt/datatransfer/flavormap.properties - src/macosx/lib/flavormap.properties ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java + src/solaris/classes/sun/awt/datatransfer/flavormap.properties - src/solaris/lib/flavormap.properties + src/windows/classes/sun/awt/datatransfer/flavormap.properties - src/windows/lib/flavormap.properties Changeset: 82e7251af1d0 Author: prr Date: 2014-07-16 15:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/82e7251af1d0 Merge ! make/CopyFiles.gmk ! make/profile-includes.txt - src/share/classes/com/sun/jmx/remote/util/CacheMap.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/javax/swing/filechooser/FileSystemView.java - src/share/lib/security/BlacklistedCertsConverter.java - src/share/lib/security/blacklisted.certs - src/share/lib/security/blacklisted.certs.pem - test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java - test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java - test/javax/management/remote/mandatory/util/CacheMapTest.java Changeset: c08675c5da7c Author: aeremeev Date: 2014-07-17 15:30 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/c08675c5da7c 8044301: BasicTreeUI: "revisit when Java2D is ready" Reviewed-by: alexsch, pchelko ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: dfcf4b835abd Author: azvegint Date: 2014-07-18 13:53 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/dfcf4b835abd 8048289: Gtk: call to UIManager.getSystemLookAndFeelClassName() leads to crash Reviewed-by: anthony, serb ! src/solaris/native/sun/awt/gtk2_interface.c Changeset: db1d1894985c Author: dermashov Date: 2014-07-21 12:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/db1d1894985c 8049694: Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK Reviewed-by: azvegint, serb + test/java/awt/Toolkit/DesktopProperties/rfe4758438.java + test/java/awt/Toolkit/DesktopProperties/rfe4758438.sh Changeset: 0e36fa13a95a Author: avstepan Date: 2014-07-21 13:17 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/0e36fa13a95a 8049617: move awt automated tests from AWT_Modality to OpenJDK repository - part 3 Reviewed-by: pchelko + test/java/awt/Modal/ModalBlockingTests/BlockingDDAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDModelessTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDNonModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDDToolkitModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFToolkitModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWModeless1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWModeless2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWNonModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWNonModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingDFWTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDModelessTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDNonModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDToolkitModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWDocModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWModeless4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWNonModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingFDWTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal5Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsAppModal6Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal5Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsSetModal6Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsTest.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal1Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal2Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal3Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal4Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal5Test.java + test/java/awt/Modal/ModalBlockingTests/BlockingWindowsToolkitModal6Test.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogAppModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogDocModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogModelessTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogNonModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogSetModalTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogTest.java + test/java/awt/Modal/ModalBlockingTests/UnblockedDialogToolkitModalTest.java ! test/java/awt/Modal/helpers/TestFrame.java Changeset: 69cfcd8883c5 Author: yan Date: 2014-07-21 18:10 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/69cfcd8883c5 8051440: move tests about maximizing undecorated to OpenJDK Reviewed-by: serb + test/java/awt/Frame/MaximizedUndecorated/MaximizedUndecorated.java Changeset: 2ebd4c1c8e51 Author: prr Date: 2014-07-21 09:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/2ebd4c1c8e51 Merge - test/sun/security/krb5/auto/KerberosHashEqualsTest.java Changeset: 8dd92831afe1 Author: pchelko Date: 2014-07-21 21:41 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/8dd92831afe1 8046884: JNI exception pending in jdk/src/solaris/native/sun/java2d/x11: X11PMPLitLoops.c, X11SurfaceData.c Reviewed-by: prr, serb ! src/solaris/native/sun/java2d/x11/X11PMBlitLoops.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c Changeset: bae12267b25d Author: pchelko Date: 2014-07-22 11:38 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/bae12267b25d 8046888: JNI exception pending in jdk/src/share/native/sun/awt/image/awt_parseImage.c Reviewed-by: prr, serb Contributed-by: Anton Melnikov ! src/share/native/sun/awt/image/awt_parseImage.c Changeset: 9ec690ccb761 Author: alexsch Date: 2014-07-22 13:14 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/9ec690ccb761 8048720: KSS sun.swing.SwingUtilities2#makeIcon Reviewed-by: serb, pchelko ! src/share/classes/javax/swing/LookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 83d8816541de Author: alexsch Date: 2014-07-22 13:23 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/83d8816541de 8030051: Check class loaders usage in Swing classes Reviewed-by: serb, pchelko ! src/share/classes/javax/swing/JEditorPane.java Changeset: d47f44d38bab Author: ddehaven Date: 2014-07-29 09:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/d47f44d38bab Merge - src/macosx/bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj/project.pbxproj - src/macosx/bundle/JavaAppLauncher/resources/English.lproj/InfoPlist.strings - src/macosx/bundle/JavaAppLauncher/resources/JavaAppLauncher-Info.plist - src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h - src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch - src/macosx/bundle/JavaAppLauncher/src/main.m - src/macosx/classes/apple/launcher/JavaAppLauncher.java - src/macosx/classes/apple/launcher/appLauncherErrors.properties - src/macosx/lib/flavormap.properties - src/macosx/native/apple/launcher/JavaAppLauncher.m - src/share/classes/sun/audio/AudioData.java - src/share/classes/sun/audio/AudioDataStream.java - src/share/classes/sun/audio/AudioDevice.java - src/share/classes/sun/audio/AudioPlayer.java - src/share/classes/sun/audio/AudioSecurityAction.java - src/share/classes/sun/audio/AudioSecurityExceptionAction.java - src/share/classes/sun/audio/AudioStream.java - src/share/classes/sun/audio/AudioStreamSequence.java - src/share/classes/sun/audio/AudioTranslatorStream.java - src/share/classes/sun/audio/ContinuousAudioDataStream.java - src/share/classes/sun/audio/InvalidAudioFormatException.java - src/share/classes/sun/audio/NativeAudioStream.java - src/solaris/lib/flavormap.properties - src/windows/lib/flavormap.properties Changeset: 4c49cf76945d Author: weijun Date: 2014-07-30 15:28 +0800 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/4c49cf76945d 8052999: ProblemList update for Unreachable.java Reviewed-by: xuelei ! test/ProblemList.txt Changeset: c1a40b729713 Author: chegar Date: 2014-07-30 17:42 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/c1a40b729713 8053938: Collections.checkedList(empty list).replaceAll((UnaryOperator)null) doesn't throw NPE after JDK-8047795 Reviewed-by: rriggs, mduigou ! src/share/classes/java/util/Collections.java ! test/java/util/Collections/CheckedListReplaceAll.java Changeset: a30506ca3c77 Author: aefimov Date: 2014-07-31 11:31 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/a30506ca3c77 8032908: getTextContent doesn't return string in JAXP Reviewed-by: joehw + test/javax/xml/jaxp/common/8032908/TestFunc.java + test/javax/xml/jaxp/common/8032908/XSLT.java + test/javax/xml/jaxp/common/8032908/in.xml + test/javax/xml/jaxp/common/8032908/test.xsl Changeset: 6b2404e27d07 Author: darcy Date: 2014-07-31 11:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/6b2404e27d07 8054050: Fix stay raw and unchecked lint warnings in core libs Reviewed-by: lancea, alanb ! src/share/classes/com/sun/management/GcInfo.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java ! src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java ! src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/jdk/nio/zipfs/ZipFileAttributeView.java ! src/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java Changeset: 532748fdbab8 Author: ntoda Date: 2014-07-31 17:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/532748fdbab8 8044867: Fix raw and unchecked lint warnings in sun.tools.* Reviewed-by: darcy ! src/share/classes/sun/tools/asm/Assembler.java ! src/share/classes/sun/tools/asm/ConstantPool.java ! src/share/classes/sun/tools/asm/SwitchData.java ! src/share/classes/sun/tools/java/BinaryClass.java ! src/share/classes/sun/tools/java/BinaryConstantPool.java ! src/share/classes/sun/tools/java/BinaryMember.java ! src/share/classes/sun/tools/java/ClassDefinition.java ! src/share/classes/sun/tools/java/ClassPath.java ! src/share/classes/sun/tools/java/Identifier.java ! src/share/classes/sun/tools/java/Imports.java ! src/share/classes/sun/tools/java/MemberDefinition.java ! src/share/classes/sun/tools/java/MethodSet.java ! src/share/classes/sun/tools/java/Package.java ! src/share/classes/sun/tools/java/Parser.java ! src/share/classes/sun/tools/java/Type.java ! src/share/classes/sun/tools/javac/BatchEnvironment.java ! src/share/classes/sun/tools/javac/BatchParser.java ! src/share/classes/sun/tools/javac/CompilerMember.java ! src/share/classes/sun/tools/javac/Main.java ! src/share/classes/sun/tools/javac/SourceClass.java ! src/share/classes/sun/tools/javac/SourceMember.java ! src/share/classes/sun/tools/tree/AndExpression.java ! src/share/classes/sun/tools/tree/ArrayAccessExpression.java ! src/share/classes/sun/tools/tree/ArrayExpression.java ! src/share/classes/sun/tools/tree/AssignExpression.java ! src/share/classes/sun/tools/tree/AssignOpExpression.java ! src/share/classes/sun/tools/tree/BinaryAssignExpression.java ! src/share/classes/sun/tools/tree/BinaryExpression.java ! src/share/classes/sun/tools/tree/BinaryLogicalExpression.java ! src/share/classes/sun/tools/tree/BooleanExpression.java ! src/share/classes/sun/tools/tree/BreakStatement.java ! src/share/classes/sun/tools/tree/CaseStatement.java ! src/share/classes/sun/tools/tree/CastExpression.java ! src/share/classes/sun/tools/tree/CatchStatement.java ! src/share/classes/sun/tools/tree/CommaExpression.java ! src/share/classes/sun/tools/tree/CompoundStatement.java ! src/share/classes/sun/tools/tree/ConditionalExpression.java ! src/share/classes/sun/tools/tree/ContinueStatement.java ! src/share/classes/sun/tools/tree/ConvertExpression.java ! src/share/classes/sun/tools/tree/DeclarationStatement.java ! src/share/classes/sun/tools/tree/DoStatement.java ! src/share/classes/sun/tools/tree/ExprExpression.java ! src/share/classes/sun/tools/tree/Expression.java ! src/share/classes/sun/tools/tree/ExpressionStatement.java ! src/share/classes/sun/tools/tree/FieldExpression.java ! src/share/classes/sun/tools/tree/FinallyStatement.java ! src/share/classes/sun/tools/tree/ForStatement.java ! src/share/classes/sun/tools/tree/IdentifierExpression.java ! src/share/classes/sun/tools/tree/IfStatement.java ! src/share/classes/sun/tools/tree/IncDecExpression.java ! src/share/classes/sun/tools/tree/InstanceOfExpression.java ! src/share/classes/sun/tools/tree/LengthExpression.java ! src/share/classes/sun/tools/tree/LocalMember.java ! src/share/classes/sun/tools/tree/MethodExpression.java ! src/share/classes/sun/tools/tree/NewArrayExpression.java ! src/share/classes/sun/tools/tree/NewInstanceExpression.java ! src/share/classes/sun/tools/tree/NotExpression.java ! src/share/classes/sun/tools/tree/OrExpression.java ! src/share/classes/sun/tools/tree/ReturnStatement.java ! src/share/classes/sun/tools/tree/Statement.java ! src/share/classes/sun/tools/tree/SuperExpression.java ! src/share/classes/sun/tools/tree/SwitchStatement.java ! src/share/classes/sun/tools/tree/SynchronizedStatement.java ! src/share/classes/sun/tools/tree/ThisExpression.java ! src/share/classes/sun/tools/tree/ThrowStatement.java ! src/share/classes/sun/tools/tree/TryStatement.java ! src/share/classes/sun/tools/tree/TypeExpression.java ! src/share/classes/sun/tools/tree/UnaryExpression.java ! src/share/classes/sun/tools/tree/VarDeclarationStatement.java ! src/share/classes/sun/tools/tree/WhileStatement.java ! src/share/classes/sun/tools/util/CommandLine.java Changeset: d766f563d30d Author: darcy Date: 2014-07-31 17:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/d766f563d30d 8039102: Add raw and unchecked lint warnings to build of jdk repository Reviewed-by: tbell ! make/Setup.gmk Changeset: a3e395b98536 Author: xuelei Date: 2014-08-01 12:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/a3e395b98536 8052406: SSLv2Hello protocol may be filter out unexpectedly Reviewed-by: weijun ! src/share/classes/sun/security/ssl/Handshaker.java + test/javax/net/ssl/TLSv12/ProtocolFilter.java Changeset: 19e8f844a3d5 Author: dmeetry Date: 2014-08-01 16:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/19e8f844a3d5 8044671: NPE from JapaneseEra when a new era is defined in calendar.properties Reviewed-by: okutsu ! src/share/classes/java/time/chrono/JapaneseEra.java Changeset: 672f52b927bc Author: prappo Date: 2014-08-01 14:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/672f52b927bc 8051991: Flatten VersionHelper hierarchies Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/VersionHelper.java - src/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/share/classes/com/sun/naming/internal/VersionHelper.java - src/share/classes/com/sun/naming/internal/VersionHelper12.java Changeset: 1223853596be Author: robm Date: 2014-08-01 15:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/1223853596be 8030166: java/lang/ProcessBuilder/Basic.java fails intermittently: waitFor took too long Reviewed-by: rriggs ! test/java/lang/ProcessBuilder/Basic.java Changeset: 7e49227e25ae Author: robm Date: 2014-08-01 15:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/7e49227e25ae 8031435: Ftp download does not work properly for ftp user without password Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! test/sun/net/ftp/FtpURL.java Changeset: 79b2e88250a9 Author: alanb Date: 2014-08-01 15:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/79b2e88250a9 8053931: (fc) FileDispatcherImpl.lock0 does not handle ERROR_IO_PENDING [win] Reviewed-by: alanb Contributed-by: martin.doerr at sap.com ! src/windows/native/sun/nio/ch/FileDispatcherImpl.c Changeset: 3eca5cf84a1c Author: robm Date: 2014-08-01 19:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/3eca5cf84a1c 8042982: Unexpected RuntimeExceptions being thrown by SSLEngine Reviewed-by: wetmore, xuelei ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java Changeset: 50dedaa523d6 Author: prappo Date: 2014-08-01 22:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/50dedaa523d6 8054158: Fix typos in JNDI-related packages Reviewed-by: rriggs, vinnie ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java ! src/share/classes/com/sun/jndi/dns/DnsClient.java ! src/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java ! src/share/classes/com/sun/jndi/ldap/ClientId.java ! src/share/classes/com/sun/jndi/ldap/EventQueue.java ! src/share/classes/com/sun/jndi/ldap/EventSupport.java ! src/share/classes/com/sun/jndi/ldap/LdapAttribute.java ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/jndi/ldap/LdapName.java ! src/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/share/classes/com/sun/jndi/ldap/LdapRequest.java ! src/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java ! src/share/classes/com/sun/jndi/ldap/LdapURL.java ! src/share/classes/com/sun/jndi/ldap/ServiceLocator.java ! src/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/ComponentContext.java ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java ! src/share/classes/com/sun/jndi/url/ldap/ldapURLContext.java ! src/share/classes/javax/naming/directory/DirContext.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/naming/ldap/SortControl.java Changeset: 868bc40c93b2 Author: weijun Date: 2014-08-03 20:09 +0800 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/868bc40c93b2 8054095: No space allowed in platforms string in ProblemList.txt Reviewed-by: weijun Contributed-by: Amy Lu ! test/ProblemList.txt Changeset: b98874789ea7 Author: lana Date: 2014-08-04 15:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/b98874789ea7 Merge - src/macosx/bundle/JavaAppLauncher/JavaAppLauncher.xcodeproj/project.pbxproj - src/macosx/bundle/JavaAppLauncher/resources/English.lproj/InfoPlist.strings - src/macosx/bundle/JavaAppLauncher/resources/JavaAppLauncher-Info.plist - src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h - src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m - src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch - src/macosx/bundle/JavaAppLauncher/src/main.m - src/macosx/classes/apple/launcher/JavaAppLauncher.java - src/macosx/classes/apple/launcher/appLauncherErrors.properties - src/macosx/lib/flavormap.properties - src/macosx/native/apple/launcher/JavaAppLauncher.m - src/share/classes/com/sun/jndi/ldap/VersionHelper12.java - src/share/classes/com/sun/naming/internal/VersionHelper12.java - src/share/classes/sun/audio/AudioData.java - src/share/classes/sun/audio/AudioDataStream.java - src/share/classes/sun/audio/AudioDevice.java - src/share/classes/sun/audio/AudioPlayer.java - src/share/classes/sun/audio/AudioSecurityAction.java - src/share/classes/sun/audio/AudioSecurityExceptionAction.java - src/share/classes/sun/audio/AudioStream.java - src/share/classes/sun/audio/AudioStreamSequence.java - src/share/classes/sun/audio/AudioTranslatorStream.java - src/share/classes/sun/audio/ContinuousAudioDataStream.java - src/share/classes/sun/audio/InvalidAudioFormatException.java - src/share/classes/sun/audio/NativeAudioStream.java - src/solaris/lib/flavormap.properties - src/windows/lib/flavormap.properties Changeset: 590fda9d9571 Author: vinnie Date: 2014-08-05 13:59 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/590fda9d9571 8051972: sun/security/pkcs11/ec/ReadCertificates.java fails intermittently Reviewed-by: mullan ! test/sun/security/pkcs11/ec/ReadCertificates.java Changeset: 4c52a35e22eb Author: vinnie Date: 2014-08-05 14:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/4c52a35e22eb 8036612: [parfait] JNI exception pending in jdk/src/windows/native/sun/security/mscapi/security.cpp Reviewed-by: valeriep ! src/windows/native/sun/security/mscapi/security.cpp Changeset: cd3e56314554 Author: mullan Date: 2014-08-05 10:00 -0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/cd3e56314554 7147060: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode Reviewed-by: xuelei ! test/ProblemList.txt ! test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java Changeset: fa98ebc2c8f5 Author: mullan Date: 2014-08-05 10:01 -0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/fa98ebc2c8f5 Merge Changeset: 1bebe5cd2502 Author: igerasim Date: 2014-08-06 02:11 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/1bebe5cd2502 8051382: Optimize java.lang.reflect.Modifier.toString() Reviewed-by: martin ! src/share/classes/java/lang/reflect/Modifier.java ! test/java/lang/reflect/Modifier/toStringTest.java Changeset: dde9f5cfde5f Author: ksrini Date: 2014-08-05 19:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/dde9f5cfde5f 8042469: Launcher changes for native memory tracking scalability enhancement Reviewed-by: darcy, ksrini, zgu Contributed-by: neil.toda at oracle.com ! src/share/bin/java.c ! src/share/bin/jli_util.h ! test/tools/launcher/TestSpecialArgs.java Changeset: 545dcbf27cb5 Author: chegar Date: 2014-08-10 19:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/545dcbf27cb5 Merge ! make/copy/Copy-java.desktop.gmk ! make/lib/PlatformLibraries.gmk ! src/java.base/share/classes/java/lang/reflect/Modifier.java ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java ! src/java.base/share/classes/java/util/Collections.java ! src/java.base/share/classes/java/util/DoubleSummaryStatistics.java ! src/java.base/share/classes/java/util/stream/DoubleStream.java ! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! src/java.base/share/classes/sun/security/provider/SecureRandom.java ! src/java.base/share/classes/sun/security/ssl/DHCrypt.java ! src/java.base/share/classes/sun/security/ssl/ECDHCrypt.java ! src/java.base/share/classes/sun/security/ssl/Handshaker.java ! src/java.base/share/native/libjli/java.c ! src/java.base/share/native/libjli/jli_util.h ! src/java.base/unix/classes/sun/nio/ch/InheritedChannel.java ! src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c ! src/java.corba/share/classes/com/sun/jndi/cosnaming/CNCtx.java ! src/java.corba/share/classes/com/sun/jndi/toolkit/corba/CorbaUtils.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppDockIconHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaBorder.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxPopup.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFocusHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaListUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java ! src/java.desktop/macosx/classes/com/apple/laf/ClientPropertyApplicator.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuBar.java + src/java.desktop/macosx/classes/sun/awt/datatransfer/flavormap.properties ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethod.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java - src/java.desktop/macosx/conf/flavormap.properties ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/wbmp/WBMPMetadata.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/share/classes/java/awt/Color.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/Graphics.java ! src/java.desktop/share/classes/java/awt/MenuComponent.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/Rectangle.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/color/ColorSpace.java ! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java ! src/java.desktop/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/java.desktop/share/classes/java/awt/font/TextAttribute.java ! src/java.desktop/share/classes/java/awt/geom/Arc2D.java ! src/java.desktop/share/classes/java/awt/image/AffineTransformOp.java ! src/java.desktop/share/classes/java/awt/image/BufferedImageFilter.java ! src/java.desktop/share/classes/java/awt/image/ImageFilter.java ! src/java.desktop/share/classes/java/awt/image/WritableRaster.java ! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java ! src/java.desktop/share/classes/java/awt/print/PrinterJob.java ! src/java.desktop/share/classes/java/beans/EventHandler.java ! src/java.desktop/share/classes/java/beans/MetaData.java ! src/java.desktop/share/classes/java/beans/NameGenerator.java ! src/java.desktop/share/classes/javax/imageio/package.html ! src/java.desktop/share/classes/javax/imageio/spi/PartiallyOrderedSet.java ! src/java.desktop/share/classes/javax/print/Doc.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/PrintService.java ! src/java.desktop/share/classes/javax/print/PrintServiceLookup.java ! src/java.desktop/share/classes/javax/print/ServiceUI.java ! src/java.desktop/share/classes/javax/print/ServiceUIFactory.java ! src/java.desktop/share/classes/javax/print/SimpleDoc.java ! src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java ! src/java.desktop/share/classes/javax/print/attribute/Attribute.java ! src/java.desktop/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/DocAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/DocAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/EnumSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/HashAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashDocAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintJobAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintRequestAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintServiceAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/IntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/PrintJobAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/PrintRequestAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/PrintServiceAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/SetOfIntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/Size2DSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/SupportedValuesAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/TextSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/URISyntax.java ! src/java.desktop/share/classes/javax/print/attribute/package.html ! src/java.desktop/share/classes/javax/print/attribute/standard/ColorSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java ! src/java.desktop/share/classes/javax/print/attribute/standard/CopiesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCreation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtProcessing.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Destination.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DialogTypeSelection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DocumentName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobHoldUntil.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressions.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsProcessed.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobOriginatingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPriority.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPrioritySupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Media.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSize.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfDocuments.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfInterveningJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUpSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OrientationRequested.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OutputDeviceAssigned.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PDLOverrideSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinute.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinuteColor.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrintQuality.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterLocation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMakeAndModel.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterURI.java ! src/java.desktop/share/classes/javax/print/attribute/standard/QueuedJobCount.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/RequestingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Severity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/SheetCollate.java ! src/java.desktop/share/classes/javax/print/attribute/standard/package.html ! src/java.desktop/share/classes/javax/print/event/package.html ! src/java.desktop/share/classes/javax/print/package.html ! src/java.desktop/share/classes/javax/sound/midi/MidiSystem.java ! src/java.desktop/share/classes/javax/swing/AbstractAction.java ! src/java.desktop/share/classes/javax/swing/CellRendererPane.java ! src/java.desktop/share/classes/javax/swing/DebugGraphics.java ! src/java.desktop/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/java.desktop/share/classes/javax/swing/DefaultDesktopManager.java ! src/java.desktop/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/java.desktop/share/classes/javax/swing/DesktopManager.java ! src/java.desktop/share/classes/javax/swing/GrayFilter.java ! src/java.desktop/share/classes/javax/swing/Icon.java ! src/java.desktop/share/classes/javax/swing/JApplet.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JDesktopPane.java ! src/java.desktop/share/classes/javax/swing/JDialog.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JInternalFrame.java ! src/java.desktop/share/classes/javax/swing/JLabel.java ! src/java.desktop/share/classes/javax/swing/JLayeredPane.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/JScrollPane.java ! src/java.desktop/share/classes/javax/swing/JSpinner.java ! src/java.desktop/share/classes/javax/swing/JTextField.java ! src/java.desktop/share/classes/javax/swing/JWindow.java ! src/java.desktop/share/classes/javax/swing/LookAndFeel.java ! src/java.desktop/share/classes/javax/swing/ProgressMonitor.java ! src/java.desktop/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/java.desktop/share/classes/javax/swing/SpinnerModel.java ! src/java.desktop/share/classes/javax/swing/Timer.java ! src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicArrowButton.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicCheckBoxMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicCheckBoxUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxRenderer.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicHTML.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPanelUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRootPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToggleButtonUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicViewportUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/ComboPopup.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/StateImpl.template ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/java.desktop/share/classes/sun/applet/AppletClassLoader.java ! src/java.desktop/share/classes/sun/applet/AppletImageRef.java ! src/java.desktop/share/classes/sun/applet/AppletObjectInputStream.java ! src/java.desktop/share/classes/sun/applet/AppletPanel.java ! src/java.desktop/share/classes/sun/applet/AppletProps.java ! src/java.desktop/share/classes/sun/applet/AppletSecurity.java ! src/java.desktop/share/classes/sun/applet/AppletViewer.java ! src/java.desktop/share/classes/sun/applet/AppletViewerFactory.java ! src/java.desktop/share/classes/sun/applet/AppletViewerPanel.java ! src/java.desktop/share/classes/sun/applet/Main.java - src/java.desktop/share/classes/sun/audio/AudioData.java - src/java.desktop/share/classes/sun/audio/AudioDataStream.java - src/java.desktop/share/classes/sun/audio/AudioDevice.java - src/java.desktop/share/classes/sun/audio/AudioPlayer.java - src/java.desktop/share/classes/sun/audio/AudioSecurityAction.java - src/java.desktop/share/classes/sun/audio/AudioSecurityExceptionAction.java - src/java.desktop/share/classes/sun/audio/AudioStream.java - src/java.desktop/share/classes/sun/audio/AudioStreamSequence.java - src/java.desktop/share/classes/sun/audio/AudioTranslatorStream.java - src/java.desktop/share/classes/sun/audio/ContinuousAudioDataStream.java - src/java.desktop/share/classes/sun/audio/InvalidAudioFormatException.java - src/java.desktop/share/classes/sun/audio/NativeAudioStream.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/java.desktop/share/classes/sun/print/CustomMediaSizeName.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/swing/PrintingStatus.java ! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java ! src/java.desktop/share/native/common/sun/java2d/opengl/OGLBufImgOps.c ! src/java.desktop/share/native/libawt/sun/awt/image/awt_parseImage.c + src/java.desktop/unix/classes/sun/awt/datatransfer/flavormap.properties ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java - src/java.desktop/unix/conf/flavormap.properties ! src/java.desktop/unix/native/common/sun/awt/CUPSfuncs.c ! src/java.desktop/unix/native/common/sun/java2d/x11/X11PMBlitLoops.c ! src/java.desktop/unix/native/common/sun/java2d/x11/X11SurfaceData.c ! src/java.desktop/unix/native/libawt_xawt/sun/awt/gtk2_interface.c + src/java.desktop/windows/classes/sun/awt/datatransfer/flavormap.properties - src/java.desktop/windows/conf/flavormap.properties ! src/java.desktop/windows/native/libawt/sun/java2d/d3d/D3DBufImgOps.cpp ! src/java.desktop/windows/native/libawt/sun/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/sun/windows/awt_List.cpp ! src/java.management/share/classes/com/sun/management/GcInfo.java ! src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java ! src/java.naming/share/classes/com/sun/jndi/ldap/ClientId.java ! src/java.naming/share/classes/com/sun/jndi/ldap/EventQueue.java ! src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapAttribute.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapName.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralContext.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaParser.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapSearchEnumeration.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapURL.java ! src/java.naming/share/classes/com/sun/jndi/ldap/ServiceLocator.java ! src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java - src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper12.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Connections.java ! src/java.naming/share/classes/com/sun/jndi/ldap/pool/Pool.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/AtomicContext.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/ComponentContext.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/dir/ContextEnumerator.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/dir/HierMemDirCtx.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/dir/SearchFilter.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/url/GenericURLContext.java ! src/java.naming/share/classes/com/sun/jndi/url/ldap/ldapURLContext.java ! src/java.naming/share/classes/com/sun/naming/internal/ResourceManager.java ! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java - src/java.naming/share/classes/com/sun/naming/internal/VersionHelper12.java ! src/java.naming/share/classes/javax/naming/Context.java ! src/java.naming/share/classes/javax/naming/InitialContext.java ! src/java.naming/share/classes/javax/naming/directory/DirContext.java ! src/java.naming/share/classes/javax/naming/ldap/LdapContext.java ! src/java.naming/share/classes/javax/naming/ldap/Rdn.java ! src/java.naming/share/classes/javax/naming/ldap/SortControl.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp - src/jdk.deploy.osx/macosx/classes/apple/launcher/JavaAppLauncher.java - src/jdk.deploy.osx/macosx/classes/apple/launcher/appLauncherErrors.properties ! src/jdk.deploy.osx/macosx/classes/apple/security/KeychainStore.java - src/jdk.deploy.osx/macosx/native/libosx/JavaAppLauncher.m ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/model/JavaClass.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/model/Snapshot.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java ! src/jdk.dev/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java ! src/jdk.rmic/share/classes/sun/tools/asm/Assembler.java ! src/jdk.rmic/share/classes/sun/tools/asm/ConstantPool.java ! src/jdk.rmic/share/classes/sun/tools/asm/SwitchData.java ! src/jdk.rmic/share/classes/sun/tools/java/BinaryClass.java ! src/jdk.rmic/share/classes/sun/tools/java/BinaryConstantPool.java ! src/jdk.rmic/share/classes/sun/tools/java/BinaryMember.java ! src/jdk.rmic/share/classes/sun/tools/java/ClassDefinition.java ! src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java ! src/jdk.rmic/share/classes/sun/tools/java/Identifier.java ! src/jdk.rmic/share/classes/sun/tools/java/Imports.java ! src/jdk.rmic/share/classes/sun/tools/java/MemberDefinition.java ! src/jdk.rmic/share/classes/sun/tools/java/MethodSet.java ! src/jdk.rmic/share/classes/sun/tools/java/Package.java ! src/jdk.rmic/share/classes/sun/tools/java/Parser.java ! src/jdk.rmic/share/classes/sun/tools/java/Type.java ! src/jdk.rmic/share/classes/sun/tools/javac/BatchEnvironment.java ! src/jdk.rmic/share/classes/sun/tools/javac/BatchParser.java ! src/jdk.rmic/share/classes/sun/tools/javac/CompilerMember.java ! src/jdk.rmic/share/classes/sun/tools/javac/Main.java ! src/jdk.rmic/share/classes/sun/tools/javac/SourceClass.java ! src/jdk.rmic/share/classes/sun/tools/javac/SourceMember.java ! src/jdk.rmic/share/classes/sun/tools/tree/AndExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/ArrayAccessExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/ArrayExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/AssignExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/AssignOpExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/BinaryAssignExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/BinaryExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/BinaryLogicalExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/BooleanExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/BreakStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/CaseStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/CastExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/CatchStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/CommaExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/CompoundStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/ConditionalExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/ContinueStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/ConvertExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/DeclarationStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/DoStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/ExprExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/Expression.java ! src/jdk.rmic/share/classes/sun/tools/tree/ExpressionStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/FieldExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/FinallyStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/ForStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/IdentifierExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/IfStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/IncDecExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/InstanceOfExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/LengthExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/LocalMember.java ! src/jdk.rmic/share/classes/sun/tools/tree/MethodExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/NewArrayExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/NewInstanceExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/NotExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/OrExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/ReturnStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/Statement.java ! src/jdk.rmic/share/classes/sun/tools/tree/SuperExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/SwitchStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/SynchronizedStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/ThisExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/ThrowStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/TryStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/TypeExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/UnaryExpression.java ! src/jdk.rmic/share/classes/sun/tools/tree/VarDeclarationStatement.java ! src/jdk.rmic/share/classes/sun/tools/tree/WhileStatement.java ! src/jdk.rmic/share/classes/sun/tools/util/CommandLine.java ! src/jdk.runtime/share/native/libjsdt/JVM.c ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileAttributeView.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java From chris.hegarty at oracle.com Sun Aug 10 20:18:39 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:18:39 +0000 Subject: hg: jigsaw/stage/hotspot: 36 new changesets Message-ID: <201408102018.s7AKIeDn005168@aojmv0008> Changeset: cf51cd09a99a Author: simonis Date: 2014-07-18 19:56 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/cf51cd09a99a 8051378: AIX: Change "8030763: Validate global memory allocation" breaks the HotSpot build Reviewed-by: kvn ! src/os/aix/vm/os_aix.cpp Changeset: 4068d04de2d5 Author: sspitsyn Date: 2014-07-15 21:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/4068d04de2d5 8049441: PPC64: Don't use StubCodeMarks for zero-length stubs Summary: Remove StubCodeMark in generate_icache_flush, generate_verify_oop, generate_throw_exception Reviewed-by: dcubed, sspitsyn Contributed-by: volker.simonis at gmail.com ! src/cpu/ppc/vm/icache_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp Changeset: 5838922362ed Author: mikael Date: 2014-07-16 15:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/5838922362ed 8050802: Update jprt runthese test suite to jck-8 Reviewed-by: dholmes, kvn ! make/jprt.properties Changeset: ecdcd96f051a Author: coleenp Date: 2014-07-17 15:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/ecdcd96f051a 8004128: NPG: remove stackwalking in Threads::gc_prologue and gc_epilogue code Summary: remove bcx and mdx handling. We no longer have to convert bytecode pointers to indices for GC since Methods aren't moved. Reviewed-by: mgerdin, kvn ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/libjvm_db.c ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 22b98ab2a69f Author: goetz Date: 2014-07-04 11:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/22b98ab2a69f 8049325: Introduce and clean up umbrella headers for the files in the cpu subdirectories. Summary: Introduce and clean up umbrella headers for the files in the cpu subdirectories. Reviewed-by: lfoltan, coleenp, dholmes ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/interpreterRT_ppc.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/register_ppc.hpp ! src/cpu/ppc/vm/runtime_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp ! src/cpu/ppc/vm/vmreg_ppc.hpp ! src/cpu/ppc/vm/vmreg_ppc.inline.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/interpreterRT_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/register_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vmreg_sparc.hpp ! src/cpu/sparc/vm/vmreg_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vmreg_x86.hpp ! src/cpu/x86/vm/vmreg_x86.inline.hpp ! src/cpu/x86/vm/x86.ad ! src/os/aix/vm/os_aix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp ! src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp ! src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp ! src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp ! src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/bytecodeAssembler.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/compiledIC.hpp + src/share/vm/code/nativeInst.hpp ! src/share/vm/code/vmreg.hpp + src/share/vm/code/vmreg.inline.hpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp + src/share/vm/interpreter/interp_masm.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/oop.inline.hpp + src/share/vm/opto/ad.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/diagnosticFramework.hpp + src/share/vm/utilities/bytes.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 739468857ffb Author: coleenp Date: 2014-07-14 10:15 -0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/739468857ffb Merge ! src/os/aix/vm/os_aix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/compiledIC.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp - src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp - src/share/vm/gc_implementation/parNew/asParNewGeneration.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: 564cca0427b0 Author: coleenp Date: 2014-07-18 11:22 -0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/564cca0427b0 Merge ! src/cpu/ppc/vm/frame_ppc.cpp ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 303c17882b24 Author: zgu Date: 2014-07-18 11:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/303c17882b24 8050165: linux-sparcv9: NMT detail causes assert((intptr_t*)younger_sp[FP->sp_offset_in_saved_window()] == (intptr_t*)((intptr_t)sp - STACK_BIAS)) failed: younger_sp must be valid Summary: Fixed native memory tracking stack walking Reviewed-by: coleenp, mikael ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp Changeset: b1eb6f5a41ec Author: sspitsyn Date: 2014-07-18 23:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/b1eb6f5a41ec Merge ! src/os/aix/vm/os_aix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/utilities/vmError.cpp Changeset: ea86cb581cfa Author: kevinw Date: 2014-07-21 10:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/ea86cb581cfa 8049684: pstack crashes on java core dump Reviewed-by: sundar, sspitsyn ! src/os/bsd/dtrace/libjvm_db.c ! src/os/solaris/dtrace/libjvm_db.c Changeset: e15a9bea6294 Author: kevinw Date: 2014-07-21 10:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/e15a9bea6294 Merge - test/compiler/uncommontrap/TestSpecTrapClassUnloading.java Changeset: 53bff7520964 Author: zgu Date: 2014-07-21 06:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/53bff7520964 8050167: linux-sparcv9: hs_err file does not show any stack information Summary: Fixed creation of starting stack frame for stack walking in error handler Reviewed-by: coleenp, mikael ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp Changeset: ec757fe48123 Author: zgu Date: 2014-07-21 09:48 -0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/ec757fe48123 Merge ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp - test/compiler/uncommontrap/TestSpecTrapClassUnloading.java Changeset: 3503744d5b23 Author: poonam Date: 2014-07-22 06:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/3503744d5b23 8049881: jstack not working on core files Summary: Access _trace_id field of Klass in try-catch block Reviewed-by: dholmes, dsamersoff, mgronlun ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java Changeset: 86736b0bc568 Author: simonis Date: 2014-07-17 11:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/86736b0bc568 8050228: Rename 'rem_size' in compactibleFreeListSpace.cpp because of name clashes on AIX Reviewed-by: dholmes, jmasa ! src/os/aix/vm/os_aix.inline.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: ab6489f6a9a5 Author: jmasa Date: 2014-07-18 15:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/ab6489f6a9a5 Merge Changeset: 2749b7a7e9d8 Author: tschatzl Date: 2014-07-21 09:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/2749b7a7e9d8 8049051: Use of during_initial_mark_pause() in G1CollectorPolicy::record_collection_pause_end() prevents use of seperate object copy time prediction during marking Summary: Replaced use of during_initial_mark_pause() with the variable last_pause_included_initial_mark that holds the real old value of _during_initial_mark_pause. Reviewed-by: brutisso, ehelin ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: 3f1eced0e393 Author: tschatzl Date: 2014-07-21 09:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/3f1eced0e393 8048085: Aborting marking just before remark results in useless additional clearing of the next mark bitmap Summary: Skip clearing the next bitmap if we just recently aborted since the full GC already clears this bitmap. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 3334afa474d7 Author: tschatzl Date: 2014-07-21 09:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/3334afa474d7 8048088: Conservative maximum heap alignment should take vm_allocation_granularity into account Summary: Also consider os::vm_allocation_granularity in the calculation. Reviewed-by: brutisso ! src/share/vm/runtime/arguments.cpp Changeset: 5689ad43b108 Author: tschatzl Date: 2014-07-21 10:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/5689ad43b108 8048112: G1 Full GC needs to support the case when the very first region is not available Summary: Refactor preparation for compaction during Full GC so that it lazily initializes the first compaction point. This also avoids problems later when the first region may not be committed. Also reviewed by K. Barrett. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/space.hpp Changeset: c0e87c6d7975 Author: jmasa Date: 2014-07-23 14:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/c0e87c6d7975 Merge ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 9312e056f155 Author: ppunegov Date: 2014-07-19 00:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/9312e056f155 8048882: Some regression tests are not robust with VM output Reviewed-by: kvn, iignatyev ! test/compiler/5091921/Test6890943.java - test/compiler/5091921/Test6890943.sh Changeset: 1eb404df2268 Author: fzhinkin Date: 2014-07-19 00:30 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/1eb404df2268 8050144: Remove '-client' from compiler/8004051/Test8004051.java's options Reviewed-by: kvn ! test/compiler/8004051/Test8004051.java Changeset: 0705d38e2d50 Author: fzhinkin Date: 2014-07-19 00:32 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/0705d38e2d50 6848902: [TESTBUG] The compiler/6589834/Test_ia32.java timed out Reviewed-by: kvn, iignatyev ! test/TEST.groups + test/compiler/6589834/InlinedArrayCloneTestCase.java ! test/compiler/6589834/Test_ia32.java Changeset: 111e4592e388 Author: aaivanov Date: 2014-07-19 00:33 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/111e4592e388 8049348: compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage Reviewed-by: kvn ! test/compiler/intrinsics/bmi/verifycode/BmiIntrinsicBase.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/LZcntTestL.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestI.java ! test/compiler/intrinsics/bmi/verifycode/TZcntTestL.java Changeset: 7f6b21a3beb0 Author: iignatyev Date: 2014-07-19 00:34 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/7f6b21a3beb0 8032449: Get rid of JMX in test/compiler Reviewed-by: kvn ! test/TEST.groups ! test/compiler/tiered/NonTieredLevelsTest.java ! test/compiler/tiered/TieredLevelsTest.java ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/GetNMethodTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/runtime/whitebox/WBStackSize.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java ! test/testlibrary_tests/whitebox/vm_flags/VmFlagTest.java Changeset: f270bf5bcfd8 Author: iignatyev Date: 2014-07-19 00:34 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/f270bf5bcfd8 8031978: compiler/ciReplay/TestVM_no_comp_level.sh fails with "TEST [CHECK :: REPLAY DATA GENERATION] FAILED: Reviewed-by: kvn ! test/compiler/ciReplay/TestSA.sh ! test/compiler/ciReplay/TestVM.sh ! test/compiler/ciReplay/TestVM_no_comp_level.sh ! test/compiler/ciReplay/common.sh Changeset: 1bae42f4e2e6 Author: iignatyev Date: 2014-07-19 13:43 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/1bae42f4e2e6 Merge ! test/TEST.groups Changeset: 0dd7b1ca3bca Author: anoll Date: 2014-07-21 10:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/0dd7b1ca3bca 8051303: 'optimized' build broken by JDK-8039425 Summary: Changed preprocessor directive in PhaseIterGVN::optimize() Reviewed-by: kvn, anoll Contributed-by: Zoltan Majo ! src/share/vm/opto/phaseX.cpp Changeset: 82cd02bbfc3a Author: mdoerr Date: 2014-07-17 10:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/82cd02bbfc3a 8050972: Concurrency problem in PcDesc cache Summary: The entries of the PcDesc cache in nmethods are not declared as volatile, but they are accessed and modified by several threads concurrently. Reviewed-by: kvn, dholmes, dcubed ! src/share/vm/code/nmethod.hpp Changeset: 198ea6575d8b Author: thartmann Date: 2014-07-23 07:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/198ea6575d8b 8051550: Printing of 'cmpN_reg_branch_short' instruction shows wrong 'op2' register Summary: Missing '$' added to the format string of the 'cmpN_reg_branch_short' instruction (sparc.ad). Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/sparc.ad Changeset: c8e602d67072 Author: goetz Date: 2014-07-18 09:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/c8e602d67072 8050978: Fix bad field access check in C1 and C2 Summary: JCK8 test vm/constantpool/accessControl/accessControl004/accessControl00402m3/accessControl00402m3.html fails with -Xbatch -Xcomp due to bad field access check in C1 and C2. Fix: In ciField::ciField(), just before the canonical holder is stored into the _holder variable (and which is used by ciField::will_link()) perform an additional access check with the holder declared in the class file. If this check fails, store the declared holder instead and ciField::will_link() will bail out compilation for this field later on. Then, the interpreter will throw an PrivilegedAccessException at runtime. Reviewed-by: kvn, vlivanov Contributed-by: andreas.schoesser at sap.com ! src/share/vm/ci/ciField.cpp Changeset: 0500ca0c5aba Author: rbackman Date: 2014-07-24 14:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/0500ca0c5aba Merge - test/compiler/5091921/Test6890943.sh Changeset: 283b523b9f2f Author: amurillo Date: 2014-07-24 13:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/283b523b9f2f Merge - test/compiler/5091921/Test6890943.sh Changeset: 48b95a073d75 Author: lana Date: 2014-08-04 15:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/48b95a073d75 Merge - test/compiler/5091921/Test6890943.sh Changeset: ee436b3d514f Author: chegar Date: 2014-08-08 19:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/ee436b3d514f Merge ! src/share/vm/runtime/os.cpp - test/compiler/5091921/Test6890943.sh From chris.hegarty at oracle.com Sun Aug 10 20:18:48 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 10 Aug 2014 20:18:48 +0000 Subject: hg: jigsaw/stage/nashorn: 11 new changesets Message-ID: <201408102018.s7AKImx1005228@aojmv0008> Changeset: 0787fe044ee6 Author: lagergren Date: 2014-07-29 14:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/0787fe044ee6 8048869: Reduce compile time by about 5% by removing the Class.casts from the AST nodes Summary: Removed the native casts that slow down the compiler unnecessarily. I also modified the compile-octane harness so that it can run with --verbose and --iterations flags so that you can run the compiler for an arbitrary time, gathering a mission control executing profile. Reviewed-by: attila, jlaskey ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/debug/ClassHistogramElement.java ! src/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/compile-octane-normal.js + test/script/basic/compile-octane-normal.js.EXPECTED ! test/script/basic/compile-octane-splitter.js ! test/script/basic/compile-octane-splitter.js.EXPECTED ! test/script/basic/compile-octane.js - test/script/basic/compile-octane.js.EXPECTED + test/script/basic/octane-payload.js ! test/script/basic/run-octane.js Changeset: b92d8a583f99 Author: lagergren Date: 2014-07-29 14:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/b92d8a583f99 8053913: Auto format caused warning in CompositeTypeBasedGuardingDynamicLinker Reviewed-by: attila, jlaskey ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java Changeset: 1de3a6ce3f57 Author: yan Date: 2014-07-30 16:49 +0400 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/1de3a6ce3f57 8049318: Test hideLocationProperties.js fails on Window due to backslash in path Reviewed-by: lagergren, sundar Contributed-by: Sergey Lugovoy ! test/script/basic/hideLocationProperties.js Changeset: 99e9916ace37 Author: attila Date: 2014-07-30 10:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/99e9916ace37 8051839: GuardedInvocation needs to clone an argument Reviewed-by: hannesw, sundar ! src/jdk/internal/dynalink/linker/GuardedInvocation.java Changeset: 2ce63129b64a Author: sundar Date: 2014-07-31 18:14 +0530 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/2ce63129b64a 8053908: jdeps is not PATH on Mac, results in ant clean test failure on Mac Reviewed-by: hannesw, jlaskey ! test/script/nosecurity/JDK-8050964.js Changeset: 44ab1e6cf0e8 Author: sundar Date: 2014-08-04 21:37 +0530 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/44ab1e6cf0e8 8054223: Nashorn: AssertionError when use __DIR__ and ScriptEngine.eval() Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 6f579dd103da Author: lana Date: 2014-08-04 15:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/6f579dd103da Merge - test/script/basic/compile-octane.js.EXPECTED Changeset: fca4db1360f7 Author: attila Date: 2014-08-06 10:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/fca4db1360f7 8044786: Some tests fail with non-optimistic compilation Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! test/script/basic/JDK-8030182_2.js ! test/script/basic/JDK-8030182_2.js.EXPECTED ! test/script/basic/optimistic_arithmetic_check_type.js ! test/script/basic/optimistic_assignment_check_type.js ! test/script/basic/optimistic_check_type.js ! test/script/trusted/event_queue.js ! test/script/trusted/optimistic_recompilation.js Changeset: ba38d4cea99e Author: attila Date: 2014-08-06 11:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/ba38d4cea99e 8051439: Wrong type calculated for ADD operator with undefined operand Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk/nashorn/internal/ir/BinaryNode.java + test/script/basic/JDK-8051439.js + test/script/basic/JDK-8051439.js.EXPECTED Changeset: ed60a4e9dd35 Author: attila Date: 2014-08-06 11:54 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/ed60a4e9dd35 8054411: Add nashorn.args.prepend system property Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: 61749bf9c6bc Author: chegar Date: 2014-08-08 18:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/61749bf9c6bc Merge ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/OptimisticTypesPersistence.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/CallNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Node.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/TryNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ClassHistogramElement.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/options/Options.java - test/script/basic/compile-octane.js.EXPECTED From chris.hegarty at oracle.com Mon Aug 11 10:37:20 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:37:20 +0000 Subject: hg: jigsaw/stage: 2 new changesets Message-ID: <201408111037.s7BAbLi8012209@aojmv0008> Changeset: a5c324e6f840 Author: lana Date: 2014-08-10 19:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/a5c324e6f840 Added tag jdk9-b26 for changeset d3ec8d048e6c ! .hgtags Changeset: d1a324623a41 Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/d1a324623a41 Merge From chris.hegarty at oracle.com Mon Aug 11 10:37:27 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:37:27 +0000 Subject: hg: jigsaw/stage/corba: 2 new changesets Message-ID: <201408111037.s7BAbR3e012267@aojmv0008> Changeset: 0113206a8c8e Author: lana Date: 2014-08-10 19:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/corba/rev/0113206a8c8e Added tag jdk9-b26 for changeset 6c777df597bb ! .hgtags Changeset: a279cdbe1f14 Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/corba/rev/a279cdbe1f14 Merge From chris.hegarty at oracle.com Mon Aug 11 10:37:33 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:37:33 +0000 Subject: hg: jigsaw/stage/jaxp: 2 new changesets Message-ID: <201408111037.s7BAbXMH012319@aojmv0008> Changeset: 98a1a9025fd0 Author: lana Date: 2014-08-10 19:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/98a1a9025fd0 Added tag jdk9-b26 for changeset a5aea8318ae4 ! .hgtags Changeset: 35d68bb88146 Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxp/rev/35d68bb88146 Merge From chris.hegarty at oracle.com Mon Aug 11 10:37:43 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:37:43 +0000 Subject: hg: jigsaw/stage/jaxws: 2 new changesets Message-ID: <201408111037.s7BAbhVx012390@aojmv0008> Changeset: 879b5cc3ce32 Author: lana Date: 2014-08-10 19:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxws/rev/879b5cc3ce32 Added tag jdk9-b26 for changeset 9b43f3993b96 ! .hgtags Changeset: edca714118ac Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jaxws/rev/edca714118ac Merge From chris.hegarty at oracle.com Mon Aug 11 10:37:49 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:37:49 +0000 Subject: hg: jigsaw/stage/langtools: 2 new changesets Message-ID: <201408111037.s7BAbnKf012443@aojmv0008> Changeset: 84d1fb7670fa Author: lana Date: 2014-08-10 19:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/84d1fb7670fa Added tag jdk9-b26 for changeset 5b20a93f8db0 ! .hgtags Changeset: 3f964f7ec528 Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/langtools/rev/3f964f7ec528 Merge From chris.hegarty at oracle.com Mon Aug 11 10:37:59 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:37:59 +0000 Subject: hg: jigsaw/stage/jdk: 2 new changesets Message-ID: <201408111037.s7BAbxwt012572@aojmv0008> Changeset: 88856f58680f Author: lana Date: 2014-08-10 19:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/88856f58680f Added tag jdk9-b26 for changeset dde9f5cfde5f ! .hgtags Changeset: 54a747db48c7 Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/54a747db48c7 Merge From chris.hegarty at oracle.com Mon Aug 11 10:38:06 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:38:06 +0000 Subject: hg: jigsaw/stage/hotspot: 2 new changesets Message-ID: <201408111038.s7BAc6fe012622@aojmv0008> Changeset: 184aac46be1f Author: lana Date: 2014-08-10 19:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/184aac46be1f Added tag jdk9-b26 for changeset 48b95a073d75 ! .hgtags Changeset: 747483da0279 Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/747483da0279 Merge From chris.hegarty at oracle.com Mon Aug 11 10:38:16 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 11 Aug 2014 10:38:16 +0000 Subject: hg: jigsaw/stage/nashorn: 2 new changesets Message-ID: <201408111038.s7BAcGvI012696@aojmv0008> Changeset: 7404f40a22e1 Author: lana Date: 2014-08-10 19:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/7404f40a22e1 Added tag jdk9-b26 for changeset ed60a4e9dd35 ! .hgtags Changeset: 9be31791b8cf Author: chegar Date: 2014-08-11 11:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/nashorn/rev/9be31791b8cf Merge From mark.reinhold at oracle.com Mon Aug 11 15:28:33 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 11 Aug 2014 08:28:33 -0700 Subject: JEP 201: Modular Source Code In-Reply-To: <53E37F4C.4040403@oracle.com> References: <20140805164907.7EF17329BF@eggemoggin.niobe.net>, , <53E37F4C.4040403@oracle.com> Message-ID: <20140811082833.389897@eggemoggin.niobe.net> 2014/8/7 6:29 -0700, alan.bateman at oracle.com: > On 06/08/2014 15:08, Stephen Colebourne wrote: >> Just wanted to express my surprise that java files are still to be >> located in "src/.../classes". For me, most open source projects and >> most users of Maven and other build systems, "classes" is the name of >> the *output* directory containing ".class" files. Having the ".java" >> files in there is very confusing. >> >> As such, could I request that consideration is given to using >> "src/.../java" as per the Maven inspired standard directory layout. >> >> If that is not deemed acceptable (because of the root package name of >> java for example) I'd be happy with other sensible options >> ("src/.../javasrc"?), but please, not "classes"! > > A historical note, going way back then the java sources were in a "java" > directory (as in java/java/lang/Object.java). It changed to using > "classes" in JDK 1.2. I don't know the full history/rational but perhaps > "java/java" was confusing then. Yes, that's exactly why we made that change, in 1997. Java class (and resource) definitions are under the "classes" directory; native class and procedure definitions are under the "native" directory. Renaming "classes" to something new ("javasrc", or whatever) raises the question of whether we then need to move resource files under a separate directory, as Maven does, and then also split source code for native classes and procedures into language-specific directories ("csrc", "cppsrc", etc.). This all seems more trouble than it's worth. I understand how "classes" can be confusing to some, but hundreds (if not thousands) of developers have had no trouble working with it for many years now. In the context of all the other changes we're making, the familiarity of the "classes" and "native" directories will help people adapt from the old source-code layout to the new one. Renaming these directories would just add further confusion. - Mark From david.bosschaert at gmail.com Mon Aug 11 15:37:46 2014 From: david.bosschaert at gmail.com (David Bosschaert) Date: Mon, 11 Aug 2014 16:37:46 +0100 Subject: Jigsaw/OSGi interoperability requirements In-Reply-To: References: Message-ID: Hi all, Neil has now asked this question twice on the jigsaw-dev mailing list. I think this is an important question and should not be left unanswered. Mark R, could you please clarify? Many thanks, David On 30 July 2014 12:37, Neil Bartlett wrote: > Hello, > > I asked the following question at the beginning of July when the re-relaunch of Jigsaw was announced, but didn?t get a response. Probably it was unintentionally overlooked with all the other traffic, but I would very much appreciate an answer so I?ll ask again: > > The previous draft requirements dated 19 April 2011 (?Draft 12?) stated the following with respect to OSGi: ?It must be demonstrated by prototype to be feasible to modify an OSGi micro-kernel such that OSGi bundles running in that kernel can depend upon Java modules. The kernel must be able to load Java modules directly and resolve them using its own resolver, except for core system modules. Core system modules can only be loaded using the module system?s reification API.? > > Can you confirm that this requirement will still apply in the new phase, or has it been deliberately dropped? > > Regards, > Neil > > From Alan.Bateman at oracle.com Mon Aug 11 17:14:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Aug 2014 18:14:44 +0100 Subject: Jigsaw/OSGi interoperability requirements In-Reply-To: References: Message-ID: <53E8FA04.7030901@oracle.com> On 11/08/2014 16:37, David Bosschaert wrote: > Hi all, > > Neil has now asked this question twice on the jigsaw-dev mailing list. > I think this is an important question and should not be left > unanswered. > The old requirements document cited is from 2011. In 2012 then Project Penrose was created to focus on the topic. I don't know if there are plans for Penrose to reboot but I would think it's the right place to explore the topic now. -Alan From mandy.chung at oracle.com Mon Aug 11 19:29:36 2014 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 11 Aug 2014 19:29:36 +0000 Subject: hg: jigsaw/stage: Minor cleanup on modules.list and modules.xml Message-ID: <201408111929.s7BJTaSq006739@aojmv0008> Changeset: 5c452ec1884d Author: mchung Date: 2014-08-11 12:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/5c452ec1884d Minor cleanup on modules.list and modules.xml ! make/common/modules.list ! modules.xml From chris.hegarty at oracle.com Tue Aug 12 14:10:15 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 12 Aug 2014 15:10:15 +0100 Subject: RFR [9] Modular Source Code Message-ID: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. Webrevs: http://cr.openjdk.java.net/~chegar/8054834/00/ Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8051619 [2] https://bugs.openjdk.java.net/browse/JDK-8051618 [3] http://hg.openjdk.java.net/jigsaw/stage From mark.reinhold at oracle.com Tue Aug 12 23:36:04 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 12 Aug 2014 23:36:04 +0000 Subject: hg: jigsaw/stage: Clarify leading comment in modules.xml Message-ID: <201408122336.s7CNa4dL002942@aojmv0008> Changeset: a2a749182a39 Author: mr Date: 2014-08-12 16:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/a2a749182a39 Clarify leading comment in modules.xml ! modules.xml From erik.joelsson at oracle.com Wed Aug 13 12:11:18 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Aug 2014 14:11:18 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EB55E6.4010104@oracle.com> I should probably write something about the rather extensive changes to the build logic in this patch. As the source gets organized around modules, it made sense to also organize the build more around modules. In this patch, the makefiles have in large parts been split into module specific files and the top level targets are oriented around modules. This means the top level targets are much more fine granular than currently in JDK 9. Another difference is that the top level targets are now able to run concurrently, to give more opportunity for utilizing multiple cpus. In JDK 9, the build moves sequentially through each repository, in a given order, now make is free to run more things in parallel. This makes the build faster, at least on beefy hardware. The drawback is that the build log gets a bit more confusing. When something fails, it won't interrupt other building threads at once, so the actual failure may be further up the log (even further than before). I have found that searching for "Error 2" is a good way to find the real failure. Another consequence is that the build time summary at the end only displays total time as there is no good definition for how much time was spent in each repository anymore. A summary on the new targets: make [default] Does pretty much the same as before. It compiles everything but does not build all jars or create images. make all Builds everything, including jars, images and docs. Also runs a verification tool on the java classes which will point out any broken module boundaries. make images Same as before make hotspot Builds the hotspot repository, like before. make docs Builds all the documentation, including javadoc. make docs-javadoc Builds just the javadoc. This target has very few prerequisites so provides a fast way to just build javadoc. make gensrc Runs all source code generation steps. make java Compiles all java classes. Other similar targets are libs, launchers, gendata and copy make java.desktop Compiles everything in the java.desktop module (and its dependencies), both java and native code. Works for any module name. make java.desktop-java Compiles the java classes in java.desktop (and its dependencies). Works for any module name (and -gensrc, -libs, -launchers, -gendata, -copy) In addition to this, the suffix -only can be added to any target to disable the prerequisites for it. Using this is not recommended but it may save time when doing certain incremental builds and you are in a terrible hurry. For incremental builds, sjavac can be used and works reasonably well (configure --enable-sjavac). Work is in progress on making it work even better. The old workaround JDK_FILTER=package/to/compile is still working. The clean target is still oriented around repositories, mostly because the build output is still in large parts repository oriented. This is something we hope to improve later. /Erik On 2014-08-12 16:10, Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051619 > [2] https://bugs.openjdk.java.net/browse/JDK-8051618 > [3] http://hg.openjdk.java.net/jigsaw/stage From Alan.Bateman at oracle.com Wed Aug 13 12:35:47 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Aug 2014 13:35:47 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EB5BA3.2050504@oracle.com> Just to add to Chris and Erik's mails, I would encourage everyone that pushes to jdk9/dev or the other jdk9 project integration forests to clone and build jigsaw/stage and get familiar with the proposed layout, new build targets, and the very different output emitted during the build. The changes are arguably as significant as the transition in JDK 8 from the "old build" to the "new build" so the more people taking the forest for a test drive the better. If you maintain your our own own IDE project then you'll likely have to adjust file paths so any issues encountered would be useful to hear about too. -Alan. From erik.joelsson at oracle.com Wed Aug 13 13:16:53 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Aug 2014 15:16:53 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5771.2010908@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5407.50306@oracle.com> <53EB5771.2010908@oracle.com> Message-ID: <53EB6545.2090008@oracle.com> On 2014-08-13 14:17, Chris Hegarty wrote: > Thanks for the explanation Erik. > > I have taken a pass over the changes, and they look ok to me ( I am > happy to be listed as a reviewer ). I also did several build and test > runs on Solaris, Linux, Max OSX, and Windows. All look good. > > I am seeing, in some cases, about a 20% reduction in image build times > on an 8 core i7, running Linux x86. > Nice to hear! > One question; Are there any new requirements on build systems as a > result of these changes? > Yes and no. The build should still be compatible with gnu make 3.81. However, certain builds of that make version (particularly the one we have used for jdk8 internally) are known to crash in Cygwin and it is instead recommended to use a newer 4.0 version of make in Cygwin. Also to get good concurrent build performance on Windows, gnu make 4.0 is required for Cygwin. I have done test builds with msys and it seems to be working too. One more thing that I forgot to mention. If you are using gnu make 4.0, there is a new feature called output-sync that can be enabled that will make it somewhat easier to read the build output. This can be enabled either with the configure parameter --with-output-sync=recurse, or at the make command line "make OUTPUT_SYNC=recurse". (it will be enabled by default in JPRT). More information on this can be found here: http://www.gnu.org/software/make/manual/make.html#Parallel-Output /Erik From chris.hegarty at oracle.com Wed Aug 13 12:17:53 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Aug 2014 13:17:53 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5407.50306@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5407.50306@oracle.com> Message-ID: <53EB5771.2010908@oracle.com> Thanks for the explanation Erik. I have taken a pass over the changes, and they look ok to me ( I am happy to be listed as a reviewer ). I also did several build and test runs on Solaris, Linux, Max OSX, and Windows. All look good. I am seeing, in some cases, about a 20% reduction in image build times on an 8 core i7, running Linux x86. One question; Are there any new requirements on build systems as a result of these changes? -Chris. On 13/08/14 13:03, Erik Joelsson wrote: > I should probably write something about the rather extensive changes to > the build logic in this patch. > > As the source gets organized around modules, it made sense to also > organize the build more around modules. In this patch, the makefiles > have in large parts been split into module specific files and the top > level targets are oriented around modules. This means the top level > targets are much more fine granular than currently in JDK 9. > > Another difference is that the top level targets are now able to run > concurrently, to give more opportunity for utilizing multiple cpus. In > JDK 9, the build moves sequentially through each repository, in a given > order, now make is free to run more things in parallel. This makes the > build faster, at least on beefy hardware. The drawback is that the build > log gets a bit more confusing. When something fails, it won't interrupt > other building threads at once, so the actual failure may be further up > the log (even further than before). I have found that searching for > "Error 2" is a good way to find the real failure. Another consequence is > that the build time summary at the end only displays total time as there > is no good definition for how much time was spent in each repository > anymore. > > A summary on the new targets: > > make [default] > Does pretty much the same as before. It compiles everything but does not > build all jars or create images. > > make all > Builds everything, including jars, images and docs. Also runs a > verification tool on the java classes which will point out any broken > module boundaries. > > make images > Same as before > > make hotspot > Builds the hotspot repository, like before. > > make docs > Builds all the documentation, including javadoc. > > make docs-javadoc > Builds just the javadoc. This target has very few prerequisites so > provides a fast way to just build javadoc. > > make gensrc > Runs all source code generation steps. > > make java > Compiles all java classes. > Other similar targets are libs, launchers, gendata and copy > > make java.desktop > Compiles everything in the java.desktop module (and its dependencies), > both java and native code. Works for any module name. > > make java.desktop-java > Compiles the java classes in java.desktop (and its dependencies). Works > for any module name (and -gensrc, -libs, -launchers, -gendata, -copy) > > In addition to this, the suffix -only can be added to any target to > disable the prerequisites for it. Using this is not recommended but it > may save time when doing certain incremental builds and you are in a > terrible hurry. > > For incremental builds, sjavac can be used and works reasonably well > (configure --enable-sjavac). Work is in progress on making it work even > better. The old workaround JDK_FILTER=package/to/compile is still working. > > The clean target is still oriented around repositories, mostly because > the build output is still in large parts repository oriented. This is > something we hope to improve later. > > /Erik > > > On 2014-08-12 16:10, Chris Hegarty wrote: >> This is a review request for the Initial changes for JEP 201: Modular >> Source Code [1]. >> >> There are a number of individuals responsible for these changes. Some, >> possibly not all, are explicitly listed in the To section of this >> mail, and they will help address any comments arising from this review >> request. >> >> For the purposes of review, the actual source file moves have been >> omitted from the webrev below, with the exception of any source file >> that has a change to it?s actual content. The new location of the >> source files can be determined from JEP 201 [1] and JEP 200 "The >> Modular JDK" [2], or by browsing the staging forest [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8054834/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has >> been tentatively reserved for their integration. All comments are >> welcome, although given the nature of the changes then we might have >> to create separate issues in JIRA to address some of them later in >> jdk9/dev.. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >> [3] http://hg.openjdk.java.net/jigsaw/stage > From mark.reinhold at oracle.com Wed Aug 13 15:50:54 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 13 Aug 2014 15:50:54 +0000 Subject: hg: jigsaw/stage: Add legal notice to modules.xml Message-ID: <201408131550.s7DFosxP005764@aojmv0008> Changeset: 4440ed486012 Author: mr Date: 2014-08-13 08:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/4440ed486012 Add legal notice to modules.xml ! modules.xml From chris.hegarty at oracle.com Wed Aug 13 19:06:59 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 13 Aug 2014 19:06:59 +0000 Subject: hg: jigsaw/stage: Revert default JPRT release Message-ID: <201408131906.s7DJ6x7I009855@aojmv0008> Changeset: 9feef5e086a4 Author: chegar Date: 2014-08-13 20:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/9feef5e086a4 Revert default JPRT release ! make/jprt.properties From mike.duigou at oracle.com Wed Aug 13 21:29:47 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Aug 2014 14:29:47 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> There's a lot to review here. This is not a complete review but hopefully contributes to our review "coverage". I am focusing on the top project in this set of comments. - --with-output-sync seems like it should be on by default if available. Downside? This could also be split out from the jigsaw changes if there is any interest in reducing the patch size. - what is TESTMAKE_OUTPUTDIR for? (ugh, more outputdir dirs...) - spec.gmk.in: Can we have a separate assignment for JAVA_TOOL_FLAGS_SMALL? It is nice to be able to see every AC_SUBST somewhere solo. - jdk-options.m4: should with_cacerts_file being empty not merit an error? what does the empty default do? - javadoc.gmk: retire JDK_IMPSRC, JDK_GENSRC, JDK_SHARE_CLASSES and JDK_SHARE_SRC - javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant) JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG? - MakeHelpers: CleanComponent should call strip on the $1 argument to $(RM) so that it is deleting what it promises to be deleting. Or it could check to make sure $(words $1) is 1 - modules.xml "Changes to this file will require review by Committers to Project Jigsaw." Will this be true after integration into jdk9/dev repo? - modules.list seems to be redundant with modules.xml but there don't seem to be any measures to ensure that they remain in sync. Even a comment in modules.xml would help. This kind of problem has been a source of errors in the past. - What is TestMake.gmk and associated for? jdk project: - I am slightly unsettled by the number of makefiles and putting them all in to the same directory. Will they eventually be moved into their modules? More to come but first I want to build it! On Aug 12 2014, at 07:10 , Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051619 > [2] https://bugs.openjdk.java.net/browse/JDK-8051618 > [3] http://hg.openjdk.java.net/jigsaw/stage From Alan.Bateman at oracle.com Wed Aug 13 22:54:46 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Aug 2014 23:54:46 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> Message-ID: <53EBECB6.7050301@oracle.com> On 13/08/2014 22:29, Mike Duigou wrote: > : > > - modules.xml "Changes to this file will require review by Committers to Project Jigsaw." Will this be true after integration into jdk9/dev repo? > There's a section in JEP 200 about modules.xml, it is temporary until there is a module system in place. The jdeps tool is updated with a new option to read it and check for changes (the dependency check is more detailed that might be initially obvious). For now, committers to Project Jigsaw are the custodians of the module graph and I think the requirement for a Reviewer will last at least as long as this side file needs to exist. In time I assume that processes for dealing with changes to the module graph will be on par with other API changes. -Alan From erik.joelsson at oracle.com Thu Aug 14 07:07:17 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Aug 2014 09:07:17 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> Message-ID: <53EC6025.7080003@oracle.com> Hello Mike, Thanks for the comments. See inline. On 2014-08-13 23:29, Mike Duigou wrote: > There's a lot to review here. This is not a complete review but hopefully contributes to our review "coverage". I am focusing on the top project in this set of comments. > > - --with-output-sync seems like it should be on by default if available. Downside? This could also be split out from the jigsaw changes if there is any interest in reducing the patch size. There are downsides yes. The way this works is that make will buffer output from all commands and print them when done. Depending on level that's when the command line is done, the recipe is done, or the complete submake. I played around with having it default for a while. For a normal build this isn't too confusing once you get used to it, but it really made running tests annoying as the output from jtreg would all be buffered until it was done. Also, a hotspot developer that was to build hotspot from the root repo would see nothing until the whole build was complete. I simply believe we need some more experience with this before we can decide on a better default behavior. Possibly we need to do the hotspot makefile rewrite first so that the hotspot build can be split into smaller logical chunks from the top level. I wanted the output-sync feature to be in this from the start to make JPRT logs easier to look at, as the feature will be default turned on there. Especially debug logs become very hard to read without it. > > - what is TESTMAKE_OUTPUTDIR for? (ugh, more outputdir dirs...) While doing this work, I had the need for adding features to SetupArchive (mainly to support multiple source dirs for jars). It quickly turned quite nasty and to make development easier, I added specific test cases for this macro in a separate makefile structure. This is the output directory for those tests. > - spec.gmk.in: Can we have a separate assignment for JAVA_TOOL_FLAGS_SMALL? It is nice to be able to see every AC_SUBST somewhere solo. Certainly, that makes sense. Must have just missed it. > - jdk-options.m4: should with_cacerts_file being empty not merit an error? what does the empty default do? The default is to use the bundled one. I didn't like having that default being defined in configure. I think it better belongs in the makefile handling the file. > - javadoc.gmk: retire JDK_IMPSRC, JDK_GENSRC, JDK_SHARE_CLASSES and JDK_SHARE_SRC We should certainly clean up javadoc.gmk properly, but I thought that was out of scope for this patch. You do have a point in that those variables are now unused so no longer need to be declared. > - javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant) JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG? I agree, but that should be a separate change. > - MakeHelpers: CleanComponent should call strip on the $1 argument to $(RM) so that it is deleting what it promises to be deleting. Or it could check to make sure $(words $1) is 1 Strip clears leading and trailing whitespace. The reason I added a strip to the echo is that in some cases the macro was called with a space after comma and in some not. The output looked weird when the echo line sometimes had 2 spaces before the component name instead of one. It should not matter to the rm command line however. > - modules.xml "Changes to this file will require review by Committers to Project Jigsaw." Will this be true after integration into jdk9/dev repo? > > - modules.list seems to be redundant with modules.xml but there don't seem to be any measures to ensure that they remain in sync. Even a comment in modules.xml would help. This kind of problem has been a source of errors in the past. They are redundant yes. modules.list is used by make to extract dependency information and modules.xml is used by the verification tool. In jigsaw development both files were dynamically created during the build process and here we simply committed static versions of them. Ideally we should only need one, but it's a temporary solution anyway. We would need to create a tool to extract dependency information from the xml to make. > - What is TestMake.gmk and associated for? These are my new tests for the common makefile logic. It's far from a complete coverage, but it has already helped me greatly. > jdk project: > > - I am slightly unsettled by the number of makefiles and putting them all in to the same directory. Will they eventually be moved into their modules? This is something I'm thinking about and would like to discuss. I think that ideally the makefiles for specific modules should be moved to module specific directories. For now I kept the existing task based directory structure. > More to come but first I want to build it! Go for it! /Erik > On Aug 12 2014, at 07:10 , Chris Hegarty wrote: > >> This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. >> >> For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8054834/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >> [3] http://hg.openjdk.java.net/jigsaw/stage From erik.joelsson at oracle.com Thu Aug 14 08:12:38 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Aug 2014 10:12:38 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EC6025.7080003@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <6BD01436-C5AF-44A8-9AE6-11FE6D1B8333@oracle.com> <53EC6025.7080003@oracle.com> Message-ID: <53EC6F76.4080407@oracle.com> On 2014-08-14 09:07, Erik Joelsson wrote: > - javadoc.gmk: JAVADOC_CMD should perhaps use (currently non-existant) > JAVA_TOOL_FLAGS_BIG or at least JAVA_FLAGS_BIG? > I agree, but that should be a separate change. Actually, the variable JAVA already contains the big java flags. The correct fix here is to remove the redundant explicit mx flag from Javadoc.gmk and just trust that JAVA is correctly sized. /Erik From erik.joelsson at oracle.com Thu Aug 14 08:37:34 2014 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 14 Aug 2014 08:37:34 +0000 Subject: hg: jigsaw/stage: Removing now unused variables from Javadoc.gmk. Adding JAVA_TOOL_FLAGS_SMALL to spec.gmk.in. Message-ID: <201408140837.s7E8bYLc016907@aojmv0008> Changeset: 7a5ae6a78455 Author: erikj Date: 2014-08-14 10:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/stage/rev/7a5ae6a78455 Removing now unused variables from Javadoc.gmk. Adding JAVA_TOOL_FLAGS_SMALL to spec.gmk.in. ! common/autoconf/spec.gmk.in ! make/Javadoc.gmk From chris.hegarty at oracle.com Thu Aug 14 18:14:32 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 14 Aug 2014 18:14:32 +0000 Subject: hg: jigsaw/stage/jdk: Fix libjavajpeg headers Message-ID: <201408141814.s7EIEW1A017567@aojmv0008> Changeset: 7dbded285381 Author: erikj Date: 2014-08-14 17:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/7dbded285381 Fix libjavajpeg headers ! make/lib/Awt2dLibraries.gmk From magnus.ihse.bursie at oracle.com Fri Aug 15 08:52:36 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Aug 2014 10:52:36 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EDCA54.2090107@oracle.com> On 2014-08-12 16:10, Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ These are indeed the single most significant changes to the build system since the "new" build system was introduced. Here follows a partial review of the changes in the jdk repo. Even though it's long, I'm not done. ;-) *** General issues *** * The new directory jdk/make/bundle should instead reside in jdk/make/data/bundles. * In GensrcSwing.gmk is a "$(if $(SHUFFLED)..." part that seems to be remnants of older, temporary work. * The new file GensrcProviders.gmk are included by the Gensrc files for jdk.attach and jdk.jdi, which only uses half of it each. Each half is just a few lines long. I believe a better solution is to remove the GensrcProviders.gmk file, move the process-provider macro to GensrcCommon.gmk and move the two actual rules to the respective module gensrc file. * In the gensrc directory, there are now almost twice as many files. For many of them, the following pattern holds: GensrcOldStyle.gmk -- defines the actual logic for some gensrc target Gensrc-.gmk -- does nothing but includes GensrcOldStyle.gmk In these cases, I think the contents of GensrcOldStyle should be inlined directly in the Gensrc-.gmk instead. This holds for all modules except the two mammuth modules java.base and java.desktop. (Depending on the treatment of GensrcProviders as described above.) * In CreateJars.gmk, the following new comment is found embedded: # This currently won't work with modular build layout, but there currently are no # types needing to be re added. In my opinion, leaving code which looks like it's working but with a note saying "out of order", is bad practice. I'd recommend that the code is removed or commented out, if it is not needed. * In CreateJars.gmk, in BUILD_TOOLS_JAR: The following looks like a duplication; I believe the "classes" version should be removed. $(JDK_OUTPUTDIR)/modules/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector \ $(JDK_OUTPUTDIR)/classes/META-INF/services/com.sun.jdi.connect.Connector \ * In CreateSecurityJars.gmk, there is a variable SECURITY_CLASSES_SUBDIR that is always set to 'modules'. I believe this is remains of an older temporary design, and that "modules" should be hard-coded into the paths. * The old Setup.gmk had a very generic-sounding name, even though it only did setup java compilers. So, the rename to SetupJava.gmk was good; however, I'd suggest we follow it through all the way and rename it further to SetupJavaCompilers.gmk, since that is an even more accurate description of it's job. * The file CopyIntoClasses.gmk is not used anymore and should be removed. * In CoreLibraries.gmk, there used to be a line "BUILD_LIBRARIES += $(BUILD_LIBFDLIBM)" which is now removed. After discussion with Erik, I learned that this was since the libfdlibm was not delivered in itself, but was used solely as a helper lib for libjava, which has BUILD_LIBFDLIBM as a requirement. While this change is thus correct, I believe a comment describing this fact would be in place on libfdlibm, since it makes it behave differently than all other libraries. *** Issues with source files moving and its repercussions *** * When the source code has moved, especially the native libraries, most of the specific INCLUDE and EXCLUDE statements are, or should be, unnecessary. Nevertheless, there are still several occasions of such statements. In some cases, it seems like dead code that can (and should) be removed. But in some cases, I believe it is an indication that the source code has still not yet been moved to a suitable location. I believe the end goal with this shuffling regarding native library source code is that there should be a one-to-one correspondance between compiled native library and source code directory. This is now indeed the case for 99% of the libraries, but there are still some exceptions. This is a slightly vague point at the moment. I indent to check the INCLUDE and EXCLUDE statements more fully and will post a second review with results of what I find. Nevertheless, I think it is important to make sure we do get things correct this time. *** Issues regarding modules.xml *** The new modules.xml and associated Java tools and make files seems rather confusing to me. I understand some of the mysteries here are due the the fact that the file has moved around during development. Nevertheless, such historical relics should be removed when the code is ready to be pushed to mainline. More concretely: * ModulesXml.gmk referes to make/data/checkdeps/modules.xml. This file does not exist. I believe this should be the $(TOPDIR)/modules.xml. * GenererateModules.Xml says: "This tool is used to generate com/sun/tools/jdeps/resources/modules.xml". This is an incorrect claim. In fact, the output file of the tool is specified by the user. The way it is used by the build tool currently, the output file is placed in $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, but that is decided by the make file and not the Java utility. * In fact, what happens is this: ** $(TOPDIR)/modules.xml is copied to $(JDK_OUTPUTDIR)/btclasses/build/tools/module/modules.xml ** Then the GenerateModulesXml tool is executed. ** The tool will open and read this file using GenerateModulesXml.class.getResourceAsStream("modules.xml"). ** The tool will generate output to a new file, specified to be $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml. ** Afterwards, the separate tool $(JDK_OUTPUTDIR)/bin/jdeps is executed, which will pick up the $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, presumably using getResourceAsStream. (I have not verified this.) I have several objections to this. * First, we are actually dealing with two different files, but both are named modules.xml. I believe one of them is an annotated version of the other, but I have not chec,ed. Nevertheless, this is just an unneccessary source of confusion. One of them should change name, e.g. annotated-modules.xml or jdeps-modules.xml or whatever. * Second, it is not documented anywhere that GenerateModulexXml requires an modules.xml as input. * Third, and this links into the bullet above, this dependency is not explicit but hidden away with unnessary shuffling and hard-to-understand shuffling of files as result. A better solution, I believe, is two modify GenerateModulesXml to require a path to the input modules.xml as an argument, in addition to the output file. That way, the dependency will be obvious, and we can just point to $(TOPDIR)/modules.xml instead of copying it around. * And fourth, all old comments etc refering to old placements of the files should be corrected. * Finally, I'm also not entirely happy with the placement of modules.xml in the root directory. Erik has told me that the intention is that this file will ultimately be created dynamically at build time, and when that happens, it will just be a build by-product which can be placed elsewhere. If this is indeed the case, I can live with some temporary extra cluttering of the top-level directory. *** More major undertakings *** * The file GensrcProperties.gmk is not split according to modules. I understand why this is harder to do and why it was not done for this milestone; nevertheless I believe it should be done in a followup patch. * GensrcCLDR.gmk is not ideal. It generates source for multiple modules, and the output is separated afterwards. Fixing this will probably means some modification to the java helper tools. * This code that previously was in jdk/make/CopyIntoClasses has now unfortunately moved this very specific logic up into the top repo. In fact, the top/make/CompileJavaModules.gmk now contain module-specific data such as "java.base_COPY := .icu .dat .spp content-types.properties". This should really be split into module-specific files and pushed down once again to the jdk/make directory, maybe into the copy directory. * I think the jdk/make/data directory could (and should) be separated on module level, e.g. jdk/make/data/java.base/... etc. Or, maybe, that the contents should even be moved out into like src/java.base/share/data, since the contents of that directory in a way is "source code" (only just not Java or native source code), and not really part of the build system. *** Issues that was not introduced now, but should be fixed at some point *** * In CopyCommon, the variables LIBDIR and INCLUDEDIR has very generic-sounding name even though they are very specific. These names are not new, but since the definition is now in a different file than the uses of it, the badly chosen names makes it even harder to understand the code. * The platform-specific correspondance, OPENJDK_TARGET_OS_INCLUDE = $(INCLUDEDIR)/$(OPENJDK_TARGET_OS) is also bad from several perspectives: It is a variant of INCLUDEDIR but it does not end in DIR, it should not start with OPENJDK since it's not a global variable, and finally it uses incorrect assignment (= instead of :=). * In Awt2dLibraries.gmk, for libsplashscreen, the logic for the three included external graphics libraries (gif, jpeg and png) is highly asymmetric, which make it hard to understand. It seems likely that at least the libjpeg handling is broken. * The BUILD_LIBT2K is used only by the Oracle closed build, and the definition should move to the closed sources. /Magnus From magnus.ihse.bursie at oracle.com Fri Aug 15 10:13:27 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Aug 2014 12:13:27 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDCA54.2090107@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> Message-ID: <53EDDD47.2010204@oracle.com> On 2014-08-15 10:52, Magnus Ihse Bursie wrote: > > *** Issues with source files moving and its repercussions *** > > * When the source code has moved, especially the native libraries, > most of the specific INCLUDE and EXCLUDE statements are, or should be, > unnecessary. Nevertheless, there are still several occasions of such > statements. In some cases, it seems like dead code that can (and > should) be removed. But in some cases, I believe it is an indication > that the source code has still not yet been moved to a suitable > location. I believe the end goal with this shuffling regarding native > library source code is that there should be a one-to-one > correspondance between compiled native library and source code > directory. This is now indeed the case for 99% of the libraries, but > there are still some exceptions. > > This is a slightly vague point at the moment. I indent to check the > INCLUDE and EXCLUDE statements more fully and will post a second > review with results of what I find. Nevertheless, I think it is > important to make sure we do get things correct this time. Here are the more concrete specification of this, for all files except Awt2dLibraries.gmk, which I'll return to. In NioLibraries: * The line "EXCLUDES := sctp" is unnecessary. In NetworkingLibraries.gmk: * There are multiple instances of this pattern: ifneq ($(OPENJDK_TARGET_OS), solaris) LIBNET_EXCLUDE_FILES += solaris_close.c endif The correct solution is to move the corresponding files away from the "unix" directory and into more specific libraries (linux, solaris and macosx) and include these directories automatically depending on platform. This will allow us to remove the exclude expression. * For AIX, this is already done (woho!); however, unfortunately, the file aix_close.c ended up not in java.base/aix/native/libnet/ but in java.base/aix/native/libnet/java/net, with remnants of the old directory structure still intact. * Also, the corresponding source line in NetworkingLibraries.gmk for AIX is incorrect, and refers to the old structure: LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ is incorrect. But if solving the two problems above, this will be corrected all by itself, rendering this statement unnecessary. In Lib-jdk.security.auth.gmk: * The file src/jdk.security.auth/unix/native/libjaas/Solaris.c should move to a solaris directory instead, rendering the EXCLUDE for libjaas unnecessary. In Lib-jdk.attach.gmk: The files * src/jdk.attach/unix/native/libattach/LinuxVirtualMachine.c * src/jdk.attach/unix/native/libattach/SolarisVirtualMachine.c * src/jdk.attach/unix/native/libattach/BsdVirtualMachine.c should move from unix to linux, solaris and macosx respectively, rendering the EXCLUDES unnecessary. The statement LIBATTACH_EXCLUDE_FILES += AixVirtualMachine.c is already unnecessary, since that files virtuously is already placed in an aix directory! :-) In Lib-java.management.gmk: The files * src/java.management/unix/native/libmanagement/LinuxOperatingSystem.c * src/java.management/unix/native/libmanagement/SolarisOperatingSystem.c * src/java.management/unix/native/libmanagement/MacosxOperatingSystem.c should move from unix to linux, solaris and macosx respectively, rendering the EXCLUDES unnecessary. In CoreLibraries.gmk, for libjava: * The file src/java.base/unix/native/libjava/java_props_macosx.c should move to a macosx directory. * The line "EXCLUDES := fdlibm/src zip prefs" is not needed anymore. * The stanza: ifeq ($(OPENJDK_TARGET_OS), macosx) LIBJAVA_EXCLUDE_FILES += $(JDK_TOPDIR)/src/java.base/unix/native/libjava/HostLocaleProviderAdapter_md.c endif is unnecessary since no such file exists. In CoreLibraries.gmk, for libjli: Here are include statements galore! :) After parsing what we're supposed to do and checking with how the source code now actually looks, this can boil down to: * As normal, set the source dirs to share and PLATFORM_OS and OS_API. * On macosx, exclude java_md_solinux.c, ergo.c and ergo_i586.c. * On unixes that are not macosx: If OPENJDK_TARGET_CPU_ARCH != x86 then also exclude ergo_i586.c and set LIBJLI_CFLAGS += -DUSE_GENERIC_ERGO But to make things worse, we also use a selected subset of the source from zlib :-(, viz.: inflate.c inftrees.c inffast.c zadler32.c zcrc32.c zutil.c This should be turned into a exclude-based statement instead (unless USE_EXTERNAL_LIBZ is true, of course), like this: BUILD_LIBJLI_SRC_DIRS += $(JDK_TOPDIR)/src/java.base/share/native/libzip/zlib-1.2.8 (as before) and exclude: compress.c deflate.c gzclose.c gzlib.c gzread.c gzwrite.c infback.c trees.c uncompr.c /Magnus From erik.joelsson at oracle.com Fri Aug 15 10:13:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 12:13:45 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDCA54.2090107@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> Message-ID: <53EDDD59.1000502@oracle.com> Hello, Magnus Thanks for the thorough review. I tend to agree with Alan, that we should rather push this in unless we find critical issues but make sure to continue cleaning this up in jdk9/dev. I have created bugs for (almost) everything you have listed below. See inline for links and comments. On 2014-08-15 10:52, Magnus Ihse Bursie wrote: > Here follows a partial review of the changes in the jdk repo. Even > though it's long, I'm not done. ;-) > > *** General issues *** > > * The new directory jdk/make/bundle should instead reside in > jdk/make/data/bundles. > > * In GensrcSwing.gmk is a "$(if $(SHUFFLED)..." part that seems to be > remnants of older, temporary work. > Created " General cleanup of minor issues from source restructure" https://bugs.openjdk.java.net/browse/JDK-8055188 > * The new file GensrcProviders.gmk are included by the Gensrc files > for jdk.attach and jdk.jdi, which only uses half of it each. Each half > is just a few lines long. I believe a better solution is to remove the > GensrcProviders.gmk file, move the process-provider macro to > GensrcCommon.gmk and move the two actual rules to the respective > module gensrc file. > > * In the gensrc directory, there are now almost twice as many files. > For many of them, the following pattern holds: > GensrcOldStyle.gmk -- defines the actual logic for some gensrc target > Gensrc-.gmk -- does nothing but includes GensrcOldStyle.gmk > > In these cases, I think the contents of GensrcOldStyle should be > inlined directly in the Gensrc-.gmk instead. This holds for > all modules except the two mammuth modules java.base and java.desktop. > (Depending on the treatment of GensrcProviders as described above.) > Created "Cleanup gensrc after source code restructure" https://bugs.openjdk.java.net/browse/JDK-8055189 > * In CreateJars.gmk, the following new comment is found embedded: > # This currently won't work with modular build layout, but > there currently are no > # types needing to be re added. > In my opinion, leaving code which looks like it's working but with a > note saying "out of order", is bad practice. I'd recommend that the > code is removed or commented out, if it is not needed. > While I agree on this in principle, I would rather not spend time on the profiles generation code since it's planned to go away soon anyway. > * In CreateJars.gmk, in BUILD_TOOLS_JAR: The following looks like a > duplication; I believe the "classes" version should be removed. > $(JDK_OUTPUTDIR)/modules/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > \ > $(JDK_OUTPUTDIR)/classes/META-INF/services/com.sun.jdi.connect.Connector > \ > > * In CreateSecurityJars.gmk, there is a variable > SECURITY_CLASSES_SUBDIR that is always set to 'modules'. I believe > this is remains of an older temporary design, and that "modules" > should be hard-coded into the paths. > > * The old Setup.gmk had a very generic-sounding name, even though it > only did setup java compilers. So, the rename to SetupJava.gmk was > good; however, I'd suggest we follow it through all the way and rename > it further to SetupJavaCompilers.gmk, since that is an even more > accurate description of it's job. > > * The file CopyIntoClasses.gmk is not used anymore and should be removed. > > * In CoreLibraries.gmk, there used to be a line "BUILD_LIBRARIES += > $(BUILD_LIBFDLIBM)" which is now removed. After discussion with Erik, > I learned that this was since the libfdlibm was not delivered in > itself, but was used solely as a helper lib for libjava, which has > BUILD_LIBFDLIBM as a requirement. While this change is thus correct, I > believe a comment describing this fact would be in place on libfdlibm, > since it makes it behave differently than all other libraries. > Added to general cleanup > *** Issues with source files moving and its repercussions *** > > * When the source code has moved, especially the native libraries, > most of the specific INCLUDE and EXCLUDE statements are, or should be, > unnecessary. Nevertheless, there are still several occasions of such > statements. In some cases, it seems like dead code that can (and > should) be removed. But in some cases, I believe it is an indication > that the source code has still not yet been moved to a suitable > location. I believe the end goal with this shuffling regarding native > library source code is that there should be a one-to-one > correspondance between compiled native library and source code > directory. This is now indeed the case for 99% of the libraries, but > there are still some exceptions. > > This is a slightly vague point at the moment. I indent to check the > INCLUDE and EXCLUDE statements more fully and will post a second > review with results of what I find. Nevertheless, I think it is > important to make sure we do get things correct this time. > Created "Cleanup include and exclude of native libraries after source code restructure" https://bugs.openjdk.java.net/browse/JDK-8055190 > *** Issues regarding modules.xml *** > > The new modules.xml and associated Java tools and make files seems > rather confusing to me. I understand some of the mysteries here are > due the the fact that the file has moved around during development. > Nevertheless, such historical relics should be removed when the code > is ready to be pushed to mainline. More concretely: > > * ModulesXml.gmk referes to make/data/checkdeps/modules.xml. This file > does not exist. I believe this should be the $(TOPDIR)/modules.xml. > > * GenererateModules.Xml says: "This tool is used to generate > com/sun/tools/jdeps/resources/modules.xml". This is an incorrect > claim. In fact, the output file of the tool is specified by the user. > The way it is used by the build tool currently, the output file is > placed in > $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, > but that is decided by the make file and not the Java utility. > > * In fact, what happens is this: > ** $(TOPDIR)/modules.xml is copied to > $(JDK_OUTPUTDIR)/btclasses/build/tools/module/modules.xml > ** Then the GenerateModulesXml tool is executed. > ** The tool will open and read this file using > GenerateModulesXml.class.getResourceAsStream("modules.xml"). > ** The tool will generate output to a new file, specified to be > $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml. > ** Afterwards, the separate tool $(JDK_OUTPUTDIR)/bin/jdeps is > executed, which will pick up the > $(JDK_OUTPUTDIR)/modules/jdk.dev/com/sun/tools/jdeps/resources/modules.xml, > presumably using getResourceAsStream. (I have not verified this.) > > I have several objections to this. > > * First, we are actually dealing with two different files, but both > are named modules.xml. I believe one of them is an annotated version > of the other, but I have not chec,ed. Nevertheless, this is just an > unneccessary source of confusion. One of them should change name, e.g. > annotated-modules.xml or jdeps-modules.xml or whatever. > > * Second, it is not documented anywhere that GenerateModulexXml > requires an modules.xml as input. > > * Third, and this links into the bullet above, this dependency is not > explicit but hidden away with unnessary shuffling and > hard-to-understand shuffling of files as result. A better solution, I > believe, is two modify GenerateModulesXml to require a path to the > input modules.xml as an argument, in addition to the output file. That > way, the dependency will be obvious, and we can just point to > $(TOPDIR)/modules.xml instead of copying it around. > > * And fourth, all old comments etc refering to old placements of the > files should be corrected. > > * Finally, I'm also not entirely happy with the placement of > modules.xml in the root directory. Erik has told me that the intention > is that this file will ultimately be created dynamically at build > time, and when that happens, it will just be a build by-product which > can be placed elsewhere. If this is indeed the case, I can live with > some temporary extra cluttering of the top-level directory. > While I agree it's messy at the moment, this is an area that is temporary and will change drastically. Added as optional to general cleanup. > *** More major undertakings *** > > * The file GensrcProperties.gmk is not split according to modules. I > understand why this is harder to do and why it was not done for this > milestone; nevertheless I believe it should be done in a followup patch. > Created "Split GensrcProperties.gmk into separate modules" https://bugs.openjdk.java.net/browse/JDK-8055191 > * GensrcCLDR.gmk is not ideal. It generates source for multiple > modules, and the output is separated afterwards. Fixing this will > probably means some modification to the java helper tools. > While I think it would be good to split this in principle, I'm not sure it's worth pursuing. The english locale is in the base module and the others are in a different module. I would leave this as it is for now. > * This code that previously was in jdk/make/CopyIntoClasses has now > unfortunately moved this very specific logic up into the top repo. In > fact, the top/make/CompileJavaModules.gmk now contain module-specific > data such as "java.base_COPY := .icu .dat .spp > content-types.properties". This should really be split into > module-specific files and pushed down once again to the jdk/make > directory, maybe into the copy directory. > Created "Move java and copy specific information in CompileJavaModules.gmk to module specific makefiles" https://bugs.openjdk.java.net/browse/JDK-8055192 > * I think the jdk/make/data directory could (and should) be separated > on module level, e.g. jdk/make/data/java.base/... etc. Or, maybe, that > the contents should even be moved out into like > src/java.base/share/data, since the contents of that directory in a > way is "source code" (only just not Java or native source code), and > not really part of the build system. > Created "Move jdk/make/data to module specific src dirs after source restructure" https://bugs.openjdk.java.net/browse/JDK-8055193 > *** Issues that was not introduced now, but should be fixed at some > point *** > > * In CopyCommon, the variables LIBDIR and INCLUDEDIR has very > generic-sounding name even though they are very specific. These names > are not new, but since the definition is now in a different file than > the uses of it, the badly chosen names makes it even harder to > understand the code. > > * The platform-specific correspondance, OPENJDK_TARGET_OS_INCLUDE = > $(INCLUDEDIR)/$(OPENJDK_TARGET_OS) is also bad from several > perspectives: It is a variant of INCLUDEDIR but it does not end in > DIR, it should not start with OPENJDK since it's not a global > variable, and finally it uses incorrect assignment (= instead of :=). > Added to general cleanup. > * In Awt2dLibraries.gmk, for libsplashscreen, the logic for the three > included external graphics libraries (gif, jpeg and png) is highly > asymmetric, which make it hard to understand. It seems likely that at > least the libjpeg handling is broken. > Created "Cleanup source and makefile logic for libsplashscreen and libjavajpeg after source restructure" https://bugs.openjdk.java.net/browse/JDK-8055194 > * The BUILD_LIBT2K is used only by the Oracle closed build, and the > definition should move to the closed sources. > Added to general cleanup /Erik From Alan.Bateman at oracle.com Fri Aug 15 10:42:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Aug 2014 11:42:15 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD47.2010204@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> Message-ID: <53EDE407.8010308@oracle.com> On 15/08/2014 11:13, Magnus Ihse Bursie wrote: > : > > In NetworkingLibraries.gmk: > > * There are multiple instances of this pattern: > ifneq ($(OPENJDK_TARGET_OS), solaris) > LIBNET_EXCLUDE_FILES += solaris_close.c > endif > The correct solution is to move the corresponding files away from the > "unix" directory and into more specific libraries (linux, solaris and > macosx) and include > these directories automatically depending on platform. This will allow > us to remove the exclude expression. > It's good that you giving these changes a thorough review. I agree that this and all the other $OS specific source that you have listed move and the EXCLUDES dropped. As I said in the previous reply then this is not necessary for this initial push. Instead the intention was to establish the new layout and for each area to gradually move any remaining Solaris, Linux and OS X sources from src/$MODULE/unix to src/$MODULE/$OS. It does mean that about 1% of the source files will need to move again once the changes are in jdk9/dev but I don't expect this to be disruptive. -Alan. From erik.joelsson at oracle.com Fri Aug 15 13:17:57 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 15:17:57 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE02EB.5060508@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EE02EB.5060508@oracle.com> Message-ID: <53EE0885.80401@oracle.com> On 2014-08-15 14:54, Maurizio Cimadamore wrote: > I'm looking at the langtools-related changes in build.xml; I what is > the degree of support available in the build.xml ant file for the > Jigsaw world? It seems to me that not all the target would function > and it also seems that some of the properties previously encoded in a > side property file (make/build.properties) have now been inlined in > the build.xml file itself, which seems problematic maintenance-wise. > Am I missing something? > As far as I know, build.xml has so far been supported by the langtools team themselves and all changes to the file in this patch have been made by them. Jon may have something to say? /Erik > Maurizio > > On 12/08/14 15:10, Chris Hegarty wrote: >> This is a review request for the Initial changes for JEP 201: Modular >> Source Code [1]. >> >> There are a number of individuals responsible for these changes. >> Some, possibly not all, are explicitly listed in the To section of >> this mail, and they will help address any comments arising from this >> review request. >> >> For the purposes of review, the actual source file moves have been >> omitted from the webrev below, with the exception of any source file >> that has a change to it?s actual content. The new location of the >> source files can be determined from JEP 201 [1] and JEP 200 "The >> Modular JDK" [2], or by browsing the staging forest [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8054834/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has >> been tentatively reserved for their integration. All comments are >> welcome, although given the nature of the changes then we might have >> to create separate issues in JIRA to address some of them later in >> jdk9/dev.. >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >> [3] http://hg.openjdk.java.net/jigsaw/stage > From Alan.Bateman at oracle.com Fri Aug 15 09:27:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 Aug 2014 10:27:11 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDC9A4.1030104@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDC9A4.1030104@oracle.com> Message-ID: <53EDD26F.5020400@oracle.com> On 15/08/2014 09:49, Magnus Ihse Bursie wrote: > These are indeed the single most significant changes to the build > system since the "new" build system was introduced. Indeed, some of us have been referring to this as the "new new build". As I recall there was a tail of issues and clean-ups for the JDK 8 "new build" and it will be the case here too. So if there aren't any blocking issues then I think the best thing is to work on those in jdk9/dev once the changes get there, otherwise I suspect we will iterate on this for a long time (and as I'm sure you can appreciate, it is painful to have to keep thousands of lines of make file changes in a side forest while the main line churns). > : > > * When the source code has moved, especially the native libraries, > most of the specific INCLUDE and EXCLUDE statements are, or should be, > unnecessary. Nevertheless, there are still several occasions of such > statements. In some cases, it seems like dead code that can (and > should) be removed. But in some cases, I believe it is an indication > that the source code has still not yet been moved to a suitable > location. I believe the end goal with this shuffling regarding native > library source code is that there should be a one-to-one > correspondance between compiled native library and source code > directory. This is now indeed the case for 99% of the libraries, but > there are still some exceptions. I assume you are referring to the rename of src/solaris to src/unix, something that was long overdue in the jdk repository. The intention is that eventually each area will go through their source files in src/$MODULE/unix and move any source files that are Linux, Solaris or OS X specific to the appropriate src/$MODULE/$OS tree. We've done it for a few libraries (such as libnio) so several EXCLUDE_FILES are already removed, the remainder of the exceptions will happen in time. > : > > * Finally, I'm also not entirely happy with the placement of > modules.xml in the root directory. Erik has told me that the intention > is that this file will ultimately be created dynamically at build > time, and when that happens, it will just be a build by-product which > can be placed elsewhere. If this is indeed the case, I can live with > some temporary extra cluttering of the top-level directory The top-level directory is intentional. It's not worth getting hung up on it because it is temporary (as noted in the JEP) and so will go away once we are further down the road on having a module system in JDK 9. -Alan. From maurizio.cimadamore at oracle.com Fri Aug 15 12:54:03 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Aug 2014 13:54:03 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EE02EB.5060508@oracle.com> I'm looking at the langtools-related changes in build.xml; I what is the degree of support available in the build.xml ant file for the Jigsaw world? It seems to me that not all the target would function and it also seems that some of the properties previously encoded in a side property file (make/build.properties) have now been inlined in the build.xml file itself, which seems problematic maintenance-wise. Am I missing something? Maurizio On 12/08/14 15:10, Chris Hegarty wrote: > This is a review request for the Initial changes for JEP 201: Modular Source Code [1]. > > There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request. > > For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it?s actual content. The new location of the source files can be determined from JEP 201 [1] and JEP 200 "The Modular JDK" [2], or by browsing the staging forest [3]. > > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ > > Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev.. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8051619 > [2] https://bugs.openjdk.java.net/browse/JDK-8051618 > [3] http://hg.openjdk.java.net/jigsaw/stage From mandy.chung at oracle.com Fri Aug 15 15:23:58 2014 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 15 Aug 2014 15:23:58 +0000 Subject: hg: jigsaw/stage/jdk: Correct the comment of the location of modules.xml Message-ID: <201408151523.s7FFNwnt023027@aojmv0008> Changeset: 5ca4c6a102a4 Author: mchung Date: 2014-08-15 07:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/stage/jdk/rev/5ca4c6a102a4 Correct the comment of the location of modules.xml ! make/ModulesXml.gmk From maurizio.cimadamore at oracle.com Fri Aug 15 15:13:26 2014 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 15 Aug 2014 16:13:26 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE0885.80401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EE02EB.5060508@oracle.com> <53EE0885.80401@oracle.com> Message-ID: <53EE2396.7090402@oracle.com> Quick update: I downloaded the jigsaw stage repo and tried the build. The biggest issue is that it requires Ant 1.9.4 (because of the MuliRootFileSet) to work, but after that is set up, everything works like before. My IntelliJ setup needed few cosmetic changes, to update the source roots, but nothing out of the ordinary. Overall, I'm pretty satisfied with it. Maurizio On 15/08/14 14:17, Erik Joelsson wrote: > > On 2014-08-15 14:54, Maurizio Cimadamore wrote: >> I'm looking at the langtools-related changes in build.xml; I what is >> the degree of support available in the build.xml ant file for the >> Jigsaw world? It seems to me that not all the target would function >> and it also seems that some of the properties previously encoded in a >> side property file (make/build.properties) have now been inlined in >> the build.xml file itself, which seems problematic maintenance-wise. >> Am I missing something? >> > As far as I know, build.xml has so far been supported by the langtools > team themselves and all changes to the file in this patch have been > made by them. Jon may have something to say? > > /Erik > >> Maurizio >> >> On 12/08/14 15:10, Chris Hegarty wrote: >>> This is a review request for the Initial changes for JEP 201: >>> Modular Source Code [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the To section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> For the purposes of review, the actual source file moves have been >>> omitted from the webrev below, with the exception of any source file >>> that has a change to it?s actual content. The new location of the >>> source files can be determined from JEP 201 [1] and JEP 200 "The >>> Modular JDK" [2], or by browsing the staging forest [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8054834/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev.. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >>> [3] http://hg.openjdk.java.net/jigsaw/stage >> > From mandy.chung at oracle.com Fri Aug 15 15:30:53 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Aug 2014 08:30:53 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDC9A4.1030104@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDC9A4.1030104@oracle.com> Message-ID: <53EE27AD.4010208@oracle.com> On 8/15/2014 1:49 AM, Magnus Ihse Bursie wrote: > *** Issues regarding modules.xml *** > > The new modules.xml and associated Java tools and make files seems > rather confusing to me. I understand some of the mysteries here are > due the the fact that the file has moved around during development. > Nevertheless, such historical relics should be removed when the code > is ready to be pushed to mainline. More concretely: > One thing to say about the modules.xml file is that it's not just for jdeps to use (verifying the module boundaries). It is an essential documentation to describe the module definition for the JDK [1] and will go away once the module system is in place and not all the modules are in the jdk repo and hence it's placed in the top level repo. > * ModulesXml.gmk referes to make/data/checkdeps/modules.xml. This file > does not exist. I believe this should be the $(TOPDIR)/modules.xml. > That reference in the comment that we missed to update when moving the file. Fixed. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8051618 From mandy.chung at oracle.com Fri Aug 15 15:41:11 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 15 Aug 2014 08:41:11 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> Message-ID: <53EE2A17.3000902@oracle.com> On 8/12/2014 7:10 AM, Chris Hegarty wrote: > Webrevs: > http://cr.openjdk.java.net/~chegar/8054834/00/ I reviewed the hotspot change. Looks good. One minor point: I think line 1230 can be removed when rt.jar is present. Mandy From omajid at redhat.com Fri Aug 15 15:55:09 2014 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Aug 2014 11:55:09 -0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53EB5BA3.2050504@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5BA3.2050504@oracle.com> Message-ID: <20140815155508.GF21356@redhat.com> Hi, * Alan Bateman [2014-08-13 08:36]: > Just to add to Chris and Erik's mails, I would encourage everyone that > pushes to jdk9/dev or the other jdk9 project integration forests to clone > and build jigsaw/stage and get familiar with the proposed layout, new build > targets, and the very different output emitted during the build. The changes > are arguably as significant as the transition in JDK 8 from the "old build" > to the "new build" so the more people taking the forest for a test drive the > better. If you maintain your our own own IDE project then you'll likely have > to adjust file paths so any issues encountered would be useful to hear about > too. Just one RFE for now: The new build would provide a detailed breakdown of the build time of each repo. With the 'new new build', all I see is an overall time: > ----- Build times ------- > Start 2014-08-15 10:59:27 > End 2014-08-15 11:17:53 > > 00:18:26 TOTAL > ------------------------- Will a detailed breakdown of the build times for each module make a return? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From erik.joelsson at oracle.com Fri Aug 15 15:58:24 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Aug 2014 17:58:24 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <20140815155508.GF21356@redhat.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5BA3.2050504@oracle.com> <20140815155508.GF21356@redhat.com> Message-ID: <53EE2E20.7040304@oracle.com> Hello Omair, No, as I tried to explain in my initial mail on this thread, since the modules are all compiled in parallel, and not sequentially like the current build does with the repositories, it doesn't make much sense timing each module. The numbers would be meaningless. /Erik On 2014-08-15 17:55, Omair Majid wrote: > Hi, > > * Alan Bateman [2014-08-13 08:36]: >> Just to add to Chris and Erik's mails, I would encourage everyone that >> pushes to jdk9/dev or the other jdk9 project integration forests to clone >> and build jigsaw/stage and get familiar with the proposed layout, new build >> targets, and the very different output emitted during the build. The changes >> are arguably as significant as the transition in JDK 8 from the "old build" >> to the "new build" so the more people taking the forest for a test drive the >> better. If you maintain your our own own IDE project then you'll likely have >> to adjust file paths so any issues encountered would be useful to hear about >> too. > Just one RFE for now: > > The new build would provide a detailed breakdown of the build time of > each repo. With the 'new new build', all I see is an overall time: > >> ----- Build times ------- >> Start 2014-08-15 10:59:27 >> End 2014-08-15 11:17:53 >> >> 00:18:26 TOTAL >> ------------------------- > Will a detailed breakdown of the build times for each module make a > return? > > Thanks, > Omair > From chris.hegarty at oracle.com Fri Aug 15 16:44:27 2014 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 15 Aug 2014 16:44:27 +0000 Subject: hg: jigsaw/stage/hotspot: Update expand_entries_to_path comment Message-ID: <201408151644.s7FGiSUS008227@aojmv0008> Changeset: 091d5820c70d Author: chegar Date: 2014-08-15 17:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/stage/hotspot/rev/091d5820c70d Update expand_entries_to_path comment ! src/share/vm/runtime/os.cpp From jonathan.gibbons at oracle.com Fri Aug 15 17:52:32 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 15 Aug 2014 10:52:32 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE0885.80401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EE02EB.5060508@oracle.com> <53EE0885.80401@oracle.com> Message-ID: <53EE48E0.7020004@oracle.com> Yes, we (the LangTools team) are on our own for this file. Jan Lahoda did some work to update the build.xml file for us. At some point we may want to do more surgery on this file, but that is a discussion for the LangTools team to have. -- Jon On 08/15/2014 06:17 AM, Erik Joelsson wrote: > > On 2014-08-15 14:54, Maurizio Cimadamore wrote: >> I'm looking at the langtools-related changes in build.xml; I what is >> the degree of support available in the build.xml ant file for the >> Jigsaw world? It seems to me that not all the target would function >> and it also seems that some of the properties previously encoded in a >> side property file (make/build.properties) have now been inlined in >> the build.xml file itself, which seems problematic maintenance-wise. >> Am I missing something? >> > As far as I know, build.xml has so far been supported by the langtools > team themselves and all changes to the file in this patch have been > made by them. Jon may have something to say? > > /Erik > >> Maurizio >> >> On 12/08/14 15:10, Chris Hegarty wrote: >>> This is a review request for the Initial changes for JEP 201: >>> Modular Source Code [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the To section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> For the purposes of review, the actual source file moves have been >>> omitted from the webrev below, with the exception of any source file >>> that has a change to it?s actual content. The new location of the >>> source files can be determined from JEP 201 [1] and JEP 200 "The >>> Modular JDK" [2], or by browsing the staging forest [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8054834/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev.. >>> >>> -Chris. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618 >>> [3] http://hg.openjdk.java.net/jigsaw/stage >> > From naoto.sato at oracle.com Fri Aug 15 18:00:15 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 15 Aug 2014 11:00:15 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD59.1000502@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD59.1000502@oracle.com> Message-ID: <53EE4AAF.1040801@oracle.com> On 8/15/14, 3:13 AM, Erik Joelsson wrote: >> * GensrcCLDR.gmk is not ideal. It generates source for multiple >> modules, and the output is separated afterwards. Fixing this will >> probably means some modification to the java helper tools. >> > While I think it would be good to split this in principle, I'm not sure > it's worth pursuing. The english locale is in the base module and the > others are in a different module. I would leave this as it is for now. I agree with Erik, as I will be working on this later. So let's leave it as is. Naoto From magnus.ihse.bursie at oracle.com Mon Aug 18 13:47:27 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Aug 2014 15:47:27 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD47.2010204@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> Message-ID: <53F203EF.9070907@oracle.com> On 2014-08-15 12:13, Magnus Ihse Bursie wrote: > Here are the more concrete specification of this, for all files except > Awt2dLibraries.gmk, which I'll return to. And here is the jury's verdict on Awt2dLibraries.gmk. :-) libjavajpeg: One of these are not needed: LIBJAVAJPEG_SRC := $(JDK_TOPDIR)/src/java.desktop/share/native/libjavajpeg LIBJAVAJPEG_SRC += $(JDK_TOPDIR)/src/java.desktop/share/native/libjavajpeg libfontmanager: EXCLUDE_FILES := $(LIBFONTMANAGER_EXCLUDE_FILES) \ AccelGlyphCache.c, \ The file AccelGlyphCache.c resides in src/java.desktop/share/native/common/sun/font, which is not included in the source dirs, so the exclude can be safely removed. The following stanza can be removed: ifeq ($(OPENJDK_TARGET_OS), windows) LIBFONTMANAGER_EXCLUDE_FILES += X11FontScaler.c \ X11TextRenderer.c LIBFONTMANAGER_OPTIMIZATION := HIGHEST LIBFONTMANAGER_CFLAGS += -I$(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libawt/sun/windows else ifeq ($(OPENJDK_TARGET_OS), macosx) LIBFONTMANAGER_EXCLUDE_FILES += X11FontScaler.c \ X11TextRenderer.c \ fontpath.c \ lcdglyph.c else LIBFONTMANAGER_EXCLUDE_FILES += fontpath.c \ lcdglyph.c endif The X11*.c files are in the unix directory and the fontpath/lcdglyph files are in the windows directory, so they need to explicit excludes. However, the X11 files stills needs to be excluded on macosx. On the other hand, these two are all that exists in $(JDK_TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS_API_DIR)/native/libfontmanager, so we can just exclude that entire directory, or only add it unless we're building for macosx. libkcms: EXCLUDE_FILES := $(BUILD_LIBKCMS_EXCLUDE_FILES), is not needed, since BUILD_LIBKCMS_EXCLUDE_FILES is no longer defined. libjawt: INCLUDE_FILES := $(LIBJAWT_INCLUDE_FILES), and INCLUDE_FILES := $(JAWT_FILES), are not needed, since LIBJAWT_INCLUDE_FILES and JAWT_FILES are not defined. libawt_lwawt: INCLUDE_FILES := $(LIBAWT_LWAWT_FILES), is not needed, since LIBAWT_LWAWT_FILES is not defined. libt2k: According to EXCLUDE_FILES := t2k/orion.c, the file orion.c is never used, so it should be removed instead. Also, the entire library definition should move to closed code. liblcms: The include file picking of LCMS.c would not be needed if the upstream lcms source code were moved into a separate subdirectory of liblcms. libjavajpeg: If the upstream IJG jpeg library were moved into a subdirectory, the explicit includes of imageIOJPEG.c and jpegdecoder.c would not be needed. libmlib_image / libmlib_image_v: The files used for libmlib_image and libmlib_image_v are somewhat chaotic. Four directories are used, in different ways: 1) SHARE-LIB: java.desktop/share/native/libmlib_image 2) UNIX-LIB: java.desktop/unix/native/libmlib_image 3) SHARE-COMMON: java.desktop/share/native/common/sun/awt/medialib 4) UNIX-COMMON: java.desktop/unix/native/common/sun/awt/medialib They are used to build three different libraries: A) libmlib_image. Built on all platforms. Includes SHARE-LIB and SHARE-COMMON B) libmlib_image_v. Built on solaris-sparc only. Includes a subset (using excludes) of SHARE-LIB, UNIX-LIB, SHARE-COMMON and UNIX-COMMON. C) libawt. Uses SHARE-COMMON and UNIX-COMMON, but only when building for solaris-sparc. Maybe this complexity is not needed, but even if it is, there are a number of things that could help improve the situation. * The UNIX-LIB and UNIX-COMMON paths are only used on solaris and should move from "unix" to "solaris". * The SHARE-COMMON and UNIX-COMMON paths should move away from the common/sun/awt directories, since they need to be explicitely excluded by all other users of the common/sun/awt directories, e.g. to common/mlib_image. This would reduce the number of excludes elsewhere significantly. * The code in UNIX-LIB is used to build libmlib_image_v, not libmlib_image, and should thus be renamed so. * The code in SHARE-LIB that is actually shared by libmlib_image and libmlib_image_v should preferably be moved to java.desktop/share/native/common. I don't have any good suggestions though on how this should be handled so as not to collide with the different shared subset found in SHARE-COMMON. These files include basically the mlib_Image*.c files. It also includes the file mlib_c_ImageThresh1_U8.c, while excluding all other mlib_c_*.c. This almost looks like a mistake. * A number of files are hardcoded to always be excluded. These should be removed instead. These files are: In java.desktop/share/native/libmlib_image: mlib_c_ImageBlendTable.c In java.desktop/unix/native/libmlib_image: mlib_v_ImageChannelExtract.c \ mlib_v_ImageChannelExtract_f.c \ mlib_v_ImageChannelInsert_34.c \ mlib_v_ImageChannelInsert.c \ mlib_v_ImageConvIndex3_8_16nw.c \ mlib_v_ImageConvIndex3_8_8nw.c \ mlib_v_ImageCopy.c \ mlib_v_ImageCopy_blk.s \ libawt et al: The relation between libawt, libawt_headless, libjawt, libawt_xawt and libawt_lwawt are hairy enough to make my brain curl up. I believe there are simplifications to be made but I gave up trying to figure them out. /Magnus From magnus.ihse.bursie at oracle.com Mon Aug 18 13:56:45 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 18 Aug 2014 15:56:45 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDDD47.2010204@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> Message-ID: <53F2061D.4000104@oracle.com> I also found these random notes scribbled down that I forgot to add to the previous mails: * In CoreLibraries.gmk, we have dead code defining BUILD_LIBVERIFY_SRC which is not used anymore. * In Tools.gmk, I notice that we copy the files $(JDK_TOPDIR)/src/java.desktop/share/classes/javax/swing/plaf/nimbus/%.template, but if they are only used by our build tools, they should probably live in make/data somewhere. * In SoundLibraries.gmk, the source code splitting is not complete. The directory libjsound is used to build not only libjsound but libjsoundalsa and libjsoundds, and thus needs a complex include/exclude system like before. * In CompileDemos, we create demo/jpda/src.zip. This includes source code from src/demo/share (expected), but also from jdk/src/jdk.jdi/share/classes/com/sun/tools/example/... (unexpected!). Should example code really live in the jdk.jdi package, and not in src/demo? /Magnus From anthony.petrov at oracle.com Mon Aug 18 14:15:08 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 18 Aug 2014 18:15:08 +0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53F203EF.9070907@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> Message-ID: <53F20A6C.7090805@oracle.com> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: > libawt et al: > The relation between libawt, libawt_headless, libjawt, libawt_xawt > and libawt_lwawt are hairy enough to make my brain curl up. I believe > there are simplifications to be made but I gave up trying to figure them > out. libawt contains code that is shared between all AWT lib implementations. Depending on what mode/toolkit is requested, it loads a specific variant of the awt native library, such as: - libawt_headless - headless AWT implementation. - libawt_xawt - XToolkit implementation (uses X11 for GUI) - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) Historically, we were able to choose between lwawt and xawt on Mac in the past, but we no longer support or even build xawt on Mac. Also, in the past there was MToolkit (which used Motif for GUI). Again, we no longer support this toolkit. So, currently we always use xawt on Linux/Solaris and lwawt on Mac. But since we still need to choose between a real toolkit and a headless toolkit, we need the common libawt library. libjawt is a helper library that implements JAWT API and is loaded by applications that use the JAWT interface which allows them to get direct access to the native AWT drawing surface and use native APIs (e.g. OpenGL) to draw on the surface. This library isn't needed for regular AWT/Swing applications. So I'm not sure if the current set of AWT libraries could be simplified any further. Hope this helps. -- best regards, Anthony From david.holmes at oracle.com Tue Aug 19 02:49:19 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Aug 2014 12:49:19 +1000 Subject: RFR [9] Modular Source Code In-Reply-To: <53EE2E20.7040304@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EB5BA3.2050504@oracle.com> <20140815155508.GF21356@redhat.com> <53EE2E20.7040304@oracle.com> Message-ID: <53F2BB2F.1010808@oracle.com> On 16/08/2014 1:58 AM, Erik Joelsson wrote: > Hello Omair, > > No, as I tried to explain in my initial mail on this thread, since the > modules are all compiled in parallel, and not sequentially like the > current build does with the repositories, it doesn't make much sense > timing each module. The numbers would be meaningless. It would still be nice to see the different times for hotspot, images, any other targets, plus the "everything Java" component. Seeing where our build time gets used up is important to some of us. Thanks, David ----- > /Erik > > On 2014-08-15 17:55, Omair Majid wrote: >> Hi, >> >> * Alan Bateman [2014-08-13 08:36]: >>> Just to add to Chris and Erik's mails, I would encourage everyone that >>> pushes to jdk9/dev or the other jdk9 project integration forests to >>> clone >>> and build jigsaw/stage and get familiar with the proposed layout, new >>> build >>> targets, and the very different output emitted during the build. The >>> changes >>> are arguably as significant as the transition in JDK 8 from the "old >>> build" >>> to the "new build" so the more people taking the forest for a test >>> drive the >>> better. If you maintain your our own own IDE project then you'll >>> likely have >>> to adjust file paths so any issues encountered would be useful to >>> hear about >>> too. >> Just one RFE for now: >> >> The new build would provide a detailed breakdown of the build time of >> each repo. With the 'new new build', all I see is an overall time: >> >>> ----- Build times ------- >>> Start 2014-08-15 10:59:27 >>> End 2014-08-15 11:17:53 >>> >>> 00:18:26 TOTAL >>> ------------------------- >> Will a detailed breakdown of the build times for each module make a >> return? >> >> Thanks, >> Omair >> > From philip.race at oracle.com Tue Aug 19 23:09:09 2014 From: philip.race at oracle.com (Phil Race) Date: Tue, 19 Aug 2014 16:09:09 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53F20A6C.7090805@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> Message-ID: <53F3D915.5030208@oracle.com> On a related note I am scratching my head about why some files destined to be compiled into libawt or libawt_xawt go into a directory called 'common'. Eg OpenGL sources are in common but aren't common to all libs or even to all awt libs, since they would go into libawt on windows and libawt_xawt on unix and not at all into libawt_headless. 'common 'might (guessing here) have started out as place to put interface header files shared between libs but maybe got adopted for other uses ? -phil. On 08/18/2014 07:15 AM, Anthony Petrov wrote: > On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: >> libawt et al: >> The relation between libawt, libawt_headless, libjawt, libawt_xawt >> and libawt_lwawt are hairy enough to make my brain curl up. I believe >> there are simplifications to be made but I gave up trying to figure them >> out. > > libawt contains code that is shared between all AWT lib > implementations. Depending on what mode/toolkit is requested, it loads > a specific variant of the awt native library, such as: > > - libawt_headless - headless AWT implementation. > - libawt_xawt - XToolkit implementation (uses X11 for GUI) > - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) > > Historically, we were able to choose between lwawt and xawt on Mac in > the past, but we no longer support or even build xawt on Mac. Also, in > the past there was MToolkit (which used Motif for GUI). Again, we no > longer support this toolkit. So, currently we always use xawt on > Linux/Solaris and lwawt on Mac. But since we still need to choose > between a real toolkit and a headless toolkit, we need the common > libawt library. > > libjawt is a helper library that implements JAWT API and is loaded by > applications that use the JAWT interface which allows them to get > direct access to the native AWT drawing surface and use native APIs > (e.g. OpenGL) to draw on the surface. This library isn't needed for > regular AWT/Swing applications. > > So I'm not sure if the current set of AWT libraries could be > simplified any further. > > Hope this helps. > > -- > best regards, > Anthony From erik.joelsson at oracle.com Wed Aug 20 08:37:09 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Aug 2014 10:37:09 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53F3D915.5030208@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F3D915.5030208@oracle.com> Message-ID: <53F45E35.7030809@oracle.com> Hello, The basic rule for the new source layout is that for each library, there is a directory where all sources for that library go. This was hard to apply to libawt and friends since as you say, some files go in libawt on windows and libawt_xawt on linux and solaris. For now, I put those in common for lack of a better place. /Erik On 2014-08-20 01:09, Phil Race wrote: > On a related note I am scratching my head about why some files > destined to be compiled into libawt or libawt_xawt go into a directory > called 'common'. > Eg OpenGL sources are in common but aren't common to all libs > or even to all awt libs, since they would go into libawt on windows > and libawt_xawt on unix and not at all into libawt_headless. > > 'common 'might (guessing here) have started out as place to put > interface > header files shared between libs but maybe got adopted for other uses ? > > -phil. > > > > On 08/18/2014 07:15 AM, Anthony Petrov wrote: >> On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: >>> libawt et al: >>> The relation between libawt, libawt_headless, libjawt, libawt_xawt >>> and libawt_lwawt are hairy enough to make my brain curl up. I believe >>> there are simplifications to be made but I gave up trying to figure >>> them >>> out. >> >> libawt contains code that is shared between all AWT lib >> implementations. Depending on what mode/toolkit is requested, it >> loads a specific variant of the awt native library, such as: >> >> - libawt_headless - headless AWT implementation. >> - libawt_xawt - XToolkit implementation (uses X11 for GUI) >> - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) >> >> Historically, we were able to choose between lwawt and xawt on Mac in >> the past, but we no longer support or even build xawt on Mac. Also, >> in the past there was MToolkit (which used Motif for GUI). Again, we >> no longer support this toolkit. So, currently we always use xawt on >> Linux/Solaris and lwawt on Mac. But since we still need to choose >> between a real toolkit and a headless toolkit, we need the common >> libawt library. >> >> libjawt is a helper library that implements JAWT API and is loaded by >> applications that use the JAWT interface which allows them to get >> direct access to the native AWT drawing surface and use native APIs >> (e.g. OpenGL) to draw on the surface. This library isn't needed for >> regular AWT/Swing applications. >> >> So I'm not sure if the current set of AWT libraries could be >> simplified any further. >> >> Hope this helps. >> >> -- >> best regards, >> Anthony > From magnus.ihse.bursie at oracle.com Wed Aug 20 09:14:10 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Aug 2014 11:14:10 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53F20A6C.7090805@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> Message-ID: <53F466E2.7070501@oracle.com> On 2014-08-18 16:15, Anthony Petrov wrote: > On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote: >> libawt et al: >> The relation between libawt, libawt_headless, libjawt, libawt_xawt >> and libawt_lwawt are hairy enough to make my brain curl up. I believe >> there are simplifications to be made but I gave up trying to figure them >> out. > > libawt contains code that is shared between all AWT lib > implementations. Depending on what mode/toolkit is requested, it loads > a specific variant of the awt native library, such as: > > - libawt_headless - headless AWT implementation. > - libawt_xawt - XToolkit implementation (uses X11 for GUI) > - libawt_lwawt - CToolkit implementation (uses Cocoa for GUI) > > Historically, we were able to choose between lwawt and xawt on Mac in > the past, but we no longer support or even build xawt on Mac. Also, in > the past there was MToolkit (which used Motif for GUI). Again, we no > longer support this toolkit. So, currently we always use xawt on > Linux/Solaris and lwawt on Mac. But since we still need to choose > between a real toolkit and a headless toolkit, we need the common > libawt library. > > libjawt is a helper library that implements JAWT API and is loaded by > applications that use the JAWT interface which allows them to get > direct access to the native AWT drawing surface and use native APIs > (e.g. OpenGL) to draw on the surface. This library isn't needed for > regular AWT/Swing applications. > > So I'm not sure if the current set of AWT libraries could be > simplified any further. > > Hope this helps. Thank you for the clarification, it was very helpful! While the set of AWT libraries probably cannot be simplified as you say, my gut feeling is still that the current layout of files on disk does not optimally match the actual libraries we build. Armed with the help of your description, I'll look into them once again and see if I can make that statement more concrete. /Magnus From magnus.ihse.bursie at oracle.com Wed Aug 20 10:14:53 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 20 Aug 2014 12:14:53 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53EDCA54.2090107@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> Message-ID: <53F4751D.8020006@oracle.com> On 2014-08-15 10:52, Magnus Ihse Bursie wrote: > These are indeed the single most significant changes to the build > system since the "new" build system was introduced. > > Here follows a partial review of the changes in the jdk repo. Even > though it's long, I'm not done. ;-) While this has turned into a post-factum code review, I continue unabashed. :-) In langtooks/make/GensrcLangtools.gmk: The fix from 8026773 was inadvertently reverted in the following line: $(ECHO) Compiling $(words $(PROPSOURCES) v1 v2 v3) properties into resource bundles This might implicate a merge error at some point, so maybe the file should be more thoroughly studied if there are more parts of the fix for 8026773 that has been lost. In make/common/JavaCompilation: The following stanza is incorrectly indented: ifneq (,$$($1_ALL_COPIES)) # Yep, there are files to be copied! $1_ALL_COPY_TARGETS:= $$(foreach i,$$($1_ALL_COPIES),$$(eval $$(call add_file_to_copy,$1,$$i))) # Now we can depend on $$($1_ALL_COPY_TARGETS) to copy all files! endif In make/CompileJavaModules: A typo: ## Service types are required in the classpath when compiing module-info In make/common/support: The ListPathsSafely support files have changed, replacing the first three strings with: s|X01|share/classes|g s|X02|internal|g s|X03|com/sun/org|g While the old replacements did not do anything useful ("shortening" three-letter strings into another three-letter string), this change breaks the old pattern of having the strings sorted in length order. At first, I thought it was just a matter of style (I still think this is a matter of style, and that it should be fixed) but then I realized there also was a reason for this: The strings are matched from longest to shortest (given, of course, that the list is correctly ordered) and thus the string "com/sun" will match and be replaced by X07 before the new string "com/sun/org" will be given the chance. In corba/make and langtools/make: For clarity and consistency, the file corba/make/CompileCorba.gmk should be renamed CompileInterimCorba.gmk and langtools/make/CompileInterim.gmk should be renamed CompileInterimLangtools.gmk. In make/Main.gmk: I'm not entirely happy with the way the following dependencies are encoded: # Declare dependencies from all other -lib to java.base-lib $(foreach t, $(filter-out java.base-libs, $(LIB_TARGETS)), \ $(eval $t: java.base-libs)) # Declare the special case dependency for jdk.deploy.osx where libosx # links against libosxapp. jdk.deploy.osx-libs: java.desktop-libs # This dependency needs to be explicitly declared. jdk.jdi-gensrc generates a # header file used by jdk.jdwp libs. jdk.jdwp-libs: jdk.jdi-gensrc I have discussed this off-line with Erik and concluded that this probably has to do for now, but I believe there should be a better way of describing this kinds of relationships. Alright, now I'm done code reviewing! :-) Lots of kudos to Erik for managing to re-create the build system for the modular source code with such high quality. /Magnus From omajid at redhat.com Tue Aug 19 20:28:21 2014 From: omajid at redhat.com (Omair Majid) Date: Tue, 19 Aug 2014 16:28:21 -0400 Subject: RFR [9] Modular Source Code In-Reply-To: <53F203EF.9070907@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> Message-ID: <20140819202821.GN17998@redhat.com> * Magnus Ihse Bursie [2014-08-18 09:48]: > liblcms: > The include file picking of LCMS.c would not be needed if the upstream > lcms source code were moved into a separate subdirectory of liblcms. > > libjavajpeg: > If the upstream IJG jpeg library were moved into a subdirectory, the > explicit includes of imageIOJPEG.c and jpegdecoder.c would not be needed. Independent of the modular source code changes, I would like to see this change. But there were concerns raised in the past about this: http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012027.html Maybe now is the right time to clean this up, once and for all? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From Alan.Bateman at oracle.com Sat Aug 23 18:35:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Aug 2014 19:35:54 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53F2061D.4000104@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F2061D.4000104@oracle.com> Message-ID: <53F8DF0A.3070807@oracle.com> On 18/08/2014 14:56, Magnus Ihse Bursie wrote: > : > > * In CompileDemos, we create demo/jpda/src.zip. This includes source > code from src/demo/share (expected), but also from > jdk/src/jdk.jdi/share/classes/com/sun/tools/example/... (unexpected!). > Should example code really live in the jdk.jdi package, and not in > src/demo? The issue is that the sources to jdb are used for two purposes. This should resolve itself once the JPDA demo is dropped, see JDK-8043981. -Alan. From magnus.ihse.bursie at oracle.com Mon Aug 25 09:14:04 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 25 Aug 2014 11:14:04 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53F466E2.7070501@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> Message-ID: <53FAFE5C.2060600@oracle.com> On 2014-08-20 11:14, Magnus Ihse Bursie wrote: > On 2014-08-18 16:15, Anthony Petrov wrote: >> So I'm not sure if the current set of AWT libraries could be >> simplified any further. >> >> Hope this helps. > > Thank you for the clarification, it was very helpful! > > While the set of AWT libraries probably cannot be simplified as you > say, my gut feeling is still that the current layout of files on disk > does not optimally match the actual libraries we build. Armed with the > help of your description, I'll look into them once again and see if I > can make that statement more concrete. This is my suggestions based on what I found when trying to remove the last unnecessary entanglement. Note that all paths are relative to the java.desktop module, and that I have at this stage only looked at compiled sources (*.c), not header files. * The following files are in the windows directory tree, but are explicitly excluded on Windows. Thus they will never be built, and should be removed instead: ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c ./windows/native/libawt/sun/windows/WBufferStrategy.cpp * The following file is in the share directory tree, but is only used on Windows. It should be moved to the corresponding windows directory instead: ./share/native/libawt/sun/java2d/ShaderList.c * The following directory is in the unix directory tree, but is only used on Solaris. It should be moved to the corresponding solaris directory instead: ./unix/native/libawt/sun/java2d/loops * The directory ./unix/native/common/sun/awt contains five more or less unrelated .c files. Three of them are only used in libawt_xawt, and should be moved there: ./unix/native/common/sun/awt/awt_Font.c ./unix/native/common/sun/awt/fontpath.c ./unix/native/common/sun/awt/X11Color.c Of the remaining two CUPSfuncs.c seems correctly placed, since it is shared between libawt_xawt and libawt_lwawt. However, I'm wondering about initIDs.c. It is compiled in libawt as well as libawt_xawt, but when I checked some random functions, they are exported (via the mapfile) for libawt only. So I believe it is a mistake to include it in libawt_xawt, and that it should be moved to the libawt directory. This will need verification from someone on the AWT team. * The directory ./unix/native/libjawt is included in libawt_xawt (and in libjawt, of course). This seems suspicious to me. There is just a single file with a single function, JAWT_GetAWT(), which is exported in libjawt (via a mapfile), but not in libawt_xawt. I believe it is a mistake to include it in libawt_xawt. This will need verification from someone on the AWT team. * All of the awt-related directories (libawt_* and common) include an unnecessary extra layer, the "sun" directory. It is not needed anymore, and just makes all paths extra long. I suggest that we remove that layer and move everything up one step. * The makefiles include too specific directories. Instead of including e.g. ./*/native/common/sun/java2d/opengl and ./*/native/common/sun/java2d/x11, we should just include ./*/native/common/sun/java2d. This level corresponds to a logical grouping of the source code, and not the directory structure in that grouping. * The file ./windows/native/common/awt_makecube.cpp is a bit strange. It is not a shared file; instead it's a stand-alone binary with a main() function. It is not compiled by any makefile targets. If this file is actually used, I suggest moving it to a better location (windows/native/launchers?), and starting to compile it with the build. (Stuff that's not built regularly is doomed to bit rot.) It if is not used, I suggest we remove it. * And as I stated before, the medlialib directories are typically not used by libawt and friends. It is used by libmlib_image and libmlib_image_v, and should move away from the awt directory. /Magnus From david.lloyd at redhat.com Tue Aug 26 13:22:56 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 26 Aug 2014 08:22:56 -0500 Subject: JEP 200: The Modular JDK In-Reply-To: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> Message-ID: <53FC8A30.9010506@redhat.com> On 8/5/14, 11:49 AM, mark.reinhold at oracle.com wrote: > New JEP Candidate: http://openjdk.java.net/jeps/200 A few minor comments: We've found that when it comes to deciding when to or when not to re-export an API dependency of another API module, the criteria comes down to whether the importing API makes use of the imported API's types directly in its API classes. If not, then re-exporting is generally counter-productive. By this standard, there may be more re-exporting going on than strictly necessary or desirable in this document. As a matter of principle I'm generally opposed to exporting specific module packages only to specific other modules. I think this indicates that a module split is required. I'm guessing that at the root of this problem is an attempt to avoid circular dependencies during compilation, but I would rather that issue not be punted to the runtime. -- - DML From Alan.Bateman at oracle.com Tue Aug 26 14:05:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Aug 2014 15:05:19 +0100 Subject: JEP 200: The Modular JDK In-Reply-To: <53FC8A30.9010506@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> <53FC8A30.9010506@redhat.com> Message-ID: <53FC941F.5040306@oracle.com> On 26/08/2014 14:22, David M. Lloyd wrote: > > We've found that when it comes to deciding when to or when not to > re-export an API dependency of another API module, the criteria comes > down to whether the importing API makes use of the imported API's > types directly in its API classes. If not, then re-exporting is > generally counter-productive. By this standard, there may be more > re-exporting going on than strictly necessary or desirable in this > document. I think you are touching on design principle #3 in the JEP. Do you have any specific examples where you see needless re-exporting (in the graph then it's the darker edges)? > > As a matter of principle I'm generally opposed to exporting specific > module packages only to specific other modules. I think this > indicates that a module split is required. I'm guessing that at the > root of this problem is an attempt to avoid circular dependencies > during compilation, but I would rather that issue not be punted to the > runtime. For legacy code bases such as a JDK then this is useful and important. There are some areas that are more tightly coupled that would be if starting afresh. The most obvious example of where you might export something to only specific modules is sun.misc. It's JDK-internal but used in many areas of the JDK. -Alan. From niftiness at gmail.com Wed Aug 27 07:35:21 2014 From: niftiness at gmail.com (Tim Boudreau) Date: Wed, 27 Aug 2014 03:35:21 -0400 Subject: JEP 200: The Modular JDK In-Reply-To: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> Message-ID: A couple of minor comments: 1. The "java." vs. "jdk." semantics are, long-term, probably doomed. That is, it's fairly inevitable that some "jdk." module will, sooner or later, grow a public API, probably starting from a "friend" API. For example, NetBeans tried a convention of "org.netbeans.api.*" for modules with public API, and "org.netbeans.modules.*" for non-api stuff, but today you'll find plenty of modules that have public APIs yet are named "org.netbeans.modules.*" because their author couldn't predict a priori that there would eventually be an API. When you reach the point of actually declaring it to be public API, there will be existing code that already uses it under the name "jdk.foo", which will break if it is changed. Yes, you could require that there be a "java." module which contains no code but simply exports the packages of "jdk.foo", but that starts to get pretty silly. If you have a mechanism by which a module can restrict the list of things that can depend on it, then the naming convention adds nothing except a message that says "you can't depend on this" (which is already obvious by the fact that, well, you can't). That has a smidgen of value, but if there's a good chance the naming convention is going to break down, or not be ruthlessly adhered to for eternity, I'm not sure it's worth it. It's easy to carve a snapshot in time of something up into modules; doing that in a way that's going to evolve sanely is harder, and the more semantics are put into things, the more ways there are for it to go wrong. 2. "java.base" smells like an antipattern - but it's not clear to me if it's just an aggregator of some other dependencies, or contains stuff of its own as well, and if so, what. If it's an aggregator, what is gained by not having the things that need what it aggregates just have direct dependencies? My guess is that those things only export APIs to java.base, and then it re-exports those. Maybe I'm misunderstanding what it is, but my experience is that sooner or later someone wants just one of the things you're exporting, but is forced to take all of them (example: org.openide.util in NetBeans is a module most other modules wind up depending on; it contains localization-related stuff, plus a grab bag of other things from fiddling with Swing Actions to thread pools to utilities for identifying the OS; it is common to need maybe one of these things, usually localization; it would be better to have that factored as a separate module). Usually I've seen this pattern when a module has been split apart into smaller things, as a way of providing backward compatibility for code that was written when it was monolithic - i.e. you wind up with this pattern not because it's particularly good, but because it was impossible to predict the future when it was created. Starting out in that place seems odd. Basically what I'm saying is, given the choice of more or less granular dependencies, more granular causes fewer headaches, long-term. But as I said, it's not clear to me precisely what java.base is, so I might just be misunderstanding that. 3. XML, really? Most of our industry has gotten over the, er, unhealthy fetish for XML that was common some years ago. If it's just as placeholder documents, okay, but it's not the cheapest thing in the world to parse, and there's nothing in the example documents that has, or even has the potential to have, a deep tree-like substructure that might justify it. -Tim -- http://timboudreau.com From niftiness at gmail.com Wed Aug 27 07:39:54 2014 From: niftiness at gmail.com (Tim Boudreau) Date: Wed, 27 Aug 2014 03:39:54 -0400 Subject: JEP 200: The Modular JDK In-Reply-To: References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> Message-ID: On Wed, Aug 27, 2014 at 3:35 AM, Tim Boudreau wrote: > probably starting from a "friend" API. For example, NetBeans tried a > convention of "org.netbeans.api.*" for modules with public API, and > "org.netbeans.modules.*" for non-api stuff, but today you'll find plenty of > modules that have public APIs yet are named "org.netbeans.modules.*" > because their author couldn't predict a priori that there would eventually > be an API. > To be fair, this problem exists in NetBeans because a module is the unit that can be updated, so you can't rename a module a user might already have or they can wind up with two versions of the same package trying to coexist, with potentially nasty consequences. That may be a non-issue here. -Tim From Alan.Bateman at oracle.com Wed Aug 27 08:41:15 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Aug 2014 09:41:15 +0100 Subject: JEP 200: The Modular JDK In-Reply-To: References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> Message-ID: <53FD99AB.8060109@oracle.com> On 27/08/2014 08:35, Tim Boudreau wrote: > A couple of minor comments: > > 1. The "java." vs. "jdk." semantics are, long-term, probably doomed. That > is, it's fairly inevitable that some "jdk." module will, sooner or later, > grow a public API, probably starting from a "friend" API. jdk.* modules can export APIs too. In the tabular summary (linked from the module-graph definition section, might not be obvious), then you'll see several examples where JDK-specific APIs are exported. Clearly anyone looking to promote a JDK-specific API to a Java SE API would need to take compatibility and migration into account. The Java Debug Interface (com.sun.jdi.** ) is a good example of a supported API used by debuggers and tools but where it never seem to be worth the disruption to define a JCP/standard API. > > 2. "java.base" smells like an antipattern - but it's not clear to me if > it's just an aggregator of some other dependencies, or contains stuff of > its own as well, and if so, what. The java.base module is where the core APIs live, it's not an aggregator and does not depend on anything. It is close to the smallest set of API packages without breaking things by omitting classes or sub-setting packages. The tabular summary page has the details. > > 3. XML, really? Most of our industry has gotten over the, er, unhealthy > fetish for XML that was common some years ago. If it's just as placeholder > documents, okay, but it's not the cheapest thing in the world to parse, and > there's nothing in the example documents that has, or even has the > potential to have, a deep tree-like substructure that might justify it. > As the JEP says, the document is just temporary until a module system is in place. For now it is checked into the top-level repo in the jdk9 forest and used to check module boundaries at JDK build time. You won't see it in the JDK/JRE images. -Alan From Alan.Bateman at oracle.com Wed Aug 27 11:17:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Aug 2014 12:17:27 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53FDB999.3030001@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> Message-ID: <53FDBE47.3000701@oracle.com> On 27/08/2014 11:57, Anthony Petrov wrote: > Hi Magnus, > > Those look like reasonable suggestions. Could you please file separate > bugs for each of these issues? Also, please note that most of them > belong to 2D, not AWT (e.g. the font-, color-, d3d-, and > opengl-related files) even though they're compiled into the awt native > libraries. > > -- > best regards, > Anthony Just to add to Magnus' list, there are a few additional AWT and libmlib_image source files listed in JDK-8047931 that should be examined too. -Alan. From david.lloyd at redhat.com Wed Aug 27 14:36:53 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 27 Aug 2014 09:36:53 -0500 Subject: JEP 200: The Modular JDK In-Reply-To: <53FC941F.5040306@oracle.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> <53FC8A30.9010506@redhat.com> <53FC941F.5040306@oracle.com> Message-ID: <53FDED05.5080106@redhat.com> On 08/26/2014 09:05 AM, Alan Bateman wrote: > On 26/08/2014 14:22, David M. Lloyd wrote: >> >> We've found that when it comes to deciding when to or when not to >> re-export an API dependency of another API module, the criteria comes >> down to whether the importing API makes use of the imported API's >> types directly in its API classes. If not, then re-exporting is >> generally counter-productive. By this standard, there may be more >> re-exporting going on than strictly necessary or desirable in this >> document. > I think you are touching on design principle #3 in the JEP. > > Do you have any specific examples where you see needless re-exporting > (in the graph then it's the darker edges)? The "java.sql" module seems to export "java.logging" though I can't find a reason for it. Also it's not super clear that the dependency on "java.xml" is necessary (though I guess it's probably harmless) since I would say *most* users are not using the XML functionality of JDBC, and if they are, they're going to be importing this API anyway. >> As a matter of principle I'm generally opposed to exporting specific >> module packages only to specific other modules. I think this >> indicates that a module split is required. I'm guessing that at the >> root of this problem is an attempt to avoid circular dependencies >> during compilation, but I would rather that issue not be punted to the >> runtime. > For legacy code bases such as a JDK then this is useful and important. > There are some areas that are more tightly coupled that would be if > starting afresh. The most obvious example of where you might export > something to only specific modules is sun.misc. It's JDK-internal but > used in many areas of the JDK. We actually had a similar capability for similar reasons but found that it fails for a couple reasons: 1. It fails as a security mechanism, as the security is trivially defeated 2. It has always been possible to solve these abstraction issues in a simpler way 3. If users want access to a module, they will get it, one way or another (this bar is after all far lower than language-level access controls) In other words, none of the above points make this functionality *necessary*. As long as code is shipped in the JDK, someone is going to want to use it. If you mark it as "unsupported", maybe migrating over the existing "proprietary API" warning, it will be of far more practical use to far more users than trying to turn this into a security mechanism. The historically better way (IMO) to get users to not use proprietary APIs is to provide equivalent or better functionality in the language and/or SDK. -- - DML From Alan.Bateman at oracle.com Wed Aug 27 15:56:57 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Aug 2014 16:56:57 +0100 Subject: JEP 200: The Modular JDK In-Reply-To: <53FDED05.5080106@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net> <53FC8A30.9010506@redhat.com> <53FC941F.5040306@oracle.com> <53FDED05.5080106@redhat.com> Message-ID: <53FDFFC9.5060303@oracle.com> On 27/08/2014 15:36, David M. Lloyd wrote: > > The "java.sql" module seems to export "java.logging" though I can't > find a reason for it. Also it's not super clear that the dependency > on "java.xml" is necessary (though I guess it's probably harmless) > since I would say *most* users are not using the XML functionality of > JDBC, and if they are, they're going to be importing this API anyway. java.sql.Driver.getParentLogger() and methods defined by java.sql.SQLXML are the reasons for this. > > We actually had a similar capability for similar reasons but found > that it fails for a couple reasons: > > 1. It fails as a security mechanism, as the security is trivially > defeated > 2. It has always been possible to solve these abstraction issues in a > simpler way > 3. If users want access to a module, they will get it, one way or > another (this bar is after all far lower than language-level access > controls) > > In other words, none of the above points make this functionality > *necessary*. As long as code is shipped in the JDK, someone is going > to want to use it. If you mark it as "unsupported", maybe migrating > over the existing "proprietary API" warning, it will be of far more > practical use to far more users than trying to turn this into a > security mechanism. The historically better way (IMO) to get users to > not use proprietary APIs is to provide equivalent or better > functionality in the language and/or SDK. There are several JEPs in progress or coming that that should reduce over time the need for some applications and libraries to make direct use of JDK-internal APIs. This should help with some of the implementation sharing in the JDK too but it won't eliminate it completely. The details on how encapsulation will be done is not this JEP. I think it would be reasonable to assume that if someone is using Core Reflection and has permission to use setAccessible(true) then access checks will be suppressed. -Alan. From mark.reinhold at oracle.com Wed Aug 27 15:57:43 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 27 Aug 2014 08:57:43 -0700 Subject: JEP 200: The Modular JDK In-Reply-To: <53FDED05.5080106@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FC8A30.9010506@redhat.com>, <53FC941F.5040306@oracle.com>, <53FDED05.5080106@redhat.com> Message-ID: <20140827085743.743023@eggemoggin.niobe.net> 2014/8/27 7:36 -0700, david.lloyd at redhat.com: > On 08/26/2014 09:05 AM, Alan Bateman wrote: >> On 26/08/2014 14:22, David M. Lloyd wrote: >>> We've found that when it comes to deciding when to or when not to >>> re-export an API dependency of another API module, the criteria comes >>> down to whether the importing API makes use of the imported API's >>> types directly in its API classes. If not, then re-exporting is >>> generally counter-productive. By this standard, there may be more >>> re-exporting going on than strictly necessary or desirable in this >>> document. >> >> I think you are touching on design principle #3 in the JEP. >> >> Do you have any specific examples where you see needless re-exporting >> (in the graph then it's the darker edges)? > > The "java.sql" module seems to export "java.logging" though I can't find > a reason for it. java.util.logging.Logger appears in the types of a few public methods in java.sql, e.g., java.sql.Driver::getParentLogger [1]. > Also it's not super clear that the dependency on > "java.xml" is necessary (though I guess it's probably harmless) since I > would say *most* users are not using the XML functionality of JDBC, and > if they are, they're going to be importing this API anyway. The java.sql.SQLXML interface references types in the java.xml module. >>> As a matter of principle I'm generally opposed to exporting specific >>> module packages only to specific other modules. I think this >>> indicates that a module split is required. I'm guessing that at the >>> root of this problem is an attempt to avoid circular dependencies >>> during compilation, but I would rather that issue not be punted to the >>> runtime. >> >> For legacy code bases such as a JDK then this is useful and important. >> There are some areas that are more tightly coupled that would be if >> starting afresh. The most obvious example of where you might export >> something to only specific modules is sun.misc. It's JDK-internal but >> used in many areas of the JDK. > > We actually had a similar capability for similar reasons but found that > it fails for a couple reasons: > > 1. It fails as a security mechanism, as the security is trivially defeated > 2. It has always been possible to solve these abstraction issues in a > simpler way > 3. If users want access to a module, they will get it, one way or > another (this bar is after all far lower than language-level access > controls) Perhaps it's not clear in the JEPs but our intent is, in fact, to enforce module boundaries via access-control checks in the VM rather than simple visibility checks in class loaders (which are, as you point out, trivially defeated). - Mark [1] http://docs.oracle.com/javase/8/docs/api/java/sql/Driver.html#getParentLogger-- From david.lloyd at redhat.com Wed Aug 27 16:14:51 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 27 Aug 2014 11:14:51 -0500 Subject: JEP 200: The Modular JDK In-Reply-To: <20140827085743.743023@eggemoggin.niobe.net> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FC8A30.9010506@redhat.com>, <53FC941F.5040306@oracle.com>, <53FDED05.5080106@redhat.com> <20140827085743.743023@eggemoggin.niobe.net> Message-ID: <53FE03FB.2050501@redhat.com> On 08/27/2014 10:57 AM, mark.reinhold at oracle.com wrote: > 2014/8/27 7:36 -0700, david.lloyd at redhat.com: >> On 08/26/2014 09:05 AM, Alan Bateman wrote: >>> On 26/08/2014 14:22, David M. Lloyd wrote: >>>> As a matter of principle I'm generally opposed to exporting specific >>>> module packages only to specific other modules. I think this >>>> indicates that a module split is required. I'm guessing that at the >>>> root of this problem is an attempt to avoid circular dependencies >>>> during compilation, but I would rather that issue not be punted to the >>>> runtime. >>> >>> For legacy code bases such as a JDK then this is useful and important. >>> There are some areas that are more tightly coupled that would be if >>> starting afresh. The most obvious example of where you might export >>> something to only specific modules is sun.misc. It's JDK-internal but >>> used in many areas of the JDK. >> >> We actually had a similar capability for similar reasons but found that >> it fails for a couple reasons: >> >> 1. It fails as a security mechanism, as the security is trivially defeated >> 2. It has always been possible to solve these abstraction issues in a >> simpler way >> 3. If users want access to a module, they will get it, one way or >> another (this bar is after all far lower than language-level access >> controls) > > Perhaps it's not clear in the JEPs but our intent is, in fact, to > enforce module boundaries via access-control checks in the VM rather > than simple visibility checks in class loaders (which are, as you point > out, trivially defeated). Even if this can be made truly secure, I wonder why this is considered, in principle, to be a good idea. Taking the "paranoid hermit" approach to encapsulation at this level has always been much less successful for us. All of my experiences with modular distributions add up to thinking that an advisory approach is far superior (and also more flexible). If you put the hermit into the system, then everyone who uses it will become a hermit, because that's just how people are. It makes more sense to be more flexible: let users describe the stability prospects of their modules in a way that consumers can be aware of it but not necessarily constrained. We use two different schemes now, but they both amount to: we have "public" modules and "private" or "unsupported" modules. The former have longer-term API guarantees and the latter may be changed or removed at any time without notice. We use run time warnings, but the JDK could also add compile-time warnings very easily, and it is easy to imagine that this could even be customizable without too much effort. Security can be enforced using the existing access controller mechanism (modulo some improvements that have already been proposed in that area and/or additional improvements that may (or may not) become possible as a result of modular architecture) without adding any fundamental complexity to the overall system. Given the complexity of langauge/JVM-level access checking as it is now - and bugs that are still being found even in this very late stage - and the complexity of access controller based access checking as it is now, adding another mechanism seems ill-advised from this point of view as well. -- - DML From Alan.Bateman at oracle.com Wed Aug 27 18:31:44 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Aug 2014 19:31:44 +0100 Subject: JEP 200: The Modular JDK In-Reply-To: <53FE03FB.2050501@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FC8A30.9010506@redhat.com>, <53FC941F.5040306@oracle.com>, <53FDED05.5080106@redhat.com> <20140827085743.743023@eggemoggin.niobe.net> <53FE03FB.2050501@redhat.com> Message-ID: <53FE2410.3090005@oracle.com> On 27/08/2014 17:14, David M. Lloyd wrote: > > Even if this can be made truly secure, I wonder why this is > considered, in principle, to be a good idea. Taking the "paranoid > hermit" approach to encapsulation at this level has always been much > less successful for us. All of my experiences with modular > distributions add up to thinking that an advisory approach is far > superior (and also more flexible). > > If you put the hermit into the system, then everyone who uses it will > become a hermit, because that's just how people are. It makes more > sense to be more flexible: let users describe the stability prospects > of their modules in a way that consumers can be aware of it but not > necessarily constrained. We use two different schemes now, but they > both amount to: we have "public" modules and "private" or > "unsupported" modules. The former have longer-term API guarantees and > the latter may be changed or removed at any time without notice. We > use run time warnings, but the JDK could also add compile-time > warnings very easily, and it is easy to imagine that this could even > be customizable without too much effort. The JDK has had warnings in the documentation since JDK 1.0 or 1.1. There has been compiler warnings since JDK 6 but they doesn't seem to be much of a deterrent either. So I think our experiences with "advisory" might to different. > Security can be enforced using the existing access controller > mechanism (modulo some improvements that have already been proposed in > that area and/or additional improvements that may (or may not) become > possible as a result of modular architecture) without adding any > fundamental complexity to the overall system. The security manager case is somewhat niche but ideally things should work the same way when running both with or without a security manager. There are few compatibility and subtle issues to do with the way things have historically worked in this area so they will need consideration. -Alan. From david.lloyd at redhat.com Wed Aug 27 20:13:14 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 27 Aug 2014 15:13:14 -0500 Subject: JEP 200: The Modular JDK In-Reply-To: <53FE2410.3090005@oracle.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FC8A30.9010506@redhat.com>, <53FC941F.5040306@oracle.com>, <53FDED05.5080106@redhat.com> <20140827085743.743023@eggemoggin.niobe.net> <53FE03FB.2050501@redhat.com> <53FE2410.3090005@oracle.com> Message-ID: <53FE3BDA.5030509@redhat.com> On 08/27/2014 01:31 PM, Alan Bateman wrote: > On 27/08/2014 17:14, David M. Lloyd wrote: >> >> Even if this can be made truly secure, I wonder why this is >> considered, in principle, to be a good idea. Taking the "paranoid >> hermit" approach to encapsulation at this level has always been much >> less successful for us. All of my experiences with modular >> distributions add up to thinking that an advisory approach is far >> superior (and also more flexible). >> >> If you put the hermit into the system, then everyone who uses it will >> become a hermit, because that's just how people are. It makes more >> sense to be more flexible: let users describe the stability prospects >> of their modules in a way that consumers can be aware of it but not >> necessarily constrained. We use two different schemes now, but they >> both amount to: we have "public" modules and "private" or >> "unsupported" modules. The former have longer-term API guarantees and >> the latter may be changed or removed at any time without notice. We >> use run time warnings, but the JDK could also add compile-time >> warnings very easily, and it is easy to imagine that this could even >> be customizable without too much effort. > The JDK has had warnings in the documentation since JDK 1.0 or 1.1. > There has been compiler warnings since JDK 6 but they doesn't seem to be > much of a deterrent either. So I think our experiences with "advisory" > might to different. I think this is the fundamental difference. You think "deterrent". I think "expectation management". People who *want* the functionality will get it; it is a far more efficient expenditure of energy to let them do it and just clearly manage expectations than to try to modify behavior (which will just result in frustration for users). Adding artificial barriers is counter-productive, and may even introduce security risks as yet more JVM security mechanisms are added on top of the existing stuff (a lesson that the constant CVE avalanche indicates has not been fully learned yet, especially in the context of Java). >> Security can be enforced using the existing access controller >> mechanism (modulo some improvements that have already been proposed in >> that area and/or additional improvements that may (or may not) become >> possible as a result of modular architecture) without adding any >> fundamental complexity to the overall system. > > The security manager case is somewhat niche but ideally things should > work the same way when running both with or without a security manager. > There are few compatibility and subtle issues to do with the way things > have historically worked in this area so they will need consideration. I don't know about that. We're talking, as always, about the concepts of visibility as opposed to accessibility. Until now, all discussion has been in the context of visibility, which as I said (and MR agreed) is easily subverted - but then MR said he intends to "enforce module boundaries via access-control checks in the VM" which blurs the line considerably. So if we're now moving into accessibility territory across class loaders, we're definitely and squarely overlapping with AccessController and its related facilities - i.e. "does module X have permission to import module Y?". This is clearly a permission check, exactly like those done against the protection domain(s) of the module's class loader - why introduce a new mechanism when an existing matching solution exists? -- - DML From Alan.Bateman at oracle.com Wed Aug 27 20:56:28 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Aug 2014 21:56:28 +0100 Subject: JEP 200: The Modular JDK In-Reply-To: <53FE3BDA.5030509@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FC8A30.9010506@redhat.com>, <53FC941F.5040306@oracle.com>, <53FDED05.5080106@redhat.com> <20140827085743.743023@eggemoggin.niobe.net> <53FE03FB.2050501@redhat.com> <53FE2410.3090005@oracle.com> <53FE3BDA.5030509@redhat.com> Message-ID: <53FE45FC.8000102@oracle.com> On 27/08/2014 21:13, David M. Lloyd wrote: > > I don't know about that. We're talking, as always, about the concepts > of visibility as opposed to accessibility. Until now, all discussion > has been in the context of visibility, which as I said (and MR agreed) > is easily subverted - but then MR said he intends to "enforce module > boundaries via access-control checks in the VM" which blurs the line > considerably. So if we're now moving into accessibility territory > across class loaders, we're definitely and squarely overlapping with > AccessController and its related facilities - i.e. "does module X have > permission to import module Y?". This is clearly a permission check, > exactly like those done against the protection domain(s) of the > module's class loader - why introduce a new mechanism when an existing > matching solution exists? > For access control then think how accessibility specified in the JLS and JVMS might evolve rather than java.security.AccessController, permissions, and the security manager world. This is all discussion for a future JEP and JSR of course. -Alan From mark.reinhold at oracle.com Wed Aug 27 21:04:03 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 27 Aug 2014 14:04:03 -0700 Subject: JEP 200: The Modular JDK In-Reply-To: <53FE3BDA.5030509@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FE2410.3090005@oracle.com>, <53FE3BDA.5030509@redhat.com> Message-ID: <20140827140403.564781@eggemoggin.niobe.net> 2014/8/27 1:13 -0700, david.lloyd at redhat.com: > ... > > I think this is the fundamental difference. You think "deterrent". I > think "expectation management". People who *want* the functionality > will get it; it is a far more efficient expenditure of energy to let > them do it and just clearly manage expectations than to try to modify > behavior (which will just result in frustration for users). As Alan noted, the experience of those of us working on the JDK itself has been rather different. We've warned against using internal APIs for years, but it's had little effect. In the meantime all this cruft upon which people have come to depend has gradually grown into a significant maintenance burden. It's time to cut the cord. > Adding > artificial barriers is counter-productive, and may even introduce > security risks as yet more JVM security mechanisms are added on top of > the existing stuff (a lesson that the constant CVE avalanche indicates > has not been fully learned yet, especially in the context of Java). We're trying to improve security, and we suspect we can do this in a reasonably straightforward way. Enforcing module boundaries in the VM would be a big improvement over the existing means of protecting JDK internals (e.g., SecurityManager::checkPackageAccess), which are are brittle and error-prone. > ... > > I don't know about that. We're talking, as always, about the concepts > of visibility as opposed to accessibility. Until now, all discussion > has been in the context of visibility, which as I said (and MR agreed) > is easily subverted - but then MR said he intends to "enforce module > boundaries via access-control checks in the VM" which blurs the line > considerably. So if we're now moving into accessibility territory > across class loaders, we're definitely and squarely overlapping with > AccessController and its related facilities - i.e. "does module X have > permission to import module Y?". The type of module-boundary access-control check we're thinking of would be an extension of what the JVM currently does during class, interface, field, and method resolution, per JVMS 5.4.4 [1]. It's the exact same mechanism that keeps private members private, and it's very difficult to subvert. It has little (direct) relation to AccessController or any kind of security-permission check. - Mark [1] http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html#jvms-5.4.4 From david.lloyd at redhat.com Wed Aug 27 22:08:12 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 27 Aug 2014 17:08:12 -0500 Subject: JEP 200: The Modular JDK In-Reply-To: <20140827140403.564781@eggemoggin.niobe.net> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FE2410.3090005@oracle.com>, <53FE3BDA.5030509@redhat.com> <20140827140403.564781@eggemoggin.niobe.net> Message-ID: <53FE56CC.4000703@redhat.com> On 08/27/2014 04:04 PM, mark.reinhold at oracle.com wrote: > 2014/8/27 1:13 -0700, david.lloyd at redhat.com: >> ... >> >> I think this is the fundamental difference. You think "deterrent". I >> think "expectation management". People who *want* the functionality >> will get it; it is a far more efficient expenditure of energy to let >> them do it and just clearly manage expectations than to try to modify >> behavior (which will just result in frustration for users). > > As Alan noted, the experience of those of us working on the JDK itself > has been rather different. We've warned against using internal APIs for > years, but it's had little effect. In the meantime all this cruft upon > which people have come to depend has gradually grown into a significant > maintenance burden. It's time to cut the cord. > >> Adding >> artificial barriers is counter-productive, and may even introduce >> security risks as yet more JVM security mechanisms are added on top of >> the existing stuff (a lesson that the constant CVE avalanche indicates >> has not been fully learned yet, especially in the context of Java). > > We're trying to improve security, and we suspect we can do this in a > reasonably straightforward way. Enforcing module boundaries in the VM > would be a big improvement over the existing means of protecting JDK > internals (e.g., SecurityManager::checkPackageAccess), which are are > brittle and error-prone. > >> ... >> >> I don't know about that. We're talking, as always, about the concepts >> of visibility as opposed to accessibility. Until now, all discussion >> has been in the context of visibility, which as I said (and MR agreed) >> is easily subverted - but then MR said he intends to "enforce module >> boundaries via access-control checks in the VM" which blurs the line >> considerably. So if we're now moving into accessibility territory >> across class loaders, we're definitely and squarely overlapping with >> AccessController and its related facilities - i.e. "does module X have >> permission to import module Y?". > > The type of module-boundary access-control check we're thinking of would > be an extension of what the JVM currently does during class, interface, > field, and method resolution, per JVMS 5.4.4 [1]. It's the exact same > mechanism that keeps private members private, and it's very difficult to > subvert. It has little (direct) relation to AccessController or any > kind of security-permission check. An intra-classloader or intra-module access level akin to package access, as previously described in the initial stages of Jigsaw, is easily understood since this is just another access protection flag in class files and is fairly easily accomplished. However once you start allowing modules to specify what modules may import from it (by name, presumably), you're now forced to define the scope of the names you're assigning, and thereby implicitly increasing the user's need to maintain security and integrity not just within modules, but also between them. IMO this in turn will imply (even more strongly than before) a loading level that corresponds to the aggregation of modules within a general namespace, which can manage the loading of modules as well as the assignment of their "friends", similarly to how class loaders (and in the future, I expect, modules) are responsible for the security and integrity of loading the classes and resources that comprise it. Am I far off the mark here? I do believe that there is still a strong overlap between the functions of AccessController and this mechanism though, in any event (not that I'm a great fan of that mechanism in general). But maybe the module mechanism can provide additional ways to improve it somehow, or perhaps even to replace it, eventually. -- - DML From mark.reinhold at oracle.com Wed Aug 27 22:33:21 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 27 Aug 2014 15:33:21 -0700 Subject: JEP 200: The Modular JDK In-Reply-To: <53FE56CC.4000703@redhat.com> References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <20140827140403.564781@eggemoggin.niobe.net>, <53FE56CC.4000703@redhat.com> Message-ID: <20140827153321.952021@eggemoggin.niobe.net> 2014/8/27 3:08 -0700, david.lloyd at redhat.com: > An intra-classloader or intra-module access level akin to package > access, as previously described in the initial stages of Jigsaw, is > easily understood since this is just another access protection flag in > class files and is fairly easily accomplished. However once you start > allowing modules to specify what modules may import from it (by name, > presumably), you're now forced to define the scope of the names you're > assigning, Yes, though we already have to define the scope of module names simply because we're introducing modules. > and thereby implicitly increasing the user's need to maintain > security and integrity not just within modules, but also between them. If you're referring to the restricted-export feature, which allows a module to export public types to a specific set of named modules, then yes, the maintainers of those modules will have to think carefully about security and integrity across module boundaries. In a new code base I'd hope and expect this feature to be used little, if at all. This feature is critical, however, when modularizing a large legacy code base such as the JDK, as Alan wrote earlier. > IMO this in turn will imply (even more strongly than before) a loading > level that corresponds to the aggregation of modules within a general > namespace, which can manage the loading of modules as well as the > assignment of their "friends", similarly to how class loaders (and in > the future, I expect, modules) are responsible for the security and > integrity of loading the classes and resources that comprise it. > > Am I far off the mark here? No, I don't think so. - Mark From magnus.ihse.bursie at oracle.com Thu Aug 28 09:00:05 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 28 Aug 2014 11:00:05 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53FDB999.3030001@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> Message-ID: <53FEEF95.5000702@oracle.com> On 2014-08-27 12:57, Anthony Petrov wrote: > Hi Magnus, > > Those look like reasonable suggestions. Could you please file separate > bugs for each of these issues? Also, please note that most of them > belong to 2D, not AWT (e.g. the font-, color-, d3d-, and > opengl-related files) even though they're compiled into the awt native > libraries. I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213, JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After some consideration, I choose to put them on the infrastructure/build category, since I believe the build part (changes to the makefiles) requires most of the work (compared to e.g. removing a file), and that we are probably more keen on having them solved :), but they need to be resolved in cooperation with the 2D team. The issue regarding the medialib directories was already reported in JDK-8055190. /Magnus > > -- > best regards, > Anthony > > On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote: >> On 2014-08-20 11:14, Magnus Ihse Bursie wrote: >>> On 2014-08-18 16:15, Anthony Petrov wrote: >>>> So I'm not sure if the current set of AWT libraries could be >>>> simplified any further. >>>> >>>> Hope this helps. >>> >>> Thank you for the clarification, it was very helpful! >>> >>> While the set of AWT libraries probably cannot be simplified as you >>> say, my gut feeling is still that the current layout of files on disk >>> does not optimally match the actual libraries we build. Armed with the >>> help of your description, I'll look into them once again and see if I >>> can make that statement more concrete. >> >> This is my suggestions based on what I found when trying to remove the >> last unnecessary entanglement. Note that all paths are relative to the >> java.desktop module, and that I have at this stage only looked at >> compiled sources (*.c), not header files. >> >> * The following files are in the windows directory tree, but are >> explicitly excluded on Windows. Thus they will never be built, and >> should be removed instead: >> ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >> ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c >> ./windows/native/libawt/sun/windows/WBufferStrategy.cpp >> >> * The following file is in the share directory tree, but is only used on >> Windows. It should be moved to the corresponding windows directory >> instead: >> ./share/native/libawt/sun/java2d/ShaderList.c >> >> * The following directory is in the unix directory tree, but is only >> used on Solaris. It should be moved to the corresponding solaris >> directory instead: >> ./unix/native/libawt/sun/java2d/loops >> >> * The directory ./unix/native/common/sun/awt contains five more or less >> unrelated .c files. Three of them are only used in libawt_xawt, and >> should be moved there: >> ./unix/native/common/sun/awt/awt_Font.c >> ./unix/native/common/sun/awt/fontpath.c >> ./unix/native/common/sun/awt/X11Color.c >> Of the remaining two CUPSfuncs.c seems correctly placed, since it is >> shared between libawt_xawt and libawt_lwawt. However, I'm wondering >> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but >> when I checked some random functions, they are exported (via the >> mapfile) for libawt only. So I believe it is a mistake to include it in >> libawt_xawt, and that it should be moved to the libawt directory. This >> will need verification from someone on the AWT team. >> >> * The directory ./unix/native/libjawt is included in libawt_xawt (and in >> libjawt, of course). This seems suspicious to me. There is just a single >> file with a single function, JAWT_GetAWT(), which is exported in libjawt >> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to >> include it in libawt_xawt. This will need verification from someone on >> the AWT team. >> >> * All of the awt-related directories (libawt_* and common) include an >> unnecessary extra layer, the "sun" directory. It is not needed anymore, >> and just makes all paths extra long. I suggest that we remove that layer >> and move everything up one step. >> >> * The makefiles include too specific directories. Instead of including >> e.g. ./*/native/common/sun/java2d/opengl and >> ./*/native/common/sun/java2d/x11, we should just include >> ./*/native/common/sun/java2d. This level corresponds to a logical >> grouping of the source code, and not the directory structure in that >> grouping. >> >> * The file ./windows/native/common/awt_makecube.cpp is a bit strange. It >> is not a shared file; instead it's a stand-alone binary with a main() >> function. It is not compiled by any makefile targets. If this file is >> actually used, I suggest moving it to a better location >> (windows/native/launchers?), and starting to compile it with the build. >> (Stuff that's not built regularly is doomed to bit rot.) It if is not >> used, I suggest we remove it. >> >> * And as I stated before, the medlialib directories are typically not >> used by libawt and friends. It is used by libmlib_image and >> libmlib_image_v, and should move away from the awt directory. >> >> /Magnus From weijun.wang at oracle.com Thu Aug 28 10:28:43 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 28 Aug 2014 18:28:43 +0800 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: <53FEF9FF.7050603@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> Message-ID: <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> This is the sub-task of "8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss" that actually moves the files. Code changes include 2 parts: 1. For jdk9/dev repo: http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ 2. For jdk9/dev/jdk. It's just moving everything inside src/java.security.jgss/share/classes/com/sun/security/ to src/jdk.security.jgss/share/classes/com/sun/security. This includes all classes in the com/sun/security/jgss and com/sun/security/sasl/gsskerb packages. Please note that the 2nd package actually calls classes in the 1st one, so they must be moved together. Precisely: - src/java.security.jgss/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java - src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java - src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java - src/java.security.jgss/share/classes/com/sun/security/jgss/Extender.java - src/java.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java - src/java.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java - src/java.security.jgss/share/classes/com/sun/security/jgss/InquireType.java - src/java.security.jgss/share/classes/com/sun/security/jgss/package-info.java - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/FactoryImpl.java - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/Extender.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireType.java + src/jdk.security.jgss/share/classes/com/sun/security/jgss/package-info.java + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/FactoryImpl.java + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java Since this is about creating a new module, do I need to request for an approval from some committee? Thanks Max From Alan.Bateman at oracle.com Thu Aug 28 10:52:17 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Aug 2014 11:52:17 +0100 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> Message-ID: <53FF09E1.8080504@oracle.com> On 28/08/2014 11:28, Wang Weijun wrote: > This is the sub-task of "8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss" that actually moves the files. > > Code changes include 2 parts: > > 1. For jdk9/dev repo: > > http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ > > 2. For jdk9/dev/jdk. It's just moving everything inside src/java.security.jgss/share/classes/com/sun/security/ to src/jdk.security.jgss/share/classes/com/sun/security. This includes all classes in the com/sun/security/jgss and com/sun/security/sasl/gsskerb packages. Please note that the 2nd package actually calls classes in the 1st one, so they must be moved together. For the benefit of the others, the substantive part that is JDK-8042900 is currently in review on security-dev. It's also one of the open issues listed in JEP 200. Max - the main thing is that is missing in this is the update to modules.xml, this is temporary document that is checked into the top-level repo until there is a module system in place. I'll defer to Mandy as to whether she wants to re-generate it or whether to edit manually (I think this will be the first adjustment since the source code restructure was pushed). -Alan From chris.hegarty at oracle.com Thu Aug 28 12:17:13 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Aug 2014 13:17:13 +0100 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> Message-ID: On 28 Aug 2014, at 11:28, Wang Weijun wrote: > This is the sub-task of "8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss" that actually moves the files. > > Code changes include 2 parts: > > 1. For jdk9/dev repo: > > http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ Thank you for updating the unshuffle list. This looks good to me. As Alan mentioned, a change to modules.xml will be required too. -Chris. > 2. For jdk9/dev/jdk. It's just moving everything inside src/java.security.jgss/share/classes/com/sun/security/ to src/jdk.security.jgss/share/classes/com/sun/security. This includes all classes in the com/sun/security/jgss and com/sun/security/sasl/gsskerb packages. Please note that the 2nd package actually calls classes in the 1st one, so they must be moved together. Precisely: > > - src/java.security.jgss/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/Extender.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/InquireType.java > - src/java.security.jgss/share/classes/com/sun/security/jgss/package-info.java > - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/FactoryImpl.java > - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java > - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java > - src/java.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/AuthorizationDataEntry.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/Extender.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireType.java > + src/jdk.security.jgss/share/classes/com/sun/security/jgss/package-info.java > + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/FactoryImpl.java > + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Base.java > + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java > + src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java > > Since this is about creating a new module, do I need to request for an approval from some committee? > Thanks > Max > From weijun.wang at oracle.com Thu Aug 28 13:02:13 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 28 Aug 2014 21:02:13 +0800 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: <53FF09E1.8080504@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> <53FF09E1.8080504@oracle.com> Message-ID: On Aug 28, 2014, at 18:52, Alan Bateman wrote: >> >> http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ >> > > Max - the main thing is that is missing in this is the update to modules.xml, this is temporary document that is checked into the top-level repo until there is a module system in place. I'll defer to Mandy as to whether she wants to re-generate it or whether to edit manually (I think this will be the first adjustment since the source code restructure was pushed). Webrev updated at the same URL. I manually edited modules.xml, but if it can be re-generated automatically I'll be happy to use it. --Max > > -Alan > > From Alan.Bateman at oracle.com Thu Aug 28 13:06:56 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Aug 2014 14:06:56 +0100 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> <53FF09E1.8080504@oracle.com> Message-ID: <53FF2970.40807@oracle.com> On 28/08/2014 14:02, Wang Weijun wrote: > On Aug 28, 2014, at 18:52, Alan Bateman wrote: > >>> >>> http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ >>> >> Max - the main thing is that is missing in this is the update to modules.xml, this is temporary document that is checked into the top-level repo until there is a module system in place. I'll defer to Mandy as to whether she wants to re-generate it or whether to edit manually (I think this will be the first adjustment since the source code restructure was pushed). > Webrev updated at the same URL. > > I manually edited modules.xml, but if it can be re-generated automatically I'll be happy to use it. > Have you run "make verify-modules"? -Alan. From weijun.wang at oracle.com Thu Aug 28 13:43:03 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 28 Aug 2014 21:43:03 +0800 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: <53FF2970.40807@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> <53FF09E1.8080504@oracle.com> <53FF2970.40807@oracle.com> Message-ID: <1091287D-845F-4492-9A16-115DD7B7CD18@oracle.com> On Aug 28, 2014, at 21:06, Alan Bateman wrote: > On 28/08/2014 14:02, Wang Weijun wrote: >> On Aug 28, 2014, at 18:52, Alan Bateman wrote: >> >>>> http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ >>>> >>> Max - the main thing is that is missing in this is the update to modules.xml, this is temporary document that is checked into the top-level repo until there is a module system in place. I'll defer to Mandy as to whether she wants to re-generate it or whether to edit manually (I think this will be the first adjustment since the source code restructure was pushed). >> Webrev updated at the same URL. >> >> I manually edited modules.xml, but if it can be re-generated automatically I'll be happy to use it. >> > Have you run "make verify-modules"? Oops. Succeed after more change diff --git a/modules.xml b/modules.xml --- a/modules.xml +++ b/modules.xml @@ -920,6 +920,14 @@ sun.security.krb5.internal.ktab jdk.security.auth + + sun.security.jgss + jdk.security.jgss + + + sun.security.krb5.internal + jdk.security.jgss + java.security.sasl @@ -1739,7 +1747,7 @@ jdk.security.jgss java.base java.logging - java.security.jgss + java.security.jgss java.security.sasl com.sun.security.jgss Webrev still there. --Max > > -Alan. From philip.race at oracle.com Thu Aug 28 19:36:12 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Aug 2014 12:36:12 -0700 Subject: RFR [9] Modular Source Code In-Reply-To: <53FF770F.2080305@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> <53FEEF95.5000702@oracle.com> <53FF770F.2080305@oracle.com> Message-ID: <53FF84AC.20401@oracle.com> * All of the awt-related directories (libawt_* and common) include an unnecessary extra layer, the "sun" directory. It is not needed anymore, Let's *not* do that. It also affects the destination package. Remember sun.* is the protected top-level package .. and people won't always be running in jigsaw mode. Plus I recently learned that compact profiles need to be informed when you do something like this. > ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c Is a tool that is run manually when we need to re-generate the shaders. It is co-located so that can be found easily. It certainly should not be deleted, nor should it be moved anywhere obscure. makecube is similar but is I think on a list to consider deletion since I don't think we need it anymore. But launchers would be the wrong place. So, yes, decisions on most of these need to be jointly discussed and reviewed although some may be better 'owned' by 2d and some by build. -phil. On 8/28/2014 11:38 AM, Anthony Petrov wrote: > Thanks! > > -- > best regards, > Anthony > > On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote: >> On 2014-08-27 12:57, Anthony Petrov wrote: >>> Hi Magnus, >>> >>> Those look like reasonable suggestions. Could you please file separate >>> bugs for each of these issues? Also, please note that most of them >>> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and >>> opengl-related files) even though they're compiled into the awt native >>> libraries. >> >> I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213, >> JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After >> some consideration, I choose to put them on the infrastructure/build >> category, since I believe the build part (changes to the makefiles) >> requires most of the work (compared to e.g. removing a file), and that >> we are probably more keen on having them solved :), but they need to be >> resolved in cooperation with the 2D team. >> >> The issue regarding the medialib directories was already reported in >> JDK-8055190. >> >> /Magnus >> >> >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote: >>>> On 2014-08-20 11:14, Magnus Ihse Bursie wrote: >>>>> On 2014-08-18 16:15, Anthony Petrov wrote: >>>>>> So I'm not sure if the current set of AWT libraries could be >>>>>> simplified any further. >>>>>> >>>>>> Hope this helps. >>>>> >>>>> Thank you for the clarification, it was very helpful! >>>>> >>>>> While the set of AWT libraries probably cannot be simplified as you >>>>> say, my gut feeling is still that the current layout of files on disk >>>>> does not optimally match the actual libraries we build. Armed with >>>>> the >>>>> help of your description, I'll look into them once again and see if I >>>>> can make that statement more concrete. >>>> >>>> This is my suggestions based on what I found when trying to remove the >>>> last unnecessary entanglement. Note that all paths are relative to the >>>> java.desktop module, and that I have at this stage only looked at >>>> compiled sources (*.c), not header files. >>>> >>>> * The following files are in the windows directory tree, but are >>>> explicitly excluded on Windows. Thus they will never be built, and >>>> should be removed instead: >>>> ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >>>> ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c >>>> ./windows/native/libawt/sun/windows/WBufferStrategy.cpp >>>> >>>> * The following file is in the share directory tree, but is only >>>> used on >>>> Windows. It should be moved to the corresponding windows directory >>>> instead: >>>> ./share/native/libawt/sun/java2d/ShaderList.c >>>> >>>> * The following directory is in the unix directory tree, but is only >>>> used on Solaris. It should be moved to the corresponding solaris >>>> directory instead: >>>> ./unix/native/libawt/sun/java2d/loops >>>> >>>> * The directory ./unix/native/common/sun/awt contains five more or >>>> less >>>> unrelated .c files. Three of them are only used in libawt_xawt, and >>>> should be moved there: >>>> ./unix/native/common/sun/awt/awt_Font.c >>>> ./unix/native/common/sun/awt/fontpath.c >>>> ./unix/native/common/sun/awt/X11Color.c >>>> Of the remaining two CUPSfuncs.c seems correctly placed, since it is >>>> shared between libawt_xawt and libawt_lwawt. However, I'm wondering >>>> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but >>>> when I checked some random functions, they are exported (via the >>>> mapfile) for libawt only. So I believe it is a mistake to include >>>> it in >>>> libawt_xawt, and that it should be moved to the libawt directory. This >>>> will need verification from someone on the AWT team. >>>> >>>> * The directory ./unix/native/libjawt is included in libawt_xawt >>>> (and in >>>> libjawt, of course). This seems suspicious to me. There is just a >>>> single >>>> file with a single function, JAWT_GetAWT(), which is exported in >>>> libjawt >>>> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to >>>> include it in libawt_xawt. This will need verification from someone on >>>> the AWT team. >>>> >>>> * All of the awt-related directories (libawt_* and common) include an >>>> unnecessary extra layer, the "sun" directory. It is not needed >>>> anymore, >>>> and just makes all paths extra long. I suggest that we remove that >>>> layer >>>> and move everything up one step. >>>> >>>> * The makefiles include too specific directories. Instead of including >>>> e.g. ./*/native/common/sun/java2d/opengl and >>>> ./*/native/common/sun/java2d/x11, we should just include >>>> ./*/native/common/sun/java2d. This level corresponds to a logical >>>> grouping of the source code, and not the directory structure in that >>>> grouping. >>>> >>>> * The file ./windows/native/common/awt_makecube.cpp is a bit >>>> strange. It >>>> is not a shared file; instead it's a stand-alone binary with a main() >>>> function. It is not compiled by any makefile targets. If this file is >>>> actually used, I suggest moving it to a better location >>>> (windows/native/launchers?), and starting to compile it with the >>>> build. >>>> (Stuff that's not built regularly is doomed to bit rot.) It if is not >>>> used, I suggest we remove it. >>>> >>>> * And as I stated before, the medlialib directories are typically not >>>> used by libawt and friends. It is used by libmlib_image and >>>> libmlib_image_v, and should move away from the awt directory. >>>> >>>> /Magnus >> From philip.race at oracle.com Thu Aug 28 19:40:09 2014 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Aug 2014 12:40:09 -0700 Subject: [OpenJDK 2D-Dev] RFR [9] Modular Source Code In-Reply-To: <53FF84AC.20401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> <53FEEF95.5000702@oracle.com> <53FF770F.2080305@oracle.com> <53FF84AC.20401@oracle.com> Message-ID: <53FF8599.8080007@oracle.com> On 8/28/2014 12:36 PM, Phil Race wrote: > > * All of the awt-related directories (libawt_* and common) include an > unnecessary extra layer, the "sun" directory. It is not needed anymore, > > Let's *not* do that. It also affects the destination package. > Remember sun.* is the protected top-level package .. and > people won't always be running in jigsaw mode. Plus > I recently learned that compact profiles need to be informed when > you do something like this. Oh, you refer to the native code that for some reason in libawt directories (not the others) has one extra level ? I don't see the same for libfontmanager for example Maybe this is one more case where libawt caused excess head-scratching -phil. > > > ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c > > Is a tool that is run manually when we need to re-generate the shaders. > It is co-located so that can be found easily. It certainly should not be > deleted, nor should it be moved anywhere obscure. > > makecube is similar but is I think on a list to consider deletion since > I don't think we need it anymore. But launchers would be the wrong place. > > So, yes, decisions on most of these need to be jointly discussed and > reviewed > although some may be better 'owned' by 2d and some by build. > > -phil. > > > On 8/28/2014 11:38 AM, Anthony Petrov wrote: >> Thanks! >> >> -- >> best regards, >> Anthony >> >> On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote: >>> On 2014-08-27 12:57, Anthony Petrov wrote: >>>> Hi Magnus, >>>> >>>> Those look like reasonable suggestions. Could you please file separate >>>> bugs for each of these issues? Also, please note that most of them >>>> belong to 2D, not AWT (e.g. the font-, color-, d3d-, and >>>> opengl-related files) even though they're compiled into the awt native >>>> libraries. >>> >>> I created JDK-8056209, JDK-8056210, JDK-8056212, JDK-8056213, >>> JDK-8056214, JDK-8056215, JDK-8056216 and JDK-8056217 for these. After >>> some consideration, I choose to put them on the infrastructure/build >>> category, since I believe the build part (changes to the makefiles) >>> requires most of the work (compared to e.g. removing a file), and that >>> we are probably more keen on having them solved :), but they need to be >>> resolved in cooperation with the 2D team. >>> >>> The issue regarding the medialib directories was already reported in >>> JDK-8055190. >>> >>> /Magnus >>> >>> >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote: >>>>> On 2014-08-20 11:14, Magnus Ihse Bursie wrote: >>>>>> On 2014-08-18 16:15, Anthony Petrov wrote: >>>>>>> So I'm not sure if the current set of AWT libraries could be >>>>>>> simplified any further. >>>>>>> >>>>>>> Hope this helps. >>>>>> >>>>>> Thank you for the clarification, it was very helpful! >>>>>> >>>>>> While the set of AWT libraries probably cannot be simplified as you >>>>>> say, my gut feeling is still that the current layout of files on >>>>>> disk >>>>>> does not optimally match the actual libraries we build. Armed >>>>>> with the >>>>>> help of your description, I'll look into them once again and see >>>>>> if I >>>>>> can make that statement more concrete. >>>>> >>>>> This is my suggestions based on what I found when trying to remove >>>>> the >>>>> last unnecessary entanglement. Note that all paths are relative to >>>>> the >>>>> java.desktop module, and that I have at this stage only looked at >>>>> compiled sources (*.c), not header files. >>>>> >>>>> * The following files are in the windows directory tree, but are >>>>> explicitly excluded on Windows. Thus they will never be built, and >>>>> should be removed instead: >>>>> ./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp >>>>> ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c >>>>> ./windows/native/libawt/sun/windows/WBufferStrategy.cpp >>>>> >>>>> * The following file is in the share directory tree, but is only >>>>> used on >>>>> Windows. It should be moved to the corresponding windows directory >>>>> instead: >>>>> ./share/native/libawt/sun/java2d/ShaderList.c >>>>> >>>>> * The following directory is in the unix directory tree, but is only >>>>> used on Solaris. It should be moved to the corresponding solaris >>>>> directory instead: >>>>> ./unix/native/libawt/sun/java2d/loops >>>>> >>>>> * The directory ./unix/native/common/sun/awt contains five more or >>>>> less >>>>> unrelated .c files. Three of them are only used in libawt_xawt, and >>>>> should be moved there: >>>>> ./unix/native/common/sun/awt/awt_Font.c >>>>> ./unix/native/common/sun/awt/fontpath.c >>>>> ./unix/native/common/sun/awt/X11Color.c >>>>> Of the remaining two CUPSfuncs.c seems correctly placed, since it is >>>>> shared between libawt_xawt and libawt_lwawt. However, I'm wondering >>>>> about initIDs.c. It is compiled in libawt as well as libawt_xawt, but >>>>> when I checked some random functions, they are exported (via the >>>>> mapfile) for libawt only. So I believe it is a mistake to include >>>>> it in >>>>> libawt_xawt, and that it should be moved to the libawt directory. >>>>> This >>>>> will need verification from someone on the AWT team. >>>>> >>>>> * The directory ./unix/native/libjawt is included in libawt_xawt >>>>> (and in >>>>> libjawt, of course). This seems suspicious to me. There is just a >>>>> single >>>>> file with a single function, JAWT_GetAWT(), which is exported in >>>>> libjawt >>>>> (via a mapfile), but not in libawt_xawt. I believe it is a mistake to >>>>> include it in libawt_xawt. This will need verification from >>>>> someone on >>>>> the AWT team. >>>>> >>>>> * All of the awt-related directories (libawt_* and common) include an >>>>> unnecessary extra layer, the "sun" directory. It is not needed >>>>> anymore, >>>>> and just makes all paths extra long. I suggest that we remove that >>>>> layer >>>>> and move everything up one step. >>>>> >>>>> * The makefiles include too specific directories. Instead of >>>>> including >>>>> e.g. ./*/native/common/sun/java2d/opengl and >>>>> ./*/native/common/sun/java2d/x11, we should just include >>>>> ./*/native/common/sun/java2d. This level corresponds to a logical >>>>> grouping of the source code, and not the directory structure in that >>>>> grouping. >>>>> >>>>> * The file ./windows/native/common/awt_makecube.cpp is a bit >>>>> strange. It >>>>> is not a shared file; instead it's a stand-alone binary with a main() >>>>> function. It is not compiled by any makefile targets. If this file is >>>>> actually used, I suggest moving it to a better location >>>>> (windows/native/launchers?), and starting to compile it with the >>>>> build. >>>>> (Stuff that's not built regularly is doomed to bit rot.) It if is not >>>>> used, I suggest we remove it. >>>>> >>>>> * And as I stated before, the medlialib directories are typically not >>>>> used by libawt and friends. It is used by libmlib_image and >>>>> libmlib_image_v, and should move away from the awt directory. >>>>> >>>>> /Magnus >>> > From mandy.chung at oracle.com Thu Aug 28 19:47:47 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Aug 2014 12:47:47 -0700 Subject: RFR 8056141: Move com.sun.security.jgss into a new module In-Reply-To: <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> References: <53FEEE2C.7000308@oracle.com> <1B57A59A-C6B8-402E-B02A-B4D81B257ECB@oracle.com> <53FEF9FF.7050603@oracle.com> <10ED1BA3-3045-4C4D-ACB0-D2C81C99391A@oracle.com> Message-ID: <53FF8763.7010401@oracle.com> On 8/28/14 3:28 AM, Wang Weijun wrote: > This is the sub-task of "8042900: Allow com.sun.security.jgss to be in different module than org.ietf.jgss" that actually moves the files. > > Code changes include 2 parts: > > 1. For jdk9/dev repo: > > http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ > > 2. For jdk9/dev/jdk. It's just moving everything inside src/java.security.jgss/share/classes/com/sun/security/ to src/jdk.security.jgss/share/classes/com/sun/security. This includes all classes in the com/sun/security/jgss and com/sun/security/sasl/gsskerb packages. Your change looks okay including the change to modules.xml. I believe jdk.security.jgss using sun.security.krb5.internal is introduced by 8042900. Can you run the following and double check: $ cd BUILD_OUTPUTDIR/jdk $ ./bin/jdeps -M modules/java.security.jgss modules/jdk.security.jgss The output will tell you what modules java.security.jgss and jdk.security.jgss depend on and then follow with the package-level dependences. Looks for "JDK internal API" that indicates that you need to add a qualified export to jdk.security.jgss to use. You have already done this: $ make verify-modules The images build will run the verify-modules as well. Mandy From Alan.Bateman at oracle.com Thu Aug 28 19:57:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Aug 2014 20:57:14 +0100 Subject: RFR [9] Modular Source Code In-Reply-To: <53FF84AC.20401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> <53FEEF95.5000702@oracle.com> <53FF770F.2080305@oracle.com> <53FF84AC.20401@oracle.com> Message-ID: <53FF899A.2080307@oracle.com> On 28/08/2014 20:36, Phil Race wrote: > > * All of the awt-related directories (libawt_* and common) include an > unnecessary extra layer, the "sun" directory. It is not needed anymore, > > Let's *not* do that. It also affects the destination package. > Remember sun.* is the protected top-level package .. and > people won't always be running in jigsaw mode. For native/libXXX then there shouldn't be any need to mirror the java package structure in the native tree now. The shuffle should have done this for most libraries, libawt may be the exception and it would be good to get it consistent if possible. There isn't a "jigsaw mode", and nothing that I can think of that would have an impact on the source structure. > Plus > I recently learned that compact profiles need to be informed when > you do something like this. The profiles build shouldn't be concerned with the source layout as it's the equivalent of an images build. So for the native code then it just needs to know which already-built native libraries to include. I suspect your comment may be related to the refactor of the datatransfer API, in which case it was a java package rather than a native libraries that just a temporary break (no big deal, easily fixed). In time we will replace the profiles build, probably when we move to the modular image as each of the images (JDK, JRE, compact1, compact2, ...) will be just built from a set of modules. -Alan. From magnus.ihse.bursie at oracle.com Fri Aug 29 08:29:54 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 Aug 2014 10:29:54 +0200 Subject: [OpenJDK 2D-Dev] RFR [9] Modular Source Code In-Reply-To: <53FF8599.8080007@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> <53FEEF95.5000702@oracle.com> <53FF770F.2080305@oracle.com> <53FF84AC.20401@oracle.com> <53FF8599.8080007@oracle.com> Message-ID: <54003A02.1040206@oracle.com> On 2014-08-28 21:40, Phil Race wrote: > On 8/28/2014 12:36 PM, Phil Race wrote: >> >> * All of the awt-related directories (libawt_* and common) include an >> unnecessary extra layer, the "sun" directory. It is not needed anymore, >> >> Let's *not* do that. It also affects the destination package. >> Remember sun.* is the protected top-level package .. and >> people won't always be running in jigsaw mode. Plus >> I recently learned that compact profiles need to be informed when >> you do something like this. > > Oh, you refer to the native code that for some reason in libawt > directories (not the others) > has one extra level ? I don't see the same for libfontmanager for > example > Maybe this is one more case where libawt caused excess head-scratching Yes, I am. Sorry if I was not clear on that point -- all my comments refered to the native code. The location of the native code does not have any effects as such on the product. Most other native libraries were "fixed" in this way, but the awt code was left out, probably as you say, due to excess head-scratching. :-) /Mangus From magnus.ihse.bursie at oracle.com Fri Aug 29 08:45:22 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 29 Aug 2014 10:45:22 +0200 Subject: RFR [9] Modular Source Code In-Reply-To: <53FF84AC.20401@oracle.com> References: <3132CBA0-5920-4DDA-8E69-308D5492F0DD@oracle.com> <53EDCA54.2090107@oracle.com> <53EDDD47.2010204@oracle.com> <53F203EF.9070907@oracle.com> <53F20A6C.7090805@oracle.com> <53F466E2.7070501@oracle.com> <53FAFE5C.2060600@oracle.com> <53FDB999.3030001@oracle.com> <53FEEF95.5000702@oracle.com> <53FF770F.2080305@oracle.com> <53FF84AC.20401@oracle.com> Message-ID: <54003DA2.4070109@oracle.com> On 2014-08-28 21:36, Phil Race wrote: > > > ./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c > > Is a tool that is run manually when we need to re-generate the shaders. > It is co-located so that can be found easily. It certainly should not be > deleted, nor should it be moved anywhere obscure. Oh, I see. There was actually some very good documention in the file itself. :) As a general rule, I think the build system should build all tools that is actively used, even if not so frequent, to avoid bit rot. In this case, we could for instance let configure detect the presence of the DirectX SDK, and if present, compile and run the D3DShaderGen tool. This will increase the likelyhood that the tool is actually working when needed, and that the generated header file is kept up to date. > So, yes, decisions on most of these need to be jointly discussed and > reviewed > although some may be better 'owned' by 2d and some by build. I moved all the bugs but one (that is pure makefile logic) to client-libs/2d. I hope that is the correct sub-component. /Magnus From greggwon at cox.net Sat Aug 30 13:52:06 2014 From: greggwon at cox.net (Gregg Wonderly) Date: Sat, 30 Aug 2014 08:52:06 -0500 Subject: JEP 200: The Modular JDK In-Reply-To: References: <20140805164905.CCEA6329BD@eggemoggin.niobe.net>, <53FC8A30.9010506@redhat.com>, <53FC941F.5040306@oracle.com>, <53FDED05.5080106@redhat.com> Message-ID: <5401D706.9010804@cox.net> On 8/27/2014 10:57 AM, mark.reinhold at oracle.com wrote: > 2014/8/27 7:36 -0700, david.lloyd at redhat.com: >> 3. If users want access to a module, they will get it, one way or another >> (this bar is after all far lower than language-level access controls) > Perhaps it's not clear in the JEPs but our intent is, in fact, to > enforce module boundaries via access-control checks in the VM rather > than simple visibility checks in class loaders (which are, as you point > out, trivially defeated). As a long time Jini user, I am very familiar with using JVM SecurityManager implementations to add my own SecurityManager checks for permissions in APIs. If you are planning on using that mechanism, then I would say that would be great, if it can work with any SecurityManager. The issue, of course, is that you need to use whatever SecurityManager a JVM has plugged in at the time, to make sure that you enforce the deployment required security needs, not something that you think will always be appropriate. The implication is then that your have .class visible implementation which can be decompiled, edited and recompiled to remove whatever security access checks that might be deemed unwanted. This is really the issue for many it would seem. Modularity for me, means that I can take things in and out of my deployment to reduce the size of it. And, in particular, I would really like to be able to take out of the deployment, every single .class file that I don't need. In the Jini environment, we do this with a dependency analysis tool so that the downloaded .jar file, at the client, doesn't contain anything more than what is actually needed by the client. What does Modular JDK, at the root of its definition here, really mean to you Mark? Gregg Wonderly