From offbynull-jigsaw at offbynull.com Thu Jul 2 19:01:35 2015 From: offbynull-jigsaw at offbynull.com (offbynull-jigsaw at offbynull.com) Date: Thu, 2 Jul 2015 12:01:35 -0700 Subject: Module container format Message-ID: <55958A8F.2030103@offbynull.com> The JEP says that the module container format is "implementation-specific" and "subject to change without notice". My concern is that this is going to end up screwing over tool maintainers, such as myself. I maintain an opensource tool that scans through core Java classes for instrumentation purposes. It's supposed to be able to target code written for Java 1.4 and above. I can force my users to use Java9 to run the tool, which means that that the tool will be able to read core Java9 classes via the jrt:/ URL solution. But what happens when Java10 comes out? Will my users be able to scan core classes in Java9 if the tool is running on Java10? So far, it looks like nothing in the JEP covers this. As far as I can tell, the jrt:/ URL solution only reads core classes/resources from the version of Java that the tool is running on. Are there any plans to work around this issue? From Alan.Bateman at oracle.com Thu Jul 2 19:57:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 02 Jul 2015 20:57:41 +0100 Subject: Module container format In-Reply-To: <55958A8F.2030103@offbynull.com> References: <55958A8F.2030103@offbynull.com> Message-ID: <559597B5.6030902@oracle.com> On 02/07/2015 20:01, offbynull-jigsaw at offbynull.com wrote: > The JEP says that the module container format is > "implementation-specific" and "subject to change without notice". My > concern is that this is going to end up screwing over tool > maintainers, such as myself. I maintain an opensource tool that scans > through core Java classes for instrumentation purposes. It's supposed > to be able to target code written for Java 1.4 and above. I can force > my users to use Java9 to run the tool, which means that that the tool > will be able to read core Java9 classes via the jrt:/ URL solution. > But what happens when Java10 comes out? Will my users be able to scan > core classes in Java9 if the tool is running on Java10? > > So far, it looks like nothing in the JEP covers this. As far as I can > tell, the jrt:/ URL solution only reads core classes/resources from > the version of Java that the tool is running on. Search for "jrt-fs.jar" in the JEP. As things stand in JDK 9 then you run the tool on JDK 8 to access the contents of a JDK 9 run-time image or run the tool on JDK 9 to access itself. We're not there yet but eventually it should be possible to run a tool on JDK 9 to access another JDK 9 run-time image (maybe it has a different set of modules) or run on JDK 9 to access a JDK 10 run-time image. -Alan. From offbynull-jigsaw at offbynull.com Fri Jul 3 04:16:17 2015 From: offbynull-jigsaw at offbynull.com (offbynull-jigsaw at offbynull.com) Date: Thu, 2 Jul 2015 21:16:17 -0700 Subject: Module container format In-Reply-To: <559597B5.6030902@oracle.com> References: <55958A8F.2030103@offbynull.com> <559597B5.6030902@oracle.com> Message-ID: <55960C91.10101@offbynull.com> "We're not there yet but eventually it should be possible to run a tool on JDK 9 to access another JDK 9 run-time image (maybe it has a different set of modules) or run on JDK 9 to access a JDK 10 run-time image. " It's disappointing, to say the least, that this wasn't fleshed out for the upcoming Java9 release. It essentially means that maintainers will have to rework their code twice. Once for the release of Java9, and once again when the ability to read another JDK's runtime image becomes a reality (Java10?). Also, the fact that the container format is "implementation-specific" and "subject to change without notice" is also a major red-flag. I suspect that many developers are going to have issues migrating to Java9 due to tool breakages (findbugs, etc..). On 7/2/2015 12:57 PM, Alan Bateman wrote: > On 02/07/2015 20:01, offbynull-jigsaw at offbynull.com wrote: >> The JEP says that the module container format is >> "implementation-specific" and "subject to change without notice". My >> concern is that this is going to end up screwing over tool >> maintainers, such as myself. I maintain an opensource tool that scans >> through core Java classes for instrumentation purposes. It's supposed >> to be able to target code written for Java 1.4 and above. I can force >> my users to use Java9 to run the tool, which means that that the tool >> will be able to read core Java9 classes via the jrt:/ URL solution. >> But what happens when Java10 comes out? Will my users be able to scan >> core classes in Java9 if the tool is running on Java10? >> >> So far, it looks like nothing in the JEP covers this. As far as I can >> tell, the jrt:/ URL solution only reads core classes/resources from >> the version of Java that the tool is running on. > Search for "jrt-fs.jar" in the JEP. As things stand in JDK 9 then you > run the tool on JDK 8 to access the contents of a JDK 9 run-time image > or run the tool on JDK 9 to access itself. > > We're not there yet but eventually it should be possible to run a tool > on JDK 9 to access another JDK 9 run-time image (maybe it has a > different set of modules) or run on JDK 9 to access a JDK 10 run-time > image. > > -Alan. > From adib.saikali at gmail.com Fri Jul 3 06:08:32 2015 From: adib.saikali at gmail.com (Adib Saikali) Date: Fri, 3 Jul 2015 02:08:32 -0400 Subject: Where to find jlink? Message-ID: Hi, I have been seeing references to jlink in a variety of conference talks / blog posts / new articles covering Java 9 for the past few years. However, I can't seem to find it anywhere in the JDK Early access release b70 on Mac OS X. Is there a plan still to include jlink in Java 9? Sorry if this is the the wrong place to ask this question. Cheers Adib From Alan.Bateman at oracle.com Fri Jul 3 06:30:34 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Jul 2015 07:30:34 +0100 Subject: Where to find jlink? In-Reply-To: References: Message-ID: <55962C0A.90800@oracle.com> On 03/07/2015 07:08, Adib Saikali wrote: > Hi, > > I have been seeing references to jlink in a variety of conference talks / > blog posts / new articles covering Java 9 for the past few years. However, > I can't seem to find it anywhere in the JDK Early access release b70 on Mac > OS X. Is there a plan still to include jlink in Java 9? > There isn't a jlink in the JDK 9 builds yet. You should start to see it once there are EA builds with the module system. -Alan. From Alan.Bateman at oracle.com Fri Jul 3 08:30:53 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Jul 2015 09:30:53 +0100 Subject: Module container format In-Reply-To: <55960C91.10101@offbynull.com> References: <55958A8F.2030103@offbynull.com> <559597B5.6030902@oracle.com> <55960C91.10101@offbynull.com> Message-ID: <5596483D.9090506@oracle.com> On 03/07/2015 05:16, offbynull-jigsaw at offbynull.com wrote: > "We're not there yet but eventually it should be possible to run a > tool on JDK 9 to access another JDK 9 run-time image (maybe it has a > different set of modules) or run on JDK 9 to access a JDK 10 run-time > image. " > > It's disappointing, to say the least, that this wasn't fleshed out for > the upcoming Java9 release. It essentially means that maintainers will > have to rework their code twice. If you are using the weekly JDK 9 builds then you are on the bleeding edge and so you need to be prepared to deal with continuous change, esp. when making use of new features and APIs that will go through several iterations before the release is done. In the case of the jrt file system then it might be a bit of work to start using it initially but I wouldn't expect it should be too difficult to keep it up to date as JDK 9 develops. -Alan From mik3hall at gmail.com Sat Jul 4 00:28:57 2015 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 3 Jul 2015 19:28:57 -0500 Subject: jdeps -jdkinternals com.apple Message-ID: <4B6690B3-1711-45AE-82B9-BE93FBB4FF47@gmail.com> Trying jeeps out on a 3rd party jar that I make some use of, the only things it flags are classes like -> "com.apple.eawt.AppEvent (JDK internal API (java.desktop))?; I don?t see any com.apple listed on? https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool These were not really private internal api?s but platform specific functionality that Apple made available to developers. That up to now have been included in openjdk runtimes for OS X. Although I think documentation may of gotten a little more difficult to find. Are these api?s to be continued or discontinued? Michael Hall From Alan.Bateman at oracle.com Sat Jul 4 07:08:20 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 04 Jul 2015 08:08:20 +0100 Subject: jdeps -jdkinternals com.apple In-Reply-To: <4B6690B3-1711-45AE-82B9-BE93FBB4FF47@gmail.com> References: <4B6690B3-1711-45AE-82B9-BE93FBB4FF47@gmail.com> Message-ID: <55978664.6020205@oracle.com> On 04/07/2015 01:28, Michael Hall wrote: > Trying jeeps out on a 3rd party jar that I make some use of, the only things it flags are classes like > > -> "com.apple.eawt.AppEvent (JDK internal API (java.desktop))?; > > I don?t see any com.apple listed on? > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > These were not really private internal api?s but platform specific functionality that Apple made available to developers. That up to now have been included in openjdk runtimes for OS X. Although I think documentation may of gotten a little more difficult to find. Are these api?s to be continued or discontinued? > The com.apple.eawt (and a few others) did come into OpenJDK as part of the OS X port. Unfortunately the supportness has always been murky. AFAIK, folks on awt-dev have been thinking about extending java.awt.Desktop to improve the platform integration. This would provide a standard API and a sensible migration for those using the Apple JDK 6 APIs. I don't know what the status is on this effort as there doesn't seem to be a JEP on it. -Alan From mik3hall at gmail.com Sat Jul 4 08:10:36 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 4 Jul 2015 03:10:36 -0500 Subject: jdeps -jdkinternals com.apple In-Reply-To: <55978664.6020205@oracle.com> References: <4B6690B3-1711-45AE-82B9-BE93FBB4FF47@gmail.com> <55978664.6020205@oracle.com> Message-ID: > On Jul 4, 2015, at 2:08 AM, Alan Bateman wrote: > > AFAIK, folks on awt-dev have been thinking about extending java.awt.Desktop to improve the platform integration. This would provide a standard API and a sensible migration for those using the Apple JDK 6 APIs. OK, but I?m not sure simply providing the same functionality in a more supportable way elsewhere will work if these Apple api?s do end up getting deleted. Developers using these haven?t had the same warnings to consider migrating off them and will instead suddenly just find their code broken if the api?s suddenly go away. The Weka machine learning library was the code I was running jdeps against. This is cross-platform code that someone obviously put the effort into for customizing for OS X. Including these api?s was for years recommended as the way to go to make your java application?s work more like native ones on Mac?s. It might be hard to know just how much code would break. Michael Hall From Alan.Bateman at oracle.com Fri Jul 10 07:50:33 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jul 2015 08:50:33 +0100 Subject: JDK 9 build with application class loader changes available? In-Reply-To: References: Message-ID: <559F7949.7090708@oracle.com> On 27/04/2015 01:52, Luke Daley wrote: > This is a follow on from: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-April/004291.html > Just an FYI that there is a currently a patch out for review [1] to add @argfile to the java launcher. That would help with the command-line limit issues that Gradle has been running into. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034524.html From jean-francois.denise at oracle.com Fri Jul 10 15:46:07 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Fri, 10 Jul 2015 17:46:07 +0200 Subject: Review for 8130344 Message-ID: Hi, asking review for this bug fix. http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ Thanks. JF From Alan.Bateman at oracle.com Fri Jul 10 16:34:28 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Jul 2015 17:34:28 +0100 Subject: Review for 8130344 In-Reply-To: References: Message-ID: <559FF414.90003@oracle.com> On 10/07/2015 16:46, Jean-Francois Denise wrote: > Hi, > asking review for this bug fix. > http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ > I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. The change to Image.c looks okay. In other areas of the libraries we have macros to do this. -Alan. From jean-francois.denise at oracle.com Fri Jul 10 16:45:30 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Fri, 10 Jul 2015 18:45:30 +0200 Subject: Review for 8130344 In-Reply-To: <559FF414.90003@oracle.com> References: <559FF414.90003@oracle.com> Message-ID: <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> Thanks Alan, I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations And it was not clear. On 10 Jul 2015, at 18:34, Alan Bateman wrote: > > > On 10/07/2015 16:46, Jean-Francois Denise wrote: >> Hi, >> asking review for this bug fix. >> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >> > I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. > > The change to Image.c looks okay. In other areas of the libraries we have macros to do this. > > -Alan. From david.holmes at oracle.com Mon Jul 13 06:06:38 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2015 16:06:38 +1000 Subject: Review for 8130344 In-Reply-To: <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> Message-ID: <55A3556E.3080108@oracle.com> On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: > Thanks Alan, > I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations > And it was not clear. FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. Cheers, David H. -------- > On 10 Jul 2015, at 18:34, Alan Bateman wrote: > >> >> >> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>> Hi, >>> asking review for this bug fix. >>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>> >> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >> >> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >> >> -Alan. > From jean-francois.denise at oracle.com Mon Jul 13 08:06:11 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Mon, 13 Jul 2015 10:06:11 +0200 Subject: Review for 8130344 In-Reply-To: <55A3556E.3080108@oracle.com> References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> <55A3556E.3080108@oracle.com> Message-ID: Thank you, I am removing the null check and throw. JF On 13 Jul 2015, at 08:06, David Holmes wrote: > On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: >> Thanks Alan, >> I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations >> And it was not clear. > > FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) > > So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. > > Cheers, > > David H. > -------- > >> On 10 Jul 2015, at 18:34, Alan Bateman wrote: >> >>> >>> >>> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>>> Hi, >>>> asking review for this bug fix. >>>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>>> >>> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >>> >>> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >>> >>> -Alan. >> From david.holmes at oracle.com Mon Jul 13 09:16:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2015 19:16:33 +1000 Subject: Review for 8130344 In-Reply-To: References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> <55A3556E.3080108@oracle.com> Message-ID: <55A381F1.4090000@oracle.com> On 13/07/2015 6:06 PM, Jean-Francois Denise wrote: > Thank you, > I am removing the null check and throw. Why are you removing them ?? David > JF > > On 13 Jul 2015, at 08:06, David Holmes wrote: > >> On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: >>> Thanks Alan, >>> I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations >>> And it was not clear. >> >> FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) >> >> So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. >> >> Cheers, >> >> David H. >> -------- >> >>> On 10 Jul 2015, at 18:34, Alan Bateman wrote: >>> >>>> >>>> >>>> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>>>> Hi, >>>>> asking review for this bug fix. >>>>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>>>> >>>> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >>>> >>>> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >>>> >>>> -Alan. >>> > From jean-francois.denise at oracle.com Mon Jul 13 10:09:34 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Mon, 13 Jul 2015 12:09:34 +0200 Subject: Review for 8130344 In-Reply-To: <55A381F1.4090000@oracle.com> References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> <55A3556E.3080108@oracle.com> <55A381F1.4090000@oracle.com> Message-ID: <17484995-9DF2-4E64-95DB-1D9DFF223441@oracle.com> In the Java code, I understand that it is useless, an OOM will be thrown. JF On 13 Jul 2015, at 11:16, David Holmes wrote: > On 13/07/2015 6:06 PM, Jean-Francois Denise wrote: >> Thank you, >> I am removing the null check and throw. > > Why are you removing them ?? > > David > >> JF >> >> On 13 Jul 2015, at 08:06, David Holmes wrote: >> >>> On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: >>>> Thanks Alan, >>>> I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations >>>> And it was not clear. >>> >>> FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) >>> >>> So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. >>> >>> Cheers, >>> >>> David H. >>> -------- >>> >>>> On 10 Jul 2015, at 18:34, Alan Bateman wrote: >>>> >>>>> >>>>> >>>>> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>>>>> Hi, >>>>>> asking review for this bug fix. >>>>>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>>>>> >>>>> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >>>>> >>>>> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >>>>> >>>>> -Alan. >>>> >> From jean-francois.denise at oracle.com Mon Jul 13 10:19:17 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Mon, 13 Jul 2015 12:19:17 +0200 Subject: Review for 8130344 In-Reply-To: <17484995-9DF2-4E64-95DB-1D9DFF223441@oracle.com> References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> <55A3556E.3080108@oracle.com> <55A381F1.4090000@oracle.com> <17484995-9DF2-4E64-95DB-1D9DFF223441@oracle.com> Message-ID: The updated fix: http://cr.openjdk.java.net/~jfdenise/JDK-8130344-2/ On 13 Jul 2015, at 12:09, Jean-Francois Denise wrote: > In the Java code, I understand that it is useless, an OOM will be thrown. > JF > On 13 Jul 2015, at 11:16, David Holmes wrote: > >> On 13/07/2015 6:06 PM, Jean-Francois Denise wrote: >>> Thank you, >>> I am removing the null check and throw. >> >> Why are you removing them ?? >> >> David >> >>> JF >>> >>> On 13 Jul 2015, at 08:06, David Holmes wrote: >>> >>>> On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: >>>>> Thanks Alan, >>>>> I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations >>>>> And it was not clear. >>>> >>>> FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) >>>> >>>> So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. >>>> >>>> Cheers, >>>> >>>> David H. >>>> -------- >>>> >>>>> On 10 Jul 2015, at 18:34, Alan Bateman wrote: >>>>> >>>>>> >>>>>> >>>>>> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>>>>>> Hi, >>>>>>> asking review for this bug fix. >>>>>>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>>>>>> >>>>>> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >>>>>> >>>>>> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >>>>>> >>>>>> -Alan. >>>>> >>> > From david.holmes at oracle.com Mon Jul 13 11:10:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Jul 2015 21:10:42 +1000 Subject: Review for 8130344 In-Reply-To: <17484995-9DF2-4E64-95DB-1D9DFF223441@oracle.com> References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> <55A3556E.3080108@oracle.com> <55A381F1.4090000@oracle.com> <17484995-9DF2-4E64-95DB-1D9DFF223441@oracle.com> Message-ID: <55A39CB2.3050601@oracle.com> On 13/07/2015 8:09 PM, Jean-Francois Denise wrote: > In the Java code, I understand that it is useless, an OOM will be thrown. No, an OOM _may_ be thrown. That is what I said below - you still need the null check based on the JNI spec (as opposed to the hotspot VM). David > JF > On 13 Jul 2015, at 11:16, David Holmes wrote: > >> On 13/07/2015 6:06 PM, Jean-Francois Denise wrote: >>> Thank you, >>> I am removing the null check and throw. >> >> Why are you removing them ?? >> >> David >> >>> JF >>> >>> On 13 Jul 2015, at 08:06, David Holmes wrote: >>> >>>> On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: >>>>> Thanks Alan, >>>>> I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations >>>>> And it was not clear. >>>> >>>> FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) >>>> >>>> So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. >>>> >>>> Cheers, >>>> >>>> David H. >>>> -------- >>>> >>>>> On 10 Jul 2015, at 18:34, Alan Bateman wrote: >>>>> >>>>>> >>>>>> >>>>>> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>>>>>> Hi, >>>>>>> asking review for this bug fix. >>>>>>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>>>>>> >>>>>> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >>>>>> >>>>>> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >>>>>> >>>>>> -Alan. >>>>> >>> > From jean-francois.denise at oracle.com Mon Jul 13 12:09:48 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Mon, 13 Jul 2015 14:09:48 +0200 Subject: Review for 8130344 In-Reply-To: <55A39CB2.3050601@oracle.com> References: <559FF414.90003@oracle.com> <2B539F46-1D3D-4FBB-95EB-18126DA66AB2@oracle.com> <55A3556E.3080108@oracle.com> <55A381F1.4090000@oracle.com> <17484995-9DF2-4E64-95DB-1D9DFF223441@oracle.com> <55A39CB2.3050601@oracle.com> Message-ID: <939A3D50-3AD0-488B-8376-E1C3D88CED04@oracle.com> Ok, yes, I read too quickly your reply, I will keep the check and throw an OOME On 13 Jul 2015, at 13:10, David Holmes wrote: > On 13/07/2015 8:09 PM, Jean-Francois Denise wrote: >> In the Java code, I understand that it is useless, an OOM will be thrown. > > No, an OOM _may_ be thrown. That is what I said below - you still need the null check based on the JNI spec (as opposed to the hotspot VM). > > David > >> JF >> On 13 Jul 2015, at 11:16, David Holmes wrote: >> >>> On 13/07/2015 6:06 PM, Jean-Francois Denise wrote: >>>> Thank you, >>>> I am removing the null check and throw. >>> >>> Why are you removing them ?? >>> >>> David >>> >>>> JF >>>> >>>> On 13 Jul 2015, at 08:06, David Holmes wrote: >>>> >>>>> On 11/07/2015 2:45 AM, Jean-Francois Denise wrote: >>>>>> Thanks Alan, >>>>>> I had read the spec from https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#array_operations >>>>>> And it was not clear. >>>>> >>>>> FYI the spec has just been updated to clarify that the NewArray functions can throw OOME if they return NULL. However the spec now also clarifies that an implementation that can both return NULL and post an exception can choose not to post the exception (a concession to existing VMs that only return NULL because the spec was inconsistent as to when OOME should be posted.) >>>>> >>>>> So you do need to check for NULL, however I think it would be more appropriate to throw OOME in that case as that is the only reason NULL would be returned AFAICS. >>>>> >>>>> Cheers, >>>>> >>>>> David H. >>>>> -------- >>>>> >>>>>> On 10 Jul 2015, at 18:34, Alan Bateman wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/07/2015 16:46, Jean-Francois Denise wrote: >>>>>>>> Hi, >>>>>>>> asking review for this bug fix. >>>>>>>> http://cr.openjdk.java.net/~jfdenise/JDK-8130344/ >>>>>>>> >>>>>>> I assume if JNI's NewByteArray returns NULL then it does so with a pending OOME. You might want to double check the JNI spec on this. If it guarantee it then you might need not need the null check in getStringBytes. >>>>>>> >>>>>>> The change to Image.c looks okay. In other areas of the libraries we have macros to do this. >>>>>>> >>>>>>> -Alan. >>>>>> >>>> >> From jean-francois.denise at oracle.com Wed Jul 15 12:34:16 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Wed, 15 Jul 2015 14:34:16 +0200 Subject: Review for 8131317 Message-ID: <710D5C18-6181-423D-884D-E8FEE2F44B3E@oracle.com> Hi, please review fix for: https://bugs.openjdk.java.net/browse/JDK-8131317 I took the opportunity of this fix to simplify ImageResourcesTree.java a bit. http://cr.openjdk.java.net/~jfdenise/8131317/ Thanks. JF From Alan.Bateman at oracle.com Wed Jul 15 13:10:13 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Jul 2015 14:10:13 +0100 Subject: Review for 8131317 In-Reply-To: <710D5C18-6181-423D-884D-E8FEE2F44B3E@oracle.com> References: <710D5C18-6181-423D-884D-E8FEE2F44B3E@oracle.com> Message-ID: <55A65BB5.5020606@oracle.com> On 15/07/2015 13:34, Jean-Francois Denise wrote: > Hi, > please review fix for: https://bugs.openjdk.java.net/browse/JDK-8131317 > > I took the opportunity of this fix to simplify ImageResourcesTree.java a bit. > > http://cr.openjdk.java.net/~jfdenise/8131317/ > > Thanks. > JF > This looks okay to me. -Alan From richard.warburton at gmail.com Sat Jul 18 13:34:15 2015 From: richard.warburton at gmail.com (Richard Warburton) Date: Sat, 18 Jul 2015 14:34:15 +0100 Subject: Manually Adding exports to JDK Modules Message-ID: Hi, In his talk at Devoxx UK Mark Reinhold demo'd a command that allows the addition of custom exports for existing modules. So you can ask the module system to enable external access to a specific internal API. I can't for the life of me find any documentation about, any mention of in other talks, and the Devoxx UK videos haven't been released yet. I also can't find a copy of the slidedeck online anywhere. Does anyone have any information about controlling exports? regards, Richard Warburton http://insightfullogic.com @RichardWarburto From ron at paralleluniverse.co Mon Jul 20 10:51:55 2015 From: ron at paralleluniverse.co (Ron Pressler) Date: Mon, 20 Jul 2015 13:51:55 +0300 Subject: JMX agents and Jigsaw Message-ID: Hi. I need to start a local JMX agent on the current JVM and obtain its secret address; I cannot rely on tools.jar being present so I can't use the attach mechanism. Currently, I do this with sun.management.Agent.agentmain and sun.misc.VMSupport.getAgentProperties because that's the only way to start an agent that won't keep the application running by leaving non-daemon threads lying around. Will JDK 9 make those classes inaccessible? If so, what alternatives do I have? Ron From Alan.Bateman at oracle.com Mon Jul 20 11:18:51 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jul 2015 12:18:51 +0100 Subject: JMX agents and Jigsaw In-Reply-To: References: Message-ID: <55ACD91B.8000100@oracle.com> On 20/07/2015 11:51, Ron Pressler wrote: > Hi. > I need to start a local JMX agent on the current JVM and obtain its secret > address; I cannot rely on tools.jar being present so I can't use the attach > mechanism. The attach API (meaning com.sun.tools.attach) is a JDK-specific/supported API. It should continue to work as it does now in JDK 9. Even better, there is a new method named startLocalManagementAgent that starts a local JMX agent and returns the connector service address. This avoids the hack that was loading managenent-agent.jar in past releases. -Alan From Alan.Bateman at oracle.com Mon Jul 20 11:42:13 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Jul 2015 12:42:13 +0100 Subject: Manually Adding exports to JDK Modules In-Reply-To: References: Message-ID: <55ACDE95.50204@oracle.com> On 18/07/2015 14:34, Richard Warburton wrote: > Hi, > > In his talk at Devoxx UK Mark Reinhold demo'd a command that allows the > addition of custom exports for existing modules. So you can ask the module > system to enable external access to a specific internal API. I can't for > the life of me find any documentation about, any mention of in other talks, > and the Devoxx UK videos haven't been released yet. I also can't find a > copy of the slidedeck online anywhere. Does anyone have any information > about controlling exports? > The module system isn't in JDK 9 yet so there isn't any documentation to point at just yet. We hope to start doing early access builds very soon with a proposed design/implementation that will allow for discussion. The get out of jail free card is currently named -XaddExport and I assume this is what Mark had in the slide. -Alan. From mark.reinhold at oracle.com Mon Jul 20 17:51:19 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Jul 2015 10:51:19 -0700 Subject: Manually Adding exports to JDK Modules In-Reply-To: <55ACDE95.50204@oracle.com> References: , <55ACDE95.50204@oracle.com> Message-ID: <20150720105119.329634@eggemoggin.niobe.net> 2015/7/20 4:42 -0700, alan.bateman at oracle.com: > On 18/07/2015 14:34, Richard Warburton wrote: >> In his talk at Devoxx UK Mark Reinhold demo'd a command that allows the >> addition of custom exports for existing modules. So you can ask the module >> system to enable external access to a specific internal API. I can't for >> the life of me find any documentation about, any mention of in other talks, >> and the Devoxx UK videos haven't been released yet. I also can't find a >> copy of the slidedeck online anywhere. Does anyone have any information >> about controlling exports? > > The module system isn't in JDK 9 yet so there isn't any documentation to > point at just yet. We hope to start doing early access builds very soon > with a proposed design/implementation that will allow for discussion. > The get out of jail free card is currently named -XaddExport and I > assume this is what Mark had in the slide. Yes, that's the option I showed in the demo (it wasn't in the slides). - Mark From mark.reinhold at oracle.com Mon Jul 20 18:06:49 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Jul 2015 11:06:49 -0700 Subject: Module container format In-Reply-To: <55960C91.10101@offbynull.com> References: <55958A8F.2030103@offbynull.com>, <559597B5.6030902@oracle.com>, <55960C91.10101@offbynull.com> Message-ID: <20150720110649.50340@eggemoggin.niobe.net> 2015/7/2 9:16 -0700, offbynull-jigsaw at offbynull.com: > "We're not there yet but eventually it should be possible to run a tool > on JDK 9 to access another JDK 9 run-time image (maybe it has a > different set of modules) or run on JDK 9 to access a JDK 10 run-time > image. " > > It's disappointing, to say the least, that this wasn't fleshed out for > the upcoming Java9 release. It essentially means that maintainers will > have to rework their code twice. Once for the release of Java9, and once > again when the ability to read another JDK's runtime image becomes a > reality (Java10?). Also, the fact that the container format is > "implementation-specific" and "subject to change without notice" is also > a major red-flag. I suspect that many developers are going to have > issues migrating to Java9 due to tool breakages (findbugs, etc..). The whole point of the virtual "jrt" file system (and related URLs) is to provide access to the classes and resources inside a run-time image in a way that's fully independent, across releases, of the image format. No external code should attempt to read the guts of an image directly, rather it should load and use the file system in that image's jrt-fs.jar file. The jrt-fs.jar file in JDK N will always run on JDK N-1, and also on all later releases. If there's something further you need from the jrt file system then let us know, so we can figure out how to expose it. - Mark From richard.warburton at gmail.com Mon Jul 20 22:46:53 2015 From: richard.warburton at gmail.com (Richard Warburton) Date: Mon, 20 Jul 2015 23:46:53 +0100 Subject: Manually Adding exports to JDK Modules In-Reply-To: <20150720105119.329634@eggemoggin.niobe.net> References: <55ACDE95.50204@oracle.com> <20150720105119.329634@eggemoggin.niobe.net> Message-ID: Hi, >> In his talk at Devoxx UK Mark Reinhold demo'd a command that allows the > >> addition of custom exports for existing modules. So you can ask the > module > >> system to enable external access to a specific internal API. I can't for > >> the life of me find any documentation about, any mention of in other > talks, > >> and the Devoxx UK videos haven't been released yet. I also can't find a > >> copy of the slidedeck online anywhere. Does anyone have any information > >> about controlling exports? > > > > The module system isn't in JDK 9 yet so there isn't any documentation to > > point at just yet. We hope to start doing early access builds very soon > > with a proposed design/implementation that will allow for discussion. > > The get out of jail free card is currently named -XaddExport and I > > assume this is what Mark had in the slide. > > Yes, that's the option I showed in the demo (it wasn't in the slides). Thanks for the information, do you have any kind of expectation in terms of schedule when things like the module system and jlink will get merged into a public repo? Could it happen within the next month or are we talking months away? regards, Richard Warburton http://insightfullogic.com @RichardWarburto From mark.reinhold at oracle.com Mon Jul 20 23:30:20 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Jul 2015 16:30:20 -0700 Subject: Manually Adding exports to JDK Modules In-Reply-To: References: , <55ACDE95.50204@oracle.com>, <20150720105119.329634@eggemoggin.niobe.net>, Message-ID: <20150720163020.607697@eggemoggin.niobe.net> 2015/7/20 3:46 -0700, richard.warburton at gmail.com: > Thanks for the information, do you have any kind of expectation in terms of > schedule when things like the module system and jlink will get merged into > a public repo? Could it happen within the next month or are we talking > months away? The former. - Mark From ron at paralleluniverse.co Tue Jul 21 05:49:00 2015 From: ron at paralleluniverse.co (Ron Pressler) Date: Tue, 21 Jul 2015 08:49:00 +0300 Subject: JMX agents and Jigsaw In-Reply-To: <55ACD91B.8000100@oracle.com> References: <55ACD91B.8000100@oracle.com> Message-ID: On Mon, Jul 20, 2015 at 2:18 PM, Alan Bateman wrote: The attach API (meaning com.sun.tools.attach) is a JDK-specific/supported > API. It should continue to work as it does now in JDK 9. Even better, there > is a new method named startLocalManagementAgent that starts a local JMX > agent and returns the connector service address. This avoids the hack that > was loading managenent-agent.jar in past releases. That's really good (esp. startLocalManagementAgent), but does it require tools.jar to be available, which means a JDK, rather than JRE installation? VMSupport and Agent are available on any JRE. Perhaps com.sun.tools.attach should be included in the JRE, too. Ron From Alan.Bateman at oracle.com Tue Jul 21 07:59:28 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Jul 2015 08:59:28 +0100 Subject: JMX agents and Jigsaw In-Reply-To: References: <55ACD91B.8000100@oracle.com> Message-ID: <55ADFBE0.30303@oracle.com> On 21/07/2015 06:49, Ron Pressler wrote: > : > > That's really good (esp. startLocalManagementAgent), but does it > require tools.jar to be available, which means a JDK, rather than JRE > installation? VMSupport and Agent are available on any JRE. Perhaps > com.sun.tools.attach should be included in the JRE, too. > The attach API is intended for tools so this is why it used to be tools.jar and why it wasn't in the JRE downloads. In our module graph then it becomes its own module (named jdk.attach) so this means a tool using this API can run on any run-time image that has the jdk.attach module linked in. This should become clearer once the module system is in and there is tooling to create run-time images with just the modules that you want. -Alan From ron at paralleluniverse.co Fri Jul 24 09:12:22 2015 From: ron at paralleluniverse.co (Ron Pressler) Date: Fri, 24 Jul 2015 12:12:22 +0300 Subject: JMX agents and Jigsaw In-Reply-To: <55ADFBE0.30303@oracle.com> References: <55ACD91B.8000100@oracle.com> <55ADFBE0.30303@oracle.com> Message-ID: OK, but assuming I have no control over the user's runtime image, am I correct that programmatically starting the local JMX agent as I do now (without the Attach API) will no longer be possible in Java 9? Ron Pressler paralleluniverse.co @puniverseco on Twitter On Tue, Jul 21, 2015 at 10:59 AM, Alan Bateman wrote: > On 21/07/2015 06:49, Ron Pressler wrote: > >> : >> >> That's really good (esp. startLocalManagementAgent), but does it require >> tools.jar to be available, which means a JDK, rather than JRE >> installation? VMSupport and Agent are available on any JRE. Perhaps >> com.sun.tools.attach should be included in the JRE, too. >> >> The attach API is intended for tools so this is why it used to be > tools.jar and why it wasn't in the JRE downloads. In our module graph then > it becomes its own module (named jdk.attach) so this means a tool using > this API can run on any run-time image that has the jdk.attach module > linked in. This should become clearer once the module system is in and > there is tooling to create run-time images with just the modules that you > want. > > -Alan > From Alan.Bateman at oracle.com Fri Jul 24 11:22:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Jul 2015 12:22:12 +0100 Subject: JMX agents and Jigsaw In-Reply-To: References: <55ACD91B.8000100@oracle.com> <55ADFBE0.30303@oracle.com> Message-ID: <55B21FE4.4040403@oracle.com> On 24/07/2015 10:12, Ron Pressler wrote: > OK, but assuming I have no control over the user's runtime image, am I > correct that programmatically starting the local JMX agent as I do now > (without the Attach API) will no longer be possible in Java 9? > I'm not aware of any supported way of doing this in any JDK release, at least not without using Runtime.exec or ProcessBuilder to invoke the jcmd tool which might or might not be present. If you have code making direct use of JDK-internal classes such as sun.management.Agent then it fail at both compile-time and run-time with JDK 9 once the module system goes in. There will be a command-line option to work around this but no guarantees of course as sun.management.Agent might not exist, might be refactored significantly, etc. You probably know this already but you can start your own JMXConnectorServer if you want. Also you don't need the JMX agent to access the platform MXBeans in the current runtime. As regards tools using the attach API then then moving them to modules means they can have an explicit dependency on the jdk.attach module. This is good because it means they won't even start on a run-time that doesn't the jdk.attach module. Also if you get to create your own run-time image and want to include one or these tools then it will ensure that the jdk.attach module is also linked in. -Alan From jean-francois.denise at oracle.com Fri Jul 24 15:29:22 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Fri, 24 Jul 2015 17:29:22 +0200 Subject: Review for JDK-8132335 Message-ID: Hi, asking for review to fix jimage recreate that is failing with NPE. Bug is http://cr.openjdk.java.net/~jfdenise/JDK-8132335/ Thanks. JF From jean-francois.denise at oracle.com Fri Jul 24 16:19:52 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Fri, 24 Jul 2015 18:19:52 +0200 Subject: Review for JDK-8132335 In-Reply-To: References: Message-ID: <1B0488C0-6C82-4A19-9FBC-D37CC72610B3@oracle.com> I forget to add details on the fix. The fileName formatting was not correct, the call to getRoot() was not right. I replaced it with getFileName() + removal of .jimage extension. JF On 24 Jul 2015, at 17:29, Jean-Francois Denise wrote: > Hi, > asking for review to fix jimage recreate that is failing with NPE. Bug is http://cr.openjdk.java.net/~jfdenise/JDK-8132335/ > Thanks. > JF From james.laskey at oracle.com Fri Jul 24 16:19:20 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 24 Jul 2015 13:19:20 -0300 Subject: Review for JDK-8132335 In-Reply-To: References: Message-ID: <9A16E877-40BE-47BF-8F01-72B02F637BEE@oracle.com> +1 > On Jul 24, 2015, at 12:29 PM, Jean-Francois Denise wrote: > > Hi, > asking for review to fix jimage recreate that is failing with NPE. Bug is http://cr.openjdk.java.net/~jfdenise/JDK-8132335/ > Thanks. > JF From jean-francois.denise at oracle.com Fri Jul 24 17:17:18 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Fri, 24 Jul 2015 19:17:18 +0200 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: <55B271A0.7090705@oracle.com> References: <165AE6EA-8FB7-4715-8D76-477692B63C95@oracle.com> <69B55DAD-6E30-4703-B2B0-4A5EEC598149@oracle.com> <487562C8-9F9D-43B3-AF21-D99368852DDB@oracle.com> <55B271A0.7090705@oracle.com> Message-ID: <3C863E9B-2C79-4058-9588-A17C5015EBBA@oracle.com> Hi, you need to prefix your path with /modules, so ?/modules/java.desktop?. JF On 24 Jul 2015, at 19:10, Sergey Bylokhov wrote: > After the latest merge I got some issue, I assume related to this fix. > Can somebody take a look to this code: > > import java.net.URI; > import java.nio.file.*; > import java.nio.file.attribute.BasicFileAttributes; > > public class JRTFileSystemError { > > public static void main(final String[] args) throws Exception { > FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/")); > Files.walkFileTree(fs.getPath("/java.desktop"), new SimpleFileVisitor() { > @Override > public FileVisitResult visitFile(Path file, > BasicFileAttributes attrs) { > return FileVisitResult.CONTINUE; > } > }); > } > } > > It fails with "Exception in thread "main" java.nio.file.NoSuchFileException: /java.desktop". > Bur previously it works correctly. Can somebody confirm this is an issue in the test(and how to change it) or in jdk? > It seems that IntelliJ also broken in some way so it cannot take classes from the jdk9 after this fix. probably they should update jrt-fs.jar? > > > On 23.06.15 19:08, Jean-Francois Denise wrote: >> Hi, >> an updated webrev that takes into account reviews. In addition the hotspot tests have been reworked following Christian Tornqvist suggestions. >> >> top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/ >> langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/ >> hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/ >> jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/ >> >> Testing: >> JCK(s) tests are passing (ran only on Mac OS) >> Hotspot tests are passing (All platforms) >> Java PIT tests are passing (All platforms). Ran once on https://bugs.openjdk.java.net/browse/JDK-8129592 >> >> Thanks. >> JF >> >> On 23 Jun 2015, at 14:10, Jean-Francois Denise wrote: >> >>> Hi Paul, >>> >>> On 19 Jun 2015, at 16:39, Paul Sandoz wrote: >>> >>>> On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) wrote: >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8080511 >>>>> >>>>> This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and improved performance for langtools in the presence of jrt-fs. >>>>> >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk >>>> I eyeballed the JDK changes. Just two thing: >>>> >>>> make/src/classes/build/tools/module/ModuleArchive.java >>>> >>>> 90 @Override >>>> 91 public Stream entries() { >>>> 92 List entries = new ArrayList<>(); >>>> 93 try { >>>> 94 if (classes != null) >>>> 95 Files.walk(classes) >>>> 96 .sorted() >>>> 97 .filter(p -> !Files.isDirectory(p) >>>> 98 && !classes.relativize(p).toString().startsWith("_the.") >>>> 99 && !classes.relativize(p).toString().equals("javac_state")) >>>> 100 .map(p -> toEntry(p, classes, EntryType.CLASS_OR_RESOURCE)) >>>> 101 .forEach(entries::add); >>>> 102 if (cmds != null) >>>> 103 Files.walk(cmds) >>>> 104 .filter(p -> !Files.isDirectory(p)) >>>> 105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD)) >>>> 106 .forEach(entries::add); >>>> 107 if (libs != null) >>>> 108 Files.walk(libs) >>>> 109 .filter(p -> !Files.isDirectory(p)) >>>> 110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB)) >>>> 111 .forEach(entries::add); >>>> 112 if (configs != null) >>>> 113 Files.walk(configs) >>>> 114 .filter(p -> !Files.isDirectory(p)) >>>> 115 .map(p -> toEntry(p, configs, EntryType.CONFIG)) >>>> 116 .forEach(entries::add); >>>> 117 } catch (IOException ioe) { >>>> 118 throw new UncheckedIOException(ioe); >>>> 119 } >>>> 120 return entries.stream(); >>>> 121 } >>>> >>>> You can use collect(toList()) >>> ==> OK collect used. In addition, filter first then sort, tryWithResource for 4 Files stream. >>> >>>> In general the contract for Archive.entries probably has to say the stream needs to be closed after use since it might cover lazy I/O based resources, so callers will need to use a try-with-resources block. >>> ==> Added a note in javadoc, implemented explicit close for non lazy streams, added missing tryWithResource. Added a comment on what should be done in ModuleArchive to keep laziness. >>>> Paul. >>> Thanks. >>> >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools >>>>> >>>>> >>>>> Details: >>>>> >>>>> - jrt-fs provides access, via the nio FileSystem API, to the classes in a .jimage file, organized by module or by package. >>>>> - Shared code for jimage support converted to native. Currently residing in hotspot, but will migrate to it?s own jdk library https://bugs.openjdk.java.net/browse/JDK-8087181 >>>>> - A new archive abstraction for class/resource sources. >>>>> - java based implementation layer for jimage reading to allow backport to JDK8 (jrt-fs.jar - IDE support.) >>>>> - JNI support for jimage into hotspot. >>>>> - White box tests written to exercise native jimage support. > > > -- > Best regards, Sergey. > From Alan.Bateman at oracle.com Sat Jul 25 07:16:39 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Jul 2015 08:16:39 +0100 Subject: Review for JDK-8132335 In-Reply-To: <1B0488C0-6C82-4A19-9FBC-D37CC72610B3@oracle.com> References: <1B0488C0-6C82-4A19-9FBC-D37CC72610B3@oracle.com> Message-ID: <55B337D7.2060205@oracle.com> On 24/07/2015 17:19, Jean-Francois Denise wrote: > I forget to add details on the fix. The fileName formatting was not correct, the call to getRoot() was not right. I replaced it with getFileName() + removal of .jimage extension. > JF > > Are you planning to add a test for this? I realize "jimage recreate" is mostly just for tools doing static instrumentation but it's very easy to break this and would be good to have a test to exercise it and catch any issues. -Alan. From Alan.Bateman at oracle.com Sat Jul 25 17:10:56 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Jul 2015 18:10:56 +0100 Subject: jrt file system now has /package and /modules directories Message-ID: <55B3C320.8060705@oracle.com> Just a heads-up that jdk9-b74 has a refresh of the jimage and jrt file system implementation. For IDEs and other tools that are using the jrt file system then an important change in this build is the addition of the /packages and /modules top-level directories in the file system. Details in JDK-8066492 [1]. -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8066492 From mik3hall at gmail.com Sun Jul 26 00:29:06 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 25 Jul 2015 19:29:06 -0500 Subject: jrt file system now has /package and /modules directories In-Reply-To: <55B3C320.8060705@oracle.com> References: <55B3C320.8060705@oracle.com> Message-ID: <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> > On Jul 25, 2015, at 12:10 PM, Alan Bateman wrote: > > > Just a heads-up that jdk9-b74 has a refresh of the jimage and jrt file system implementation. Have mostly just been following along on this a little with the early access releases. I was a little curious on this though so I cloned and built current jdk9. I have a simple jrt filesystem lister that I tried running getting? ~/jdk9/build/macosx-x86_64-normal-server-release/jdk/bin/java -cp . JRTLister java.nio.file.FileSystemNotFoundException: /Users/mjh/jdk9/build/macosx-x86_64-normal-server-release/jdk/lib/modules/bootmodules.jimage at jdk.internal.jrtfs.JrtFileSystem.checkExists(JrtFileSystem.java:87) at jdk.internal.jrtfs.JrtFileSystem.(JrtFileSystem.java:102) at jdk.internal.jrtfs.JrtFileSystemProvider$1.(JrtFileSystemProvider.java:113) at jdk.internal.jrtfs.JrtFileSystemProvider.getTheFileSystem(JrtFileSystemProvider.java:113) at jdk.internal.jrtfs.JrtFileSystemProvider.getFileSystem(JrtFileSystemProvider.java:131) at java.nio.file.FileSystems.getFileSystem(FileSystems.java:221) at JRTLister.main(JRTLister.java:13) Obviously finding JrtFileSystem but not modules/bootmodules.jimage? Built version shows as openjdk version "1.9.0-internal" OpenJDK Runtime Environment (build 1.9.0-internal-mjh_2015_07_25_16_42-b00) OpenJDK 64-Bit Server VM (build 1.9.0-internal-mjh_2015_07_25_16_42-b00, mixed mode) So I don?t know that this is really the b74 build. Is there some other way I should get that? (I had downloaded the current download page available jdk9 early access shortly before this getting b73) Again, mostly curiosity, thanks. Michael Hall From Alan.Bateman at oracle.com Sun Jul 26 07:08:57 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 26 Jul 2015 08:08:57 +0100 Subject: jrt file system now has /package and /modules directories In-Reply-To: <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> Message-ID: <55B48789.6020907@oracle.com> On 26/07/2015 01:29, Michael Hall wrote: >> On Jul 25, 2015, at 12:10 PM, Alan Bateman wrote: >> >> >> Just a heads-up that jdk9-b74 has a refresh of the jimage and jrt file system implementation. > Have mostly just been following along on this a little with the early access releases. I was a little curious on this though so I cloned and built current jdk9. > I have a simple jrt filesystem lister that I tried running getting? > > ~/jdk9/build/macosx-x86_64-normal-server-release/jdk/bin/java -cp . JRTLister > java.nio.file.FileSystemNotFoundException: /Users/mjh/jdk9/build/macosx-x86_64-normal-server-release/jdk/lib/modules/bootmodules.jimage > at jdk.internal.jrtfs.JrtFileSystem.checkExists(JrtFileSystem.java:87) > at jdk.internal.jrtfs.JrtFileSystem.(JrtFileSystem.java:102) > at jdk.internal.jrtfs.JrtFileSystemProvider$1.(JrtFileSystemProvider.java:113) > at jdk.internal.jrtfs.JrtFileSystemProvider.getTheFileSystem(JrtFileSystemProvider.java:113) > at jdk.internal.jrtfs.JrtFileSystemProvider.getFileSystem(JrtFileSystemProvider.java:131) > at java.nio.file.FileSystems.getFileSystem(FileSystems.java:221) > at JRTLister.main(JRTLister.java:13) > > Obviously finding JrtFileSystem but not modules/bootmodules.jimage? > Replace jdk/bin/java with images/jdk/bin/java in your path above and I expect it should work. The jdk directory in the build output is the "exploded build". It's an intermediate step in the build before the JDK and JRE images are created. Many people working on the JDK use the exploded builds for quick edit-build-debug sessions and local testing but I don't think is used much beyond that. JDK-8066860 [1] is tracking an update to the jrt file system to support exploded builds. Sundar has an initial patch but it's not in JDK 9 yet. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8066860 From mik3hall at gmail.com Sun Jul 26 09:30:23 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 26 Jul 2015 04:30:23 -0500 Subject: jrt file system now has /package and /modules directories In-Reply-To: <55B48789.6020907@oracle.com> References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> Message-ID: > On Jul 26, 2015, at 2:08 AM, Alan Bateman wrote: > > Replace jdk/bin/java with images/jdk/bin/java in your path above and I expect it should work. Doing the build wrong besides being in the wrong directory. Have it now thanks. Michael Hall From ron at paralleluniverse.co Sun Jul 26 16:42:09 2015 From: ron at paralleluniverse.co (Ron Pressler) Date: Sun, 26 Jul 2015 19:42:09 +0300 Subject: JMX agents and Jigsaw In-Reply-To: <55B21FE4.4040403@oracle.com> References: <55ACD91B.8000100@oracle.com> <55ADFBE0.30303@oracle.com> <55B21FE4.4040403@oracle.com> Message-ID: Got it. Thanks! The problem with JMXConnectorServer is that it keeps the JVM running with a non-daemon thread -- that's the only reason why I use sun.management.Agent. Perhaps it would be a good idea to provide a solution for that, but this is the wrong mailing list for that discussion... Ron On Fri, Jul 24, 2015 at 2:22 PM, Alan Bateman wrote: > On 24/07/2015 10:12, Ron Pressler wrote: > >> OK, but assuming I have no control over the user's runtime image, am I >> correct that programmatically starting the local JMX agent as I do now >> (without the Attach API) will no longer be possible in Java 9? >> >> I'm not aware of any supported way of doing this in any JDK release, at > least not without using Runtime.exec or ProcessBuilder to invoke the jcmd > tool which might or might not be present. > > If you have code making direct use of JDK-internal classes such as > sun.management.Agent then it fail at both compile-time and run-time with > JDK 9 once the module system goes in. There will be a command-line option > to work around this but no guarantees of course as sun.management.Agent > might not exist, might be refactored significantly, etc. > > You probably know this already but you can start your own > JMXConnectorServer if you want. Also you don't need the JMX agent to access > the platform MXBeans in the current runtime. > > As regards tools using the attach API then then moving them to modules > means they can have an explicit dependency on the jdk.attach module. This > is good because it means they won't even start on a run-time that doesn't > the jdk.attach module. Also if you get to create your own run-time image > and want to include one or these tools then it will ensure that the > jdk.attach module is also linked in. > > -Alan > From sundararajan.athijegannathan at oracle.com Mon Jul 27 07:39:33 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 27 Jul 2015 13:09:33 +0530 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: <3C863E9B-2C79-4058-9588-A17C5015EBBA@oracle.com> References: <165AE6EA-8FB7-4715-8D76-477692B63C95@oracle.com> <69B55DAD-6E30-4703-B2B0-4A5EEC598149@oracle.com> <487562C8-9F9D-43B3-AF21-D99368852DDB@oracle.com> <55B271A0.7090705@oracle.com> <3C863E9B-2C79-4058-9588-A17C5015EBBA@oracle.com> Message-ID: <55B5E035.8060501@oracle.com> Please see also: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-July/004403.html -Sundar On Friday 24 July 2015 10:47 PM, Jean-Francois Denise wrote: > Hi, > you need to prefix your path with /modules, so ?/modules/java.desktop?. > JF > > > On 24 Jul 2015, at 19:10, Sergey Bylokhov wrote: > >> After the latest merge I got some issue, I assume related to this fix. >> Can somebody take a look to this code: >> >> import java.net.URI; >> import java.nio.file.*; >> import java.nio.file.attribute.BasicFileAttributes; >> >> public class JRTFileSystemError { >> >> public static void main(final String[] args) throws Exception { >> FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/")); >> Files.walkFileTree(fs.getPath("/java.desktop"), new SimpleFileVisitor() { >> @Override >> public FileVisitResult visitFile(Path file, >> BasicFileAttributes attrs) { >> return FileVisitResult.CONTINUE; >> } >> }); >> } >> } >> >> It fails with "Exception in thread "main" java.nio.file.NoSuchFileException: /java.desktop". >> Bur previously it works correctly. Can somebody confirm this is an issue in the test(and how to change it) or in jdk? >> It seems that IntelliJ also broken in some way so it cannot take classes from the jdk9 after this fix. probably they should update jrt-fs.jar? >> >> >> On 23.06.15 19:08, Jean-Francois Denise wrote: >>> Hi, >>> an updated webrev that takes into account reviews. In addition the hotspot tests have been reworked following Christian Tornqvist suggestions. >>> >>> top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/ >>> langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/ >>> hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/ >>> jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/ >>> >>> Testing: >>> JCK(s) tests are passing (ran only on Mac OS) >>> Hotspot tests are passing (All platforms) >>> Java PIT tests are passing (All platforms). Ran once on https://bugs.openjdk.java.net/browse/JDK-8129592 >>> >>> Thanks. >>> JF >>> >>> On 23 Jun 2015, at 14:10, Jean-Francois Denise wrote: >>> >>>> Hi Paul, >>>> >>>> On 19 Jun 2015, at 16:39, Paul Sandoz wrote: >>>> >>>>> On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) wrote: >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8080511 >>>>>> >>>>>> This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and improved performance for langtools in the presence of jrt-fs. >>>>>> >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk >>>>> I eyeballed the JDK changes. Just two thing: >>>>> >>>>> make/src/classes/build/tools/module/ModuleArchive.java >>>>> >>>>> 90 @Override >>>>> 91 public Stream entries() { >>>>> 92 List entries = new ArrayList<>(); >>>>> 93 try { >>>>> 94 if (classes != null) >>>>> 95 Files.walk(classes) >>>>> 96 .sorted() >>>>> 97 .filter(p -> !Files.isDirectory(p) >>>>> 98 && !classes.relativize(p).toString().startsWith("_the.") >>>>> 99 && !classes.relativize(p).toString().equals("javac_state")) >>>>> 100 .map(p -> toEntry(p, classes, EntryType.CLASS_OR_RESOURCE)) >>>>> 101 .forEach(entries::add); >>>>> 102 if (cmds != null) >>>>> 103 Files.walk(cmds) >>>>> 104 .filter(p -> !Files.isDirectory(p)) >>>>> 105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD)) >>>>> 106 .forEach(entries::add); >>>>> 107 if (libs != null) >>>>> 108 Files.walk(libs) >>>>> 109 .filter(p -> !Files.isDirectory(p)) >>>>> 110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB)) >>>>> 111 .forEach(entries::add); >>>>> 112 if (configs != null) >>>>> 113 Files.walk(configs) >>>>> 114 .filter(p -> !Files.isDirectory(p)) >>>>> 115 .map(p -> toEntry(p, configs, EntryType.CONFIG)) >>>>> 116 .forEach(entries::add); >>>>> 117 } catch (IOException ioe) { >>>>> 118 throw new UncheckedIOException(ioe); >>>>> 119 } >>>>> 120 return entries.stream(); >>>>> 121 } >>>>> >>>>> You can use collect(toList()) >>>> ==> OK collect used. In addition, filter first then sort, tryWithResource for 4 Files stream. >>>> >>>>> In general the contract for Archive.entries probably has to say the stream needs to be closed after use since it might cover lazy I/O based resources, so callers will need to use a try-with-resources block. >>>> ==> Added a note in javadoc, implemented explicit close for non lazy streams, added missing tryWithResource. Added a comment on what should be done in ModuleArchive to keep laziness. >>>>> Paul. >>>> Thanks. >>>> >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools >>>>>> >>>>>> >>>>>> Details: >>>>>> >>>>>> - jrt-fs provides access, via the nio FileSystem API, to the classes in a .jimage file, organized by module or by package. >>>>>> - Shared code for jimage support converted to native. Currently residing in hotspot, but will migrate to it?s own jdk library https://bugs.openjdk.java.net/browse/JDK-8087181 >>>>>> - A new archive abstraction for class/resource sources. >>>>>> - java based implementation layer for jimage reading to allow backport to JDK8 (jrt-fs.jar - IDE support.) >>>>>> - JNI support for jimage into hotspot. >>>>>> - White box tests written to exercise native jimage support. >> >> -- >> Best regards, Sergey. >> From simon at cjnash.com Tue Jul 28 11:21:38 2015 From: simon at cjnash.com (Simon Nash) Date: Tue, 28 Jul 2015 12:21:38 +0100 Subject: Accessing internal packages in JDK 9 Message-ID: <55B765C2.4080203@cjnash.com> I am developing an application that is using some internal JDK packages (sun.*) to work around some problems with "leaked" Swing objects that reference my application classloader via their protection domain. This means that my application classloader cannot be garbage collected even if I remove all references to it from within my application. This is a problem because my application uses native DLLs that sometimes need to be replaced by new versions without restarting the application and these DLLs cannot be unloaded and reloaded unless the application classloader that loaded these DLLs has been garbage collected. The workarounds I am using for this problem use a combination of internal APIs together with reflection to locate the fields that are holding these internal "leaked" objects and set these fields to null. With JDK 9 and Project Jigsaw, I understand that it will no longer be possible for my application to directly reference internal sun.* classes. Will it still be possible to use ClassLoader.loadClass to load these sun.* classes and use reflection to invoke their methods? Simon Nash From mark.reinhold at oracle.com Tue Jul 28 14:39:52 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Jul 2015 07:39:52 -0700 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B765C2.4080203@cjnash.com> References: <55B765C2.4080203@cjnash.com> Message-ID: <20150728073952.255257@eggemoggin.niobe.net> 2015/7/28 4:21 -0700, Simon Nash : > ... > > With JDK 9 and Project Jigsaw, I understand that it will no longer be > possible for my application to directly reference internal sun.* classes. > Will it still be possible to use ClassLoader.loadClass to load these sun.* > classes and use reflection to invoke their methods? Yes, but you'll have to use a command-line flag to make the classes accessible via the reflection API. - Mark From simon at cjnash.com Tue Jul 28 15:12:37 2015 From: simon at cjnash.com (Simon Nash) Date: Tue, 28 Jul 2015 16:12:37 +0100 Subject: [SPAM?] Re: Accessing internal packages in JDK 9 In-Reply-To: <20150728073952.255257@eggemoggin.niobe.net> References: <55B765C2.4080203@cjnash.com> <20150728073952.255257@eggemoggin.niobe.net> Message-ID: <55B79BE5.4030504@cjnash.com> mark.reinhold at oracle.com wrote: > 2015/7/28 4:21 -0700, Simon Nash : >> ... >> >> With JDK 9 and Project Jigsaw, I understand that it will no longer be >> possible for my application to directly reference internal sun.* classes. >> Will it still be possible to use ClassLoader.loadClass to load these sun.* >> classes and use reflection to invoke their methods? > > Yes, but you'll have to use a command-line flag to make the classes > accessible via the reflection API. > > - Mark > Is this a single option that enables all internal access or does the option need to be repeated for every internal package or class that the application needs to access? If the option is set, can the application use imports for the internal packages or is it required to access them reflectively? Would it be possible to allow the application to set this option programmatically on initialization or set it internally in some other way (e.g., in its jar manifest) so that the users of the application don't need to specify it on the launch command? Simon From mark.reinhold at oracle.com Tue Jul 28 15:22:23 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Jul 2015 08:22:23 -0700 Subject: Accessing internal packages in JDK 9 In-Reply-To: <55B79BE5.4030504@cjnash.com> References: <55B765C2.4080203@cjnash.com>, <20150728073952.255257@eggemoggin.niobe.net>, <55B79BE5.4030504@cjnash.com> Message-ID: <20150728082223.715364@eggemoggin.niobe.net> 2015/7/28 8:12 -0700, Simon Nash : > mark.reinhold at oracle.com wrote: >> 2015/7/28 4:21 -0700, Simon Nash : >>> ... >>> >>> With JDK 9 and Project Jigsaw, I understand that it will no longer be >>> possible for my application to directly reference internal sun.* classes. >>> Will it still be possible to use ClassLoader.loadClass to load these sun.* >>> classes and use reflection to invoke their methods? >> >> Yes, but you'll have to use a command-line flag to make the classes >> accessible via the reflection API. > > Is this a single option that enables all internal access or does the option > need to be repeated for every internal package or class that the application > needs to access? > > If the option is set, can the application use imports for the internal > packages or is it required to access them reflectively? > > Would it be possible to allow the application to set this option > programmatically on initialization or set it internally in some other way > (e.g., in its jar manifest) so that the users of the application don't need > to specify it on the launch command? These are all good questions. We're nearly done drafting a JEP which will answer them, so rather than answer them here can I ask that you read the JEP when it's published? Thanks, - Mark From pbenedict at apache.org Tue Jul 28 15:28:34 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 28 Jul 2015 10:28:34 -0500 Subject: Accessing internal packages in JDK 9 In-Reply-To: <20150728082223.715364@eggemoggin.niobe.net> References: <55B765C2.4080203@cjnash.com> <20150728073952.255257@eggemoggin.niobe.net> <55B79BE5.4030504@cjnash.com> <20150728082223.715364@eggemoggin.niobe.net> Message-ID: Is the option the Visibility Policy file? Cheers, Paul On Tue, Jul 28, 2015 at 10:22 AM, wrote: > 2015/7/28 8:12 -0700, Simon Nash : > > mark.reinhold at oracle.com wrote: > >> 2015/7/28 4:21 -0700, Simon Nash : > >>> ... > >>> > >>> With JDK 9 and Project Jigsaw, I understand that it will no longer be > >>> possible for my application to directly reference internal sun.* > classes. > >>> Will it still be possible to use ClassLoader.loadClass to load these > sun.* > >>> classes and use reflection to invoke their methods? > >> > >> Yes, but you'll have to use a command-line flag to make the classes > >> accessible via the reflection API. > > > > Is this a single option that enables all internal access or does the > option > > need to be repeated for every internal package or class that the > application > > needs to access? > > > > If the option is set, can the application use imports for the internal > > packages or is it required to access them reflectively? > > > > Would it be possible to allow the application to set this option > > programmatically on initialization or set it internally in some other way > > (e.g., in its jar manifest) so that the users of the application don't > need > > to specify it on the launch command? > > These are all good questions. We're nearly done drafting a JEP which > will answer them, so rather than answer them here can I ask that you > read the JEP when it's published? > > Thanks, > - Mark > From simon at cjnash.com Tue Jul 28 15:53:55 2015 From: simon at cjnash.com (Simon Nash) Date: Tue, 28 Jul 2015 16:53:55 +0100 Subject: Accessing internal packages in JDK 9 In-Reply-To: <20150728082223.715364@eggemoggin.niobe.net> References: <55B765C2.4080203@cjnash.com>, <20150728073952.255257@eggemoggin.niobe.net>, <55B79BE5.4030504@cjnash.com> <20150728082223.715364@eggemoggin.niobe.net> Message-ID: <55B7A593.4030108@cjnash.com> mark.reinhold at oracle.com wrote: > 2015/7/28 8:12 -0700, Simon Nash : >> mark.reinhold at oracle.com wrote: >>> 2015/7/28 4:21 -0700, Simon Nash : >>>> ... >>>> >>>> With JDK 9 and Project Jigsaw, I understand that it will no longer be >>>> possible for my application to directly reference internal sun.* classes. >>>> Will it still be possible to use ClassLoader.loadClass to load these sun.* >>>> classes and use reflection to invoke their methods? >>> Yes, but you'll have to use a command-line flag to make the classes >>> accessible via the reflection API. >> Is this a single option that enables all internal access or does the option >> need to be repeated for every internal package or class that the application >> needs to access? >> >> If the option is set, can the application use imports for the internal >> packages or is it required to access them reflectively? >> >> Would it be possible to allow the application to set this option >> programmatically on initialization or set it internally in some other way >> (e.g., in its jar manifest) so that the users of the application don't need >> to specify it on the launch command? > > These are all good questions. We're nearly done drafting a JEP which > will answer them, so rather than answer them here can I ask that you > read the JEP when it's published? > > Thanks, > - Mark > Thanks! I look forward to doing that. :) Simon From Alan.Bateman at oracle.com Tue Jul 28 20:04:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Jul 2015 21:04:58 +0100 Subject: RFR(XS): 8132475 : The commands in the modular images are executable by the owner only (once again) In-Reply-To: References: Message-ID: <55B7E06A.8070508@oracle.com> On 28/07/2015 19:32, Volker Simonis wrote: > Hi, > > could you please review this tiny change: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/ > https://bugs.openjdk.java.net/browse/JDK-8132475 > > After "8080511: Refresh of jimage support" the executable commands in > jdk/bin and jre/bin are only executable by the file owner. This means > that only the user who built the images can execute the programs. > > The fix is trivial, but I've also added a test now so this won't > happen a third time :) > This is a new image writer, it's different to what was there previously. I assume the test can't run if the permissions are not right :-) -Alan. From volker.simonis at gmail.com Wed Jul 29 09:31:21 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jul 2015 11:31:21 +0200 Subject: RFR(XS): 8132475 : The commands in the modular images are executable by the owner only (once again) In-Reply-To: <55B7E06A.8070508@oracle.com> References: <55B7E06A.8070508@oracle.com> Message-ID: On Tue, Jul 28, 2015 at 10:04 PM, Alan Bateman wrote: > On 28/07/2015 19:32, Volker Simonis wrote: >> >> Hi, >> >> could you please review this tiny change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/ >> https://bugs.openjdk.java.net/browse/JDK-8132475 >> >> After "8080511: Refresh of jimage support" the executable commands in >> jdk/bin and jre/bin are only executable by the file owner. This means >> that only the user who built the images can execute the programs. >> >> The fix is trivial, but I've also added a test now so this won't >> happen a third time :) >> > This is a new image writer, it's different to what was there previously. > Just for the case it is changed once again :) > I assume the test can't run if the permissions are not right :-) > Of coarse it can't run if there are no executable permissions at all, but it will run and give an error if only the owner of the file has executable permissions which is what this bug is all about. Obviously, you (i.e. Oracle) are running all the tests with the same user who also built the VM that's why you didn't saw this problem two times. We have a distinct build and test users (which I think is good) so we always run into this instantly. Regards, Volker > -Alan. From mik3hall at gmail.com Thu Jul 30 23:08:51 2015 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Jul 2015 18:08:51 -0500 Subject: Should this work? Message-ID: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> jdeps -v -dotoutput ~/dotfiles jrt:/java.desktop/com/apple/laf/AquaBorder.class or what would be a good way to determine the dependencies for a Swing L&F? Running jdeps against the application jar for a Swing application shows no look and feel dependencies. Michael Hall From mik3hall at gmail.com Thu Jul 30 23:35:13 2015 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 30 Jul 2015 18:35:13 -0500 Subject: Should this work? In-Reply-To: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> Message-ID: <92271C8F-D3BB-4C34-838E-62DE032E76BB@gmail.com> > On Jul 30, 2015, at 6:08 PM, Michael Hall wrote: > > jdeps -v -dotoutput ~/dotfiles jrt:/java.desktop/com/apple/laf/AquaBorder.class > > or what would be a good way to determine the dependencies for a Swing L&F? > Running jdeps against the application jar for a Swing application shows no look and feel dependencies. OK, jdeps with plain class name works ok. Still sort of curious if the jrt version wouldn?t be a valid path? It is what is returned by the ClassLoader method getResource(). public URL getResource(String name) Finds the resource with the given name. Michael Hall From Alan.Bateman at oracle.com Fri Jul 31 06:45:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 Jul 2015 07:45:24 +0100 Subject: Should this work? In-Reply-To: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> Message-ID: <55BB1984.5000201@oracle.com> On 31/07/2015 00:08, Michael Hall wrote: > jdeps -v -dotoutput ~/dotfiles jrt:/java.desktop/com/apple/laf/AquaBorder.class > > or what would be a good way to determine the dependencies for a Swing L&F? > Running jdeps against the application jar for a Swing application shows no look and feel dependencies. > The argument to jdeps is a file path (to a JAR file, directory or .class files), it doesn't take a URL. This Swing LAF is the java.desktop module. The module can't have any dependences on anything that isn't also in the run-time image so you can be sure that this Swing LAF doesn't dependent on anything beyond the java.desktop, java.base and a few other standard/JDK modules. Is that what you are concerned about? For other LAFs then I assume they are in a JAR file or on the file system somewhere and you should be able to run jdeps on them. -Alan From mik3hall at gmail.com Fri Jul 31 08:37:46 2015 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 31 Jul 2015 03:37:46 -0500 Subject: Should this work? In-Reply-To: <55BB1984.5000201@oracle.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> Message-ID: <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> > On Jul 31, 2015, at 1:45 AM, Alan Bateman wrote: > > > This Swing LAF is the java.desktop module. The module can't have any dependences on anything that isn't also in the run-time image so you can be sure that this Swing LAF doesn't dependent on anything beyond the java.desktop, java.base and a few other standard/JDK modules. Is that what you are concerned about? My first concern was how do I use jdeps to know what dependencies my application code has on the l&f. If this doesn?t work I can just enumerate the l&f from java.desktop and determine what dependencies there are from that. All probably runtime as you mention. I was hoping jdeps would sort of indicate to me the same object tree that might be followed by serialization. The complete absence of l&f modules being listed when run against the application jar does seems like it could be a concern if the purpose is to modularize the applications use of the runtime itself. There would be no indication given by jdeps for the l&f that java.desktop is needed by the application. This is probably dynamic and not static to the application jar, I can?t say I know exactly how the laf linkage works, so if dynamic jdeps wouldn?t pick up on it. The person modularizing their runtime would just have to know they need to include java.desktop in their modularized runtime to get the l&f and would be able to add it manually, correct? I?m not that concerned that jrt:// usage doesn?t work but nio seems to be leaning in the url/uri direction so I sort of vaguely wondered if the command line tools might start reflecting that at some point and allow url type path specifications. Michael Hall From mik3hall at gmail.com Fri Jul 31 21:16:28 2015 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 31 Jul 2015 16:16:28 -0500 Subject: Should this work? In-Reply-To: <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> Message-ID: <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> > On Jul 31, 2015, at 3:37 AM, Michael Hall wrote: > > The complete absence of l&f modules being listed when run against the application jar does seems like it could be a concern if the purpose is to modularize the applications use of the runtime itself. Fwiw, I have tried -R recursive, and even -jdkinternals. Neither gave me the laf dependenciies for my application jar. I was not successful in using -M for module information to see if anything else identified java.desktop as a required module, it just didn?t work for me. Neither did -p to try and go directly after the package, or -filter:package. Either these are not in place or my build or usage is incorrect. But, having been unable to get jdeps to indicate java.desktop as a module dependency for the Aqua laf I still might consider this a concern if someone was trying to determine required modules for a OS X swing application. I haven?t tried other platforms. Maybe I should at least wait on doc before having concerns but this still seems one. Michael Hall From christian.thalinger at oracle.com Fri Jul 24 17:17:15 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Jul 2015 17:17:15 -0000 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: <55B271A0.7090705@oracle.com> References: <165AE6EA-8FB7-4715-8D76-477692B63C95@oracle.com> <69B55DAD-6E30-4703-B2B0-4A5EEC598149@oracle.com> <487562C8-9F9D-43B3-AF21-D99368852DDB@oracle.com> <55B271A0.7090705@oracle.com> Message-ID: <04A08DDE-B9A8-4DFD-82F9-6C0A668E4BC4@oracle.com> > On Jul 24, 2015, at 10:10 AM, Sergey Bylokhov wrote: > > After the latest merge I got some issue, I assume related to this fix. > Can somebody take a look to this code: > > import java.net.URI; > import java.nio.file.*; > import java.nio.file.attribute.BasicFileAttributes; > > public class JRTFileSystemError { > > public static void main(final String[] args) throws Exception { > FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/")); > Files.walkFileTree(fs.getPath("/java.desktop"), new SimpleFileVisitor() { > @Override > public FileVisitResult visitFile(Path file, > BasicFileAttributes attrs) { > return FileVisitResult.CONTINUE; > } > }); > } > } > > It fails with "Exception in thread "main" java.nio.file.NoSuchFileException: /java.desktop?. After the refresh all modules are under /modules. Try ?/modules/java.desktop?. > Bur previously it works correctly. Can somebody confirm this is an issue in the test(and how to change it) or in jdk? > It seems that IntelliJ also broken in some way so it cannot take classes from the jdk9 after this fix. probably they should update jrt-fs.jar? > > > On 23.06.15 19:08, Jean-Francois Denise wrote: >> Hi, >> an updated webrev that takes into account reviews. In addition the hotspot tests have been reworked following Christian Tornqvist suggestions. >> >> top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/ >> langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/ >> hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/ >> jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/ >> >> Testing: >> JCK(s) tests are passing (ran only on Mac OS) >> Hotspot tests are passing (All platforms) >> Java PIT tests are passing (All platforms). Ran once on https://bugs.openjdk.java.net/browse/JDK-8129592 >> >> Thanks. >> JF >> >> On 23 Jun 2015, at 14:10, Jean-Francois Denise wrote: >> >>> Hi Paul, >>> >>> On 19 Jun 2015, at 16:39, Paul Sandoz wrote: >>> >>>> On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) wrote: >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8080511 >>>>> >>>>> This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and improved performance for langtools in the presence of jrt-fs. >>>>> >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk >>>> I eyeballed the JDK changes. Just two thing: >>>> >>>> make/src/classes/build/tools/module/ModuleArchive.java >>>> >>>> 90 @Override >>>> 91 public Stream entries() { >>>> 92 List entries = new ArrayList<>(); >>>> 93 try { >>>> 94 if (classes != null) >>>> 95 Files.walk(classes) >>>> 96 .sorted() >>>> 97 .filter(p -> !Files.isDirectory(p) >>>> 98 && !classes.relativize(p).toString().startsWith("_the.") >>>> 99 && !classes.relativize(p).toString().equals("javac_state")) >>>> 100 .map(p -> toEntry(p, classes, EntryType.CLASS_OR_RESOURCE)) >>>> 101 .forEach(entries::add); >>>> 102 if (cmds != null) >>>> 103 Files.walk(cmds) >>>> 104 .filter(p -> !Files.isDirectory(p)) >>>> 105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD)) >>>> 106 .forEach(entries::add); >>>> 107 if (libs != null) >>>> 108 Files.walk(libs) >>>> 109 .filter(p -> !Files.isDirectory(p)) >>>> 110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB)) >>>> 111 .forEach(entries::add); >>>> 112 if (configs != null) >>>> 113 Files.walk(configs) >>>> 114 .filter(p -> !Files.isDirectory(p)) >>>> 115 .map(p -> toEntry(p, configs, EntryType.CONFIG)) >>>> 116 .forEach(entries::add); >>>> 117 } catch (IOException ioe) { >>>> 118 throw new UncheckedIOException(ioe); >>>> 119 } >>>> 120 return entries.stream(); >>>> 121 } >>>> >>>> You can use collect(toList()) >>> ==> OK collect used. In addition, filter first then sort, tryWithResource for 4 Files stream. >>> >>>> In general the contract for Archive.entries probably has to say the stream needs to be closed after use since it might cover lazy I/O based resources, so callers will need to use a try-with-resources block. >>> ==> Added a note in javadoc, implemented explicit close for non lazy streams, added missing tryWithResource. Added a comment on what should be done in ModuleArchive to keep laziness. >>>> Paul. >>> Thanks. >>> >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot >>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools >>>>> >>>>> >>>>> Details: >>>>> >>>>> - jrt-fs provides access, via the nio FileSystem API, to the classes in a .jimage file, organized by module or by package. >>>>> - Shared code for jimage support converted to native. Currently residing in hotspot, but will migrate to it?s own jdk library https://bugs.openjdk.java.net/browse/JDK-8087181 >>>>> - A new archive abstraction for class/resource sources. >>>>> - java based implementation layer for jimage reading to allow backport to JDK8 (jrt-fs.jar - IDE support.) >>>>> - JNI support for jimage into hotspot. >>>>> - White box tests written to exercise native jimage support. > > > -- > Best regards, Sergey. > From Sergey.Bylokhov at oracle.com Fri Jul 24 17:11:04 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 17:11:04 -0000 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: <487562C8-9F9D-43B3-AF21-D99368852DDB@oracle.com> References: <165AE6EA-8FB7-4715-8D76-477692B63C95@oracle.com> <69B55DAD-6E30-4703-B2B0-4A5EEC598149@oracle.com> <487562C8-9F9D-43B3-AF21-D99368852DDB@oracle.com> Message-ID: <55B271A0.7090705@oracle.com> After the latest merge I got some issue, I assume related to this fix. Can somebody take a look to this code: import java.net.URI; import java.nio.file.*; import java.nio.file.attribute.BasicFileAttributes; public class JRTFileSystemError { public static void main(final String[] args) throws Exception { FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/")); Files.walkFileTree(fs.getPath("/java.desktop"), new SimpleFileVisitor() { @Override public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) { return FileVisitResult.CONTINUE; } }); } } It fails with "Exception in thread "main" java.nio.file.NoSuchFileException: /java.desktop". Bur previously it works correctly. Can somebody confirm this is an issue in the test(and how to change it) or in jdk? It seems that IntelliJ also broken in some way so it cannot take classes from the jdk9 after this fix. probably they should update jrt-fs.jar? On 23.06.15 19:08, Jean-Francois Denise wrote: > Hi, > an updated webrev that takes into account reviews. In addition the hotspot tests have been reworked following Christian Tornqvist suggestions. > > top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/ > langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/ > hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/ > jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/ > > Testing: > JCK(s) tests are passing (ran only on Mac OS) > Hotspot tests are passing (All platforms) > Java PIT tests are passing (All platforms). Ran once on https://bugs.openjdk.java.net/browse/JDK-8129592 > > Thanks. > JF > > On 23 Jun 2015, at 14:10, Jean-Francois Denise wrote: > >> Hi Paul, >> >> On 19 Jun 2015, at 16:39, Paul Sandoz wrote: >> >>> On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8080511 >>>> >>>> This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and improved performance for langtools in the presence of jrt-fs. >>>> >>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top >>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk >>> I eyeballed the JDK changes. Just two thing: >>> >>> make/src/classes/build/tools/module/ModuleArchive.java >>> >>> 90 @Override >>> 91 public Stream entries() { >>> 92 List entries = new ArrayList<>(); >>> 93 try { >>> 94 if (classes != null) >>> 95 Files.walk(classes) >>> 96 .sorted() >>> 97 .filter(p -> !Files.isDirectory(p) >>> 98 && !classes.relativize(p).toString().startsWith("_the.") >>> 99 && !classes.relativize(p).toString().equals("javac_state")) >>> 100 .map(p -> toEntry(p, classes, EntryType.CLASS_OR_RESOURCE)) >>> 101 .forEach(entries::add); >>> 102 if (cmds != null) >>> 103 Files.walk(cmds) >>> 104 .filter(p -> !Files.isDirectory(p)) >>> 105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD)) >>> 106 .forEach(entries::add); >>> 107 if (libs != null) >>> 108 Files.walk(libs) >>> 109 .filter(p -> !Files.isDirectory(p)) >>> 110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB)) >>> 111 .forEach(entries::add); >>> 112 if (configs != null) >>> 113 Files.walk(configs) >>> 114 .filter(p -> !Files.isDirectory(p)) >>> 115 .map(p -> toEntry(p, configs, EntryType.CONFIG)) >>> 116 .forEach(entries::add); >>> 117 } catch (IOException ioe) { >>> 118 throw new UncheckedIOException(ioe); >>> 119 } >>> 120 return entries.stream(); >>> 121 } >>> >>> You can use collect(toList()) >> ==> OK collect used. In addition, filter first then sort, tryWithResource for 4 Files stream. >> >>> In general the contract for Archive.entries probably has to say the stream needs to be closed after use since it might cover lazy I/O based resources, so callers will need to use a try-with-resources block. >> ==> Added a note in javadoc, implemented explicit close for non lazy streams, added missing tryWithResource. Added a comment on what should be done in ModuleArchive to keep laziness. >>> Paul. >> Thanks. >> >>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot >>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools >>>> >>>> >>>> Details: >>>> >>>> - jrt-fs provides access, via the nio FileSystem API, to the classes in a .jimage file, organized by module or by package. >>>> - Shared code for jimage support converted to native. Currently residing in hotspot, but will migrate to it?s own jdk library https://bugs.openjdk.java.net/browse/JDK-8087181 >>>> - A new archive abstraction for class/resource sources. >>>> - java based implementation layer for jimage reading to allow backport to JDK8 (jrt-fs.jar - IDE support.) >>>> - JNI support for jimage into hotspot. >>>> - White box tests written to exercise native jimage support. -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Jul 24 18:46:46 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 24 Jul 2015 18:46:46 -0000 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: <3C863E9B-2C79-4058-9588-A17C5015EBBA@oracle.com> References: <165AE6EA-8FB7-4715-8D76-477692B63C95@oracle.com> <69B55DAD-6E30-4703-B2B0-4A5EEC598149@oracle.com> <487562C8-9F9D-43B3-AF21-D99368852DDB@oracle.com> <55B271A0.7090705@oracle.com> <3C863E9B-2C79-4058-9588-A17C5015EBBA@oracle.com> Message-ID: <55B2880F.8050102@oracle.com> On 24.07.15 20:17, Jean-Francois Denise wrote: > Hi, > you need to prefix your path with /modules, so ?/modules/java.desktop?. Thanks. It works. > JF > > > On 24 Jul 2015, at 19:10, Sergey Bylokhov wrote: > >> After the latest merge I got some issue, I assume related to this fix. >> Can somebody take a look to this code: >> >> import java.net.URI; >> import java.nio.file.*; >> import java.nio.file.attribute.BasicFileAttributes; >> >> public class JRTFileSystemError { >> >> public static void main(final String[] args) throws Exception { >> FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/")); >> Files.walkFileTree(fs.getPath("/java.desktop"), new SimpleFileVisitor() { >> @Override >> public FileVisitResult visitFile(Path file, >> BasicFileAttributes attrs) { >> return FileVisitResult.CONTINUE; >> } >> }); >> } >> } >> >> It fails with "Exception in thread "main" java.nio.file.NoSuchFileException: /java.desktop". >> Bur previously it works correctly. Can somebody confirm this is an issue in the test(and how to change it) or in jdk? >> It seems that IntelliJ also broken in some way so it cannot take classes from the jdk9 after this fix. probably they should update jrt-fs.jar? >> >> >> On 23.06.15 19:08, Jean-Francois Denise wrote: >>> Hi, >>> an updated webrev that takes into account reviews. In addition the hotspot tests have been reworked following Christian Tornqvist suggestions. >>> >>> top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/ >>> langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/ >>> hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/ >>> jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/ >>> >>> Testing: >>> JCK(s) tests are passing (ran only on Mac OS) >>> Hotspot tests are passing (All platforms) >>> Java PIT tests are passing (All platforms). Ran once on https://bugs.openjdk.java.net/browse/JDK-8129592 >>> >>> Thanks. >>> JF >>> >>> On 23 Jun 2015, at 14:10, Jean-Francois Denise wrote: >>> >>>> Hi Paul, >>>> >>>> On 19 Jun 2015, at 16:39, Paul Sandoz wrote: >>>> >>>>> On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) wrote: >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8080511 >>>>>> >>>>>> This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and improved performance for langtools in the presence of jrt-fs. >>>>>> >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk >>>>> I eyeballed the JDK changes. Just two thing: >>>>> >>>>> make/src/classes/build/tools/module/ModuleArchive.java >>>>> >>>>> 90 @Override >>>>> 91 public Stream entries() { >>>>> 92 List entries = new ArrayList<>(); >>>>> 93 try { >>>>> 94 if (classes != null) >>>>> 95 Files.walk(classes) >>>>> 96 .sorted() >>>>> 97 .filter(p -> !Files.isDirectory(p) >>>>> 98 && !classes.relativize(p).toString().startsWith("_the.") >>>>> 99 && !classes.relativize(p).toString().equals("javac_state")) >>>>> 100 .map(p -> toEntry(p, classes, EntryType.CLASS_OR_RESOURCE)) >>>>> 101 .forEach(entries::add); >>>>> 102 if (cmds != null) >>>>> 103 Files.walk(cmds) >>>>> 104 .filter(p -> !Files.isDirectory(p)) >>>>> 105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD)) >>>>> 106 .forEach(entries::add); >>>>> 107 if (libs != null) >>>>> 108 Files.walk(libs) >>>>> 109 .filter(p -> !Files.isDirectory(p)) >>>>> 110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB)) >>>>> 111 .forEach(entries::add); >>>>> 112 if (configs != null) >>>>> 113 Files.walk(configs) >>>>> 114 .filter(p -> !Files.isDirectory(p)) >>>>> 115 .map(p -> toEntry(p, configs, EntryType.CONFIG)) >>>>> 116 .forEach(entries::add); >>>>> 117 } catch (IOException ioe) { >>>>> 118 throw new UncheckedIOException(ioe); >>>>> 119 } >>>>> 120 return entries.stream(); >>>>> 121 } >>>>> >>>>> You can use collect(toList()) >>>> ==> OK collect used. In addition, filter first then sort, tryWithResource for 4 Files stream. >>>> >>>>> In general the contract for Archive.entries probably has to say the stream needs to be closed after use since it might cover lazy I/O based resources, so callers will need to use a try-with-resources block. >>>> ==> Added a note in javadoc, implemented explicit close for non lazy streams, added missing tryWithResource. Added a comment on what should be done in ModuleArchive to keep laziness. >>>>> Paul. >>>> Thanks. >>>> >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot >>>>>> http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools >>>>>> >>>>>> >>>>>> Details: >>>>>> >>>>>> - jrt-fs provides access, via the nio FileSystem API, to the classes in a .jimage file, organized by module or by package. >>>>>> - Shared code for jimage support converted to native. Currently residing in hotspot, but will migrate to it?s own jdk library https://bugs.openjdk.java.net/browse/JDK-8087181 >>>>>> - A new archive abstraction for class/resource sources. >>>>>> - java based implementation layer for jimage reading to allow backport to JDK8 (jrt-fs.jar - IDE support.) >>>>>> - JNI support for jimage into hotspot. >>>>>> - White box tests written to exercise native jimage support. >> >> -- >> Best regards, Sergey. >> -- Best regards, Sergey.