From Alan.Bateman at oracle.com Thu Jan 1 09:16:22 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Jan 2015 09:16:22 +0000 Subject: "Scanning" module contents In-Reply-To: <54A2DE6A.6050807@jetbrains.com> References: <54A2A14D.3040201@gmail.com> <54A2CFA4.4090507@univ-mlv.fr> <54A2DE6A.6050807@jetbrains.com> Message-ID: <54A51066.5070606@oracle.com> On 30/12/2014 17:18, Roman Shevchenko wrote: > Hi R?mi, > > do you by any chance know if there is a legitimate way of doing the > same from another JVM, not the one the scanning code is loaded into? > I've seen your jigsaw-jrtfs, but that patch() part of it feels hacky > and (if I got it right) does not scale to more then one JDK instance. > At this time you can get a reference to jrt:/ for the current runtime (as per Remi's reply and example). It is also possible for a tool running on JDK 8 to create a jrt:/ that provides access to the contents of a JDK 9 runtime image. For this to work then it requires putting $JDK9/jrt-fs.jar on the class path (jrt-fs.jar is intended to be a supported interface, see JEP 220 [1]). Alternatively, for the IDE-like case where you target a runtime image selected by the user then you can use code such as following: String jdkHome = "/yonder/jdk9"; URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL(); URLClassLoader loader = new URLClassLoader(new URL[] { url }); FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), Collections.emptyMap(), loader); Path top = fs.getPath("/"); Files.walk(top).filter(Files::isRegularFile).forEach(System.out::println); In time then we expect to improve on this so that jrt-fs.jar is loaded automatically from the target runtime image. That will allow a tool running on one JDK 9 runtime image to access the contents of another JDK 9 runtime image for example. There are a few issues to sort out before we can get there. -Alan [1] http://openjdk.java.net/jeps/220 From Alan.Bateman at oracle.com Sat Jan 3 09:24:34 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 03 Jan 2015 09:24:34 +0000 Subject: 8067867: Subsume module java.xml.soap into module java.xml.ws Message-ID: <54A7B552.7060807@oracle.com> There are a number of proposed updates to the module graph that we need reflected in the source code layout (and the module graph in JEP 200 [1] will need to be refreshed too). JDK-8067867 tracks dropping the module java.xml.soap and subsuming the API into the java.xml.ws module. The webrevs with the proposed changes are here: http://cr.openjdk.java.net/~alanb/8067867/ The main change is in the jaxws repo to move the source code, the other changes are just the configuration for the build and module graph validation. Miran - it's important that you (or someone in the JAX-WS or EE area) review the moves in the jaxws repository as I assume it will impact the scripts/process that you have for bringing changes from the upstream projects. I'm sure Mandy will review the changes in the top-level and jdk repos so you can ignore those if you want. Thanks, Alan. [1] http://openjdk.java.net/jeps/200 From Alan.Bateman at oracle.com Sat Jan 3 10:01:37 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 03 Jan 2015 10:01:37 +0000 Subject: 8047776: Add module java.transaction to export API javax.transaction Message-ID: <54A7BE01.3040408@oracle.com> This is another update to the module graph, this time it's the quagmire of the Java Transaction API, a subset of which is defined for Java SE for mapping of CORBA exceptions to RMI exceptions and for the XA support in the JDBC API. The proposal is to create a new module (named java.transaction) that exports the API package javax.transaction. EE can provide an upgraded version of this module as they need it. For the source code layout then this means moving the 3 exceptions that were previously in java.corba module to the new module. I've used the opportunity to also move the API package javax.transaction.xa to the jdk repo (Lance - I hope you are okay with the latter, it's just a bit cleaner/understandable to have all of java.sql in the one repo). The webrevs with the proposed changes are here: http://cr.openjdk.java.net/~alanb/8047776/ One annoyance is that exception types don't define a serialVersionUID and so don't compile outside of the java.corba module. The right thing is to add the SUID of course but that subtly changes the spec in that SUID will show up in the serialized form. To avoid getting stuck in the mud then I've created a new issue JDK-8068413 to track this (it really needs JSR 907 to define the SUID for each of its serialized types) and added @SuppressWarnings("serial") to these exceptions. -Alan From miroslav.kos at oracle.com Mon Jan 5 09:30:43 2015 From: miroslav.kos at oracle.com (Miroslav Kos) Date: Mon, 05 Jan 2015 10:30:43 +0100 Subject: 8067867: Subsume module java.xml.soap into module java.xml.ws In-Reply-To: <54A7B552.7060807@oracle.com> References: <54A7B552.7060807@oracle.com> Message-ID: <54AA59C3.1010307@oracle.com> Hi Alan, no problem, the change is simple, will adjusting our integration scripts. Thanks Miran On 03/01/15 10:24, Alan Bateman wrote: > > There are a number of proposed updates to the module graph that we > need reflected in the source code layout (and the module graph in JEP > 200 [1] will need to be refreshed too). JDK-8067867 tracks dropping > the module java.xml.soap and subsuming the API into the java.xml.ws > module. > > The webrevs with the proposed changes are here: > http://cr.openjdk.java.net/~alanb/8067867/ > > The main change is in the jaxws repo to move the source code, the > other changes are just the configuration for the build and module > graph validation. > > Miran - it's important that you (or someone in the JAX-WS or EE area) > review the moves in the jaxws repository as I assume it will impact > the scripts/process that you have for bringing changes from the > upstream projects. I'm sure Mandy will review the changes in the > top-level and jdk repos so you can ignore those if you want. > > Thanks, > Alan. > > [1] http://openjdk.java.net/jeps/200 From Alan.Bateman at oracle.com Mon Jan 5 12:12:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Jan 2015 12:12:02 +0000 Subject: 8047776: Add module java.transaction to export API javax.transaction In-Reply-To: <32451809-1336-446B-83C1-1AE150225CD1@oracle.com> References: <54A7BE01.3040408@oracle.com> <32451809-1336-446B-83C1-1AE150225CD1@oracle.com> Message-ID: <54AA7F92.5090607@oracle.com> On 03/01/2015 14:49, Lance Andersen wrote: > Hi Alan, > > I think this looks fine and of course I am OK with where you moved > javax.transaction.xa > > > I am not sure we need to have an MR for the SerialVersionUID given the > serialization spec defines how the default is calculated so just > adding the value does not change the behavior. I know it now shows up > in the serialized form but given the signature tests do not report > whether the field is or is not there (just went through this exercise > with JMS as they did not specify the SUID and updated JMSException > which caused failures on WLS.), I would like to think Paul can handle > this as part of his next MR and we can make the change ahead of time. > I will follow up with Bill and Paul as Bill and I had talked about > addressing default SUID issues in Java EE. > > Thanks Lance. My hesitation with adding the SUID is that it would mean that the Java SE subset of javax.transaction would temporarily be ahead of the JTA / EE specification. However if this is something that can be fixed in a JTA update in the JDK 9 timeframe then I think it should be okay. -Alan. From mandy.chung at oracle.com Mon Jan 5 17:24:37 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 05 Jan 2015 09:24:37 -0800 Subject: 8067867: Subsume module java.xml.soap into module java.xml.ws In-Reply-To: <54A7B552.7060807@oracle.com> References: <54A7B552.7060807@oracle.com> Message-ID: <54AAC8D5.5000207@oracle.com> On 1/3/15 1:24 AM, Alan Bateman wrote: > > There are a number of proposed updates to the module graph that we > need reflected in the source code layout (and the module graph in JEP > 200 [1] will need to be refreshed too). JDK-8067867 tracks dropping > the module java.xml.soap and subsuming the API into the java.xml.ws > module. > > The webrevs with the proposed changes are here: > http://cr.openjdk.java.net/~alanb/8067867/ > This patch looks good to me. Mandy From mandy.chung at oracle.com Mon Jan 5 18:07:06 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 05 Jan 2015 10:07:06 -0800 Subject: 8047776: Add module java.transaction to export API javax.transaction In-Reply-To: <54A7BE01.3040408@oracle.com> References: <54A7BE01.3040408@oracle.com> Message-ID: <54AAD2CA.30102@oracle.com> On 1/3/15 2:01 AM, Alan Bateman wrote: > > This is another update to the module graph, this time it's the > quagmire of the Java Transaction API, a subset of which is defined for > Java SE for mapping of CORBA exceptions to RMI exceptions and for the > XA support in the JDBC API. > > The proposal is to create a new module (named java.transaction) that > exports the API package javax.transaction. EE can provide an upgraded > version of this module as they need it. For the source code layout > then this means moving the 3 exceptions that were previously in > java.corba module to the new module. I've used the opportunity to also > move the API package javax.transaction.xa to the jdk repo (Lance - I > hope you are okay with the latter, it's just a bit > cleaner/understandable to have all of java.sql in the one repo). > > The webrevs with the proposed changes are here: > http://cr.openjdk.java.net/~alanb/8047776/ > Looks good to me. It's good to see javax.transaction.xa moved to the jdk repo that does make it a bit cleaner and understandable. Mandy From roman.shevchenko at jetbrains.com Mon Jan 5 20:19:54 2015 From: roman.shevchenko at jetbrains.com (Roman Shevchenko) Date: Mon, 05 Jan 2015 21:19:54 +0100 Subject: "Scanning" module contents In-Reply-To: <54A51066.5070606@oracle.com> References: <54A2A14D.3040201@gmail.com> <54A2CFA4.4090507@univ-mlv.fr> <54A2DE6A.6050807@jetbrains.com> <54A51066.5070606@oracle.com> Message-ID: <54AAF1EA.2060409@jetbrains.com> Thanks! Yep, I was looking exactly for the IDE case. Regarding scanning JDK 9 from other JDK 9 - I'm extremly interested in this case too. Is there any way I may be notified once the case is resolved? On 01.01.2015 10:16, Alan Bateman wrote: > On 30/12/2014 17:18, Roman Shevchenko wrote: >> Hi R?mi, >> >> do you by any chance know if there is a legitimate way of doing the >> same from another JVM, not the one the scanning code is loaded into? >> I've seen your jigsaw-jrtfs, but that patch() part of it feels hacky >> and (if I got it right) does not scale to more then one JDK instance. >> > At this time you can get a reference to jrt:/ for the current runtime > (as per Remi's reply and example). > > It is also possible for a tool running on JDK 8 to create a jrt:/ that > provides access to the contents of a JDK 9 runtime image. For this to > work then it requires putting $JDK9/jrt-fs.jar on the class path > (jrt-fs.jar is intended to be a supported interface, see JEP 220 [1]). > Alternatively, for the IDE-like case where you target a runtime image > selected by the user then you can use code such as following: > > String jdkHome = "/yonder/jdk9"; > > URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL(); > URLClassLoader loader = new URLClassLoader(new URL[] { url }); > FileSystem fs = FileSystems.newFileSystem(URI.create("jrt:/"), > Collections.emptyMap(), > loader); > Path top = fs.getPath("/"); > Files.walk(top).filter(Files::isRegularFile).forEach(System.out::println); > > > In time then we expect to improve on this so that jrt-fs.jar is loaded > automatically from the target runtime image. That will allow a tool > running on one JDK 9 runtime image to access the contents of another > JDK 9 runtime image for example. There are a few issues to sort out > before we can get there. > > -Alan > > [1] http://openjdk.java.net/jeps/220 From Alan.Bateman at oracle.com Tue Jan 6 10:03:15 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Jan 2015 10:03:15 +0000 Subject: "Scanning" module contents In-Reply-To: <54AAF1EA.2060409@jetbrains.com> References: <54A2A14D.3040201@gmail.com> <54A2CFA4.4090507@univ-mlv.fr> <54A2DE6A.6050807@jetbrains.com> <54A51066.5070606@oracle.com> <54AAF1EA.2060409@jetbrains.com> Message-ID: <54ABB2E3.10906@oracle.com> On 05/01/2015 20:19, Roman Shevchenko wrote: > Thanks! Yep, I was looking exactly for the IDE case. > > Regarding scanning JDK 9 from other JDK 9 - I'm extremly interested in > this case too. Is there any way I may be notified once the case is > resolved? You are on the right mailing list for any discussion/code-review on this topic. The solution that we have in mind is that the java.home of the target JDK be specified when creating the file system. There are a few other issues to sort out first but we know that more flexibility is required in this area. -Alan From rkennke at redhat.com Wed Jan 7 20:15:22 2015 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 07 Jan 2015 21:15:22 +0100 Subject: Problem using -Xbootclasspath/p Message-ID: <1420661722.6838.21.camel@localhost> Hi there, I'm sending to this mailing list as it seems likely to me to be a problem related to Jigsaw (not sure). I try to run SpecJVM2008 using a recent JDK9 checkout. When I pass -Xbootclasspath/p:lib/javac.jar (which is required for SpecJVM2008 currently to run with OpenJDK) I get: Fatal Error: Unable to find package java.lang in classpath or bootclasspath It works with OpenJDK8. The full command to run SPECjvm2008 is: images/jdk/bin/java -Xms1g -Xmx1g -jar SPECjvm2008.jar -ikv compiler.compiler compress crypto.aes crypto.rsa crypto.signverify derby mpegaudio scimark.fft.large scimark.lu.large scimark.sor.large scimark.sparse.large scimark.fft.small scimark.lu.small scimark.sor.small scimark.sparse.small scimark.monte_carlo serial sunflow xml.transform xml.validation Is there a known issue related to bootclasspath handling in JDK9? Or maybe something changed and I'm doing it wrong? Regards, Roman From jonathan.gibbons at oracle.com Wed Jan 7 21:00:28 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Jan 2015 13:00:28 -0800 Subject: Problem using -Xbootclasspath/p In-Reply-To: <1420661722.6838.21.camel@localhost> References: <1420661722.6838.21.camel@localhost> Message-ID: <54AD9E6C.70307@oracle.com> On 01/07/2015 12:15 PM, Roman Kennke wrote: > Hi there, > > I'm sending to this mailing list as it seems likely to me to be a > problem related to Jigsaw (not sure). > > I try to run SpecJVM2008 using a recent JDK9 checkout. When I pass > -Xbootclasspath/p:lib/javac.jar (which is required for SpecJVM2008 > currently to run with OpenJDK) I get: > > Fatal Error: Unable to find package java.lang in classpath or > bootclasspath > > It works with OpenJDK8. > > The full command to run SPECjvm2008 is: > > images/jdk/bin/java -Xms1g -Xmx1g -jar SPECjvm2008.jar -ikv > compiler.compiler compress crypto.aes crypto.rsa crypto.signverify derby > mpegaudio scimark.fft.large scimark.lu.large scimark.sor.large > scimark.sparse.large scimark.fft.small scimark.lu.small > scimark.sor.small scimark.sparse.small scimark.monte_carlo serial > sunflow xml.transform xml.validation > > Is there a known issue related to bootclasspath handling in JDK9? Or > maybe something changed and I'm doing it wrong? > > Regards, > Roman > Roman, From the message, I would say that the javac in javac.jar is trying to access the platform classes, and not recognizing that they are now in the platform image instead of rt.jar. You need to either change your copy of javac, or else make it so that when you run javac from SPECjvm2008, you specify a -bootclasspath pointing to a suitable copy of rt.jar. -- Jon From Alan.Bateman at oracle.com Wed Jan 7 21:06:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Jan 2015 21:06:11 +0000 Subject: Problem using -Xbootclasspath/p In-Reply-To: <1420661722.6838.21.camel@localhost> References: <1420661722.6838.21.camel@localhost> Message-ID: <54AD9FC3.7060104@oracle.com> On 07/01/2015 20:15, Roman Kennke wrote: > Hi there, > > I'm sending to this mailing list as it seems likely to me to be a > problem related to Jigsaw (not sure). > > I try to run SpecJVM2008 using a recent JDK9 checkout. When I pass > -Xbootclasspath/p:lib/javac.jar (which is required for SpecJVM2008 > currently to run with OpenJDK) I get: > > Fatal Error: Unable to find package java.lang in classpath or > bootclasspath > > It works with OpenJDK8. > > The full command to run SPECjvm2008 is: > > images/jdk/bin/java -Xms1g -Xmx1g -jar SPECjvm2008.jar -ikv > compiler.compiler compress crypto.aes crypto.rsa crypto.signverify derby > mpegaudio scimark.fft.large scimark.lu.large scimark.sor.large > scimark.sparse.large scimark.fft.small scimark.lu.small > scimark.sor.small scimark.sparse.small scimark.monte_carlo serial > sunflow xml.transform xml.validation > > Is there a known issue related to bootclasspath handling in JDK9? Or > maybe something changed and I'm doing it wrong? > This looks like it's an error come from the code in javac.jar rather than anything to do with -Xbootclasspath/p. Is it possible for SPECjvm98 to run with the javac in the JDK image rather than the (old copy?) in javac.jar that pre-images the runtime image work? That said, I expect that later in JDK 9 that we will need to drop -Xbootclasspath/p and replace it with a means to override classes in modules. -Alan From jonathan.gibbons at oracle.com Wed Jan 7 22:15:04 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 07 Jan 2015 14:15:04 -0800 Subject: Problem using -Xbootclasspath/p In-Reply-To: <54AD9FC3.7060104@oracle.com> References: <1420661722.6838.21.camel@localhost> <54AD9FC3.7060104@oracle.com> Message-ID: <54ADAFE8.3010907@oracle.com> On 01/07/2015 01:06 PM, Alan Bateman wrote: > This looks like it's an error come from the code in javac.jar rather > than anything to do with -Xbootclasspath/p. Is it possible for > SPECjvm98 to run with the javac in the JDK image rather than the (old > copy?) in javac.jar that pre-images the runtime image work? > > That said, I expect that later in JDK 9 that we will need to drop > -Xbootclasspath/p and replace it with a means to override classes in > modules. > > -Alan Alan, In this context, javac.jar does not so much contain "a utility for transforming .java files .class files" as much as "a significant body of open source code suitable for testing the performance of a JVM". In that context, it would not be appropriate to change javac.jar more than necessary. -- Jon From Alan.Bateman at oracle.com Thu Jan 8 11:10:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 Jan 2015 11:10:04 +0000 Subject: Problem using -Xbootclasspath/p In-Reply-To: <54ADAFE8.3010907@oracle.com> References: <1420661722.6838.21.camel@localhost> <54AD9FC3.7060104@oracle.com> <54ADAFE8.3010907@oracle.com> Message-ID: <54AE658C.50006@oracle.com> On 07/01/2015 22:15, Jonathan Gibbons wrote: > : > > Alan, > > In this context, javac.jar does not so much contain "a utility for > transforming .java files .class files" as much as "a significant body > of open source code suitable for testing the performance of a JVM". > In that context, it would not be appropriate to change javac.jar more > than necessary. > Right, if Roman is running SPECjvm98 for benchmark purposes (as opposed to using it as part of a quality test run) then upgrading javac means it would be a different benchmark. However some change (maybe -bootclasspath as you suggest) is required because it seems to be an older version of javac that doesn't know anything about the new runtime image. -Alan From rkennke at redhat.com Thu Jan 8 11:23:13 2015 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 08 Jan 2015 12:23:13 +0100 Subject: Problem using -Xbootclasspath/p In-Reply-To: <54AE658C.50006@oracle.com> References: <1420661722.6838.21.camel@localhost> <54AD9FC3.7060104@oracle.com> <54ADAFE8.3010907@oracle.com> <54AE658C.50006@oracle.com> Message-ID: <1420716193.6838.29.camel@localhost> Hi, thanks for your replies. If I leave out the -Xbootclasspath stuff, then it blows up because of some clash (I think it uses its old javac.jar in the normal classpath then). I can't check it right now, but iirc, it found the signer information of some javac related class is different than the signer information of another class in the same package or such. I'm currently using it for testing. I can skip the compiler benchmarks for now. However, it is a nice test-benchmark because it does lots and lots of allocations, would be nice to have it working. I hope SPEC releases an updated SPECjvm soon. It has been somewhat broken since JDK8, and now even more... Regards, Roman Am Donnerstag, den 08.01.2015 um 11:10 +0000 schrieb Alan Bateman: > On 07/01/2015 22:15, Jonathan Gibbons wrote: > > : > > > > Alan, > > > > In this context, javac.jar does not so much contain "a utility for > > transforming .java files .class files" as much as "a significant body > > of open source code suitable for testing the performance of a JVM". > > In that context, it would not be appropriate to change javac.jar more > > than necessary. > > > Right, if Roman is running SPECjvm98 for benchmark purposes (as opposed > to using it as part of a quality test run) then upgrading javac means it > would be a different benchmark. However some change (maybe > -bootclasspath as you suggest) is required because it seems to be an > older version of javac that doesn't know anything about the new runtime > image. > > -Alan From Lance.Andersen at oracle.com Sat Jan 3 14:49:00 2015 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Sat, 3 Jan 2015 09:49:00 -0500 Subject: 8047776: Add module java.transaction to export API javax.transaction In-Reply-To: <54A7BE01.3040408@oracle.com> References: <54A7BE01.3040408@oracle.com> Message-ID: <32451809-1336-446B-83C1-1AE150225CD1@oracle.com> Hi Alan, I think this looks fine and of course I am OK with where you moved javax.transaction.xa I am not sure we need to have an MR for the SerialVersionUID given the serialization spec defines how the default is calculated so just adding the value does not change the behavior. I know it now shows up in the serialized form but given the signature tests do not report whether the field is or is not there (just went through this exercise with JMS as they did not specify the SUID and updated JMSException which caused failures on WLS.), I would like to think Paul can handle this as part of his next MR and we can make the change ahead of time. I will follow up with Bill and Paul as Bill and I had talked about addressing default SUID issues in Java EE. Best, Lance On Jan 3, 2015, at 5:01 AM, Alan Bateman wrote: > > This is another update to the module graph, this time it's the quagmire of the Java Transaction API, a subset of which is defined for Java SE for mapping of CORBA exceptions to RMI exceptions and for the XA support in the JDBC API. > > The proposal is to create a new module (named java.transaction) that exports the API package javax.transaction. EE can provide an upgraded version of this module as they need it. For the source code layout then this means moving the 3 exceptions that were previously in java.corba module to the new module. I've used the opportunity to also move the API package javax.transaction.xa to the jdk repo (Lance - I hope you are okay with the latter, it's just a bit cleaner/understandable to have all of java.sql in the one repo). > > The webrevs with the proposed changes are here: > http://cr.openjdk.java.net/~alanb/8047776/ > > One annoyance is that exception types don't define a serialVersionUID and so don't compile outside of the java.corba module. The right thing is to add the SUID of course but that subtly changes the spec in that SUID will show up in the serialized form. To avoid getting stuck in the mud then I've created a new issue JDK-8068413 to track this (it really needs JSR 907 to define the SUID for each of its serialized types) and added @SuppressWarnings("serial") to these exceptions. > > -Alan > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Lance.Andersen at oracle.com Mon Jan 5 20:03:14 2015 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 5 Jan 2015 15:03:14 -0500 Subject: 8047776: Add module java.transaction to export API javax.transaction In-Reply-To: <54AA7F92.5090607@oracle.com> References: <54A7BE01.3040408@oracle.com> <32451809-1336-446B-83C1-1AE150225CD1@oracle.com> <54AA7F92.5090607@oracle.com> Message-ID: On Jan 5, 2015, at 7:12 AM, Alan Bateman wrote: > On 03/01/2015 14:49, Lance Andersen wrote: >> Hi Alan, >> >> I think this looks fine and of course I am OK with where you moved javax.transaction.xa >> >> >> I am not sure we need to have an MR for the SerialVersionUID given the serialization spec defines how the default is calculated so just adding the value does not change the behavior. I know it now shows up in the serialized form but given the signature tests do not report whether the field is or is not there (just went through this exercise with JMS as they did not specify the SUID and updated JMSException which caused failures on WLS.), I would like to think Paul can handle this as part of his next MR and we can make the change ahead of time. I will follow up with Bill and Paul as Bill and I had talked about addressing default SUID issues in Java EE. >> >> > Thanks Lance. My hesitation with adding the SUID is that it would mean that the Java SE subset of javax.transaction would temporarily be ahead of the JTA / EE specification. However if this is something that can be fixed in a JTA update in the JDK 9 timeframe then I think it should be okay. > Discussion is started and I am talking with all of the Java EE architects on Jan 26 at the arch meeting. So this should be doable. Best, Lance > -Alan. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Rony.Flatscher at wu.ac.at Mon Jan 12 16:09:09 2015 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 12 Jan 2015 17:09:09 +0100 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? Message-ID: <54B3F1A5.3080903@wu.ac.at> Hi there, reading References: <54B3F1A5.3080903@wu.ac.at> Message-ID: <54B4D4E2.9000003@univ-mlv.fr> Hi Rony, does javax.script discovery implementation use java.util.ServiceLoader convention ? If the answer is yes, then it will work out of the box. cheers, R?mi On 01/12/2015 05:09 PM, Rony G. Flatscher wrote: > Hi there, > > reading regarding the removal of the "extension" mechanism and what can be used instead? > > There is one particular use-case that I regard to be of tremendeous importance for the Java world, > recognizing that many Java movers and shakers do not really realize ;) : making javax.script > scripting languages available to Java applications. > > Background: I served as an expert on JSR-223 which defined javax.script (personal background: Apache > Commons BSF scripting framework, BSF4ooRexx a JNI-bridge to the opensource ooRexx.org scripting > language, which itself is implemented in C++, creator of the Apache OpenOffice AOO ooRexx plugin > using the AOO Java scripting framework, teaching at a Business University among other things > scripting, ...). > > "javax.script" defines a discovery mechanism which allows a Java app to enumerate all available > scripting engines. This way all discoverable (= installed) javax.script engines are available to any > Java app and script/macro programmers. As a result the (end) users become able to pick the script > language they wish to use to create macros/scripts for their Java application. [An example would be > Apache OpenOffice (AOO), which allows using any script language, provided it is made available via > AOOs Java based scripting framework, like BeanShell, JavaScript, ooRexx, et.al.] > > Please note, that a Java application developer may not even (and need not) know in advance which > javax.script engines will be available on a target installation, just that it is rather easy to > enumerate the javax.script engines available to it and allow the (end) user programmer to pick one > for creating scripts targeted at the Java application. > > --- > > Currently (in pre-Java 9 environments), if one wishes to use javax.script engines (e.g. in web > browsers via the Oracle browser Java plugin and in parallel in other Java apps), one can make any > javax.script engine available by placing it in the Java "extension" directory, which works even > then, when Java apps (like the Oracle browser Java plugin or AOO) does not honor the CLASSPATH > environment variable. > > Now, having learned that JDK 9 will remove the "extension" mechanism, I am very interested in > learning what alternatives are discussed, planned for Java 9 to enable this particular important > use-case: making javax.script engines (packaged as jars) available to any Java app! > > TIA, > > ---rony > > From Rony.Flatscher at wu.ac.at Tue Jan 13 11:43:33 2015 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 13 Jan 2015 12:43:33 +0100 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: <54B4D4E2.9000003@univ-mlv.fr> References: <54B3F1A5.3080903@wu.ac.at> <54B4D4E2.9000003@univ-mlv.fr> Message-ID: <54B504E5.6040202@wu.ac.at> Hi R?mi, On 13.01.2015 09:18, Remi Forax wrote: > does javax.script discovery implementation use java.util.ServiceLoader convention ? The discovery mechanism relies on (cf. ): 5. *Script engine discovery and Metadata*: Applications written to the Scripting API might have specific requirements on script engines. Some may require a specific scripting language and/or version while others may require a specific implementation engine and/or version. Script engines are packaged in a specified way so that engines can be discovered at runtime and queried for attributes. The Engine discovery mechanism is based on the Service discovery mechanism described in the *Jar File Specification*. Script engine implementing classes are packaged in jar files that include a text resource named *META-INF/services/javax.script.ScriptEngineFactory*. This resource must include a line for each |ScriptEngineFactory| that is packaged in the jar file. |ScriptEngineManager| includes |getEngineFactories| method to get all |ScriptEngineFactory| instances discovered using this mechanism. |ScriptEngineFactory| has methods to query attributes about script engine. Not sure whether this matches the java.util.ServiceLoader convention. > If the answer is yes, then it will work out of the box. If the answer would be yes, how would one make access to such a scripting engine jar available (e.g. to Java code running from the Oracle Java plugin in a browser), what needs to be configured where? TIA, ---rony > > On 01/12/2015 05:09 PM, Rony G. Flatscher wrote: >> Hi there, >> >> reading > regarding the removal of the "extension" mechanism and what can be used instead? >> >> There is one particular use-case that I regard to be of tremendeous importance for the Java world, >> recognizing that many Java movers and shakers do not really realize ;) : making javax.script >> scripting languages available to Java applications. >> >> Background: I served as an expert on JSR-223 which defined javax.script (personal background: Apache >> Commons BSF scripting framework, BSF4ooRexx a JNI-bridge to the opensource ooRexx.org scripting >> language, which itself is implemented in C++, creator of the Apache OpenOffice AOO ooRexx plugin >> using the AOO Java scripting framework, teaching at a Business University among other things >> scripting, ...). >> >> "javax.script" defines a discovery mechanism which allows a Java app to enumerate all available >> scripting engines. This way all discoverable (= installed) javax.script engines are available to any >> Java app and script/macro programmers. As a result the (end) users become able to pick the script >> language they wish to use to create macros/scripts for their Java application. [An example would be >> Apache OpenOffice (AOO), which allows using any script language, provided it is made available via >> AOOs Java based scripting framework, like BeanShell, JavaScript, ooRexx, et.al.] >> >> Please note, that a Java application developer may not even (and need not) know in advance which >> javax.script engines will be available on a target installation, just that it is rather easy to >> enumerate the javax.script engines available to it and allow the (end) user programmer to pick one >> for creating scripts targeted at the Java application. >> >> --- >> >> Currently (in pre-Java 9 environments), if one wishes to use javax.script engines (e.g. in web >> browsers via the Oracle browser Java plugin and in parallel in other Java apps), one can make any >> javax.script engine available by placing it in the Java "extension" directory, which works even >> then, when Java apps (like the Oracle browser Java plugin or AOO) does not honor the CLASSPATH >> environment variable. >> >> Now, having learned that JDK 9 will remove the "extension" mechanism, I am very interested in >> learning what alternatives are discussed, planned for Java 9 to enable this particular important >> use-case: making javax.script engines (packaged as jars) available to any Java app! >> >> TIA, >> >> ---rony From Alan.Bateman at oracle.com Fri Jan 16 15:39:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Jan 2015 15:39:02 +0000 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: <54B3F1A5.3080903@wu.ac.at> References: <54B3F1A5.3080903@wu.ac.at> Message-ID: <54B93096.9000801@oracle.com> On 12/01/2015 16:09, Rony G. Flatscher wrote: > : > > Now, having learned that JDK 9 will remove the "extension" mechanism, I am very interested in > learning what alternatives are discussed, planned for Java 9 to enable this particular important > use-case: making javax.script engines (packaged as jars) available to any Java app! > > Yes, the extension mechanism and specifically the discovery of installed optional packages has been removed in JDK 9. In general then we haven't seen a lot of usage of this mechanism in a long time (it's problematic when upgrading or switching JDKs for example). For standalone applications then you can put the service provider JARs (in this this case a scripting engine) on the class path and it should just work the same as if you had copied it into the extensions directory. The only difference might be if you are running with a security manager then you might have to configure the security policy whereas in JDK 8 and older then you might have replied on it getting AllPermission (this is something that is also changed in JDK 9, code loaded by the extension class loader does not get AllPermission by default now). The applet scenario that you bring up is interesting in that it assumes that the users of the applet have copied the scripting engine into their ext directory. That is, I think that is what you mean rather than JAR packaged applets triggering the download of optional packages. I wonder if you've tried creating the applet with JNLP and putting a reference to the scripting engine in the resources section? In any case, once JDK 9 is further along then we expect to have support for runtime images that are built by linking a set of module so that might be an alternative approach to having a runtime image with the scripting engines available. -Alan From Rony.Flatscher at wu.ac.at Mon Jan 19 12:28:21 2015 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Mon, 19 Jan 2015 13:28:21 +0100 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: <54B93096.9000801@oracle.com> References: <54B3F1A5.3080903@wu.ac.at> <54B93096.9000801@oracle.com> Message-ID: <54BCF865.4090105@wu.ac.at> Hi Alan, On 16.01.2015 16:39, Alan Bateman wrote: > On 12/01/2015 16:09, Rony G. Flatscher wrote: >> : >> >> Now, having learned that JDK 9 will remove the "extension" mechanism, I am very interested in >> learning what alternatives are discussed, planned for Java 9 to enable this particular important >> use-case: making javax.script engines (packaged as jars) available to any Java app! >> >> > Yes, the extension mechanism and specifically the discovery of installed optional packages has > been removed in JDK 9. In general then we haven't seen a lot of usage of this mechanism in a long > time (it's problematic when upgrading or switching JDKs for example). Yes, that has been probably the reason, why starting with Java 6 a version independent ext-directory got defined (cf. ). Ad "not seeing a lot of usage": probably only those take advantage of the extension mechanism who have no alternative to it. So it would make sense that only a few use it, but for them it is probable, that it is of high importance. (Speculation: I would also expect that many of those will only realize the missing of the extension mechanism, once Java 9 gets GA and is planned to be deployed. The alternative for those affected in such a scenario would be to stick to their older Java deployments, if no alternative to the extension mechanism becomes availabel.) > For standalone applications then you can put the service provider JARs (in this this case a > scripting engine) on the class path and it should just work the same as if you had copied it into > the extensions directory. The only difference might be if you are running with a security manager > then you might have to configure the security policy whereas in JDK 8 and older then you might > have replied on it getting AllPermission (this is something that is also changed in JDK 9, code > loaded by the extension class loader does not get AllPermission by default now). This works only, if the application honors the CLASSPATH environment variable or if it becomes possible for oneself to supply the classpath information upon startup of the application. Unfortunately, this is not always the case/possible. E.g OpenOffice starts from native code and uses JNI to interface with Java using its own classloader that ignores the CLASSPATH envrionment variable. > The applet scenario that you bring up is interesting in that it assumes that the users of the > applet have copied the scripting engine into their ext directory. In this concrete example the scripting engine (ooRexx) is not written in Java, but in C++. The support for ooRexx for Java gets installed via the BSF4ooRexx package, such that it is feasible to supply the scripting jar to the extension directory once and have all Java apps, including the Java plugin, access that script engine thereafter, without any additional configuration needs. > That is, I think that is what you mean rather than JAR packaged applets triggering the download of > optional packages. I wonder if you've tried creating the applet with JNLP and putting a reference > to the scripting engine in the resources section? Will look into this for this particular scenario (making scripting engines accessible via Java plugin) as one can use the Java plugin to download resources. However, preliminary experiments with the Java plugin (quite a while ago, then deciding to place the script jar simply into an extension directory which solved the problem for all versions of Java) where everything packaged in a jar was quite cumbersome and caused nightmare in configuration and resource overhead, removing also quite soem flexibility. Having the Java plugin in place and access to javax.script jars from it (without any need on the user side for configuration), would solve the problem, if the Java plugin would cater for that (it also would make the Java plugin interesting for many scripting language aficionados, if all javax.script languages could be used for scripting x|html in lieu of JavaScript, just by setting the language attribute on the script tag; the Java plugin could probably allow for such a functionality). > In any case, once JDK 9 is further along then we expect to have support for runtime images that > are built by linking a set of module so that might be an alternative approach to having a runtime > image with the scripting engines available. This sounds very interesting, hoping that it becomes possible with it to define for certain applications (in this particular important case, the Java plugin for browsers) the modules that should be made available to them. (Pure speculation, expecting that an installation program becomes able to check out the Java version and whether certain applications are installed, configuring those applications to get access to the installed jars/modules, if running under Java 9 or higher.) Where would one be able to learn (about and experiment with) what you are creating/thinking here as a replacement? Maybe there are some blogs sketching the ideas, possibilities? ---rony From Alan.Bateman at oracle.com Mon Jan 19 19:26:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Jan 2015 19:26:04 +0000 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: <54BCF865.4090105@wu.ac.at> References: <54B3F1A5.3080903@wu.ac.at> <54B93096.9000801@oracle.com> <54BCF865.4090105@wu.ac.at> Message-ID: <54BD5A4C.20609@oracle.com> On 19/01/2015 12:28, Rony G. Flatscher wrote: > : > > (Speculation: I would also expect that many of those will only realize the missing of the extension > mechanism, once Java 9 gets GA and is planned to be deployed. The alternative for those affected in > such a scenario would be to stick to their older Java deployments, if no alternative to the > extension mechanism becomes availabel.) The changes to deprecate this legacy mechanism are in the 8u40 EA builds and a MR of JSR 337 is in the works with a section on deprecating this mechanism. I'm sure there will be Oracle documentation too. One useful command-line option in the 8u40 EA builds is -XX:+CheckEndorsedAndExtDirs to help identify if this mechanism (or the endorsed standards override mechanism) are being used. So lots of preparation as we know well that removing anything has the potential to being pain. > : > > Unfortunately, this is not always the case/possible. E.g OpenOffice starts from native code and uses > JNI to interface with Java using its own classloader that ignores the CLASSPATH envrionment variable. If OpenOffice is shipping with a JRE and additional scripting engines in the ext directory then it might be a candidate to create a custom image with the modules that it needs (including any scripting engines). > : > > Where would one be able to learn (about and experiment with) what you are creating/thinking here as > a replacement? Maybe there are some blogs sketching the ideas, possibilities? > You are on the right mailing list and I'm sure there will be lots of discussion in time. -Alan From niftiness at gmail.com Tue Jan 20 01:53:17 2015 From: niftiness at gmail.com (Tim Boudreau) Date: Mon, 19 Jan 2015 20:53:17 -0500 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: <54BCF865.4090105@wu.ac.at> References: <54B3F1A5.3080903@wu.ac.at> <54B93096.9000801@oracle.com> <54BCF865.4090105@wu.ac.at> Message-ID: > > Ad "not seeing a lot of usage": probably only those take advantage of the > extension mechanism who > have no alternative to it. So it would make sense that only a few use it, > but for them it is > probable, that it is of high importance. > I'll express some kudos for the removal of that. Until you've worked full-time on an application where its users have random undiagnosable bugs caused because some other application installed something buggy into the JDK system-wide (ancient, broken versions of XML parsers come to mind), you can't appreciate how horrific a mistake it was to ever permit this sort of thing. It was a mistake that it ever existed, probably caused by someone seeing that that was the model for delivering libraries for Windows in the 90s and thinking that made it an okay thing to do (dll-hell, anyone?). It never was, and there are decades of evidence to support that conclusion. If OpenOffice or something else needs a list of scripting engines, it should bundle what it needs, or provide a way for users to add more, and make those available. The idea of a magic JDK that grows new features thanks to other applications installing stuff on the system is a recipe for disaster. For the applet scenario, if the server and client do their HTTP cache headers right, there is no practical difference between loading a java extension from disk somewhere in the JDK and using a previously downloaded JAR cached by the browser from disk. It really can't be overstated how bad an idea that was from day one - for stability, for predictable behavior, for knowing what you're running against and for security. -Tim From Rony.Flatscher at wu.ac.at Tue Jan 20 16:40:53 2015 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 20 Jan 2015 17:40:53 +0100 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: References: <54B3F1A5.3080903@wu.ac.at> <54B93096.9000801@oracle.com> <54BCF865.4090105@wu.ac.at> Message-ID: <54BE8514.4020100@wu.ac.at> Hi Tim, On 20.01.2015 02:53, Tim Boudreau wrote: > > Ad "not seeing a lot of usage": probably only those take advantage of the extension mechanism who > have no alternative to it. So it would make sense that only a few use it, but for them it is > probable, that it is of high importance. > > > I'll express some kudos for the removal of that. > > Until you've worked full-time on an application where its users have random undiagnosable bugs > caused because some other application installed something buggy into the JDK system-wide (ancient, > broken versions of XML parsers come to mind), you can't appreciate how horrific a mistake it was > to ever permit this sort of thing. One can tell from such statements, that there are quite some emotions linked to this issue. :) Of course, everything that solves or improves the cause of such nightmares is good as long as there are alternatives for the exploited functionality (there has been a need for it). [I have been around for quite some time too (since Java 1.1 on OS/2) and have experienced all sorts of "horror-because-of-configuration-problems" that BTW continue to this very day. Just today I had to debug a configuration problem with Java 1.8 on 64-bit Windows 7 Enterprise, because the registry entries for 32-bit apps (and 32-bit Java that was installed in addition) pointed erroneously (despite Windows' registry virtualisation) to the 64-bit Java on that particular system, which was used to learn about Java's 32-bit configuration (using java.lang.System's properties).] > It was a mistake that it ever existed, probably caused by someone seeing that that was the model > for delivering libraries for Windows in the 90s and thinking that made it an okay thing to do > (dll-hell, anyone?). It never was, and there are decades of evidence to support that conclusion. Yet, Java 6 extended the extension directory scheme to allow to define directories that are independent of any particular Java version installed. And this functionality serves its purpose at times. However, if there is an alternative that allows solving certain configuration problems, then that would be fine with everyone, I assume. > If OpenOffice or something else needs a list of scripting engines, it should bundle what it needs, > or provide a way for users to add more, and make those available. The idea of a magic JDK that > grows new features thanks to other applications installing stuff on the system is a recipe for > disaster. Probably, I did not explain clearly enough (I am not a native English speaker): the point I tried to make was that even non-Java-applications like OpenOffice that employ Java via JNI may not honor the CLASSPATH environment variable. As a result it is not possible to allow Java from within OpenOffice to access javax.script engines by placing them on the CLASSPATH. [OpenOffice itself is self-contained including the Java modules. The OpenOffice way to add Java modules is its extension mechanism which one needs to learn and to apply.] Probably there are other applications (Java- and non-Java-based ones) that might have a need to be extended dynamically (with the help of the current extension mechanism), hence being interested in what Java 9 defines as an alternative for such scenarios. > For the applet scenario, if the server and client do their HTTP cache headers right, there is no > practical difference between loading a java extension from disk somewhere in the JDK and using a > previously downloaded JAR cached by the browser from disk. This might sound like a possible solution that also could work on older Java installations (have a need for Java 1.6 and up as commercially deployed Java applications might run with older JRE). There is one caveat though: in the case of scripting engines that are implemented with native code and have a JNI bridge to javax.script there is more to be done to the target system than merely downloading a jar package or two. In such a "non-pure Java" scenario the scripting engine with the matching Java support gets installed on the target PCs (once) anyway. Downloading jar versions from the Internet may still cause a "dll-hell"-comparable scenario over time, this time with different types of jars (downloaded via the net) having different dependencies on the native scripting engine (mixing wrong versions, "dll-hell"). For these scenarios it becomes important to make the locally installed native script engine with its companion jars directly available to the locally executing JRE (no matter whether bundled with an app or with a system wide installed JRE). > It really can't be overstated how bad an idea that was from day one - for stability, for > predictable behavior, for knowing what you're running against and for security. :) Not making fun, but inferring that you feel *very* reliefed by the outlook that what you have experienced as a nightmare may be over with Java 9. Probably there are more deployments of the Java extension mechanism in the field, than assumed. Expecting that many of those will experience the loss of this mechanism only when Java 1.9 goes GA. --- In the case of javax.script engines: they are infrastructural and can be added or removed easily from the JRE with the currently supported Java extension mechanism. It is easy for applications using javax.script engines to enumerate the currently available engines at runtime and make them available to applications (e.g. as macro languages for deploying scripts written in a particular engine). Therefore I hope for a general, workable solution for the current extension mechanism in Java 1.9 that does not have the mentioned drawbacks. ---rony P.S.: If it was possible to somehow define such jars for already installed applications that ignore the CLASSPATH environment variable, then most such problems could be solved already. P.P.S.: If one could rely on Java apps to have to honor the CLASSPATH environment variable one way or another, then there would be no problem either. Maybe something crazy like automatically searching a set, but ignored, CLASSPATH environment path, if a class cannot be found (only those fragments that have not been searched yet). From mandy.chung at oracle.com Thu Jan 22 19:45:51 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 22 Jan 2015 11:45:51 -0800 Subject: Review request: JDK-8069414: Rename oracle.accessbridge to jdk.accessbridge Message-ID: <54C1536F.6010603@oracle.com> diff --git a/modules.xml b/modules.xml --- a/modules.xml +++ b/modules.xml @@ -737,7 +737,7 @@ sun.awt - oracle.accessbridge + jdk.accessbridge Mandy From Alan.Bateman at oracle.com Thu Jan 22 19:59:46 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Jan 2015 19:59:46 +0000 Subject: Review request: JDK-8069414: Rename oracle.accessbridge to jdk.accessbridge In-Reply-To: <54C1536F.6010603@oracle.com> References: <54C1536F.6010603@oracle.com> Message-ID: <54C156B2.5060101@oracle.com> Thanks looks okay to me. -Alan From greggwon at cox.net Mon Jan 26 05:59:44 2015 From: greggwon at cox.net (Gregg Wonderly) Date: Sun, 25 Jan 2015 23:59:44 -0600 Subject: A question ad JDK 9 or: how to make all javax.script engines available to all Java apps in JDK 9? In-Reply-To: References: <54B3F1A5.3080903@wu.ac.at> <54B93096.9000801@oracle.com> <54BCF865.4090105@wu.ac.at> Message-ID: <54C5D7D0.4060306@cox.net> On 1/19/2015 7:53 PM, Tim Boudreau wrote: > It really can't be overstated how bad an idea that was from day one - for > stability, for predictable behavior, for knowing what you're running against > and for security. -Tim Indeed! You can list the contents of directories, use URLClassLoader, complete with designation of parent class loaders. It's been a large pain for a lot of people. Gregg Wonderly From weijun.wang at oracle.com Thu Jan 29 14:32:22 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 29 Jan 2015 22:32:22 +0800 Subject: No way to access sun.* in a regression test? Message-ID: <54CA4476.9070005@oracle.com> We have a lot of tests accessing internal classes inside sun.*. Is there still a way to do that? This is closed jake. Thanks Max From Alan.Bateman at oracle.com Thu Jan 29 14:59:14 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Jan 2015 14:59:14 +0000 Subject: No way to access sun.* in a regression test? In-Reply-To: <54CA4476.9070005@oracle.com> References: <54CA4476.9070005@oracle.com> Message-ID: <54CA4AC2.1070300@oracle.com> On 29/01/2015 14:32, Weijun Wang wrote: > We have a lot of tests accessing internal classes inside sun.*. Is > there still a way to do that? There is a requirement listed for that: http://openjdk.java.net/projects/jigsaw/goals-reqs/03#preserve-testability In preparation, code-tools/jtreg tip has a @modules tag that will in time provide a way to declare what the test needs. This is to allow work on the tests to move ahead in jdk9/dev. -Alan From mandy.chung at oracle.com Thu Jan 29 20:58:09 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 29 Jan 2015 12:58:09 -0800 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base Message-ID: <54CA9EE1.2010800@oracle.com> Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 java.security.acl is superceded by java.security package since 1.2. This patch proposes to move java.security.acl package to java.base module rather than complicating the module graph with a close-to-useless dedicated module. Mandy From sean.mullan at oracle.com Thu Jan 29 22:19:38 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Jan 2015 17:19:38 -0500 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CA9EE1.2010800@oracle.com> References: <54CA9EE1.2010800@oracle.com> Message-ID: <54CAB1FA.8020100@oracle.com> Looks fine to me. --Sean On 01/29/2015 03:58 PM, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 > > java.security.acl is superceded by java.security package since 1.2. > > This patch proposes to move java.security.acl package to java.base > module rather than complicating the module graph with a close-to-useless > dedicated module. > > Mandy From Alan.Bateman at oracle.com Fri Jan 30 08:50:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Jan 2015 08:50:41 +0000 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CA9EE1.2010800@oracle.com> References: <54CA9EE1.2010800@oracle.com> Message-ID: <54CB45E1.9070300@oracle.com> On 29/01/2015 20:58, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 > > java.security.acl is superceded by java.security package since 1.2. > > This patch proposes to move java.security.acl package to java.base > module rather than complicating the module graph with a > close-to-useless dedicated module. This looks okay. One small suggestion is to move the lines in unshuffle_list.txt up to where the other java.base paths are. -Alan From mandy.chung at oracle.com Fri Jan 30 17:10:33 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 30 Jan 2015 09:10:33 -0800 Subject: Review request 8069551: Move java.security.acl from compact3 to java.base In-Reply-To: <54CB45E1.9070300@oracle.com> References: <54CA9EE1.2010800@oracle.com> <54CB45E1.9070300@oracle.com> Message-ID: <54CBBB09.9000000@oracle.com> On 1/30/15 12:50 AM, Alan Bateman wrote: > On 29/01/2015 20:58, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00 >> >> java.security.acl is superceded by java.security package since 1.2. >> >> This patch proposes to move java.security.acl package to java.base >> module rather than complicating the module graph with a >> close-to-useless dedicated module. > This looks okay. One small suggestion is to move the lines in > unshuffle_list.txt up to where the other java.base paths are. Yes that's better. Fixed. thanks. Mandy