From mandy.chung at oracle.com Sun Nov 1 04:55:58 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sun, 01 Nov 2015 04:55:58 +0000 Subject: hg: jigsaw/jake/jdk: Update java.util.spi.AbstractResourceBundleProvider javadoc per the fix for 8139067 Message-ID: <201511010455.tA14twMH016812@aojmv0008.oracle.com> Changeset: 0b5cbd1f966e Author: mchung Date: 2015-10-31 21:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0b5cbd1f966e Update java.util.spi.AbstractResourceBundleProvider javadoc per the fix for 8139067 ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java From alan.bateman at oracle.com Sun Nov 1 18:34:19 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 01 Nov 2015 18:34:19 +0000 Subject: hg: jigsaw/jake/jdk: Drop -Xoverride, replaced by -Xpatch Message-ID: <201511011834.tA1IYJGC000918@aojmv0008.oracle.com> Changeset: 34a20e1f0d8b Author: alanb Date: 2015-11-01 18:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/34a20e1f0d8b Drop -Xoverride, replaced by -Xpatch ! src/java.base/share/native/libjli/java.c From mandy.chung at oracle.com Mon Nov 2 04:05:59 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 02 Nov 2015 04:05:59 +0000 Subject: hg: jigsaw/jake/langtools: Update T6769027.java to use JavacMessages.add(ResourceBundleHelper) Message-ID: <201511020405.tA245xrP018846@aojmv0008.oracle.com> Changeset: 056daf65e292 Author: mchung Date: 2015-11-01 20:05 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/056daf65e292 Update T6769027.java to use JavacMessages.add(ResourceBundleHelper) ! test/tools/javac/Diagnostics/6769027/T6769027.java From rory.odonnell at oracle.com Mon Nov 2 08:51:32 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 2 Nov 2015 08:51:32 +0000 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <5634C884.6040302@oracle.com> References: <5634C884.6040302@oracle.com> Message-ID: <56372414.7010605@oracle.com> I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log an issue there ? Rgds,Rory On 31/10/2015 13:56, Alan Bateman wrote: > On 31/10/2015 12:50, Mani Sarkar wrote: >> Hi Rory, >> >> Do you know of a version of Gradle or a EA version which is JDK 9 >> Jigsaw compatible, we get these failures when building: >> >> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console >> >> > Caused by: java.lang.IllegalAccessException: class > org.gradle.internal.reflect.DirectInstantiator cannot access class > com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because > module jdk.compiler does not export package com.sun.tools.javac.api to > > at > org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49) > ... 86 more > > We should at least check if there is a bug in the Gradle JIRA for > this. It can be worked around by configuring the compileJava options > to fork javac but you might not want to do that. > > The other issue with Gradle that we know about is the > ClassCastException when attempting to run tests, this is tracked here: > https://issues.gradle.org/browse/GRADLE-3287 > > -Alan. > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From cedric.champeau at gmail.com Mon Nov 2 08:56:39 2015 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 2 Nov 2015 09:56:39 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <56372414.7010605@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> Message-ID: BTW, Groovy itself is not compatible with Jigsaw, so my guess would be that even if Gradle fixed this, you would have different errors because Gradle uses Groovy. What is possible today is to run Gradle on Java 9 non jigsaw, and compile using Java 9 Jigsaw. Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with Jigsaw") but as far as I understand, there's no clear understanding of the problem/solutions so far. 2015-11-02 9:51 GMT+01:00 Rory O'Donnell : > I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log > an issue there ? > > Rgds,Rory > > > On 31/10/2015 13:56, Alan Bateman wrote: > >> On 31/10/2015 12:50, Mani Sarkar wrote: >> >>> Hi Rory, >>> >>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw >>> compatible, we get these failures when building: >>> >>> >>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console >>> >>> Caused by: java.lang.IllegalAccessException: class >> org.gradle.internal.reflect.DirectInstantiator cannot access class >> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module >> jdk.compiler does not export package com.sun.tools.javac.api to > module @b7f23d9> >> at >> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49) >> ... 86 more >> >> We should at least check if there is a bug in the Gradle JIRA for this. >> It can be worked around by configuring the compileJava options to fork >> javac but you might not want to do that. >> >> The other issue with Gradle that we know about is the ClassCastException >> when attempting to run tests, this is tracked here: >> https://issues.gradle.org/browse/GRADLE-3287 >> >> -Alan. >> >> > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > From Alan.Bateman at oracle.com Mon Nov 2 09:05:23 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Nov 2015 09:05:23 +0000 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> Message-ID: <56372753.6010702@oracle.com> On 02/11/2015 08:56, C?dric Champeau wrote: > BTW, Groovy itself is not compatible with Jigsaw, so my guess would be > that even if Gradle fixed this, you would have different errors > because Gradle uses Groovy. What is possible today is to run Gradle on > Java 9 non jigsaw, and compile using Java 9 Jigsaw. > > Jochen sent an email on jigsaw-dev a few weeks ago ("Groovy with > Jigsaw") but as far as I understand, there's no clear understanding of > the problem/solutions so far. There was one specific issue in that thread, it was a VerifyError that stemmed from Guava overriding java.lang.reflect.AccessibleObject.setAccessible. That issue was resolved at the time and I don't think there were any other specific issues on that thread. There was of course the general issue that Groovy seems to access or wrap types in non-exported packages but we don't have a solution to that except via the command-line -XaddExports. -Alan. From jarthana at in.ibm.com Mon Nov 2 09:48:24 2015 From: jarthana at in.ibm.com (Jayaprakash Arthanareeswaran) Date: Mon, 2 Nov 2015 15:18:24 +0530 Subject: Is Caching JrtFileSystem acceptable? Message-ID: Hello, We recently changed our code in Eclipse to support JRE 8 when loading classes from a Java 9 images (discussion at [1]). The change was to use a JrtFileSystem with a class loader. The file system is then cached and re-used for every request to get something from the JRE 9 images. The code is something like this: URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL(); URLClassLoader loader = new URLClassLoader(new URL[] { url }); FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader); After this change, we have started getting an NPE in the file system (We are randomly hitting this and at this point no idea what is causing it): Daemon Thread [Java indexing] (Suspended (exception NullPointerException)) ByteArrayInputStream.(byte[]) line: 106 JrtFileSystem.newByteChannel(byte[], Set, FileAttribute...) line: 600 JrtPath.newByteChannel(Set, FileAttribute...) line: 732 JrtFileSystemProvider.newByteChannel(Path, Set, FileAttribute...) line: 218 Files.newByteChannel(Path, Set, FileAttribute...) line: 361 Files.newByteChannel(Path, OpenOption...) line: 407 Files.readAllBytes(Path) line: 3152 I have confirmed that the JrtFileSystem that is used in the above stack and what we cached are the same objects. And the path that is being passed in the beginning is a valid JrtPath. I would like to know if this is a bug in the file system implementation or something to do with our code. Of course, I don't have the source for JrtFileSystem, so unable to debug this further. Thanks for any pointers in trouble-shooting this further. Regards, Jay [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-October/004857.html From cedric.champeau at gmail.com Mon Nov 2 09:58:06 2015 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 2 Nov 2015 10:58:06 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <56372753.6010702@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> Message-ID: > > That issue was resolved at the time and I don't think there were any > other specific issues on that thread. There was of course the general issue > that Groovy seems to access or wrap types in non-exported packages but we > don't have a solution to that except via the command-line -XaddExports. > > -Alan. > I think this is the particular issue Jochen is very worried about. We should think about the consequences of it. What does it mean to be forced to use -XaddExports. It is at least unclear to me. What would be catastrophic is releasing Jigsaw and realizing that we killed Groovy because it cannot use modules without, for example, disabling all kind of security. From Alan.Bateman at oracle.com Mon Nov 2 10:24:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Nov 2015 10:24:50 +0000 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> Message-ID: <563739F2.2030002@oracle.com> On 02/11/2015 09:58, C?dric Champeau wrote: > > I think this is the particular issue Jochen is very worried about. We > should think about the consequences of it. What does it mean to be > forced to use -XaddExports. It is at least unclear to me. What would > be catastrophic is releasing Jigsaw and realizing that we killed > Groovy because it cannot use modules without, for example, disabling > all kind of security. Uwe Schindler has created a bug on this topic here: https://issues.apache.org/jira/browse/GROOVY-7587 It makes me wonder if Groovy has ever been used with a security manager as it seems to wrap or need access to all JDK-internal types. -Alan. From Alan.Bateman at oracle.com Mon Nov 2 10:35:36 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Nov 2015 10:35:36 +0000 Subject: Is Caching JrtFileSystem acceptable? In-Reply-To: References: Message-ID: <56373C78.4090807@oracle.com> On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote: > > Hello, > > We recently changed our code in Eclipse to support JRE 8 when loading > classes from a Java 9 images (discussion at [1]). The change was to use a > JrtFileSystem with a class loader. The file system is then cached and > re-used for every request to get something from the JRE 9 images. The code > is something like this: > > URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL(); > URLClassLoader loader = new URLClassLoader(new URL[] { url }); > FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader); > > After this change, we have started getting an NPE in the file system (We > are randomly hitting this and at this point no idea what is causing it): > > Daemon Thread [Java indexing] (Suspended (exception NullPointerException)) > ByteArrayInputStream.(byte[]) line: 106 > JrtFileSystem.newByteChannel(byte[], Set, > FileAttribute...) line: 600 > JrtPath.newByteChannel(Set, FileAttribute...) line: > 732 > JrtFileSystemProvider.newByteChannel(Path, Set, > FileAttribute...) line: 218 > Files.newByteChannel(Path, Set, FileAttribute...) > line: 361 > Files.newByteChannel(Path, OpenOption...) line: 407 > Files.readAllBytes(Path) line: 3152 > > I have confirmed that the JrtFileSystem that is used in the above stack and > what we cached are the same objects. And the path that is being passed in > the beginning is a valid JrtPath. I would like to know if this is a bug in > the file system implementation or something to do with our code. > > Of course, I don't have the source for JrtFileSystem, so unable to debug > this further. Thanks for any pointers in trouble-shooting this further. > I'm not aware of any issues here and there shouldn't be an issue retaining the reference to the jrt FileSystem. As the jrt FileSystem is in the stack trace then it means that Files.readAllBytes has been called with Path associated with the jrt file system. It's not obvious how a NPE could arise after that. The only thing that comes to mind is the file system being closed asynchronously, I can't recall how the jrt file system handles that (Sundar will know). However, just to establish the environment - is this IBM JDK 8 or an Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK 9 build or a Jigsaw build? There are changes to the jrt file system code in the Jigsaw forest but this is mostly to support exploded builds. -Alan From cedric.champeau at gmail.com Mon Nov 2 10:49:35 2015 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 2 Nov 2015 11:49:35 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <563739F2.2030002@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> <563739F2.2030002@oracle.com> Message-ID: Surely Groovy is widely used with security managers, and it has never been a problem so far. I'm not sure how this issue is relevant to the problem, but Jochen expressed several times concerns about how Groovy would interact with Jigsaw without getting clear answers, or at best "we don't know". I'm unfortunately not in a position where I can investigate right now, but Jigsaw is certainly critical for both Groovy and Gradle, so I'd like to make sure we address all issues before Jigsaw is out. Basically my focus today is making Gradle capable of building apps using Jigsaw, but not running on Jigsaw. Just because those are competing priorities. But both *have* to be fixed. 2015-11-02 11:24 GMT+01:00 Alan Bateman : > > On 02/11/2015 09:58, C?dric Champeau wrote: > >> >> I think this is the particular issue Jochen is very worried about. We >> should think about the consequences of it. What does it mean to be forced >> to use -XaddExports. It is at least unclear to me. What would be >> catastrophic is releasing Jigsaw and realizing that we killed Groovy >> because it cannot use modules without, for example, disabling all kind of >> security. >> > > Uwe Schindler has created a bug on this topic here: > > https://issues.apache.org/jira/browse/GROOVY-7587 > > It makes me wonder if Groovy has ever been used with a security manager as > it seems to wrap or need access to all JDK-internal types. > > -Alan. > From blackdrag at gmx.org Mon Nov 2 12:55:45 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 2 Nov 2015 13:55:45 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <563739F2.2030002@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> <563739F2.2030002@oracle.com> Message-ID: <56375D51.6020101@gmx.org> On 02.11.2015 11:24, Alan Bateman wrote: [...] > Uwe Schindler has created a bug on this topic here: > > https://issues.apache.org/jira/browse/GROOVY-7587 > > It makes me wonder if Groovy has ever been used with a security manager > as it seems to wrap or need access to all JDK-internal types. This impression is wrong, Groovy does not need access to all JDK-internal types. But this is a dynamic language at heart. If you do not have a static type, then the runtime type is what counts, and that is the exact type, which is sometime an internal JDK type. It means Groovy has to do the same thing it has to do when a security manager doesn't like access to this class, which is to not use the specific class/method, but the super class information... or the information of that super class.. in worst case this will be Object, which means only method from Object can be called using Groovy in that case. The current state is, that this issue is now fixed. The example scripts in the issue are working. That does not mean we can now run the build on jigsaw of course. bye Jochen From ali.ebrahimi1781 at gmail.com Mon Nov 2 13:20:47 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 2 Nov 2015 16:50:47 +0330 Subject: Question on Implied readability Message-ID: Hi, please clear situation for me: I have two version of com.bar module one com.baz that depends on com.bar one com.foo that depends on both com.bar and com.baz Two layer: layer 1: com.baz and com.bar at 1 --------------------------- module com.bar {//version1 exports com.bar; } ------------------ //Bar.java package com.bar; public class Bar { public String bar(){ return "bar1";} } module com.baz { requires com.bar; exports com.baz; } ----------------- //Baz.java package com.baz; import com.bar.Bar; public class Baz { public String baz(){ return new Bar().bar();} public Bar bar(){ return new Bar(); } } layer 2: com.foo and com.bar at 2 -------------------- module com.bar {//version2 exports com.bar; } ------------- //Bar.java package com.bar; public class Bar { public String bar(){ return "bar2";} } ------------- module com.foo { requires com.bar; requires com.baz; } ------------- Foo.java package com.foo; import com.bar.Bar; import com.baz.Baz; public class Main { public static void main(String[] args) { System.out.println(new Baz().baz()); System.out.println(new Bar().bar()); } } Result: bar1 bar2 Good. So we can have different versions of same module. But, my question arise from section "Implied readability" of "The State of the Module System" document: "The public modifiers mean that any module that depends upon the java.sql module will read not only the java.sql module but also the java.logging and java.xml modules. " Based on this paragraph we can edit module descriptors for modules com.foo and com.baz as: -------------------- module com.baz { requires public com.bar; exports com.baz; } -------------- module com.foo { requires com.baz; } But result is: bar1 Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0 /NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0 /DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:531) at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0 /Bootstrapper.java:67) Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: com.foo) cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read com.bar at com.foo.Main.main(com.foo/Main.java:12) ... 5 more The exception message says: com.foo cannot read com.bar. Why? Is not two situation equivalent? (before Implied readability and after) This is bug? Best Regards, Ali Ebrahimi From artem.smotrakov at oracle.com Mon Nov 2 13:30:39 2015 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 2 Nov 2015 16:30:39 +0300 Subject: [9] RFR: 8140649: imageFile should use delete[] with new[] Message-ID: <5637657F.1060108@oracle.com> Hello, Please review this small fix for jdk9/dev repo. It updates imageFile.cpp to use delete[] operator together with new[]. It also adds a check to ImageLocation::set_data(u1*) method to prevent a possible null-dereference. Bug: https://bugs.openjdk.java.net/browse/JDK-8140649 Webrev: http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/ Artem From james.laskey at oracle.com Mon Nov 2 14:59:18 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 2 Nov 2015 10:59:18 -0400 Subject: [9] RFR: 8140649: imageFile should use delete[] with new[] In-Reply-To: <5637657F.1060108@oracle.com> References: <5637657F.1060108@oracle.com> Message-ID: +1 > On Nov 2, 2015, at 9:30 AM, Artem Smotrakov wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates imageFile.cpp to use delete[] operator together with new[]. It also adds a check to ImageLocation::set_data(u1*) method to prevent a possible null-dereference. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140649 > Webrev: http://cr.openjdk.java.net/~asmotrak/image_file_new_delete/webrev.01/ > > Artem From Alan.Bateman at oracle.com Mon Nov 2 18:48:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Nov 2015 18:48:04 +0000 Subject: Question on Implied readability In-Reply-To: References: Message-ID: <5637AFE4.8020000@oracle.com> On 02/11/2015 13:20, Ali Ebrahimi wrote: > : > > bar1 > Exception in thread "main" java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native > Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0 > /NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0 > /DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:531) > at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0 > /Bootstrapper.java:67) > Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: > com.foo) > cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read > com.bar > at com.foo.Main.main(com.foo/Main.java:12) > ... 5 more > > The exception message says: com.foo cannot read com.bar. Why? > Is not two situation equivalent? (before Implied readability and after) > This is bug? I used the source from your mail to create a test case but I didn't duplicate what you were seeing. In my test then I created two layers L1 and L2. In L1 then com.bar at 1 and com.baz are mapped to the same loader CL1. In L2 then com.bar at 2 and com.foo are mapped to the same loader CL2. The parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing local-first rather than parent delegation so that it loads the local version of module com.bar's types. The readability is setup as expected: Module foo = layer2.findModule("com.foo").get(); Module bar2 = layer2.findModule("com.bar").get(); assertTrue(foo.canRead(bar2)); Module bar1 = layer1.findModule("com.bar").get(); assertFalse(foo.canRead(bar1)) I can't rule out a bug of course but I would need to see an outline of what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the layers and class loaders are arranged. -Alan. From pbenedict at apache.org Mon Nov 2 19:13:42 2015 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 2 Nov 2015 13:13:42 -0600 Subject: Question on Implied readability In-Reply-To: <5637AFE4.8020000@oracle.com> References: <5637AFE4.8020000@oracle.com> Message-ID: Alan, please correct me if wrong, but there is no enforced correlation between the module name and the jar name it's packaged in, right? The name is officially taken from the module-info.class? If so, I'd like to make a suggestion. One thing that's been extremely useful to me with JBoss is the ability to link back to the JAR path in the stack trace. Is there any chance you would consider expanding the stack trace to something like this: bar1 Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0 [c:\jdk\1.9\jre\modules\java.base.jar]/NativeMethod) Paul Cheers, Paul On Mon, Nov 2, 2015 at 12:48 PM, Alan Bateman wrote: > On 02/11/2015 13:20, Ali Ebrahimi wrote: > >> : >> >> bar1 >> Exception in thread "main" java.lang.reflect.InvocationTargetException >> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0 >> /Native >> Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0 >> /NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0 >> /DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(java.base at 9.0 >> /Method.java:531) >> at jakeplus.minicontainer.Bootstrapper.main(java.base at 9.0 >> /Bootstrapper.java:67) >> Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: >> com.foo) >> cannot access class com.bar.Bar (in module: com.bar), com.foo cannot >> read >> com.bar >> at com.foo.Main.main(com.foo/Main.java:12) >> ... 5 more >> >> The exception message says: com.foo cannot read com.bar. Why? >> Is not two situation equivalent? (before Implied readability and after) >> This is bug? >> > > I used the source from your mail to create a test case but I didn't > duplicate what you were seeing. In my test then I created two layers L1 and > L2. In L1 then com.bar at 1 and com.baz are mapped to the same loader CL1. > In L2 then com.bar at 2 and com.foo are mapped to the same loader CL2. The > parent of L2 is L1. The parent of CL2 is CL1 with CL2 doing local-first > rather than parent delegation so that it loads the local version of module > com.bar's types. > > The readability is setup as expected: > > Module foo = layer2.findModule("com.foo").get(); > Module bar2 = layer2.findModule("com.bar").get(); > assertTrue(foo.canRead(bar2)); > > Module bar1 = layer1.findModule("com.bar").get(); > assertFalse(foo.canRead(bar1)) > > I can't rule out a bug of course but I would need to see an outline of > what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the > layers and class loaders are arranged. > > -Alan. > From ali.ebrahimi1781 at gmail.com Mon Nov 2 20:02:20 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 2 Nov 2015 23:32:20 +0330 Subject: Question on Implied readability In-Reply-To: <5637AFE4.8020000@oracle.com> References: <5637AFE4.8020000@oracle.com> Message-ID: Hi Alan, I don't khow how you testing this. But this is simple possible test case: public class Test { public static void main(String[] args) throws Exception { ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1")); Configuration cfg1 = Configuration.resolve(finder1, Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz"); ModuleClassLoader cl1 = new ModuleClassLoader(cfg1); Layer layer1 = Layer.create(cfg1, m -> cl1); ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2")); Configuration cfg2 = Configuration.resolve(finder2, layer1,ModuleFinder.empty(),"com.bar","com.foo"); ModuleClassLoader cl2 = new ModuleClassLoader(cl1,cfg2); Layer layer2 = Layer.create(cfg2, m -> cl2); System.out.println("layer2.modules()\n"+layer2.modules()); System.out.println("layer1.modules()\n"+layer1.modules()); Module foo = layer2.findModule("com.foo").get(); Module bar2 = layer2.findModule("com.bar").get(); System.out.println("foo.canRead(bar2) -> "+foo.canRead(bar2)); Module bar1 = layer1.findModule("com.bar").get(); System.out.println("foo.canRead(bar1) -> "+foo.canRead(bar1)); ClassLoader fooModuleLoader = layer2.findLoader("com.foo"); Class mainClass = fooModuleLoader.loadClass("com.foo.Main"); Test.class.getModule().addReads(mainClass.getModule()); Method mainMethod = mainClass.getMethod("main", String[].class); mainMethod.invoke(null, (Object)new String[0]); } And Result: layer2.modules() [module com.foo, module com.bar] layer1.modules() [module com.baz, module com.bar] foo.canRead(bar2) -> false foo.canRead(bar1) -> false bar1 Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0/Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(java.base at 9.0/NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 9.0/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base at 9.0/Method.java:531) at com.test.Test.main(com.test/Test.java:48) Caused by: java.lang.IllegalAccessError: class com.foo.Main (in module: com.foo) cannot access class com.bar.Bar (in module: com.bar), com.foo cannot read com.bar at com.foo.Main.main(com.foo/Main.java:12) ... 5 more Note that I get above result if Implied readability used. On Mon, Nov 2, 2015 at 10:18 PM, Alan Bateman wrote: > On 02/11/2015 13:20, Ali Ebrahimi wrote: > >> : >> >> > I can't rule out a bug of course but I would need to see an outline of > what jakeplus.minicontainer.Bootstrapper is doing so that I can see how the > layers and class loaders are arranged. This is simple extension to jake that build layers based on config from command line. Sample Input: > > -Alan. > -- Best Regards, Ali Ebrahimi From alex.buckley at oracle.com Mon Nov 2 21:03:17 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 02 Nov 2015 13:03:17 -0800 Subject: Avoiding same-package conflicts In-Reply-To: <5633D52C.6050406@gmx.org> References: <563223CB.8060300@oracle.com> <5633D52C.6050406@gmx.org> Message-ID: <5637CF95.9030800@oracle.com> On 10/30/2015 1:38 PM, Jochen Theodorou wrote: > I can second that by an example using Groovy. We have not yet taken > steps to make jigsaw modules, but we quite some time ago we have split > the code base in what would become eventually become modules in the > future. Because of history this did mean to split packages. So we have a > couple of jars (that want to be modules), with overlapping package names. > > Examples of package conflicts with the "base module": > > * The groovy-console has a conflict in groovy.ui > * groovy-ant has a conflict in groovy.util > * groovy-docgenerator in org.codehaus.groovy.tools > * groovy-nio in org.codehaus.groovy.runtime > * groovy-sql in org.codehaus.groovy.runtime > * groovy-swing in org.codehaus.groovy.runtime > * groovy-test in goovy.lang and groovy.util > * groovy-xml in org.codehaus.groovy.runtime and goovy.util > > That's 7 "modules" with conflicts out of 19. One should remember here, > that the codebase is like 10+ years old, and something that is now a > "module" used to be fixed part of the language in the past. So some poor > naming decision have been made. The org.codehaus.groovy.runtime > conflicts could probably be solved, but the groovy.util ones are > difficult, since this is a package imported by default (like java.lang > in java), so moving classes to differing packages will break Groovy > scripts... very elementary here for example GroovyTestCase in > groovy-util, which is in the groovy-test "module".. The initial modularization of JavaFX had a similar pattern: more split packages than you would think, due to a "horizontal" module wanting to share packages with numerous "vertical" domain modules. There, the "horizontal" module was a 'builder' module which hoped to add $COMPONENTBuilder classes to the packages of various 'component' modules; eventually the $COMPONENTBuilder classes were deemed unnecessary and the 'builder' module deleted. For Groovy, I suggest that your "base module" has the greatest claim to the org.codehaus.groovy.runtime package, and that the groovy-{nio,sql,swing,xml} modules should export org.codehaus.groovy.runtime.* subpackages to the base module only. It doesn't seem great that the groovy-ant and groovy-test modules try to augment the important groovy.util package owned by your base module. Speaking generally, it makes no sense to allow a module to protect its internals if at the same time its API can be augmented by unrelated modules -- it can't be the "same" API because it doesn't have access to the same internals. > also... there is a automated meta class lookup system, that is based on > the package name with a prefix. So someone could provide a meta class > for java.util.ArrayList, while another does this for LinkedList. If they > are using modules, they cannot be loaded at the same time. Granted, I > don't like this mechanism, and I am looking for ways to deprecate it in > the near future, but it is another example of same-package conflicts. Does this mean a Groovy meta class can currently be defined as a class in the java.* run-time package of the bootstrap loader? Alex From Alan.Bateman at oracle.com Mon Nov 2 21:51:23 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 Nov 2015 21:51:23 +0000 Subject: Question on Implied readability In-Reply-To: References: <5637AFE4.8020000@oracle.com> Message-ID: <5637DADB.7000407@oracle.com> On 02/11/2015 20:02, Ali Ebrahimi wrote: > : > layer2.modules() [module com.foo, module com.bar] layer1.modules() > [module com.baz, module com.bar] foo.canRead(bar2) -> false > foo.canRead(bar1) -> false Thanks, I see the issue. The reason it didn't duplicate for me is because I hadn't dropped the requires com.bar. So the bug is implied readability across layers when the same named module exists in multiple layers. In this case com.foo should read com.bar at 1. The com.bar (@2) is the same configuration as com.foo is confusing the code. We'll need to fix this. -Alan From sadhak001 at gmail.com Mon Nov 2 22:23:38 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 2 Nov 2015 22:23:38 +0000 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <56372414.7010605@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> Message-ID: Hi Rory, TestNG has an alternative build system which we will try to use to build it using the Jigsaw binary. How do you report such bugs to Gradle / Groovy ? Is it simpler if you reported to them on their mailing list ? Let me know what works best, this is fairly important as other Gradle users might have similar issues. Cheers, Mani On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell wrote: > I can't find a bug in Gradle's JIRA on this issue, Mani do you want to log > an issue there ? > > Rgds,Rory > > > On 31/10/2015 13:56, Alan Bateman wrote: > >> On 31/10/2015 12:50, Mani Sarkar wrote: >> >>> Hi Rory, >>> >>> Do you know of a version of Gradle or a EA version which is JDK 9 Jigsaw >>> compatible, we get these failures when building: >>> >>> >>> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console >>> >>> Caused by: java.lang.IllegalAccessException: class >> org.gradle.internal.reflect.DirectInstantiator cannot access class >> com.sun.tools.javac.api.JavacTool (in module jdk.compiler) because module >> jdk.compiler does not export package com.sun.tools.javac.api to > module @b7f23d9> >> at >> org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49) >> ... 86 more >> >> We should at least check if there is a bug in the Gradle JIRA for this. >> It can be worked around by configuring the compileJava options to fork >> javac but you might not want to do that. >> >> The other issue with Gradle that we know about is the ClassCastException >> when attempting to run tests, this is tracked here: >> https://issues.gradle.org/browse/GRADLE-3287 >> >> -Alan. >> >> > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From ali.ebrahimi1781 at gmail.com Mon Nov 2 23:32:04 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 Nov 2015 03:02:04 +0330 Subject: Question on Implied readability In-Reply-To: <5637DADB.7000407@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> Message-ID: Hi, On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman wrote: > On 02/11/2015 20:02, Ali Ebrahimi wrote: > Thanks, I see the issue. The reason it didn't duplicate for me is because > I hadn't dropped the requires com.bar. > > So the bug is implied readability across layers when the same named module > exists in multiple layers. In this case com.foo should read com.bar at 1. > The com.bar (@2) is the same configuration as com.foo is confusing the > code. We'll need to fix this. > > So, you say com.foo can not read com.bar(@2) and why? Based on implied readability module com.foo implicitly reads com.bar, in other word have requires com.bar; and because com.bar(@2) is co-layer with com.foo, so module com.foo should reads com.bar(@2). com.bar(@2) override com.bar(@1) for com.foo. How this specified in spec? > -Alan > -- Best Regards, Ali Ebrahimi From alex.buckley at oracle.com Tue Nov 3 02:27:18 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 02 Nov 2015 18:27:18 -0800 Subject: Question on Implied readability In-Reply-To: References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> Message-ID: <56381B86.4010705@oracle.com> On 11/2/2015 3:32 PM, Ali Ebrahimi wrote: > On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman > wrote: > >> On 02/11/2015 20:02, Ali Ebrahimi wrote: >> Thanks, I see the issue. The reason it didn't duplicate for me is because >> I hadn't dropped the requires com.bar. >> >> So the bug is implied readability across layers when the same named module >> exists in multiple layers. In this case com.foo should read com.bar at 1. >> The com.bar (@2) is the same configuration as com.foo is confusing the >> code. We'll need to fix this. >> >> So, you say com.foo can not read com.bar(@2) and why? > Based on implied readability module com.foo implicitly reads com.bar, in > other word have requires com.bar; > and because com.bar(@2) is co-layer with com.foo, so > module com.foo should reads com.bar(@2). > com.bar(@2) override com.bar(@1) for com.foo. > How this specified in spec? It's currently underspecified in Configuration::resolve as "A readability graph is then constructed to take account of implicitly declared dependences (requires public)." We'll have to think about the implication of com.baz in layer1 sometimes offering a 'requires public' on com.bar in layer1, and sometimes offering a 'requires public' on com.bar in layer2, depending on who is reading com.baz in layer1. Alex From frank.yuan at oracle.com Tue Nov 3 04:07:34 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 3 Nov 2015 12:07:34 +0800 Subject: Question on Implied readability In-Reply-To: <56381B86.4010705@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> Message-ID: <016501d115ed$3037a2c0$90a6e840$@oracle.com> > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alex Buckley > Sent: Tuesday, November 03, 2015 10:27 AM > To: jigsaw-dev > Subject: Re: Question on Implied readability > > On 11/2/2015 3:32 PM, Ali Ebrahimi wrote: > > On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman > > wrote: > > > >> On 02/11/2015 20:02, Ali Ebrahimi wrote: > >> Thanks, I see the issue. The reason it didn't duplicate for me is > >> because I hadn't dropped the requires com.bar. > >> > >> So the bug is implied readability across layers when the same named > >> module exists in multiple layers. In this case com.foo should read com.bar at 1. > >> The com.bar (@2) is the same configuration as com.foo is confusing > >> the code. We'll need to fix this. > >> > >> So, you say com.foo can not read com.bar(@2) and why? > > Based on implied readability module com.foo implicitly reads com.bar, > > in other word have requires com.bar; and because com.bar(@2) is > > co-layer with com.foo, so module com.foo should reads com.bar(@2). > > com.bar(@2) override com.bar(@1) for com.foo. > > How this specified in spec? > > It's currently underspecified in Configuration::resolve as "A readability graph is then constructed to take account of implicitly declared > dependences (requires public)." > > We'll have to think about the implication of com.baz in layer1 sometimes offering a 'requires public' on com.bar in layer1, and > sometimes offering a 'requires public' on com.bar in layer2, depending on who is reading com.baz in layer1. Hi Alex I don't think so. com.baz declares "requires public com.bar", so com.baz decide which com.bar is readable, in this case, decide which com.bar is used by com.foo Consider the following scenario, which is the common usage of implied readability com.baz provides the following service: public Object1 getObject(); Object1 is a class defined in com.bar, please not com.bar at 2 is not visible to com.baz(indeed to avoid conflict, only one com.bar can be visible/readable to com.baz), so com.baz construct an Object1 of com.bar at 1 during getObject() is invoked, and then com.foo get this Object1 instance, now com.foo can only use type Object1 of com.bar at 1 to interpret it, who guarantee what Object1 of com.bar at 2 is?! So here the type must be definite, M2 requires public M1, M3 requires M2, then which M1 is read by M2, which M1 must be readable to M3. It's not related to Layer actually. Frank > > Alex From sundararajan.athijegannathan at oracle.com Tue Nov 3 06:00:10 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 3 Nov 2015 11:30:10 +0530 Subject: Is Caching JrtFileSystem acceptable? In-Reply-To: <56373C78.4090807@oracle.com> References: <56373C78.4090807@oracle.com> Message-ID: <56384D6A.5010507@oracle.com> As Alan said, other thing async. closing of the file system, nothing really comes to mind. There is checkResource call in code to check that the resource exists before opening channel on it.. Is it possible to reproduce this on a smaller app? -Sundar On 11/2/2015 4:05 PM, Alan Bateman wrote: > On 02/11/2015 09:48, Jayaprakash Arthanareeswaran wrote: >> >> Hello, >> >> We recently changed our code in Eclipse to support JRE 8 when loading >> classes from a Java 9 images (discussion at [1]). The change was to >> use a >> JrtFileSystem with a class loader. The file system is then cached and >> re-used for every request to get something from the JRE 9 images. The >> code >> is something like this: >> >> URL url = Paths.get(jdkHome, "jrt-fs.jar").toUri().toURL(); >> URLClassLoader loader = new URLClassLoader(new URL[] { url }); >> FileSystem jrt = FileSystems.newFileSystem("jrt:/", env, loader); >> >> After this change, we have started getting an NPE in the file system (We >> are randomly hitting this and at this point no idea what is causing it): >> >> Daemon Thread [Java indexing] (Suspended (exception >> NullPointerException)) >> ByteArrayInputStream.(byte[]) line: 106 >> JrtFileSystem.newByteChannel(byte[], Set, >> FileAttribute...) line: 600 >> JrtPath.newByteChannel(Set, FileAttribute...) line: >> 732 >> JrtFileSystemProvider.newByteChannel(Path, Set, >> FileAttribute...) line: 218 >> Files.newByteChannel(Path, Set, FileAttribute...) >> line: 361 >> Files.newByteChannel(Path, OpenOption...) line: 407 >> Files.readAllBytes(Path) line: 3152 >> >> I have confirmed that the JrtFileSystem that is used in the above >> stack and >> what we cached are the same objects. And the path that is being >> passed in >> the beginning is a valid JrtPath. I would like to know if this is a >> bug in >> the file system implementation or something to do with our code. >> >> Of course, I don't have the source for JrtFileSystem, so unable to debug >> this further. Thanks for any pointers in trouble-shooting this further. >> > I'm not aware of any issues here and there shouldn't be an issue > retaining the reference to the jrt FileSystem. > > As the jrt FileSystem is in the stack trace then it means that > Files.readAllBytes has been called with Path associated with the jrt > file system. It's not obvious how a NPE could arise after that. The > only thing that comes to mind is the file system being closed > asynchronously, I can't recall how the jrt file system handles that > (Sundar will know). > > However, just to establish the environment - is this IBM JDK 8 or an > Oracle/OpenJDK build of JDK 8? Also is the target image a regular JDK > 9 build or a Jigsaw build? There are changes to the jrt file system > code in the Jigsaw forest but this is mostly to support exploded builds. > > -Alan From ali.ebrahimi1781 at gmail.com Tue Nov 3 08:14:49 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 Nov 2015 11:44:49 +0330 Subject: Question on Implied readability In-Reply-To: <016501d115ed$3037a2c0$90a6e840$@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> <016501d115ed$3037a2c0$90a6e840$@oracle.com> Message-ID: Hi Frank, *I think Alex's interpretation of *implied readability is consistent with current definition of concept and expected behavior. Based on your intention public modifier should mean: com.baz embeds com.bar in itself and exports com.bar packages for com.baz's readers and com.foo does not reads module com.bar. If this is expected behavior (that I don't think so) why we use: 'require public com.bar' instead of 'includes com.bar'? On Tue, Nov 3, 2015 at 7:37 AM, Frank Yuan wrote: > > > > > Hi Alex > > I don't think so. com.baz declares "requires public com.bar", so com.baz > decide which com.bar is readable, in this case, decide which com.bar is > used by com.foo > Consider the following scenario, which is the common usage of implied > readability > com.baz provides the following service: > public Object1 getObject(); > Object1 is a class defined in com.bar, please not com.bar at 2 is not > visible to com.baz(indeed to avoid conflict, only one com.bar can be > visible/readable to com.baz), so com.baz construct an Object1 of com.bar at 1 > during getObject() is invoked, and then com.foo get this Object1 instance, > now com.foo can only use type Object1 of com.bar at 1 to interpret it, who > guarantee what Object1 of com.bar at 2 is?! So here the type must be > definite, M2 requires public M1, M3 requires M2, then which M1 is read by > M2, which M1 must be readable to M3. It's not related to Layer actually. This would arise error as of pre-jigsaw with multiple classloaders and expected. I think completed related to layer. Intention of Layers is to handle such scenarios. > Frank > > -- Best Regards, Ali Ebrahimi From ali.ebrahimi1781 at gmail.com Tue Nov 3 08:22:34 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 Nov 2015 11:52:34 +0330 Subject: Question on Implied readability In-Reply-To: <56381B86.4010705@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> Message-ID: Thanks Alex, So this is currently not fully implemented. I think this would have many use cases in EE land where we would need override some modules. On Tue, Nov 3, 2015 at 5:57 AM, Alex Buckley wrote: > On 11/2/2015 3:32 PM, Ali Ebrahimi wrote: > >> On Tue, Nov 3, 2015 at 1:21 AM, Alan Bateman >> wrote: >> >> On 02/11/2015 20:02, Ali Ebrahimi wrote: >>> Thanks, I see the issue. The reason it didn't duplicate for me is because >>> I hadn't dropped the requires com.bar. >>> >>> So the bug is implied readability across layers when the same named >>> module >>> exists in multiple layers. In this case com.foo should read com.bar at 1. >>> The com.bar (@2) is the same configuration as com.foo is confusing the >>> code. We'll need to fix this. >>> >>> So, you say com.foo can not read com.bar(@2) and why? >>> >> Based on implied readability module com.foo implicitly reads com.bar, in >> other word have requires com.bar; >> and because com.bar(@2) is co-layer with com.foo, so >> module com.foo should reads com.bar(@2). >> com.bar(@2) override com.bar(@1) for com.foo. >> How this specified in spec? >> > > It's currently underspecified in Configuration::resolve as "A readability > graph is then constructed to take account of implicitly declared > dependences (requires public)." > > We'll have to think about the implication of com.baz in layer1 sometimes > offering a 'requires public' on com.bar in layer1, and sometimes offering a > 'requires public' on com.bar in layer2, depending on who is reading com.baz > in layer1. > > Alex > -- Best Regards, Ali Ebrahimi From philippe.marschall at netcetera.ch Tue Nov 3 08:25:09 2015 From: philippe.marschall at netcetera.ch (Philippe Marschall) Date: Tue, 3 Nov 2015 09:25:09 +0100 Subject: Possible jrt filesystem bug Message-ID: <56386F65.2030909@netcetera.ch> Hi I have encountered something with I believe may be a bug in the jrt filesystem. The children/directory entries of /packages/com.oracle/java.xml.ws/com are /modules/java.xml.ws/com/sun /modules/java.xml.ws/com/oracle when I believe they should be: /packages/com.oracle/java.xml.ws/com/sun /packages/com.oracle/java.xml.ws/com/oracle You can use the following code to reproduce the issue: FileSystem fileSystem = FileSystems.getFileSystem(URI.create("jrt:/")); Path parent = fileSystem.getPath("/packages/com.oracle/java.xml.ws/com"); try (DirectoryStream directoryStream = Files.newDirectoryStream(parent)) { for (Path each : directoryStream) { System.out.println(" parent: " + parent + " child: " + each + " startsWith: " + each.startsWith(parent)); } } The output I get is: parent: /packages/com.oracle/java.xml.ws/com child: /modules/java.xml.ws/com/oracle startsWith: false parent: /packages/com.oracle/java.xml.ws/com child: /modules/java.xml.ws/com/sun startsWith: false This is based on b86 with Jigsaw on Mac OS. Cheers Philippe From Alan.Bateman at oracle.com Tue Nov 3 08:49:46 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 08:49:46 +0000 Subject: Is Caching JrtFileSystem acceptable? In-Reply-To: <56384D6A.5010507@oracle.com> References: <56373C78.4090807@oracle.com> <56384D6A.5010507@oracle.com> Message-ID: <5638752A.1070304@oracle.com> On 03/11/2015 06:00, Sundararajan Athijegannathan wrote: > As Alan said, other thing async. closing of the file system, nothing > really comes to mind. There is checkResource call in code to check > that the resource exists before opening channel on it.. Is it possible > to reproduce this on a smaller app? Speaking of, I assume jrtfs needs to be more robust in the face of asynchronous close, maybe a RW lock. Jayaprakash - are you able to establish if the file system is open or closed when you get the NPE? From Alan.Bateman at oracle.com Tue Nov 3 09:30:55 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 09:30:55 +0000 Subject: Question on Implied readability In-Reply-To: References: <5637AFE4.8020000@oracle.com> Message-ID: <56387ECF.4030906@oracle.com> On 02/11/2015 19:13, Paul Benedict wrote: > Alan, please correct me if wrong, but there is no enforced correlation > between the module name and the jar name it's packaged in, right? The > name is officially taken from the module-info.class? For explicit modules (meaning those with a module-info.class) then that is correct. > If so, I'd like to make a suggestion. One thing that's been extremely > useful to me with JBoss is the ability to link back to the JAR path in > the stack trace. Is there any chance you would consider expanding the > stack trace to something like this: > > bar1 > Exception in thread "main" java.lang.reflect.InvocationTargetException > at > sun.reflect.NativeMethodAccessorImpl.invoke0(java.base at 9.0[c:\jdk\1.9\jre\modules\java.base.jar]/NativeMethod) On the surface then this might look appealing but I've no doubt it would be highly problematic too. For starters, disclosing file paths in exceptions will lead to security concerns. The other thing is that file paths or code sources can be quite long so it will make stack traces harder to read. We are also not quite over the consequences of adding the module name and version to the stack trace as there are always consequences to changing something that is serialization. In this case, there is still work to do in JMX. BTW: With -verbose:class and -listmods then we already have a few ways to tell where a module is loaded from. -Alan From ali.ebrahimi1781 at gmail.com Tue Nov 3 09:39:51 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 Nov 2015 13:09:51 +0330 Subject: Simple typo in ModuleInfo Message-ID: Hi, diff --git a/src/java.base/share/classes/java/lang/module/ModuleInfo.java b/src/java.base/share/classes/java/lang/module/ModuleInfo.java --- a/src/java.base/share/classes/java/lang/module/ModuleInfo.java +++ b/src/java.base/share/classes/java/lang/module/ModuleInfo.java @@ -186,7 +186,7 @@ int methods_count = in.readUnsignedShort(); if (methods_count > 0) - throw invalidModuleDescriptor("Bad #fields"); + throw invalidModuleDescriptor("Bad #methods"); int attributes_count = in.readUnsignedShort(); -- Best Regards, Ali Ebrahimi From blackdrag at gmx.org Tue Nov 3 09:56:56 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 3 Nov 2015 10:56:56 +0100 Subject: Avoiding same-package conflicts In-Reply-To: <5637CF95.9030800@oracle.com> References: <563223CB.8060300@oracle.com> <5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com> Message-ID: <563884E8.4060505@gmx.org> On 02.11.2015 22:03, Alex Buckley wrote: [...] > The initial modularization of JavaFX had a similar pattern: more split > packages than you would think, due to a "horizontal" module wanting to > share packages with numerous "vertical" domain modules. There, the > "horizontal" module was a 'builder' module which hoped to add > $COMPONENTBuilder classes to the packages of various 'component' > modules; eventually the $COMPONENTBuilder classes were deemed > unnecessary and the 'builder' module deleted. For Groovy, I suggest that > your "base module" has the greatest claim to the > org.codehaus.groovy.runtime package, and that the > groovy-{nio,sql,swing,xml} modules should export > org.codehaus.groovy.runtime.* subpackages to the base module only. > > It doesn't seem great that the groovy-ant and groovy-test modules try to > augment the important groovy.util package owned by your base module. > Speaking generally, it makes no sense to allow a module to protect its > internals if at the same time its API can be augmented by unrelated > modules -- it can't be the "same" API because it doesn't have access to > the same internals. Oh, I am not talking about internal API here. The conflicts in org.codehaus.groovy.runtime are due to historic reasons. They are mostly extension methods, which could be in any package. But traditionally they had been part of DefaultGroovyMethods, from which we factored out a lot of methods over time to modularize the codebase more. And they tended to stay in the same package, since there was in the past no reason to choose a different one... looks strange to put a single class in a package that could be somewhere else perfectly fine after all. If we move those classes to new packages, then we will get into trouble with static compiled code. After all we did that modularization before Groovy had an optional static compiler, and we did a major version change for that (from 1.8 to 2.0) as well. For groovy.util the case is more problematic. Moving GroovyTestCase into a new package would for example break an estimated 95% of our test cases. What will most likely happen is, that the test module merges with the base module thus pulling in "optional" dependencies like JUnit 3... which is in conflict with us trying to slim down the base runtime even more, to for example give the android version an easier standing. We have been thinking about for example moving the compiler into a separate jar. But splitting something something as tightly coupled as that will cause numerous same-package conflicts... Just to give an example... Eval is a class in groovy.util and used for example like this: assert 10 == Eval.me(' 2 * 4 + 2') assert 10 == Eval.x(2, ' x * 4 + 2') Of course this will call the compiler.. but what use is there to make a groovy-base and a groovy compiler jigsaw style module, if they strongly depend on each other anyway? Anyway... my intension was to give an example of how some people divide a broad library into "modules" and how it does not fit the "one module per jar, no exported name space duplication" idea. And you just confirmed it with the initial modularization of JavaFX. Just to clarify... hiding parts of API is out of scope for groovy modules atm. A first step for us would be to get some kind of mapping of our current multi jar system to jigsaw modules that fits our needs. >> also... there is a automated meta class lookup system, that is based on >> the package name with a prefix. So someone could provide a meta class >> for java.util.ArrayList, while another does this for LinkedList. If they >> are using modules, they cannot be loaded at the same time. Granted, I >> don't like this mechanism, and I am looking for ways to deprecate it in >> the near future, but it is another example of same-package conflicts. > > Does this mean a Groovy meta class can currently be defined as a class > in the java.* run-time package of the bootstrap loader? The class would be groovy.runtime.metaclass.java.util.ArrayListMetaClass and doesn't have need the bootsrap loader for this of course. We actually always avoided implementing logic that depends on being in the bootstrap loader. bye Jochen From blackdrag at gmx.org Tue Nov 3 10:01:12 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 3 Nov 2015 11:01:12 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> Message-ID: <563885E8.80101@gmx.org> Hi, Jochen here, not Rory, but Groovy maintainer ;) So for Groovy reporting on the mailing list is good, if you also want to discuss the bug a bit there. If you really only want to report it, then you can just write it in the bug tracker. Of course Gradle is Gradle and Groovy is Groovy bye Jochen On 02.11.2015 23:23, Mani Sarkar wrote: > Hi Rory, > > TestNG has an alternative build system which we will try to use to build > it using the Jigsaw binary. > > How do you report such bugs to Gradle / Groovy ? Is it simpler if you > reported to them on their mailing list ? Let me know what works best, > this is fairly important as other Gradle users might have similar issues. > > Cheers, > Mani > > On Mon, Nov 2, 2015 at 8:51 AM, Rory O'Donnell > wrote: > > I can't find a bug in Gradle's JIRA on this issue, Mani do you want > to log an issue there ? > > Rgds,Rory > > > On 31/10/2015 13:56, Alan Bateman wrote: > > On 31/10/2015 12:50, Mani Sarkar wrote: > > Hi Rory, > > Do you know of a version of Gradle or a EA version which is > JDK 9 Jigsaw compatible, we get these failures when building: > > https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/job/TestNG-Jigsaw/5/console > > > Caused by: java.lang.IllegalAccessException: class > org.gradle.internal.reflect.DirectInstantiator cannot access > class com.sun.tools.javac.api.JavacTool (in module jdk.compiler) > because module jdk.compiler does not export package > com.sun.tools.javac.api to > at > org.gradle.internal.reflect.DirectInstantiator.newInstance(DirectInstantiator.java:49) > ... 86 more > > We should at least check if there is a bug in the Gradle JIRA > for this. It can be worked around by configuring the compileJava > options to fork javac but you might not want to do that. > > The other issue with Gradle that we know about is the > ClassCastException when attempting to run tests, this is tracked > here: > https://issues.gradle.org/browse/GRADLE-3287 > > -Alan. > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > ** | **LinkedIn > * > *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* From frank.yuan at oracle.com Tue Nov 3 10:00:50 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 3 Nov 2015 18:00:50 +0800 Subject: Question on Implied readability In-Reply-To: References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> <016501d115ed$3037a2c0$90a6e840$@oracle.com> Message-ID: <020501d1161e$8a0d4350$9e27c9f0$@oracle.com> Hi Frank, I think Alex's interpretation of implied readability is consistent with current definition of concept and expected behavior. Based on your intention public modifier should mean: com.baz embeds com.bar in itself and exports com.bar packages for com.baz's readers and com.foo does not reads module com.bar. Up to the point, yes, this is my view even though I don't mean com.baz embeds com.bar physically. But if com.foo intends to read com.bar, it should declare "requires com.bar" explicitly. Article http://openjdk.java.net/projects/jigsaw/spec/sotms/ states the purpose of implied readability as well as the common use case. The key of this design is at that the module, which provides some service, take the responsibility to make some other necessary modules readable to the consumer module. Or it can encapsulate the interface in the necessary modules, that it won't declare "requires" with "public". If the consumer module doesn't demand the producer module, consumer also won't need to read those "necessary modules". Besides the conceptual aspect, it doesn't work if consumer uses any instance returned from producer but consumer interprets it to be the type in any different module with which the producer reads, as the example I gave in my pervious mail. If this is expected behavior (that I don't think so) why we use: 'require public com.bar' instead of 'includes com.bar'? On Tue, Nov 3, 2015 at 7:37 AM, Frank Yuan > wrote: > Hi Alex I don't think so. com.baz declares "requires public com.bar", so com.baz decide which com.bar is readable, in this case, decide which com.bar is used by com.foo Consider the following scenario, which is the common usage of implied readability com.baz provides the following service: public Object1 getObject(); Object1 is a class defined in com.bar, please not com.bar at 2 is note visible to com.baz(indeed to avoid conflict, only one com.bar can be visible/readable to com.baz), so com.baz construct an Object1 of com.bar at 1 during getObject() is invoked, and then com.foo get this Object1 instance, now com.foo can only use type Object1 of com.bar at 1 to interpret it, who guarantee what Object1 of com.bar at 2 is?! So here the type must be definite, M2 requires public M1, M3 requires M2, then which M1 is read by M2, which M1 must be readable to M3. It's not related to Layer actually. This would arise error as of pre-jigsaw with multiple classloaders and expected. I think completed related to layer. Intention of Layers is to handle such scenarios. Our gap may be you think com.baz should construct Object1 with the type in com.bar at 2 , but in your code, com.baz does read com.bar at 1 according to its static module descriptors and your layer's configuration, and then in com.baz, the hard code will construct Object1 with the type in com.bar at 1 , you can use reflection to addReads(com.bar at 2 ) inside com.baz but I guess it should fail because of duplicate module name, further, package name and qualified class name should not be duplicate in same one scope. I said it's not related to Layer because I wanted to emphasize it's related to Layer properties. Anyway we don't need to struggle on the words. Frank -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Tue Nov 3 10:01:56 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 10:01:56 +0000 Subject: Simple typo in ModuleInfo In-Reply-To: References: Message-ID: <56388614.5000904@oracle.com> On 03/11/2015 09:39, Ali Ebrahimi wrote: > Hi, > > > diff --git a/src/java.base/share/classes/java/lang/module/ModuleInfo.java > b/src/java.base/share/classes/java/lang/module/ModuleInfo.java > --- a/src/java.base/share/classes/java/lang/module/ModuleInfo.java > +++ b/src/java.base/share/classes/java/lang/module/ModuleInfo.java > @@ -186,7 +186,7 @@ > > int methods_count = in.readUnsignedShort(); > if (methods_count > 0) > - throw invalidModuleDescriptor("Bad #fields"); > + throw invalidModuleDescriptor("Bad #methods"); > > Thanks, we'll get that typo fixed. -Alan From ali.ebrahimi1781 at gmail.com Tue Nov 3 10:38:14 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 Nov 2015 14:08:14 +0330 Subject: Question on Implied readability In-Reply-To: <020501d1161e$8a0d4350$9e27c9f0$@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> <016501d115ed$3037a2c0$90a6e840$@oracle.com> <020501d1161e$8a0d4350$9e27c9f0$@oracle.com> Message-ID: Hi Frank, On Tue, Nov 3, 2015 at 1:30 PM, Frank Yuan wrote: > > > > This would arise error as of pre-jigsaw with multiple classloaders and > expected. > > I think completed related to layer. Intention of Layers is to handle such > scenarios. > > > > Our gap may be you think com.baz should construct Object1 with the type in > com.bar at 2, but in your code, com.baz does read com.bar at 1 according to its > static module descriptors and your layer's configuration, and then in > com.baz, > Not at all. I think com.baz should construct Object1 with the type in com.bar at 1 (com.baz can not read com.bar at 2 from upper layer 'layer2') and if that object passed to com.foo in layer2 as said before, error should occur. -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Tue Nov 3 11:28:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 11:28:01 +0000 Subject: Compilation feedback and version question In-Reply-To: References: <5631616D.6080707@oracle.com> Message-ID: <56389A41.1010103@oracle.com> On 29/10/2015 11:25, Stephen Colebourne wrote: > : > > However, my feedback is that the -listmods option is confusing. An > option called "list" is something I expect to list all things, not to > be clever and only show some subset. At the very least, I consider it > vital for there to be a tool (preferably java.exe) that can list *all* > available modules given a module path. Maybe the current -listmods > should be renamed to -applicationmods or -initialmods, or split to > -listmods:app and -listmods:all ? (Being able to list everything > available feels like module 101). > I think you have a point. The -listmods option lists the modules in the boot layer when it might more understandable if it simply listed all observable modules and just exited like java -version. We'll need to think about this. -Alan From sundararajan.athijegannathan at oracle.com Tue Nov 3 11:28:02 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 3 Nov 2015 16:58:02 +0530 Subject: Possible jrt filesystem bug In-Reply-To: <56386F65.2030909@netcetera.ch> References: <56386F65.2030909@netcetera.ch> Message-ID: <56389A42.40700@oracle.com> This appears to be a bug. I'll check with the latest code in jigsaw forest and file a bug if needed. Thanks, -Sundar On 11/3/2015 1:55 PM, Philippe Marschall wrote: > Hi > > I have encountered something with I believe may be a bug in the jrt > filesystem. > > The children/directory entries of > /packages/com.oracle/java.xml.ws/com are > /modules/java.xml.ws/com/sun > /modules/java.xml.ws/com/oracle > when I believe they should be: > /packages/com.oracle/java.xml.ws/com/sun > /packages/com.oracle/java.xml.ws/com/oracle > > You can use the following code to reproduce the issue: > > FileSystem fileSystem = FileSystems.getFileSystem(URI.create("jrt:/")); > Path parent = fileSystem.getPath("/packages/com.oracle/java.xml.ws/com"); > try (DirectoryStream directoryStream = > Files.newDirectoryStream(parent)) { > for (Path each : directoryStream) { > System.out.println(" parent: " + parent + " child: " + each + " > startsWith: " + each.startsWith(parent)); > } > } > > The output I get is: > > parent: /packages/com.oracle/java.xml.ws/com child: > /modules/java.xml.ws/com/oracle startsWith: false > > parent: /packages/com.oracle/java.xml.ws/com child: > /modules/java.xml.ws/com/sun startsWith: false > > This is based on b86 with Jigsaw on Mac OS. > > Cheers > Philippe From jborgers at jpinpoint.com Tue Nov 3 11:37:54 2015 From: jborgers at jpinpoint.com (Jeroen Borgers) Date: Tue, 3 Nov 2015 12:37:54 +0100 Subject: Java 9 performance optimizations In-Reply-To: References: Message-ID: I found this interesting presentation "Java goes AOT" from JVM Language Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc As presented by Christiaan Thalinger from HS compiler team, AOT is used with Graal to reduce startup time and quicker peak performance (tiered). Currently they don't do any inlining in AOT yet because compilation time blows up by inlining everything since no profiling information is available yet. I guess modules and knowing dependencies can help here to reduce this. Besides test running to generate profiling data. Regards, Jeroen 2015-10-27 1:39 GMT+01:00 Vitaly Davidovich : > Is there more info on aggressive lambda inlining? If it's what I think it > is, it would be very useful performance wise. > > sent from my phone > On Oct 25, 2015 12:51 PM, "Jeroen Borgers" wrote: > >> Hi, >> >> One of the goals of Jigsaw I read here: >> >> http://openjdk.java.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques >> is: >> *Enable ahead-of-time, whole-program optimization techniques* - >> [..] >> The optimization techniques envisioned here include, but are not limited >> to: Fast lookup of both JDK and application classes; early bytecode >> verification; aggressive inlining of, *e.g.*, lambda expressions, and >> other >> standard compiler optimizations; construction of JVM-specific memory >> images >> that can be loaded more efficiently than class files; ahead-of-time >> compilation of method bodies to native code; and the removal of unused >> fields, methods, and classes. These kinds of techniques tend to work best >> when JDK and application code is analyzed together, prior to run time. >> [..] >> >> - >> >> *Optimize existing code as-is* ? It must be possible to apply the >> optimizer tool to existing code already packaged in traditional jar >> files, >> without changing those files. >> - >> >> *Actual optimizations* ? As a proof of concept, provide at least two >> optimizations that deliver nontrivial performance benefits. >> >> My questions are: >> * What is the current state? Which techniques/optimizations are already >> implemented and available from the current ea JDK 9 or will be? >> * Are there any new insights/developments in this area? >> * I noticed in my JMH microbenchmark with parallelstream and lambda's that >> it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused >> by >> more aggressive inlining of lambda's? >> * It seems to me that some compilation and optimization work is moved from >> runtime to link time, this will only be beneficial in limited cases, >> right? >> Are there obvious cases? >> * I don't really see why aggressive inlining and std optimizations can now >> be more effective. Because there will be less de-optimization events >> needed >> because of better predictability? Can in-lining now take place in two >> ways, >> between platform modules and application? Through interfaces? >> >> Thanks! >> >> -Jeroen >> > From Alan.Bateman at oracle.com Tue Nov 3 11:53:23 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 11:53:23 +0000 Subject: Question on Implied readability In-Reply-To: <56381B86.4010705@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> Message-ID: <5638A033.6000205@oracle.com> On 03/11/2015 02:27, Alex Buckley wrote: > > It's currently underspecified in Configuration::resolve as "A > readability graph is then constructed to take account of implicitly > declared dependences (requires public)." Yes, the javadoc does indeed need more work. > > We'll have to think about the implication of com.baz in layer1 > sometimes offering a 'requires public' on com.bar in layer1, and > sometimes offering a 'requires public' on com.bar in layer2, depending > on who is reading com.baz in layer1. Yes, although for the configuration then the read edges are always to modules in same configuration or to modules in parent layers. So in Ali's example then the configuration for layer2 should have have com.foo reading both com.baz and com.bar in layer1. At runtime then com.foo might decide to also read com.bar at 2 but it's playing with fire at that point. In any case, the issue that Ali ran into turns out to be a small oversight in the implementation, easily fixed. There is however another case that will need yet more thought and that is where an indistinguishable com.bar is in both layers. If they are different (meaning not equal) then the implementation will be correct. This is somewhat of a corner case but will need to be handled too. -Alan. From Alan.Bateman at oracle.com Tue Nov 3 12:02:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 12:02:24 +0000 Subject: Possible jrt filesystem bug In-Reply-To: <56389A42.40700@oracle.com> References: <56386F65.2030909@netcetera.ch> <56389A42.40700@oracle.com> Message-ID: <5638A250.1030505@oracle.com> On 03/11/2015 11:28, Sundararajan Athijegannathan wrote: > This appears to be a bug. I'll check with the latest code in jigsaw > forest and file a bug if needed. Is this solely that the jrt implementation of DirectoryStream is resolving entries in the directory when they are sym links or is there more to this? -Alan. From Alan.Bateman at oracle.com Tue Nov 3 12:06:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 12:06:31 +0000 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <56375D51.6020101@gmx.org> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> <563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org> Message-ID: <5638A347.3000907@oracle.com> On 02/11/2015 12:55, Jochen Theodorou wrote: > > This impression is wrong, Groovy does not need access to all > JDK-internal types. Okay, I should have said "potentially all" as there are many cases were the implementation type is not in an exported package. > But this is a dynamic language at heart. If you do not have a static > type, then the runtime type is what counts, and that is the exact > type, which is sometime an internal JDK type. It means Groovy has to > do the same thing it has to do when a security manager doesn't like > access to this class, which is to not use the specific class/method, > but the super class information... or the information of that super > class.. in worst case this will be Object, which means only method > from Object can be called using Groovy in that case. > > The current state is, that this issue is now fixed. The example > scripts in the issue are working. That does not mean we can now run > the build on jigsaw of course. Good to hear, so I'm guess you have to talk the hierarchy of the runtime time to find the type that is part of the API. With modules then could this look at the exportness? -Alan From vitalyd at gmail.com Tue Nov 3 12:09:04 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 3 Nov 2015 07:09:04 -0500 Subject: Java 9 performance optimizations In-Reply-To: References: Message-ID: Yes, I had seen Chris' presentation as well. Certainly modularization will help AOT in many ways. But, I'm particularly interested on the JIT side. What was meant by aggressive lambda inlining, for example? Can anyone point at some additional info? Thanks sent from my phone On Nov 3, 2015 6:37 AM, "Jeroen Borgers" wrote: > I found this interesting presentation "Java goes AOT" from JVM Language > Summit: https://www.youtube.com/watch?v=Xybzyv8qbOc > > As presented by Christiaan Thalinger from HS compiler team, AOT is used > with Graal to reduce startup time and quicker peak performance (tiered). > Currently they don't do any inlining in AOT yet because compilation time > blows up by inlining everything since no profiling information is available > yet. I guess modules and knowing dependencies can help here to reduce this. > Besides test running to generate profiling data. > > Regards, Jeroen > > 2015-10-27 1:39 GMT+01:00 Vitaly Davidovich : > >> Is there more info on aggressive lambda inlining? If it's what I think it >> is, it would be very useful performance wise. >> >> sent from my phone >> On Oct 25, 2015 12:51 PM, "Jeroen Borgers" >> wrote: >> >>> Hi, >>> >>> One of the goals of Jigsaw I read here: >>> >>> http://openjdk.java.net/projects/jigsaw/goals-reqs/03#enable-ahead-of-time-whole-program-optimization-techniques >>> is: >>> *Enable ahead-of-time, whole-program optimization techniques* - >>> [..] >>> The optimization techniques envisioned here include, but are not limited >>> to: Fast lookup of both JDK and application classes; early bytecode >>> verification; aggressive inlining of, *e.g.*, lambda expressions, and >>> other >>> standard compiler optimizations; construction of JVM-specific memory >>> images >>> that can be loaded more efficiently than class files; ahead-of-time >>> compilation of method bodies to native code; and the removal of unused >>> fields, methods, and classes. These kinds of techniques tend to work best >>> when JDK and application code is analyzed together, prior to run time. >>> [..] >>> >>> - >>> >>> *Optimize existing code as-is* ? It must be possible to apply the >>> optimizer tool to existing code already packaged in traditional jar >>> files, >>> without changing those files. >>> - >>> >>> *Actual optimizations* ? As a proof of concept, provide at least two >>> optimizations that deliver nontrivial performance benefits. >>> >>> My questions are: >>> * What is the current state? Which techniques/optimizations are already >>> implemented and available from the current ea JDK 9 or will be? >>> * Are there any new insights/developments in this area? >>> * I noticed in my JMH microbenchmark with parallelstream and lambda's >>> that >>> it runs slightly faster on 9_b85 compared to 8_u66. Could this be caused >>> by >>> more aggressive inlining of lambda's? >>> * It seems to me that some compilation and optimization work is moved >>> from >>> runtime to link time, this will only be beneficial in limited cases, >>> right? >>> Are there obvious cases? >>> * I don't really see why aggressive inlining and std optimizations can >>> now >>> be more effective. Because there will be less de-optimization events >>> needed >>> because of better predictability? Can in-lining now take place in two >>> ways, >>> between platform modules and application? Through interfaces? >>> >>> Thanks! >>> >>> -Jeroen >>> >> > From ali.ebrahimi1781 at gmail.com Tue Nov 3 12:21:11 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Tue, 3 Nov 2015 15:51:11 +0330 Subject: Question on Implied readability In-Reply-To: <5638A033.6000205@oracle.com> References: <5637AFE4.8020000@oracle.com> <5637DADB.7000407@oracle.com> <56381B86.4010705@oracle.com> <5638A033.6000205@oracle.com> Message-ID: Hi, This patch works for me: diff --git a/src/java.base/share/classes/java/lang/module/Resolver.java b/src/java.base/share/classes/java/lang/module/Resolver.java --- a/src/java.base/share/classes/java/lang/module/Resolver.java +++ b/src/java.base/share/classes/java/lang/module/Resolver.java @@ -263,6 +263,34 @@ // already defined to the runtime if (mref == null && layer.findModule(dn).isPresent()) { + //Implied readability wrt to layers + ModuleDescriptor parentLayerModuleDescriptor = layer.findModule(dn).get().getDescriptor(); + for (ModuleDescriptor.Requires parentLayerModuleRequires : parentLayerModuleDescriptor.requires()) { + if(parentLayerModuleRequires.modifiers().contains(Requires.Modifier.PUBLIC)) + { + String dn2 = parentLayerModuleRequires.name(); + //Search for implicitly required module in current layer + ModuleReference mref2 = find(beforeFinder, dn2); + if(mref2 != null){//module dn2 overrided in current layer + // check if module descriptor has already been seen + ModuleDescriptor other2 = mref2.descriptor(); + if (!selected.contains(other2) && !newlySelected.contains(other2)) { + if (nameToReference.put(dn2, mref2) == null) { + if (TRACE) { + trace("Module %s located, required by %s", + dn2, descriptor.name ()); + if (mref2.location().isPresent()) + trace(" (%s)", mref2.location().get()); + } + } + + newlySelected.add(other2); + + q.offer(other2); + } + } + } + } trace("Module %s found in parent Layer", dn); continue; } @@ -508,10 +536,14 @@ g2.put(descriptor, requiresPublic); for (Requires d: descriptor.requires()) { String dn = d.name(); - if (nameToDescriptor.get(dn) == null - && d.modifiers().contains(Requires.Modifier.PUBLIC)) + if (d.modifiers().contains(Requires.Modifier.PUBLIC)) { - ModuleReference mref = findInLayer(l, dn); + ModuleReference mref; + if(nameToDescriptor.get(dn)== null){ + mref = findInLayer(l, dn); + }else { + mref = find(beforeFinder,dn); + } if (mref == null) throw new InternalError(dn + " not found"); requiresPublic.add(mref.descriptor()); On Tue, Nov 3, 2015 at 3:23 PM, Alan Bateman wrote: > On 03/11/2015 02:27, Alex Buckley wrote: > >> >> It's currently underspecified in Configuration::resolve as "A readability >> graph is then constructed to take account of implicitly declared >> dependences (requires public)." >> > Yes, the javadoc does indeed need more work. > > >> We'll have to think about the implication of com.baz in layer1 sometimes >> offering a 'requires public' on com.bar in layer1, and sometimes offering a >> 'requires public' on com.bar in layer2, depending on who is reading com.baz >> in layer1. >> > Yes, although for the configuration then the read edges are always to > modules in same configuration or to modules in parent layers. So in Ali's > example then the configuration for layer2 should have have com.foo reading > both com.baz and com.bar in layer1. At runtime then com.foo might decide to > also read com.bar at 2 but it's playing with fire at that point. > > In any case, the issue that Ali ran into turns out to be a small oversight > in the implementation, easily fixed. There is however another case that > will need yet more thought and that is where an indistinguishable com.bar > is in both layers. If they are different (meaning not equal) then the > implementation will be correct. This is somewhat of a corner case but will > need to be handled too. > > -Alan. > -- Best Regards, Ali Ebrahimi From paul.sandoz at oracle.com Tue Nov 3 12:32:51 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 Nov 2015 13:32:51 +0100 Subject: Java 9 performance optimizations In-Reply-To: References: Message-ID: <3C5587C3-32D3-4B21-BFC0-40CA27732878@oracle.com> Hi Vitaly, Probably worth sending an email to the hotspot-dev at openjdk.java.net > On 3 Nov 2015, at 13:09, Vitaly Davidovich wrote: > > Yes, I had seen Chris' presentation as well. Certainly modularization will > help AOT in many ways. But, I'm particularly interested on the JIT side. > What was meant by aggressive lambda inlining, for example? Can anyone point > at some additional info? > I presume it in part might relate to cracking open the lambda ?box? implementing the targeted functional interface to obtain the underlying method containing the lambda body, generated by javac, that the box defers to, then subsituting the indy call to an invocation of that underlying method. Cue lots of hand waving? Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at JVMLS 2014: http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf Paul. From vitalyd at gmail.com Tue Nov 3 13:07:00 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 3 Nov 2015 08:07:00 -0500 Subject: Java 9 performance optimizations In-Reply-To: <3C5587C3-32D3-4B21-BFC0-40CA27732878@oracle.com> References: <3C5587C3-32D3-4B21-BFC0-40CA27732878@oracle.com> Message-ID: Hi Paul, Thanks for the response and the link -- will look at it later. I presume it in part might relate to cracking open the lambda ?box? > implementing the targeted functional interface to obtain the underlying > method containing the lambda body, generated by javac, that the box defers > to, then subsituting the indy call to an invocation of that underlying > method. Cue lots of hand waving? Yes, that's sort of what I assumed it referred to. That would be great! Thanks On Tue, Nov 3, 2015 at 7:32 AM, Paul Sandoz wrote: > Hi Vitaly, > > Probably worth sending an email to the hotspot-dev at openjdk.java.net > > > > On 3 Nov 2015, at 13:09, Vitaly Davidovich wrote: > > > > Yes, I had seen Chris' presentation as well. Certainly modularization > will > > help AOT in many ways. But, I'm particularly interested on the JIT side. > > What was meant by aggressive lambda inlining, for example? Can anyone > point > > at some additional info? > > > > I presume it in part might relate to cracking open the lambda ?box? > implementing the targeted functional interface to obtain the underlying > method containing the lambda body, generated by javac, that the box defers > to, then subsituting the indy call to an invocation of that underlying > method. Cue lots of hand waving? > > Maybe more clues in Oleg Pliss?s Closures on Embedded JVM presentation at > JVMLS 2014: > > http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf < > http://www.oracle.com/technetwork/java/jvmls2014pliss-2265210.pdf> > > Paul. > > From blackdrag at gmx.org Tue Nov 3 13:41:10 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 3 Nov 2015 14:41:10 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <5638A347.3000907@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> <563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org> <5638A347.3000907@oracle.com> Message-ID: <5638B976.7000600@gmx.org> On 03.11.2015 13:06, Alan Bateman wrote: [...] > Good to hear, so I'm guess you have to talk the hierarchy of the runtime > time to find the type that is part of the API. With modules then could > this look at the exportness? Well, what we currently do is fill a ClassInfo class (a kind of reflection cache from which we generate our meta class) with the all the members we can access. This is the non-private members from the parents and all declared members of the current class. If the current class is blocked, it will automatically consist only of the not blocked information from the parent. We don't try to find the module and its exports at runtime. Maybe we will do such things later to improve performance. bye Jochen From alan.bateman at oracle.com Tue Nov 3 14:59:10 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 03 Nov 2015 14:59:10 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511031459.tA3ExAGi025260@aojmv0008.oracle.com> Changeset: c63cc080ff93 Author: alanb Date: 2015-11-03 14:21 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c63cc080ff93 Exception message incorrect when InvalidModuleDescriptorException thrown because module-info.class has non-empty method table Contributed-by: ali.ebrahimi1781 at gmail.com ! src/java.base/share/classes/java/lang/module/ModuleInfo.java Changeset: d770953d20e5 Author: alanb Date: 2015-11-03 14:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d770953d20e5 requires public not handled correctly when same named module in current configuration and parent layer ! src/java.base/share/classes/java/lang/module/Resolver.java ! test/jdk/jigsaw/module/ConfigurationTest.java From Alan.Bateman at oracle.com Tue Nov 3 15:03:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 Nov 2015 15:03:12 +0000 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <5638B976.7000600@gmx.org> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> <563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org> <5638A347.3000907@oracle.com> <5638B976.7000600@gmx.org> Message-ID: <5638CCB0.7010706@oracle.com> On 03/11/2015 13:41, Jochen Theodorou wrote: > > Well, what we currently do is fill a ClassInfo class (a kind of > reflection cache from which we generate our meta class) with the all > the members we can access. This is the non-private members from the > parents and all declared members of the current class. If the current > class is blocked, it will automatically consist only of the not > blocked information from the parent. By "blocked" then do you mean setAccessible(true) fails or specific exceptions like IllegalAccess*, InaccessibleObjectException or maybe SecurityException? Does it meant that Groovy will work with strong encapsulation? I realize there are issues with support for dynamic code generation that aren't currently exposed in the API. -Alan From alan.bateman at oracle.com Tue Nov 3 15:36:50 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 03 Nov 2015 15:36:50 +0000 Subject: hg: jigsaw/jake/jdk: 8139587: ThreadMXBean.dumpAllThreads() may fail with "java.io.InvalidObjectException: Failed to invoke from(CompositeData)" Message-ID: <201511031536.tA3FaogQ007130@aojmv0008.oracle.com> Changeset: 8103705ebe2f Author: jbachorik Date: 2015-11-03 15:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8103705ebe2f 8139587: ThreadMXBean.dumpAllThreads() may fail with "java.io.InvalidObjectException: Failed to invoke from(CompositeData)" ! src/java.management/share/classes/sun/management/StackTraceElementCompositeData.java ! src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java + src/java.management/share/classes/sun/management/TypeVersionMapper.java ! src/java.management/share/classes/sun/management/Util.java + test/sun/management/StackTraceElementCompositeData/CompatibilityTest.java From alan.bateman at oracle.com Tue Nov 3 16:25:34 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 03 Nov 2015 16:25:34 +0000 Subject: hg: jigsaw/jake/jdk: Fix up header/comments on TypeVersionMapper Message-ID: <201511031625.tA3GPYp3020455@aojmv0008.oracle.com> Changeset: 4601ebe760f8 Author: jbachorik Date: 2015-11-03 16:24 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4601ebe760f8 Fix up header/comments on TypeVersionMapper ! src/java.management/share/classes/sun/management/TypeVersionMapper.java From blackdrag at gmx.org Tue Nov 3 18:02:04 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 3 Nov 2015 19:02:04 +0100 Subject: TestNG build failing with JDK9 Jigsaw due to Gradle In-Reply-To: <5638CCB0.7010706@oracle.com> References: <5634C884.6040302@oracle.com> <56372414.7010605@oracle.com> <56372753.6010702@oracle.com> <563739F2.2030002@oracle.com> <56375D51.6020101@gmx.org> <5638A347.3000907@oracle.com> <5638B976.7000600@gmx.org> <5638CCB0.7010706@oracle.com> Message-ID: <5638F69C.3040808@gmx.org> On 03.11.2015 16:03, Alan Bateman wrote: > On 03/11/2015 13:41, Jochen Theodorou wrote: >> >> Well, what we currently do is fill a ClassInfo class (a kind of >> reflection cache from which we generate our meta class) with the all >> the members we can access. This is the non-private members from the >> parents and all declared members of the current class. If the current >> class is blocked, it will automatically consist only of the not >> blocked information from the parent. > By "blocked" then do you mean setAccessible(true) fails or specific > exceptions like IllegalAccess*, InaccessibleObjectException or maybe > SecurityException? I mean SecurityException and InaccessibleObjectException. > Does it meant that Groovy will work with strong encapsulation? I realize > there are issues with support for dynamic code generation that aren't > currently exposed in the API. IllegalAccessException is a different story, Groovy does not do strong encapsulation in the Java sense. Well, it is more that the access modifiers have a slightly different meaning, but it goes probably too far to explain details. bye Jochen From harold.seigel at oracle.com Tue Nov 3 19:42:16 2015 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Tue, 03 Nov 2015 19:42:16 +0000 Subject: hg: jigsaw/jake/hotspot: Fix Observability tests Message-ID: <201511031942.tA3JgGBs005377@aojmv0008.oracle.com> Changeset: 7e972ba1fe32 Author: gtriantafill Date: 2015-11-03 11:14 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7e972ba1fe32 Fix Observability tests Reviewed-by: lfoltan, hseigel + test/runtime/modules/Visibility/XbootcpNoVisibility.java - test/runtime/modules/observability3/Observability3.sh - test/runtime/modules/observability3/Observability3_A.java - test/runtime/modules/observability3/java/util/Observability3_B.java From alex.buckley at oracle.com Tue Nov 3 21:28:29 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 03 Nov 2015 13:28:29 -0800 Subject: Avoiding same-package conflicts In-Reply-To: <563884E8.4060505@gmx.org> References: <563223CB.8060300@oracle.com> <5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com> <563884E8.4060505@gmx.org> Message-ID: <563926FD.1090805@oracle.com> On 11/3/2015 1:56 AM, Jochen Theodorou wrote: > On 02.11.2015 22:03, Alex Buckley wrote: > For groovy.util the case is more problematic. Moving GroovyTestCase into > a new package would for example break an estimated 95% of our test > cases. What will most likely happen is, that the test module merges with > the base module thus pulling in "optional" dependencies like JUnit 3... > which is in conflict with us trying to slim down the base runtime even > more, to for example give the android version an easier standing. We > have been thinking about for example moving the compiler into a separate > jar. But splitting something something as tightly coupled as that will > cause numerous same-package conflicts... Just to give an example... Eval > is a class in groovy.util and used for example like this: > > assert 10 == Eval.me(' 2 * 4 + 2') > assert 10 == Eval.x(2, ' x * 4 + 2') > > Of course this will call the compiler.. but what use is there to make a > groovy-base and a groovy compiler jigsaw style module, if they strongly > depend on each other anyway? groovy-compiler will obviously have a hard dependency on groovy-base, but you can avoid groovy-base having a hard dependency on groovy-compiler by using services. Of course this assumes a suitable split between the interface of your compiler and its implementation. Even the java.base module is very open to external providers -- see the Services column of http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html#java.base -- for example, "uses java.net.ContentHandlerFactory" can be provided by java.desktop, and "uses java.security.Provider" can be provided by java.naming, java.security.jgss, et al. > Anyway... my intension was to give an example of how some people divide > a broad library into "modules" and how it does not fit the "one module > per jar, no exported name space duplication" idea. And you just > confirmed it with the initial modularization of JavaFX. Yes. We were clear at JavaOne that 1:1 migration -- one module per JAR -- is just one possibility among many. I actually expect the main obstacle to 1:1 migration to be not duplication of exported packages but rather cycles between classes in the JARs. >>> also... there is a automated meta class lookup system, that is based on >>> the package name with a prefix. So someone could provide a meta class >>> for java.util.ArrayList, while another does this for LinkedList. If they >>> are using modules, they cannot be loaded at the same time. Granted, I >>> don't like this mechanism, and I am looking for ways to deprecate it in >>> the near future, but it is another example of same-package conflicts. >> >> Does this mean a Groovy meta class can currently be defined as a class >> in the java.* run-time package of the bootstrap loader? > > The class would be groovy.runtime.metaclass.java.util.ArrayListMetaClass > and doesn't have need the bootsrap loader for this of course. We > actually always avoided implementing logic that depends on being in the > bootstrap loader. That's good. Still, as you said, the meta classes for java.util.{A,B} might live in different modules, so each of those modules will try to export g.r.m.java.util to the same consumer. One option for the Groovy runtime is to special case its meta class package hierarchy by arranging for g.r.m.** classes to be defined by, and exported from, a special module that the runtime generates; the runtime would set up readability between this module and the user modules that "thought" they were defining and exporting g.r.m.**. You can see a flavor of this technique in the "dynamic module" created by Java's Core Reflection when you proxy certain interfaces -- see "Package and Module Membership of Proxy Class" in http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html. Alex From wolfgang.weigend at oracle.com Wed Nov 4 00:24:28 2015 From: wolfgang.weigend at oracle.com (Wolfgang Weigend) Date: Tue, 3 Nov 2015 16:24:28 -0800 (PST) Subject: An exception has occurred in jlink In-Reply-To: <562BB3B0.3000903@oracle.com> References: <6591de18-6eb3-4476-ac37-d651f13e044e@default> <562BB3B0.3000903@oracle.com> Message-ID: Alan, with ";" jlink works perfect with jdk9-jigsaw-b83 :-) Thanks Wolfgang -----Original Message----- From: Alan Bateman Sent: Samstag, 24. Oktober 2015 18:37 To: Wolfgang Weigend; jigsaw-dev at openjdk.java.net Subject: Re: An exception has occurred in jlink On 24/10/2015 17:32, Wolfgang Weigend wrote: > Dear folks, > > > > I tried the jdk 9 EA jigsaw b83 with the quick start example as below. > > > > C:\>jlink --modulepath C:\projects\jdk1.9.0\jmods:mlib --addmods > C:\src\com.greetings --output greetingsapp The path separator on Windows is ";" so replace this with "C:\projects\jdk1.9.0\jmods;mlib" and I expect it should be work. Also you might want to grab the latest download (based on jdk9-b86) to get the latest jlink. -Alan From jeroen at sumatra.nl Wed Nov 4 07:45:45 2015 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Wed, 4 Nov 2015 07:45:45 +0000 Subject: Avoiding same-package conflicts In-Reply-To: <563926FD.1090805@oracle.com> References: <563223CB.8060300@oracle.com> <5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com> <563884E8.4060505@gmx.org> <563926FD.1090805@oracle.com> Message-ID: Alex Buckley wrote: > Yes. We were clear at JavaOne that 1:1 migration -- one module per JAR > -- is just one possibility among many. I actually expect the main > obstacle to 1:1 migration to be not duplication of exported packages but > rather cycles between classes in the JARs. In your JavaOne talk you also mentioned "[no] duplication of exported packages", but the real restriction (at least in the current builds) seems to be "no duplication of packages (in the same layer)". Can you confirm this? Thanks, Jeroen From ali.ebrahimi1781 at gmail.com Wed Nov 4 08:00:14 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 4 Nov 2015 11:30:14 +0330 Subject: Some API Change Suggessions Message-ID: Hi, I think some renaming can improves API and avoid some illegible future confusions. Candidates: 1) Configuration ===> LayerConfiguration or LayerConfig 2) Configuration.layer() ===> Configuration.parentLayer() This was confusing when I tried this: Configuration cfg = Configuration.resolve(... Layer layer = Layer .create(cfg, m -> cl); assertTrue(layer.equals(cfg.layer())); // After change: assertTrue(layer.parent().equals(cfg.parentLayer())); -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Wed Nov 4 08:10:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Nov 2015 08:10:41 +0000 Subject: Avoiding same-package conflicts In-Reply-To: References: <563223CB.8060300@oracle.com> <5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com> <563884E8.4060505@gmx.org> <563926FD.1090805@oracle.com> Message-ID: <5639BD81.9050402@oracle.com> On 04/11/2015 07:45, Jeroen Frijters wrote: > : > In your JavaOne talk you also mentioned "[no] duplication of exported packages", but the real restriction (at least in the current builds) seems to be "no duplication of packages (in the same layer)". > > Can you confirm this? > Not quite, the requirement is that a module M cannot read two or modules that export the same package to M. This is one of the checks when creating a configuration: http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/module/Configuration.html#resolve-java.lang.module.ModuleFinder-java.lang.reflect.Layer-java.lang.module.ModuleFinder-java.util.Collection- Instantiating a configuration as a Layer requires that you don't map two modules with the same package to the same class loader. More on this here: http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Layer.html#create-java.lang.module.Configuration-java.lang.reflect.Layer.ClassLoaderFinder- I think some of the chatter here has been specific to the boot layer where all modules on the application module path are mapped to the application class loader. -Alan From dalibor.topic at oracle.com Wed Nov 4 13:58:44 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 4 Nov 2015 14:58:44 +0100 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: References: Message-ID: <563A0F14.9070205@oracle.com> On 30.10.2015 16:29, Vincent Privat wrote: > Hi, > - Is it expected to allow external people to have the possibility to > subscribe to JDK issues? See http://robilad.livejournal.com/139637.html cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From alan.bateman at oracle.com Wed Nov 4 14:04:05 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 04 Nov 2015 14:04:05 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> Changeset: 8e0eb0540634 Author: alanb Date: 2015-11-04 13:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e0eb0540634 JT_HOME in test/Makefile out of date ! test/Makefile Changeset: fd7cc28c24c7 Author: alanb Date: 2015-11-04 13:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7 Improve finding source module when creating a layer Expand test coverage for implied readability + layers ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! test/jdk/jigsaw/module/ConfigurationTest.java ! test/jdk/jigsaw/reflect/Layer/LayerTest.java From ali.ebrahimi1781 at gmail.com Wed Nov 4 15:55:06 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 4 Nov 2015 19:25:06 +0330 Subject: hg: jigsaw/jake/jdk: 2 new changesets In-Reply-To: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> Message-ID: Hi, On Wed, Nov 4, 2015 at 5:34 PM, wrote: > > > Changeset: fd7cc28c24c7 > Author: alanb > Date: 2015-11-04 13:59 +0000 > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd7cc28c24c7 > > Improve finding source module when creating a layer > Expand test coverage for implied readability + layers > > ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java > ! src/java.base/share/classes/java/lang/reflect/Module.java > ! test/jdk/jigsaw/module/ConfigurationTest.java > ! test/jdk/jigsaw/reflect/Layer/LayerTest.java > > In recent change to Module.java: +++ b/src/java.base/share/classes/java/lang/reflect/Module.java Wed Nov 04 13:59:58 2015 +0000 @@ -40,6 +40,7 @@ import java.util.HashSet; import java.util.Map; import java.util.Objects; +import java.util.Optional; import java.util.Set; import java.util.WeakHashMap; import java.util.concurrent.locks.Lock; @@ -891,12 +892,32 @@ // reads Set reads = new HashSet<>(); - for (ModuleDescriptor other: cf.reads(descriptor)) { + for (ModuleDescriptor other : cf.reads(descriptor)) { + Module m2 = null; + + // Search the configuration and parent layers for the module + // descriptor. This is temporary until Configuration defines + // an API to return the layer + name of the source rather than + // the module descriptor. String dn = other.name(); - Module m2 = modules.get(dn); - Layer parent = cf.layer(); - if (m2 == null && parent != null) - m2 = parent.findModule(other.name()).orElse(null); + Module candidate = modules.get(dn); + if (candidate != null && other.equals(candidate.getDescriptor())) { + m2 = candidate; + } else { + Layer parent = cf.layer(); + while (parent != null) { + Optional om = parent.findModule(dn); + if (om.isPresent()) { + candidate = om.get(); + if (other.equals(candidate.getDescriptor())) { + m2 = candidate; + break; + } + } + parent = parent.parent().orElse(null); + } + } Layer.findModule already do recursive search for modules in parent layers -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Wed Nov 4 16:01:32 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Nov 2015 16:01:32 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets In-Reply-To: References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> Message-ID: <563A2BDC.9030202@oracle.com> On 04/11/2015 15:55, Ali Ebrahimi wrote: > > > Layer.findModule already do recursive search for modules in parent layers That is by name and so does not uniquely identify the module. The module descriptor is also not unique which is why further work is required to have the layer of the source module. -Alan From ali.ebrahimi1781 at gmail.com Wed Nov 4 16:26:14 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 4 Nov 2015 19:56:14 +0330 Subject: hg: jigsaw/jake/jdk: 2 new changesets In-Reply-To: <563A2BDC.9030202@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> Message-ID: Hi, On Wed, Nov 4, 2015 at 7:31 PM, Alan Bateman wrote: > > On 04/11/2015 15:55, Ali Ebrahimi wrote: > > > > Layer.findModule already do recursive search for modules in parent layers > > That is by name and so does not uniquely identify the module. The module > descriptor is also not unique which is why further work is required to have > the layer of the source module. > > Yes, I got it. But should not upper level descriptors win over lower descriptors regards to current configuration. What I missed here? -- Best Regards, Ali Ebrahimi From christian.tornqvist at oracle.com Wed Nov 4 20:28:47 2015 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Wed, 04 Nov 2015 20:28:47 +0000 Subject: hg: jigsaw/jake/hotspot: Fixed sun.misc issues in hotspot/test/testlibrary_tests/ctw Message-ID: <201511042028.tA4KSlDx020153@aojmv0008.oracle.com> Changeset: e1b2092789e5 Author: ctornqvi Date: 2015-11-04 12:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1b2092789e5 Fixed sun.misc issues in hotspot/test/testlibrary_tests/ctw ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java ! test/testlibrary_tests/ctw/ClassesDirTest.java ! test/testlibrary_tests/ctw/JarDirTest.java ! test/testlibrary_tests/ctw/JarsTest.java From Alan.Bateman at oracle.com Wed Nov 4 22:03:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 Nov 2015 22:03:11 +0000 Subject: Implied readability + layers In-Reply-To: References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> Message-ID: <563A809F.9020402@oracle.com> On 04/11/2015 16:26, Ali Ebrahimi wrote: > : > > Yes, I got it. But should not upper level descriptors win over lower > descriptors regards to current configuration. > What I missed here? > (Changing the subject line so that it's clearer what this discussion is about). In your implied readability mail then I think you have: configuration1/layer1: com.bar at 1 com.baz requires public com.bar configuration2: com.bar at 2 com.foo requires com.baz The readability graph for configuration2 is: com.bar at 2 requires java.base com.foo reads java.base com.foo reads com.baz com.foo reads com.bar at 1 Instantiating this configuration (as a layer) means locating the jlr.Module for com.bar at 1. For now, and it's temporary, it is found by matching the ModuleDescriptor starting in the configuration and working through the stack of layers. I say temporary because we need an API change to expose the layer of the source module. That will eliminate the search and will fix the corner case that arises when modules in different layers have equal ModuleDescriptor objects. We'll get to this soon. -Alan. From ali.ebrahimi1781 at gmail.com Wed Nov 4 22:45:24 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 02:15:24 +0330 Subject: Implied readability + layers In-Reply-To: <563A809F.9020402@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> Message-ID: Hi, On Thu, Nov 5, 2015 at 1:33 AM, Alan Bateman wrote: > > > On 04/11/2015 16:26, Ali Ebrahimi wrote: > > : > > Yes, I got it. But should not upper level descriptors win over lower > descriptors regards to current configuration. > What I missed here? > > (Changing the subject line so that it's clearer what this discussion is > about). > > In your implied readability mail then I think you have: > > configuration1/layer1: > com.bar at 1 > com.baz requires public com.bar > > configuration2: > com.bar at 2 > com.foo requires com.baz > > The readability graph for configuration2 is: > > com.bar at 2 requires java.base > com.foo reads java.base > com.foo reads com.baz > com.foo reads com.bar at 1 > > Instantiating this configuration (as a layer) means locating the > jlr.Module for com.bar at 1. For now, and it's temporary, it is found by > matching the ModuleDescriptor starting in the configuration and working > through the stack of layers. I say temporary because we need an API change > to expose the layer of the source module. That will eliminate the search > and will fix the corner case that arises when modules in different layers > have equal ModuleDescriptor objects. We'll get to this soon. > So you say com.bar at 2 does not override com.bar at 1 in layer2 and types will be loaded from com.bar at 1 in layer2 for com.foo? This is changed from yesterday? I now get bar1 bar1 instead of bar1 bar2 for my yesterday sample code. quite supersizing! Second, what can you say for this test case: public static void testLayerWithRequiresPublic4() { // cf1: m1 and m2 at 1, m1 requires public m2 ModuleDescriptor descriptor1 = new ModuleDescriptor.Builder("m1") .requires(ModuleDescriptor.Requires.Modifier.PUBLIC, "m2") .build(); ModuleDescriptor descriptor2_v1 = new ModuleDescriptor.Builder("m2") .version("1") .build(); ModuleFinder finder1 = ModuleUtils.finderOf(descriptor1, descriptor2_v1); Configuration cf1 = Configuration.resolve(finder1, boot(), ModuleFinder.empty(), "m1"); ClassLoader cl1 = new ClassLoader() { }; Layer layer1 = Layer.create(cf1, mn -> cl1); // cf2: m3 and m2 at 2, m3 requires m1 ModuleDescriptor descriptor2_v2 = new ModuleDescriptor.Builder("m2") .version("2") .build(); ModuleDescriptor descriptor3 = new ModuleDescriptor.Builder("m3") .requires("m1") .build(); ModuleFinder finder2 = ModuleUtils.finderOf(descriptor2_v2, descriptor3); Configuration cf2 = Configuration.resolve(finder2, layer1, ModuleFinder.empty(), "m3"); ClassLoader cl2 = new ClassLoader() { }; Layer layer2 = Layer.create(cf2, mn -> cl2); Module m1 = layer1.findModule("m1").get(); Module m2_v1 = layer1.findModule("m2").get(); Module m2_v2 = layer2.findModule("m2").get(); Module m3 = layer2.findModule("m3").get(); assertTrue(m2_v2.getLayer() == layer2); assertFalse(m1.canRead(m2_v2)); assertFalse(m2_v1.canRead(m2_v2)); assertFalse(m2_v2.canRead(m2_v1)); assertFalse(m3.canRead(m2_v2)); } -- Best Regards, Ali Ebrahimi From weijun.wang at oracle.com Thu Nov 5 02:07:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Nov 2015 10:07:45 +0800 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: References: Message-ID: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> I was talking with Vincent off the list, but it seems better to be back. Here is Vincent's mail on how he thinks of the new API we are about to provide in JDK-8058778. > The new API is interesting but if it's not available in Java SE I'm afraid it does not fit our use case. We cannot make JOSM depend on a JDK at runtime just for this feature :( There might be some confusion on what "JDK" means. It used to be the developer's toolkit versus JRE the runtime, but as for module names, a jdk.* module contains APIs defined by OpenJDK instead of Java SE. In fact, most of them are not especially designed for developers. That said, I am not exactly sure what kind of images we will release after jigsaw. If there is still a JRE, I think it will include not only the java.* modules but also some jdk.* ones. I hope jdk.security.cert is one of them. Personally I am not afraid of using jdk.* modules, since almost every JDK distribution is based on OpenJDK. At least it is now a supported API of OpenJDK instead of old sun.* classes that were never claimed to be supported by anyone. In fact, keytool was not defined in Java SE either. It was in JRE though. Thanks Max > On Oct 31, 2015, at 12:34 AM, Mandy Chung wrote: > >> >> - We'd like to know if it can be expected to see the >> package sun.security.x509 become a public JDK API, for example in >> javax.security.cert? We currently use it to generate a self-signed >> certificate in order to create a local https server. That's our only use of >> private JDK API. > > There are two RFEs related to signing and certificates > 8058778: New APIs for some keytool functions > 8056174: New APIs for jar signing > > I have added this comment in 8058778 for the security team to look into. You can subscribe to security-dev at openjdk.java.net where the discussion for these RFEs will be. > > Mandy > From Alan.Bateman at oracle.com Thu Nov 5 08:50:34 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 08:50:34 +0000 Subject: Implied readability + layers In-Reply-To: References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> Message-ID: <563B185A.8020409@oracle.com> On 04/11/2015 22:45, Ali Ebrahimi wrote: > : > So you say com.bar at 2 does not override com.bar at 1 in layer2 and types > will be loaded from com.bar at 1 in layer2 for com.foo? The configuration for layer2 doesn't contain any modules that require com.bar. If you expand the scenario to com.bax requires com.bar and if com.bax is in configuration2 then you would have com.bax reads com.bar at 2 in the readability graph (and layer2). > This is changed from yesterday? > I now get > bar1 > bar1 > instead of > bar1 > bar2 > for my yesterday sample code. quite supersizing! It will take time to shake out issues and it's great that you are trying things and finding issues. At this time the only issue I'm aware of is where there are equal ModuleDescriptors in multiple layers. That one requires an API change as I mentioned, we'll get that sorted out soon. > > Second, what can you say for this test case: > > : > > > Module m1 = layer1.findModule("m1").get(); > Module m2_v1 = layer1.findModule("m2").get(); > Module m2_v2 = layer2.findModule("m2").get(); > Module m3 = layer2.findModule("m3").get(); > > assertTrue(m2_v2.getLayer() == layer2); > assertFalse(m1.canRead(m2_v2)); > assertFalse(m2_v1.canRead(m2_v2)); > assertFalse(m2_v2.canRead(m2_v1)); > assertFalse(m3.canRead(m2_v2)); In this example then m3 is the only module in layer2 and so layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1). If you adjust the example so that m3 requires m2 then layer2 will contain m3 and m2 at 2. It's also possible for m3 require both m1 and m2. The result may be a surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both versions of m2 were to export the same package then it would fail but there are no exports in this test case. -Alan. From sundararajan.athijegannathan at oracle.com Thu Nov 5 08:52:41 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 5 Nov 2015 14:22:41 +0530 Subject: Possible jrt filesystem bug In-Reply-To: <56386F65.2030909@netcetera.ch> References: <56386F65.2030909@netcetera.ch> Message-ID: <563B18D9.4060201@oracle.com> Hi, I filed a bug : https://bugs.openjdk.java.net/browse/JDK-8141521 Thanks for reporting this issue, -Sundar On 11/3/2015 1:55 PM, Philippe Marschall wrote: > Hi > > I have encountered something with I believe may be a bug in the jrt > filesystem. > > The children/directory entries of > /packages/com.oracle/java.xml.ws/com are > /modules/java.xml.ws/com/sun > /modules/java.xml.ws/com/oracle > when I believe they should be: > /packages/com.oracle/java.xml.ws/com/sun > /packages/com.oracle/java.xml.ws/com/oracle > > You can use the following code to reproduce the issue: > > FileSystem fileSystem = FileSystems.getFileSystem(URI.create("jrt:/")); > Path parent = fileSystem.getPath("/packages/com.oracle/java.xml.ws/com"); > try (DirectoryStream directoryStream = > Files.newDirectoryStream(parent)) { > for (Path each : directoryStream) { > System.out.println(" parent: " + parent + " child: " + each + " > startsWith: " + each.startsWith(parent)); > } > } > > The output I get is: > > parent: /packages/com.oracle/java.xml.ws/com child: > /modules/java.xml.ws/com/oracle startsWith: false > > parent: /packages/com.oracle/java.xml.ws/com child: > /modules/java.xml.ws/com/sun startsWith: false > > This is based on b86 with Jigsaw on Mac OS. > > Cheers > Philippe From sundararajan.athijegannathan at oracle.com Thu Nov 5 08:54:08 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 5 Nov 2015 14:24:08 +0530 Subject: Possible jrt filesystem bug In-Reply-To: <5638A250.1030505@oracle.com> References: <56386F65.2030909@netcetera.ch> <56389A42.40700@oracle.com> <5638A250.1030505@oracle.com> Message-ID: <563B1930.1080501@oracle.com> Appears to be only localized to jrt fs DirectoryStream's handling of symlink paths under /packages -Sundar On 11/3/2015 5:32 PM, Alan Bateman wrote: > On 03/11/2015 11:28, Sundararajan Athijegannathan wrote: >> This appears to be a bug. I'll check with the latest code in jigsaw >> forest and file a bug if needed. > Is this solely that the jrt implementation of DirectoryStream is > resolving entries in the directory when they are sym links or is there > more to this? > > -Alan. From ali.ebrahimi1781 at gmail.com Thu Nov 5 09:30:33 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 13:00:33 +0330 Subject: Implied readability + layers In-Reply-To: <563B185A.8020409@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> Message-ID: Hi alan, So far quite disappointing! But I think Alex's last response on this topic says opposite of this: "We'll have to think about the implication of com.baz in layer1 sometimes offering a 'requires public' on com.bar in layer1, and sometimes offering a 'requires public' on com.bar in layer2, depending on who is reading com.baz in layer1." In this case adding 'requires public' on com.bar in layer2 does not mean we should pick com.bar at 2 for com,foo? This scenario would have many usages in future when world would filled with modules and developers would have to use newer versions of modules to fix bugs. What if com.foo compiled against com.bar at 2? adding redundant requires com.bar in com.foo does not help and my app will fail. So what is advantage of multiple layers? On Thu, Nov 5, 2015 at 12:20 PM, Alan Bateman wrote: > > > On 04/11/2015 22:45, Ali Ebrahimi wrote: > > : > > So you say com.bar at 2 does not override com.bar at 1 in layer2 and types will > be loaded from com.bar at 1 in layer2 for com.foo? > > The configuration for layer2 doesn't contain any modules that require > com.bar. > > If you expand the scenario to com.bax requires com.bar and if com.bax is > in configuration2 then you would have com.bax reads com.bar at 2 in the > readability graph (and layer2). > > > This is changed from yesterday? > I now get > bar1 > bar1 > instead of > bar1 > bar2 > for my yesterday sample code. quite supersizing! > > It will take time to shake out issues and it's great that you are trying > things and finding issues. At this time the only issue I'm aware of is > where there are equal ModuleDescriptors in multiple layers. That one > requires an API change as I mentioned, we'll get that sorted out soon. > > > > Second, what can you say for this test case: > > : > > > Module m1 = layer1.findModule("m1").get(); > Module m2_v1 = layer1.findModule("m2").get(); > Module m2_v2 = layer2.findModule("m2").get(); > Module m3 = layer2.findModule("m3").get(); > > assertTrue(m2_v2.getLayer() == layer2); > assertFalse(m1.canRead(m2_v2)); > assertFalse(m2_v1.canRead(m2_v2)); > assertFalse(m2_v2.canRead(m2_v1)); > assertFalse(m3.canRead(m2_v2)); > > In this example then m3 is the only module in layer2 and so > layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1). > > If you adjust the example so that m3 requires m2 then layer2 will contain > m3 and m2 at 2. > > It's also possible for m3 require both m1 and m2. The result may be a > surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both versions of m2 > were to export the same package then it would fail but there are no exports > in this test case. > > -Alan. > -- Best Regards, Ali Ebrahimi From sundararajan.athijegannathan at oracle.com Thu Nov 5 09:45:46 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 5 Nov 2015 15:15:46 +0530 Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages Message-ID: <563B254A.7090001@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8141521 Thanks -Sundar From frank.yuan at oracle.com Thu Nov 5 10:49:53 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 5 Nov 2015 18:49:53 +0800 Subject: Implied readability + layers In-Reply-To: <563B185A.8020409@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> Message-ID: <010b01d117b7$bf075d80$3d161880$@oracle.com> > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman > Sent: Thursday, November 05, 2015 4:51 PM > To: Ali Ebrahimi > Cc: jigsaw-dev > Subject: Re: Implied readability + layers > > > > On 04/11/2015 22:45, Ali Ebrahimi wrote: > > : > > So you say com.bar at 2 does not override com.bar at 1 in layer2 and types > > will be loaded from com.bar at 1 in layer2 for com.foo? > The configuration for layer2 doesn't contain any modules that require com.bar. > > If you expand the scenario to com.bax requires com.bar and if com.bax is in configuration2 then you would have com.bax reads > com.bar at 2 in the readability graph (and layer2). > > > > This is changed from yesterday? > > I now get > > bar1 > > bar1 > > instead of > > bar1 > > bar2 > > for my yesterday sample code. quite supersizing! > It will take time to shake out issues and it's great that you are trying things and finding issues. At this time the only issue I'm aware of is > where there are equal ModuleDescriptors in multiple layers. That one requires an API change as I mentioned, we'll get that sorted out > soon. > > > > > > Second, what can you say for this test case: > > > > : > > > > > > Module m1 = layer1.findModule("m1").get(); > > Module m2_v1 = layer1.findModule("m2").get(); > > Module m2_v2 = layer2.findModule("m2").get(); > > Module m3 = layer2.findModule("m3").get(); > > > > assertTrue(m2_v2.getLayer() == layer2); > > assertFalse(m1.canRead(m2_v2)); > > assertFalse(m2_v1.canRead(m2_v2)); > > assertFalse(m2_v2.canRead(m2_v1)); > > assertFalse(m3.canRead(m2_v2)); > In this example then m3 is the only module in layer2 and so > layer2.findModule("m2") will find m2 in its parent (hence m2_v2 == m2_v1). > > If you adjust the example so that m3 requires m2 then layer2 will contain m3 and m2 at 2. > > It's also possible for m3 require both m1 and m2. The result may be a surprising as m3 will read m2 at 1 and m2 at 2. Clearly if both > versions of m2 were to export the same package then it would fail but there are no exports in this test case. Generally, m2 at 1 and m2 at 2 are different versions of a same component. So essentially a module M cannot read duplicate types/modules, except only use reflection to access, right? > > -Alan. From ali.ebrahimi1781 at gmail.com Thu Nov 5 11:05:19 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 14:35:19 +0330 Subject: Implied readability + layers In-Reply-To: <010b01d117b7$bf075d80$3d161880$@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> <010b01d117b7$bf075d80$3d161880$@oracle.com> Message-ID: Hi, On Thu, Nov 5, 2015 at 2:19 PM, Frank Yuan wrote: > > > > Generally, m2 at 1 and m2 at 2 are different versions of a same component. So > essentially a module M cannot read duplicate types/modules, except only use > reflection to access, right? > I think this should be true with flat classpath days not now! I think we should assume sublayers and parent layers somewhat as subclasses and supper classes and think about method overriding vs module overriding. -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Thu Nov 5 11:38:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 11:38:19 +0000 Subject: Implied readability + layers In-Reply-To: References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> Message-ID: <563B3FAB.7050809@oracle.com> On 05/11/2015 09:30, Ali Ebrahimi wrote: > Hi alan, > So far quite disappointing! > > But I think Alex's last response on this topic says opposite of this: > > "We'll have to think about the implication of com.baz in layer1 > sometimes offering a 'requires public' on com.bar in layer1, and > sometimes offering a 'requires public' on com.bar in layer2, depending > on who is reading com.baz in layer1." > > In this case adding 'requires public' on com.bar in layer2 does not > mean we should pick com.bar at 2 for com,foo? In this example then com.baz in layer1 doesn't know anything about com.bar at 2 or other modules that comes into existence in future "child" layers, at least not statically. com.baz does read com.bar at 1 and as it declares "requires public com.bar" then I assume com.baz's exported API must have com.bar at 1 types in its method signatories. This will usually be good for other modules in layer1 or modules in descendants of layer1 that use the com.baz API. Creating a new layer2 does not change modules in other layers. This means that creating layer2 will not change com.baz (in layer1) to read com.bar at 2 (in layer2). It is of course possible for com.baz to opt-in and reflectively to read com.bar at 2 but great care is required (static references in code in com.baz will presumably resolve to types in com.bar at 1). > > This scenario would have many usages in future when world would filled > with modules and developers would have to use newer versions of > modules to fix bugs. > What if com.foo compiled against com.bar at 2? adding redundant > requirescom.bar in com.foo does not help and my app will fail. Assuming com.bar at 1 and com.bar at 2 export the same packages then it should fail when you attempt to create the Configuration for layer2 as com.foo cannot read both. In this example then you might consider a new instance of module com.baz in layer2. That way, layer2 would have com.foo, com.baz and com.bar at 2. -Alan. From Alan.Bateman at oracle.com Thu Nov 5 11:44:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 11:44:30 +0000 Subject: Implied readability + layers In-Reply-To: <010b01d117b7$bf075d80$3d161880$@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> <010b01d117b7$bf075d80$3d161880$@oracle.com> Message-ID: <563B411E.6050503@oracle.com> On 05/11/2015 10:49, Frank Yuan wrote: > : > Generally, m2 at 1 and m2 at 2 are different versions of a same component. So essentially a module M cannot read duplicate types/modules, except only use reflection to access, right? > Yes, assuming m2 at 1 and m2 at 2 export the same package to M then it should be caught when attempting to create the Configuration. And yes, M can use the reflection API to read any other module at run-time. -Alan. From christian.tornqvist at oracle.com Thu Nov 5 12:56:50 2015 From: christian.tornqvist at oracle.com (christian.tornqvist at oracle.com) Date: Thu, 05 Nov 2015 12:56:50 +0000 Subject: hg: jigsaw/jake/hotspot: Fixed exports for another of the CTW tests Message-ID: <201511051256.tA5Cuo0T021551@aojmv0008.oracle.com> Changeset: e2caae19bed6 Author: ctornqvi Date: 2015-11-05 04:56 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2caae19bed6 Fixed exports for another of the CTW tests ! test/testlibrary_tests/ctw/ClassesListTest.java From ali.ebrahimi1781 at gmail.com Thu Nov 5 13:17:19 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 16:47:19 +0330 Subject: Implied readability + layers Message-ID: Hi, On Thu, Nov 5, 2015 at 3:08 PM, Alan Bateman wrote: > On 05/11/2015 09:30, Ali Ebrahimi wrote: > > Hi alan, > So far quite disappointing! > > > In this example then com.baz in layer1 doesn't know anything about > com.bar at 2 or other modules that comes into existence in future "child" > layers, at least not statically. > I know that and may be even com.baz not compatible with com.bar at 2. So I don't expect sublayers's modules propagated in parent layers. However, in current design we don't involve module version in declaration of dependence and I think that is good decision. So my assumption is: The readability graph for configuration1 is: com.bar at 1 reads java.base com.baz reads com.bar at 1 The readability graph for configuration2 is: com.bar at 2 requires java.base com.foo reads java.base com.foo reads com.baz com.foo reads com.bar at 2 > com.baz does read com.bar at 1 and as it declares "requires public com.bar" > then I assume com.baz's exported API must have com.bar at 1 types in its > method signatories. This will usually be good for other modules in layer1 > or modules in descendants of layer1 that use the com.baz API. > This does not affect modules belong layerx < layer2 so can be happy. If API usage of com.baz in com.foo does not contain any type of com.bar you wouldn't have any issue, otherwise com.foo must live on layer1. > Creating a new layer2 does not change modules in other layers. This means > that creating layer2 will not change com.baz (in layer1) to read com.bar at 2 > (in layer2). It is of course possible for com.baz to opt-in and > reflectively to read com.bar at 2 but great care is required (static > references in code in com.baz will presumably resolve to types in com.bar at 1 > ). > See above. > > > > This scenario would have many usages in future when world would filled > with modules and developers would have to use newer versions of modules to > fix bugs. > What if com.foo compiled against com.bar at 2? adding redundant requires com.bar > in com.foo does not help and my app will fail. > > Assuming com.bar at 1 and com.bar at 2 export the same packages then it should > fail when you attempt to create the Configuration for layer2 as com.foo > cannot read both. > I think this is reasonable that when executing bytecode belong to layer2 (com.foo or com.poo) that request for types of module com.foo we pick from com.bar at 2. > In this example then you might consider a new instance of module com.baz > in layer2. That way, layer2 would have com.foo, com.baz and com.bar at 2. > If I'm not owner of com.baz or what do for com.baz dependent modules I think we have tree possible choices: 1) pick com.bar at 1 for layer1 and layer2 2) pick com.bar at 1 for layer1 and com.bar at 1 for layer2 3) pick com.bar at 2 for layer1 and layer2 I think 2 would be best and flexible choice. Best Regards, Ali Ebrahimi From ali.ebrahimi1781 at gmail.com Thu Nov 5 13:24:33 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 16:54:33 +0330 Subject: Implied readability + layers In-Reply-To: <563B411E.6050503@oracle.com> References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> <010b01d117b7$bf075d80$3d161880$@oracle.com> <563B411E.6050503@oracle.com> Message-ID: Hi, On Thu, Nov 5, 2015 at 3:14 PM, Alan Bateman wrote: > > > On 05/11/2015 10:49, Frank Yuan wrote: > >> : >> Generally, m2 at 1 and m2 at 2 are different versions of a same component. So >> essentially a module M cannot read duplicate types/modules, except only use >> reflection to access, right? >> >> Yes, assuming m2 at 1 and m2 at 2 export the same package to M then it should > be caught when attempting to create the Configuration. And yes, M can use > the reflection API to read any other module at run-time. If m2 at 2 can hide(override) m2 at 1 for M then you don't have duplicates. -- Best Regards, Ali Ebrahimi From james.laskey at oracle.com Thu Nov 5 13:27:24 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 5 Nov 2015 09:27:24 -0400 Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages In-Reply-To: <563B254A.7090001@oracle.com> References: <563B254A.7090001@oracle.com> Message-ID: <561B12CD-D642-43CF-A444-80BCEAAFDA42@oracle.com> +1 > On Nov 5, 2015, at 5:45 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8141521 > > Thanks > -Sundar From Alan.Bateman at oracle.com Thu Nov 5 14:02:47 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 14:02:47 +0000 Subject: Implied readability + layers In-Reply-To: References: Message-ID: <563B6187.4030108@oracle.com> On 05/11/2015 13:17, Ali Ebrahimi wrote: > > If API usage of com.baz in com.foo does not contain any type of > com.bar you wouldn't have any issue, otherwise com.foo must live on > layer1. Are there com.bar types in com.baz's API? If not then users of com.baz need to vigorously lobby the maintainer of com.baz to stop using requires public. If com.baz agrees then com.foo will not read com.bar at 1 and this frees up com.foo to use another version of com.bar in layer2. On the other hand, if there are com.bar types in com.baz's API then com.foo will be exposed to com.bar at 1 types. -Alan. From ali.ebrahimi1781 at gmail.com Thu Nov 5 15:06:11 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 18:36:11 +0330 Subject: Implied readability + layers In-Reply-To: <563B6187.4030108@oracle.com> References: <563B6187.4030108@oracle.com> Message-ID: Hi, On Thu, Nov 5, 2015 at 5:32 PM, Alan Bateman wrote: > > > On 05/11/2015 13:17, Ali Ebrahimi wrote: > >> >> If API usage of com.baz in com.foo does not contain any type of com.bar >> you wouldn't have any issue, otherwise com.foo must live on layer1. >> > > Are there com.bar types in com.baz's API? If not then users of com.baz > need to vigorously lobby the maintainer of com.baz to stop using requires > public. If com.baz agrees then com.foo will not read com.bar at 1 and this > frees up com.foo to use another version of com.bar in layer2. > > On the other hand, if there are com.bar types in com.baz's API then > com.foo will be exposed to com.bar at 1 types. If com.foo does not use any com.baz's com.bar depend API or com.bar depend API added latter or requires public in com.baz added later or removed latter any com.foo may be not aware that, estimating what version of com.bar for com.foo module that depend on com.bar at 2 would be quite puzzling and this would be a good candidate for next edition of java puzzlers book. But with one simple rule "Always current layer's version of module win over parent layer's one. you don't have unexpected result as in this example com.bar at 2 may be ignored while com.foo not being aware. -- Best Regards, Ali Ebrahimi From jean-francois.denise at oracle.com Thu Nov 5 15:21:23 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Thu, 5 Nov 2015 16:21:23 +0100 Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages In-Reply-To: <561B12CD-D642-43CF-A444-80BCEAAFDA42@oracle.com> References: <563B254A.7090001@oracle.com> <561B12CD-D642-43CF-A444-80BCEAAFDA42@oracle.com> Message-ID: <0E86B110-DBC4-480D-9A02-3A211DD672EB@oracle.com> +1, in the test, could you make sure that childCount is not zero? On 5 Nov 2015, at 14:27, Jim Laskey (Oracle) wrote: > +1 > >> On Nov 5, 2015, at 5:45 AM, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8141521 >> >> Thanks >> -Sundar > From Alan.Bateman at oracle.com Thu Nov 5 15:34:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 15:34:19 +0000 Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages In-Reply-To: <563B254A.7090001@oracle.com> References: <563B254A.7090001@oracle.com> Message-ID: <563B76FB.4020709@oracle.com> On 05/11/2015 09:45, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8141521 The NodeAndImage.symLink field looks very strange as a DirectoryStream just needs the names of the entries where each is resolved against the Path that newDirectoryStream is called on. I just wonder how it works with a combination of "." and ".." and other interesting paths. In the test then shouldn't L608 be child.startsWith(path) as this should not be a String comparison. I also wonder having a much more expanded test for newDirectoryStream as this should have been caught by unit tests. BTW: A small request but would it be possible to reduce the length of the some of the really long lines. It makes it a bit easier to do side-by-side reviews when there isn't horizontal scrolling. -Alan From Alan.Bateman at oracle.com Thu Nov 5 15:45:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 Nov 2015 15:45:19 +0000 Subject: Implied readability + layers In-Reply-To: References: <563B6187.4030108@oracle.com> Message-ID: <563B798F.2090703@oracle.com> On 05/11/2015 15:06, Ali Ebrahimi wrote: > : > If com.foo does not use any com.baz's com.bar depend API or com.bar > depend API added latter or requires public in com.baz added later or > removed latter any com.foo may be not aware that, estimating what > version of com.bar for com.foo module that depend on com.bar at 2 would > be quite puzzling and this would be a good candidate for next edition > of java puzzlers book. Right, module maintainers will need to consider the compatibility impact of dropping requires public. If the motivation is that they are removing APIs then they are likely breaking users of the API anyway. -Alan From rahman.usta.88 at gmail.com Thu Nov 5 18:28:33 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 5 Nov 2015 20:28:33 +0200 Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw Message-ID: Hi all; I'm trying Jigsaw build with my JavaFX project, everything is fine but with two exception. javac could not find/access com.sun.javafx.scene.control.skin.ContextMenuContent and com.sun.javafx.stage.StageHelper classes. Is it possible to use them or are there any alternatives for these classes. Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From ali.ebrahimi1781 at gmail.com Thu Nov 5 18:39:51 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Thu, 5 Nov 2015 22:09:51 +0330 Subject: Implied readability + layers In-Reply-To: <563B798F.2090703@oracle.com> References: <563B6187.4030108@oracle.com> <563B798F.2090703@oracle.com> Message-ID: Hi, So with current implementation of Implied readability w.r.t. layers and unexpected consequences of its remove or addition, I strongly propose to drop it from current design. On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman wrote: > On 05/11/2015 15:06, Ali Ebrahimi wrote: > >> : >> If com.foo does not use any com.baz's com.bar depend API or com.bar >> depend API added latter or requires public in com.baz added later or >> removed latter any com.foo may be not aware that, estimating what version >> of com.bar for com.foo module that depend on com.bar at 2 would be quite >> puzzling and this would be a good candidate for next edition of java >> puzzlers book. >> > > Right, module maintainers will need to consider the compatibility impact > of dropping requires public. If the motivation is that they are removing > APIs then they are likely breaking users of the API anyway. How about adding requires public to M2 and can you say how many modules may fail. I don't understand this strict rule that all consumers of M2 and consumers of consumers of M2 should lock to same version of com.bar. -- Best Regards, Ali Ebrahimi From alex.buckley at oracle.com Thu Nov 5 18:44:36 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Nov 2015 10:44:36 -0800 Subject: Implied readability + layers In-Reply-To: References: <201511041404.tA4E45FI016710@aojmv0008.oracle.com> <563A2BDC.9030202@oracle.com> <563A809F.9020402@oracle.com> <563B185A.8020409@oracle.com> Message-ID: <563BA394.80201@oracle.com> On 11/5/2015 1:30 AM, Ali Ebrahimi wrote: > Hi alan, > So far quite disappointing! > > But I think Alex's last response on this topic says opposite of this: > > "We'll have to think about the implication of com.baz in layer1 sometimes > offering a 'requires public' on com.bar in layer1, and sometimes offering a > 'requires public' on com.bar in layer2, depending on who is reading com.baz > in layer1." Alan and I have discussed this. It's not possible for com.baz in layer1 to "switch" which com.bar it depends on. There are two reasons. First, in some loader of layer1, code in com.baz refers to a type exported by com.bar at 1, and thus triggers class loading of that type from whichever class loader in layer1 is responsible for loading com.bar at 1. The loader for com.baz will be marked by the JVM as an "initiating loader" for the type -- see JVMS8 5.3.2 -- so any further execution of code in com.baz that refers to the type will get the same class as initially loaded (from com.bar at 1). There is no way around this. Second, when code in com.foo calls code in com.baz, the callee has no idea who the caller is. The bytecodes for method invocation don't pass that information. Since code in com.baz doesn't know the caller is com.foo in layer2, there is no possibility of com.baz "switching" to invoke code in com.bar at 2 in layer2 rather than com.bar at 1 in layer1. It would be possible to write code in com.baz that reflectively detects its caller, then reflectively invokes code in either com.bar at 2 or com.bar at 1, never referring to exported types of any com.bar module via the constant pool. If you do this, good luck with all the mental accounting -- it's not a sane technique to build into the module system. Since layers can come and go, it makes sense for the module system to isolate code in a parent layer (com.baz in layer1) from the comings and goings of code in a child layer (com.bar in layer2). > In this case adding 'requires public' on com.bar in layer2 does not mean > we should pick com.bar at 2 for com,foo? > This scenario would have many usages in future when world would filled with > modules and developers would have to use newer versions of modules to fix > bugs. > What if com.foo compiled against com.bar at 2? adding redundant requires com.bar > in com.foo does not help and my app will fail. > So what is advantage of multiple layers? Inconsistent separate compilation has caused problems at run time since 1995. I was very clear in "Project Jigsaw: Under The Hood" that mixing multiple versions of a module must not be done casually. What layers give to a managed runtime (e.g. an app server) is i) freedom to map modules to loaders (not only 1:1 but also n:1 and n:m), and ii) freedom to isolate different versions of modules from each other (see slide 55 in http://openjdk.java.net/projects/jigsaw/j1/jigsaw-under-the-hood-j1-2015.pdf). Alex From jonathan.gibbons at oracle.com Thu Nov 5 18:50:15 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 05 Nov 2015 18:50:15 +0000 Subject: hg: jigsaw/jake/langtools: 2 new changesets Message-ID: <201511051850.tA5IoFOa024735@aojmv0008.oracle.com> Changeset: 755579d808dc Author: alundblad Date: 2015-11-05 10:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/755579d808dc add missing methods in ForwardingFileManager ! src/java.compiler/share/classes/javax/tools/ForwardingJavaFileManager.java Changeset: 76aeac001089 Author: jjg Date: 2015-11-05 10:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/76aeac001089 allow for new jtreg naming convention for patches ! test/tools/lib/ToolBox.java From kevin.rushforth at oracle.com Thu Nov 5 19:51:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Nov 2015 11:51:15 -0800 Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw In-Reply-To: References: Message-ID: <563BB333.3050606@oracle.com> The StageHelper class is deliberately not exposed for good reasons, since it's purpose is to provide internal access to non-public state. We moved most of the skin classes to a publicly exported javafx.scene.control.skin package as part of JEP 253, but that didn't include ContextMenuContent. Can you explain what you are trying to do with these classes? Perhaps there is an alternative? If this is a detailed JavaFX question, then I suggest asking it on openjfx-dev rather than jigsaw-dev. -- Kevin Rahman USTA wrote: > Hi all; > > I'm trying Jigsaw build with my JavaFX project, everything is fine but with > two exception. > > javac could not find/access > com.sun.javafx.scene.control.skin.ContextMenuContent > and com.sun.javafx.stage.StageHelper classes. > > Is it possible to use them or are there any alternatives for these classes. > > Thanks. > > From peter.levart at gmail.com Thu Nov 5 20:13:16 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Nov 2015 21:13:16 +0100 Subject: Implied readability + layers In-Reply-To: References: <563B6187.4030108@oracle.com> <563B798F.2090703@oracle.com> Message-ID: <563BB85C.3030407@gmail.com> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote: > Hi, > So with current implementation of Implied readability w.r.t. layers and > unexpected consequences of its remove or addition, I strongly propose to > drop it from current design. Unless the rule is very simple. The implied readability should be no different than explicit readability. The following situation: module foo { requires public bar; ... } module baz { requires foo; ... } Should behave exactly like the following: module foo { requires bar; ... } module baz { requires foo; requires bar; ... } ...in all possible configurations of layers and classloaders. If implied readability is taken "symbolically", the same caveats apply to one or the other form - they are just different forms of expressing the same thing. Regards, Peter > On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman > wrote: > >> On 05/11/2015 15:06, Ali Ebrahimi wrote: >> >>> : >>> If com.foo does not use any com.baz's com.bar depend API or com.bar >>> depend API added latter or requires public in com.baz added later or >>> removed latter any com.foo may be not aware that, estimating what version >>> of com.bar for com.foo module that depend on com.bar at 2 would be quite >>> puzzling and this would be a good candidate for next edition of java >>> puzzlers book. >>> >> Right, module maintainers will need to consider the compatibility impact >> of dropping requires public. If the motivation is that they are removing >> APIs then they are likely breaking users of the API anyway. > How about adding requires public to M2 and can you say how many modules > may fail. > > I don't understand this strict rule that all consumers of M2 and consumers > of consumers of M2 should lock to same version of com.bar. > From ali.ebrahimi1781 at gmail.com Thu Nov 5 20:42:43 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 6 Nov 2015 00:12:43 +0330 Subject: Implied readability + layers Message-ID: Hi, On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart wrote: > > > On 11/05/2015 07:39 PM, Ali Ebrahimi wrote: > > Hi, > So with current implementation of Implied readability w.r.t. layers and > unexpected consequences of its remove or addition, I strongly propose to > drop it from current design. > > > Unless the rule is very simple. The implied readability should be no > different than explicit readability. > > ...in all possible configurations of layers and classloaders. > Exactly. I agree. Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2. situation1: module foo { requires public bar; ... } module baz { requires foo; ... } The readability graph for configuration1/layer1 is: bar at 1 reads java.base foo reads java.base foo reads bar at 1 The readability graph for configuration2/layer2 is: bar at 2 reads java.base baz reads foo baz reads bar at 1================== But situation2: module foo { requires bar; ... } module baz { requires foo; requires bar; ... } The readability graph for configuration1/layer1 is: bar at 1 reads java.base foo reads java.base foo reads bar at 1 The readability graph for configuration2/layer2 is: bar at 2 reads java.base baz reads foo baz reads bar at 2================== > If implied readability is taken "symbolically", the same caveats apply to > one or the other form - they are just different forms of expressing the > same thing. > As you can see this is currently is not case. But with one simple rule "Always current layer's version of module win over parent layer's one" we would have same readability graphs for both situations. -- Best Regards, Ali Ebrahimi From rahman.usta.88 at gmail.com Thu Nov 5 20:59:14 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 5 Nov 2015 22:59:14 +0200 Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw In-Reply-To: <563BB333.3050606@oracle.com> References: <563BB333.3050606@oracle.com> Message-ID: I'm using ContextMenuContent to add new menu items to webview's default context menu. I can set a new ContextMenu for Webviews but, I want to use actions of default menuitems as well. Code I'm doing something when application focus-out, but when an JavaFX Alert is shown, it acts as focus-out, to avoid this circumstances I'm using StageHelper Code Note: I can also ask the question to openjfx-dev 2015-11-05 21:51 GMT+02:00 Kevin Rushforth : > The StageHelper class is deliberately not exposed for good reasons, since > it's purpose is to provide internal access to non-public state. > > We moved most of the skin classes to a publicly exported > javafx.scene.control.skin package as part of JEP 253, but that didn't > include ContextMenuContent. > > Can you explain what you are trying to do with these classes? Perhaps > there is an alternative? If this is a detailed JavaFX question, then I > suggest asking it on openjfx-dev rather than jigsaw-dev. > > -- Kevin > > > > Rahman USTA wrote: > >> Hi all; >> >> I'm trying Jigsaw build with my JavaFX project, everything is fine but >> with >> two exception. >> >> javac could not find/access >> com.sun.javafx.scene.control.skin.ContextMenuContent >> and com.sun.javafx.stage.StageHelper classes. >> >> Is it possible to use them or are there any alternatives for these >> classes. >> >> Thanks. >> >> >> > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From peter.levart at gmail.com Thu Nov 5 21:15:15 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Nov 2015 22:15:15 +0100 Subject: Implied readability + layers In-Reply-To: References: Message-ID: <563BC6E3.1090903@gmail.com> On 11/05/2015 09:42 PM, Ali Ebrahimi wrote: > Hi, > > On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart > wrote: > > > > On 11/05/2015 07:39 PM, Ali Ebrahimi wrote: >> Hi, >> So with current implementation of Implied readability w.r.t. layers and >> unexpected consequences of its remove or addition, I strongly propose to >> drop it from current design. > > Unless the rule is very simple. The implied readability should be > no different than explicit readability. > > ...in all possible configurations of layers and classloaders. > > Exactly. I agree. > Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2. > > situation1: > > module foo { > requires public bar; > ... > } > > module baz { > requires foo; > ... > } > > The readability graph for configuration1/layer1 is: > bar at 1 reads java.base > foo reads java.base > foo reads bar at 1 > > The readability graph for configuration2/layer2 is: > bar at 2 reads java.base > baz reads foo > baz reads bar at 1================== > > But situation2: > module foo { > requires bar; > ... > } > > module baz { > requires foo; > requires bar; > ... > } > > The readability graph for configuration1/layer1 is: > bar at 1 reads java.base > foo reads java.base > foo reads bar at 1 > > The readability graph for configuration2/layer2 is: > bar at 2 reads java.base > baz reads foo > baz reads bar at 2================== > > > > If implied readability is taken "symbolically", the same caveats > apply to one or the other form - they are just different forms of > expressing the same thing. > > As you can see this is currently is not case. What I'm trying to say is that it should be the same. situation1 should construct the same readability graph as situation2 (which is the right one). > > But with one simple rule "Always current layer's version of module win > over parent layer's one" we would have same readability graphs for > both situations. Right. I would say it even simpler: take the implicitly and explicitly required module names "symbolically" and evaluate them in the context of each module. This way adding a "public" keyword is always safe and the existence of "public" keyword can not harm anybody. Removing it is of course not safe and can not be made safe. Regards, Peter > > > > -- > > Best Regards, > Ali Ebrahimi From alex.buckley at oracle.com Thu Nov 5 21:21:19 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Nov 2015 13:21:19 -0800 Subject: Implied readability + layers In-Reply-To: References: Message-ID: <563BC84F.2070503@oracle.com> On 11/5/2015 12:42 PM, Ali Ebrahimi wrote: > On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart > wrote: >> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote: >> So with current implementation of Implied readability w.r.t. layers and >> unexpected consequences of its remove or addition, I strongly propose to >> drop it from current design. >> >> Unless the rule is very simple. The implied readability should be no >> different than explicit readability. >> >> ...in all possible configurations of layers and classloaders. >> > > Exactly. I agree. > Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2. > > situation1: > > module foo { > requires public bar; > ... > } > > module baz { > requires foo; > ... > } > > The readability graph for configuration1/layer1 is: > bar at 1 reads java.base > foo reads java.base > foo reads bar at 1 > > The readability graph for configuration2/layer2 is: > bar at 2 reads java.base > baz reads foo > baz reads bar at 1================== > > But situation2: > module foo { > requires bar; > ... > } > > module baz { > requires foo; > requires bar; > ... > } > > The readability graph for configuration1/layer1 is: > bar at 1 reads java.base > foo reads java.base > foo reads bar at 1 > > The readability graph for configuration2/layer2 is: > bar at 2 reads java.base > baz reads foo > baz reads bar at 2================== > >> If implied readability is taken "symbolically", the same caveats apply to >> one or the other form - they are just different forms of expressing the >> same thing. >> > As you can see this is currently is not case. It is the case for modules in the same layer. For modules in different layers, the fundamental design of class loading (initiating loader v. defining loader) means that explicit readability within a layer "dominates" implicit readability across layers. A redesign of class loading is not on the table, so anyone creating layers has to carefully track the cross-layer dependencies, just like they have to carefully manage the module->loader mapping. Alex From alex.buckley at oracle.com Thu Nov 5 21:39:24 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Nov 2015 13:39:24 -0800 Subject: Implied readability + layers In-Reply-To: References: <563B6187.4030108@oracle.com> <563B798F.2090703@oracle.com> Message-ID: <563BCC8C.1000004@oracle.com> On 11/5/2015 10:39 AM, Ali Ebrahimi wrote: > Hi, > So with current implementation of Implied readability w.r.t. layers and > unexpected consequences of its remove or addition, I strongly propose to > drop it from current design. > > On Thu, Nov 5, 2015 at 7:15 PM, Alan Bateman > wrote: > >> On 05/11/2015 15:06, Ali Ebrahimi wrote: >> >>> : >>> If com.foo does not use any com.baz's com.bar depend API or com.bar >>> depend API added latter or requires public in com.baz added later or >>> removed latter any com.foo may be not aware that, estimating what version >>> of com.bar for com.foo module that depend on com.bar at 2 would be quite >>> puzzling and this would be a good candidate for next edition of java >>> puzzlers book. >>> >> >> Right, module maintainers will need to consider the compatibility impact >> of dropping requires public. If the motivation is that they are removing >> APIs then they are likely breaking users of the API anyway. > > How about adding requires public to M2 and can you say how many modules > may fail. > > I don't understand this strict rule that all consumers of M2 and consumers > of consumers of M2 should lock to same version of com.bar. A single version of com.bar in a program is strongly presumed to be better than multiple versions of com.bar in a program. I showed elsewhere that explicit readability within a parent layer causes class loading to behave in such a way that modules in a child layer cannot override modules in the parent layer. That's just how the JVM works. Sometimes that will rear its head as "consumers of M2 are locked to the same com.bar as consumers of consumers of M2", sometimes it won't, depending on which layers have which modules. But unlimited support for multiple versions in all possible layer arrangements is not a goal. Alex From kevin.rushforth at oracle.com Thu Nov 5 21:41:12 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Nov 2015 13:41:12 -0800 Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw In-Reply-To: References: <563BB333.3050606@oracle.com> Message-ID: <563BCCF8.5010906@oracle.com> Yes, this is case of your using internal classes and unsupported methods, so let's discuss on openjfx-dev to see if there is another way to do what you want to do. I note that in addition to the two internal classes, you are also accessing a non-supported (and not documented) impl_* method which may or may not continue to work. -- Kevin Rahman USTA wrote: > I'm using ContextMenuContent to add new menu items to webview's > default context menu. I can set a new ContextMenu for Webviews but, I > want to use actions of default menuitems as well. Code > > > > I'm doing something when application focus-out, but when an JavaFX > Alert is shown, it acts as focus-out, to avoid this circumstances I'm > using StageHelper Code > > > Note: I can also ask the question to openjfx-dev > > 2015-11-05 21:51 GMT+02:00 Kevin Rushforth >: > > The StageHelper class is deliberately not exposed for good > reasons, since it's purpose is to provide internal access to > non-public state. > > We moved most of the skin classes to a publicly exported > javafx.scene.control.skin package as part of JEP 253, but that > didn't include ContextMenuContent. > > Can you explain what you are trying to do with these classes? > Perhaps there is an alternative? If this is a detailed JavaFX > question, then I suggest asking it on openjfx-dev rather than > jigsaw-dev. > > -- Kevin > > > > Rahman USTA wrote: > > Hi all; > > I'm trying Jigsaw build with my JavaFX project, everything is > fine but with > two exception. > > javac could not find/access > com.sun.javafx.scene.control.skin.ContextMenuContent > and com.sun.javafx.stage.StageHelper classes. > > Is it possible to use them or are there any alternatives for > these classes. > > Thanks. > > > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From ali.ebrahimi1781 at gmail.com Thu Nov 5 22:02:00 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 6 Nov 2015 01:32:00 +0330 Subject: Implied readability + layers Message-ID: Hi, On Thu, Nov 5, 2015 at 10:14 PM, Alex Buckley wrote: > On 11/5/2015 1:30 AM, Ali Ebrahimi wrote: > >> Hi alan, >> So far quite disappointing! >> >> But I think Alex's last response on this topic says opposite of this: >> >> "We'll have to think about the implication of com.baz in layer1 sometimes >> offering a 'requires public' on com.bar in layer1, and sometimes offering >> a >> 'requires public' on com.bar in layer2, depending on who is reading >> com.baz >> in layer1." >> > > Alan and I have discussed this. It's not possible for com.baz in layer1 to > "switch" which com.bar it depends on. I never said we do version switch for com.bar in com.baz in layer1 depend on its consumer module. I just say we use com.bar at 1 for layer1's modules and com.bar at 2 for layer2's modules. You may say it is possible (not always) com.bar at 1 passed to layer2 and we what we can do. This is simple: Or transfer com.foo to layer1 or refactor that to 2 module com.foobaz and com.foobar2 and transfer com.foobaz to layer1. See my previous posts for current implementation unexpected results. This is simple for all module system and module developers module and module consumers and there would not be any puzzle. -- Best Regards, Ali Ebrahimi From harold.seigel at oracle.com Thu Nov 5 22:19:42 2015 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Thu, 05 Nov 2015 22:19:42 +0000 Subject: hg: jigsaw/jake/hotspot: Make ModuleEntry hashtable lookup more efficient. Message-ID: <201511052219.tA5MJgWf011362@aojmv0008.oracle.com> Changeset: e2f40992e003 Author: hseigel Date: 2015-11-05 16:58 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e2f40992e003 Make ModuleEntry hashtable lookup more efficient. ! src/share/vm/classfile/moduleEntry.cpp From peter.levart at gmail.com Thu Nov 5 22:28:10 2015 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 5 Nov 2015 23:28:10 +0100 Subject: Implied readability + layers In-Reply-To: <563BC84F.2070503@oracle.com> References: <563BC84F.2070503@oracle.com> Message-ID: <563BD7FA.3010602@gmail.com> On 11/05/2015 10:21 PM, Alex Buckley wrote: > On 11/5/2015 12:42 PM, Ali Ebrahimi wrote: >> On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart >> wrote: >>> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote: >>> So with current implementation of Implied readability w.r.t. layers and >>> unexpected consequences of its remove or addition, I strongly >>> propose to >>> drop it from current design. >>> >>> Unless the rule is very simple. The implied readability should be no >>> different than explicit readability. >>> >>> ...in all possible configurations of layers and classloaders. >>> >> >> Exactly. I agree. >> Now suppose we have foo, bar at 1 in layer1 and baz and bar at 2 in layer2. >> >> situation1: >> >> module foo { >> requires public bar; >> ... >> } >> >> module baz { >> requires foo; >> ... >> } >> >> The readability graph for configuration1/layer1 is: >> bar at 1 reads java.base >> foo reads java.base >> foo reads bar at 1 >> >> The readability graph for configuration2/layer2 is: >> bar at 2 reads java.base >> baz reads foo >> baz reads bar at 1================== >> >> But situation2: >> module foo { >> requires bar; >> ... >> } >> >> module baz { >> requires foo; >> requires bar; >> ... >> } >> >> The readability graph for configuration1/layer1 is: >> bar at 1 reads java.base >> foo reads java.base >> foo reads bar at 1 >> >> The readability graph for configuration2/layer2 is: >> bar at 2 reads java.base >> baz reads foo >> baz reads bar at 2================== >> >>> If implied readability is taken "symbolically", the same caveats >>> apply to >>> one or the other form - they are just different forms of expressing the >>> same thing. >>> >> As you can see this is currently is not case. > > It is the case for modules in the same layer. For modules in different > layers, the fundamental design of class loading (initiating loader v. > defining loader) means that explicit readability within a layer > "dominates" implicit readability across layers. You mean explicit readability within a layer must dominate implicit readability across layers unless we want the possibility of strange ClassCastExceptions like "com.bar.Type can not be cast to com.bar.Type" and similar? So what is written in javadoc for: public static Configuration resolve(ModuleFinder beforeFinder, Layer parent, ModuleFinder afterFinder, Collection roots) *

Each root module is located using the given {@code beforeFinder} * and if not found, using the given {@code afterFinder}. Their transitive * dependences are located using the given {@code beforeFinder}, or if not * found then the parent {@code Layer}, or if not found then the given * {@code afterFinder}. Dependences located in the parent {@code Layer} * are resolved no further.

...is true only for explicit dependencies? If "transitive" dependency is implicit, then the order is: parent Layer, beforeFinder, afterFinder ? Or is it just so that the module definition is searched in the specified order, but classes are always loaded according to ClassLoader hierarchy and their delegation strategy, regardless of Layer configurations that just sit above them and must be aligned with them? So we can achieve the desired effect if we construct our own ClassLoader(s) that delegate according to beforeFinder/parentLayer/afterFinder ? Regards, Peter > A redesign of class loading is not on the table, so anyone creating > layers has to carefully track the cross-layer dependencies, just like > they have to carefully manage the module->loader mapping. > > Alex From ali.ebrahimi1781 at gmail.com Thu Nov 5 22:30:18 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 6 Nov 2015 02:00:18 +0330 Subject: Implied readability + layers In-Reply-To: <563BCC8C.1000004@oracle.com> References: <563B6187.4030108@oracle.com> <563B798F.2090703@oracle.com> <563BCC8C.1000004@oracle.com> Message-ID: Hi, On Fri, Nov 6, 2015 at 1:09 AM, Alex Buckley wrote: > >> > A single version of com.bar in a program is strongly presumed to be better > than multiple versions of com.bar in a program. > In Ideal world this would be perfect. But, If you use many modules from different third-parties with different release cycles, things may change and finding this single version may be impossible. > I showed elsewhere that explicit readability within a parent layer causes > class loading to behave in such a way that modules in a child layer cannot > override modules in the parent layer. That's just how the JVM works. > Sometimes that will rear its head as "consumers of M2 are locked to the > same com.bar as consumers of consumers of M2", sometimes it won't, > depending on which layers have which modules. But unlimited support for > multiple versions in all possible layer arrangements is not a goal. If goal is prevent from overriding as for methods in clesses why not use 'final': require final com.bar? -- Best Regards, Ali Ebrahimi From alex.buckley at oracle.com Fri Nov 6 00:39:47 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Nov 2015 16:39:47 -0800 Subject: Implied readability + layers In-Reply-To: References: Message-ID: <563BF6D3.3000702@oracle.com> On 11/5/2015 2:02 PM, Ali Ebrahimi wrote: > Hi, > > On Thu, Nov 5, 2015 at 10:14 PM, Alex Buckley > wrote: > > On 11/5/2015 1:30 AM, Ali Ebrahimi wrote: > > Hi alan, > So far quite disappointing! > > But I think Alex's last response on this topic says opposite of > this: > > "We'll have to think about the implication of com.baz in layer1 > sometimes > offering a 'requires public' on com.bar in layer1, and sometimes > offering a > 'requires public' on com.bar in layer2, depending on who is > reading com.baz > in layer1." > > > Alan and I have discussed this. It's not possible for com.baz in > layer1 to "switch" which com.bar it depends on. > > I never said we do version switch for com.bar in com.baz in layer1 > depend on its consumer module. > I just say we use com.bar at 1 for layer1's modules and com.bar at 2 for > layer2's modules. com.foo in layer2 requires com.baz in layer1, right? Yes. com.baz in layer1 uses types from com.bar in layer1, and NOT from com.bar in layer2, right? Yes. Therefore, com.foo uses types from com.bar in layer1 (as required by com.baz in layer1), right? Yes. I don't know what it means to say "we use com.bar at 2 for layer2's modules". com.foo is in layer2, and you can make it read com.bar at 2 via reflection, but otherwise com.bar at 2 is not read by com.foo because com.baz doesn't know about it. > You may say it is possible (not always) com.bar at 1 passed to layer2 and > we what we can do. > This is simple: Or transfer com.foo to layer1 or refactor that to 2 > module com.foobaz and com.foobar2 and transfer com.foobaz to layer1. I can't follow the "simple" solution, sorry. Alex From alex.buckley at oracle.com Fri Nov 6 00:53:03 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Nov 2015 16:53:03 -0800 Subject: Implied readability + layers In-Reply-To: <563BD7FA.3010602@gmail.com> References: <563BC84F.2070503@oracle.com> <563BD7FA.3010602@gmail.com> Message-ID: <563BF9EF.1080605@oracle.com> On 11/5/2015 2:28 PM, Peter Levart wrote: > On 11/05/2015 10:21 PM, Alex Buckley wrote: >>>> If implied readability is taken "symbolically", the same >>>> caveats apply to one or the other form - they are just >>>> different forms of expressing the same thing. >>>> >>> As you can see this is currently is not case. >> >> It is the case for modules in the same layer. For modules in different >> layers, the fundamental design of class loading (initiating loader v. >> defining loader) means that explicit readability within a layer >> "dominates" implicit readability across layers. > > You mean explicit readability within a layer must dominate implicit > readability across layers unless we want the possibility of strange > ClassCastExceptions like "com.bar.Type can not be cast to com.bar.Type" > and similar? Yes. > So what is written in javadoc for: > > public static Configuration resolve(ModuleFinder beforeFinder, > Layer parent, > ModuleFinder afterFinder, > Collection roots) > > *

Each root module is located using the given {@code beforeFinder} > * and if not found, using the given {@code afterFinder}. Their > transitive > * dependences are located using the given {@code beforeFinder}, or > if not > * found then the parent {@code Layer}, or if not found then the given > * {@code afterFinder}. Dependences located in the parent {@code Layer} > * are resolved no further.

> > ...is true only for explicit dependencies? If "transitive" dependency is > implicit, then the order is: parent Layer, beforeFinder, afterFinder ? I believe that "transitive" dependencies means "the set of explicit dependencies mentioned by 'requires' clauses all the way down to java.base". Implicitly read dependencies appear later, and are dominated by the explicit dependencies that have already been resolved. > Or is it just so that the module definition is searched in the specified > order, but classes are always loaded according to ClassLoader hierarchy > and their delegation strategy, regardless of Layer configurations that > just sit above them and must be aligned with them? It goes without saying that classes are always loaded according to the class loaders' delegation strategy (e.g. "a hierarchy") and the JVM's loaded class cache (where the "initiating loader" info I mentioned earlier is stored). Layers don't change that, so they need to align with loader delegation rather than the other way around. > So we can achieve the desired effect if we construct our own > ClassLoader(s) that delegate according to > beforeFinder/parentLayer/afterFinder ? I'm not really sure what the desired effect is at this point, but yes the loaders passed to a layer should delegate in accordance with the resolved graph, and yes the graph would have been resolved on the basis of beforeFinder-then-parentLayer-then-afterFinder. Alex From alex.buckley at oracle.com Fri Nov 6 01:10:34 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 05 Nov 2015 17:10:34 -0800 Subject: Implied readability + layers In-Reply-To: References: <563B6187.4030108@oracle.com> <563B798F.2090703@oracle.com> <563BCC8C.1000004@oracle.com> Message-ID: <563BFE0A.5020505@oracle.com> On 11/5/2015 2:30 PM, Ali Ebrahimi wrote: > On Fri, Nov 6, 2015 at 1:09 AM, Alex Buckley > wrote: > > A single version of com.bar in a program is strongly presumed to be > better than multiple versions of com.bar in a program. > > In Ideal world this would be perfect. > > But, If you use many modules from different third-parties with different > release cycles, things may change and finding this single version may be > impossible. Disagree. Since JDK 1.0, people have been finding this single version by putting it earlier on the classpath than other versions. And if other versions have been shaded so as to co-exist on the classpath with the primary version, then that technique will still work in modules. There is a requirement to support modules from different third parties: http://openjdk.java.net/projects/jigsaw/spec/reqs/#alternate-module-versions-in-dynamic-configurations -- but that doesn't mean arbitrary combinations like a module in a child layer overriding a module in a parent layer. Alex From rahman.usta.88 at gmail.com Fri Nov 6 10:43:52 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 6 Nov 2015 12:43:52 +0200 Subject: Accessing JavaFX' StageHelper and ContextMenuContent in Jigsaw In-Reply-To: <563BCCF8.5010906@oracle.com> References: <563BB333.3050606@oracle.com> <563BCCF8.5010906@oracle.com> Message-ID: Thank you Kevin, I'll move on openjfx-dev. 2015-11-05 23:41 GMT+02:00 Kevin Rushforth : > Yes, this is case of your using internal classes and unsupported methods, > so let's discuss on openjfx-dev to see if there is another way to do what > you want to do. I note that in addition to the two internal classes, you > are also accessing a non-supported (and not documented) impl_* method which > may or may not continue to work. > > -- Kevin > > > Rahman USTA wrote: > > I'm using ContextMenuContent to add new menu items to webview's default > context menu. I can set a new ContextMenu for Webviews but, I want to use > actions of default menuitems as well. Code > > > I'm doing something when application focus-out, but when an JavaFX Alert > is shown, it acts as focus-out, to avoid this circumstances I'm using > StageHelper Code > > > Note: I can also ask the question to openjfx-dev > > 2015-11-05 21:51 GMT+02:00 Kevin Rushforth : > >> The StageHelper class is deliberately not exposed for good reasons, since >> it's purpose is to provide internal access to non-public state. >> >> We moved most of the skin classes to a publicly exported >> javafx.scene.control.skin package as part of JEP 253, but that didn't >> include ContextMenuContent. >> >> Can you explain what you are trying to do with these classes? Perhaps >> there is an alternative? If this is a detailed JavaFX question, then I >> suggest asking it on openjfx-dev rather than jigsaw-dev. >> >> -- Kevin >> >> >> >> Rahman USTA wrote: >> >>> Hi all; >>> >>> I'm trying Jigsaw build with my JavaFX project, everything is fine but >>> with >>> two exception. >>> >>> javac could not find/access >>> com.sun.javafx.scene.control.skin.ContextMenuContent >>> and com.sun.javafx.stage.StageHelper classes. >>> >>> Is it possible to use them or are there any alternatives for these >>> classes. >>> >>> Thanks. >>> >>> >>> >> > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From ali.ebrahimi1781 at gmail.com Fri Nov 6 10:59:17 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 6 Nov 2015 14:29:17 +0330 Subject: Implied readability + layers Message-ID: Hi, On Fri, Nov 6, 2015 at 4:09 AM, Alex Buckley wrote: > > > com.foo in layer2 requires com.baz in layer1, right? Yes. > > com.baz in layer1 uses types from com.bar in layer1, and NOT from com.bar > in layer2, right? Yes. > > Therefore, com.foo uses types from com.bar in layer1 (as required by > com.baz in layer1), right? Yes. > > I don't know what it means to say "we use com.bar at 2 for layer2's > modules". com.foo is in layer2, and you can make it read com.bar at 2 via > reflection, but otherwise com.bar at 2 is not read by com.foo because > com.baz doesn't know about it. There is no need for reflection: Please follow this sample and test it: layer 1: com.baz and com.bar at 1 --------------------------- module com.bar {//version1 exports com.bar; } ------------------ //Bar.java package com.bar; public class Bar { public String bar(){ return "bar1";} } module com.baz { requires com.bar; exports com.baz; } ----------------- //Baz.java package com.baz; import com.bar.Bar; public class Baz { public String baz(){ return new Bar().bar();} public Bar bar(){ return new Bar(); } } layer 2: com.foo and com.bar at 2 -------------------- module com.bar {//version2 exports com.bar; } ------------- //Bar.java package com.bar; public class Bar { public String bar(){ return "bar2";} } ------------- module com.foo { requires com.baz; exports com.foo; } ------------- Foo.java package com.foo; import com.bar.Bar; import com.baz.Baz; public class Main { public static void main(String[] args) { System.out.println(new Baz().baz()); System.out.println(new Bar().bar()); } } ------------------------- test code public class Test { public static void main(String[] args) throws Exception { ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1")); Configuration cfg1 = Configuration.resolve(finder1, Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz"); ModuleClassLoader cl1 = new ModuleClassLoader(cfg1); Layer layer1 = Layer.create(cfg1, m -> cl1); ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2")); Configuration cfg2 = Configuration.resolve(finder2, layer1,ModuleFinder.empty(),"com.bar","com.foo"); ModuleClassLoader cl2 = new ModuleClassLoader(cl1,cfg2); Layer layer2 = Layer.create(cfg2, m -> cl2); Module foo = layer2.findModule("com.foo").get(); Module bar2 = layer2.findModule("com.bar").get(); Module bar1 = layer1.findModule("com.bar").get(); ClassLoader fooModuleLoader = layer2.findLoader("com.foo"); Class mainClass = fooModuleLoader.loadClass("com.foo.Main"); Test.class.getModule().addReads(mainClass.getModule()); Method mainMethod = mainClass.getMethod("main", String[].class); mainMethod.invoke(null, (Object)new String[0]); } } Result: bar1 bar2 As you can see com.foo reads com.bar at 2 without reflection. I say this is puzzling since with almost the equivalent code I get another result. If you want I can show for you in another post. If you want I can send all test files to your mail? -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Fri Nov 6 16:48:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Nov 2015 16:48:12 +0000 Subject: Implied readability + layers In-Reply-To: References: Message-ID: <563CD9CC.8080109@oracle.com> On 06/11/2015 10:59, Ali Ebrahimi wrote: > : > > module com.foo { > requires com.baz; > > exports com.foo; > > } In this example then com.foo will also need to require com.bar as otherwise com.foo will not compile (I assume you've deliberately removed the requires public for this example). In any case, I think what you have here is: layer1: com.bar at 1 com.baz reads com.bar at 1 The (library) module com.baz has com.bar types in its API. layer2 com.bar at 2 com.foo reads com.baz com.foo reads com.bar at 2 > : > > > Result: > > bar1 > bar2 > > As you can see com.foo reads com.bar at 2 without reflection. Yes, because when creating the configuration for this layer then you are resolving com.bar and have arranged that it be found with the before-finder. You would get the same thing if you just resolved com.foo because resolving com.foo's dependences would require finding com.bar. In any case, I think you will start to see some of the issues that Alex warns about when you change com.foo.Main to do more than invoke toString. If you change it to create Bar and Baz objects for example then it's easy to provoke this example to fail with a loader constraint violation. -Alan From alex.buckley at oracle.com Fri Nov 6 17:50:49 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 06 Nov 2015 09:50:49 -0800 Subject: Implied readability + layers In-Reply-To: References: Message-ID: <563CE879.3050409@oracle.com> On 11/6/2015 2:59 AM, Ali Ebrahimi wrote: > On Fri, Nov 6, 2015 at 4:09 AM, Alex Buckley > wrote: > > com.foo in layer2 requires com.baz in layer1, right? Yes. > > com.baz in layer1 uses types from com.bar in layer1, and NOT from > com.bar in layer2, right? Yes. > > Therefore, com.foo uses types from com.bar in layer1 (as required by > com.baz in layer1), right? Yes. > > I don't know what it means to say "we use com.bar at 2 for layer2's > modules". com.foo is in layer2, and you can make it read com.bar at 2 > via reflection, but otherwise com.bar at 2 is not read by com.foo > because com.baz doesn't know about it. > > There is no need for reflection: > Please follow this sample and test it: > > layer 1: com.baz and com.bar at 1 > --------------------------- > > module com.bar {//version1 > exports com.bar; > } > > ------------------ > > //Bar.java > > packagecom.bar; > public classBar { > publicString bar(){return"bar1";} > } > > module com.baz { > requires com.bar; > exports com.baz; > } > > ----------------- > > //Baz.java > > packagecom.baz; > > importcom.bar.Bar; > public classBaz { > publicString baz(){return newBar().bar();} > publicBar bar(){ > return newBar(); > } > } I expect javac will warn about the bar() method of class Baz. As a public method in a public type in an exported package, its return type is from another module (com.bar), yet module com.baz doesn't set up implied readability to that other module. Anyway, moving on. > layer 2: com.foo and com.bar at 2 > -------------------- > module com.bar {//version2 > > exports com.bar; > } > > ------------- > > //Bar.java > > packagecom.bar; > > public classBar { > publicString bar(){return"bar2";} > } > > ------------- > > module com.foo { > requires com.baz; > > exports com.foo; > > } > > ------------- > > Foo.java > > packagecom.foo; > > importcom.bar.Bar; > importcom.baz.Baz; > > public classMain { > public static voidmain(String[] args) { > System.out.println(newBaz().baz()); > System.out.println(newBar().bar()); > } > } Foo.java should not compile. 'import com.bar.Bar' names a type that is inaccessible from module foo. This makes the rest of the scenario moot. > public classTest { > public static voidmain(String[] args)throwsException { > ModuleFinder finder1 = ModuleFinder.of(Paths.get("mods1")); > Configuration cfg1 = Configuration.resolve(finder1, Layer.boot(),ModuleFinder.empty(),"com.bar","com.baz"); > > ModuleClassLoader cl1 =newModuleClassLoader(cfg1); > Layer layer1 = Layer.create(cfg1, m -> cl1); > > ModuleFinder finder2 = ModuleFinder.of(Paths.get("mods2")); > Configuration cfg2 = Configuration.resolve(finder2, layer1,ModuleFinder.empty(),"com.bar","com.foo"); > > ModuleClassLoader cl2 =newModuleClassLoader(cl1,cfg2); > Layer layer2 = Layer.create(cfg2, m -> cl2); > > > > Module foo = layer2.findModule("com.foo").get(); > Module bar2 = layer2.findModule("com.bar").get(); > > Module bar1 = layer1.findModule("com.bar").get(); > > ClassLoader fooModuleLoader = layer2.findLoader("com.foo"); > Class mainClass = fooModuleLoader.loadClass("com.foo.Main"); > > Test.class.getModule().addReads(mainClass.getModule()); > Method mainMethod = mainClass.getMethod("main", String[].class); > > mainMethod.invoke(null, (Object)newString[0]); > } > > } > > Result: > > bar1 > bar2 > > As you can see com.fooreads com.bar at 2 without reflection. > > I say this is puzzling since with almost the equivalent code I get another result. If you want I can show for you in another post. It is puzzling. By specifying com.bar at 2 as one of the root modules in cfg2, you have managed to get layer2's loader to load the class com.bar.Bar from com.bar at 2. And code in module foo can access that class, despite module foo not reading any com.bar module. Even though the main class in Foo.java should not have compiled, it would have been possible to produce class com.foo.Main by other means, and the module system should be more resilient in the face of such inconsistent separate compilation. We'll have to debug this. Alex From ali.ebrahimi1781 at gmail.com Fri Nov 6 19:18:49 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 6 Nov 2015 22:48:49 +0330 Subject: Implied readability + layers In-Reply-To: <563CD9CC.8080109@oracle.com> References: <563CD9CC.8080109@oracle.com> Message-ID: Hi, On Fri, Nov 6, 2015 at 8:18 PM, Alan Bateman wrote: > > > On 06/11/2015 10:59, Ali Ebrahimi wrote: > >> : >> >> module com.foo { >> requires com.baz; >> >> exports com.foo; >> >> } >> > In this example then com.foo will also need to require com.bar as > otherwise com.foo will not compile (I assume you've deliberately removed > the requires public for this example). > This is my bad, I emitted requires public when typing mail. The is correct version: module com.baz{ requires public com.baz; exports com.bar; } Stil result is: foo.canRead(bar2) -> true foo.canRead(bar1) -> false baz.canRead(bar1) -> true baz.canRead(bar2) -> false bar1 bar2 But: I figure out what is problem here: If you try this sample once with exploded modules and then with modular jars you will found. Also, if you remove com.bar from root module list for cfg2 final result will change: Configuration cfg2 = Configuration .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo") .bind(); So all of this can not cause hard to find bugs in user applications. -- Best Regards, Ali Ebrahimi From blackdrag at gmx.org Fri Nov 6 20:07:44 2015 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 6 Nov 2015 21:07:44 +0100 Subject: Avoiding same-package conflicts In-Reply-To: <563926FD.1090805@oracle.com> References: <563223CB.8060300@oracle.com> <5633D52C.6050406@gmx.org> <5637CF95.9030800@oracle.com> <563884E8.4060505@gmx.org> <563926FD.1090805@oracle.com> Message-ID: <563D0890.3020807@gmx.org> On 03.11.2015 22:28, Alex Buckley wrote: [...] > groovy-compiler will obviously have a hard dependency on groovy-base, > but you can avoid groovy-base having a hard dependency on > groovy-compiler by using services. Of course this assumes a suitable > split between the interface of your compiler and its implementation. and of course that split does not exist ;) It is a difference of not including something and referring to it by reflection, to have it optional; and to have it as a service. The first we can do without bigger changes, the later requires the definition of a whole "new" API. [...] > One option for the Groovy runtime is to special case its meta class > package hierarchy by arranging for g.r.m.** classes to be defined by, > and exported from, a special module that the runtime generates; the > runtime would set up readability between this module and the user > modules that "thought" they were defining and exporting g.r.m.**. > > You can see a flavor of this technique in the "dynamic module" created > by Java's Core Reflection when you proxy certain interfaces -- see > "Package and Module Membership of Proxy Class" in > http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Proxy.html. will have a look soon, thanks. bye Jochen From Alan.Bateman at oracle.com Fri Nov 6 20:12:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 Nov 2015 20:12:04 +0000 Subject: Implied readability + layers In-Reply-To: References: <563CD9CC.8080109@oracle.com> Message-ID: <563D0994.3020002@oracle.com> On 06/11/2015 19:18, Ali Ebrahimi wrote: > > This is my bad, I emitted requires public when typing mail. > The is correct version: > > module com.baz{ > requires public com.baz; > exports com.bar; > } > > Stil result is: > > foo.canRead(bar2) -> true > foo.canRead(bar1) -> false > baz.canRead(bar1) -> true > baz.canRead(bar2) -> false > bar1 > bar2 > > > But: > I figure out what is problem here: > If you try this sample once with exploded modules and then with > modular jars you will found. Right, I think you are running into issue again where the two versions of com.bar have equal ModuleDescriptors. When you create modular JAR then I'm guessing you add a module version and this makes them non-equal. For the exploded module case then you could changing one of them to "export com.bar.extra" to make them non-equal. This is just temporary until we get the API changed as I mentioned in some of the other mails. > > Also, if you remove com.bar from root module list for cfg2 final > result will change: > > Configuration cfg2 = Configuration > .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo") > .bind(); > > So all of this can not cause hard to find bugs in user applications. > Yes, nobody requires com.bar in the configuration for layer2 and so com.bar at 2 is ignored. -Alan From ali.ebrahimi1781 at gmail.com Fri Nov 6 20:21:26 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Fri, 6 Nov 2015 23:51:26 +0330 Subject: Implied readability + layers In-Reply-To: <563D0994.3020002@oracle.com> References: <563CD9CC.8080109@oracle.com> <563D0994.3020002@oracle.com> Message-ID: Hi, On Fri, Nov 6, 2015 at 9:20 PM, Alex Buckley wrote: > >> >> importcom.bar.Bar; >> public classBaz { >> publicString baz(){return newBar().bar();} >> publicBar bar(){ >> return newBar(); >> } >> } >> > > I expect javac will warn about the bar() method of class Baz. As a public > method in a public type in an exported package, its return type is from > another module (com.bar), yet module com.baz doesn't set up implied > readability to that other module. Anyway, moving on. > As said in Alan's response this is my bad and I missed requires public. > > layer 2: com.foo and com.bar at 2 >> -------------------- >> module com.bar {//version2 >> >> exports com.bar; >> } >> >> ------------- >> >> //Bar.java >> >> packagecom.bar; >> >> public classBar { >> publicString bar(){return"bar2";} >> } >> >> ------------- >> >> module com.foo { >> requires com.baz; >> >> exports com.foo; >> >> } >> >> ------------- >> >> Foo.java >> >> packagecom.foo; >> >> importcom.bar.Bar; >> importcom.baz.Baz; >> >> public classMain { >> public static voidmain(String[] args) { >> System.out.println(newBaz().baz()); >> System.out.println(newBar().bar()); >> } >> } >> > > Foo.java should not compile. 'import com.bar.Bar' names a type that is > inaccessible from module foo. This makes the rest of the scenario moot. > >> >> >> I say this is puzzling since with almost the equivalent code I get >> another result. If you want I can show for you in another post. >> > > It is puzzling. By specifying com.bar at 2 as one of the root modules in > cfg2, you have managed to get layer2's loader to load the class com.bar.Bar > from com.bar at 2. And code in module foo can access that class, despite > module foo not reading any com.bar module. > I sent test files directly to your mail. -- Best Regards, Ali Ebrahimi From ali.ebrahimi1781 at gmail.com Fri Nov 6 20:37:22 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sat, 7 Nov 2015 00:07:22 +0330 Subject: Implied readability + layers In-Reply-To: <563D0994.3020002@oracle.com> References: <563CD9CC.8080109@oracle.com> <563D0994.3020002@oracle.com> Message-ID: Hi, On Fri, Nov 6, 2015 at 11:42 PM, Alan Bateman wrote: > > > On 06/11/2015 19:18, Ali Ebrahimi wrote: > >> >> > Right, I think you are running into issue again where the two versions of > com.bar have equal ModuleDescriptors. When you create modular JAR then I'm > guessing you add a module version and this makes them non-equal. > > For the exploded module case then you could changing one of them to > "export com.bar.extra" to make them non-equal. This is just temporary until > we get the API changed as I mentioned in some of the other mails. Is not better we allow compiler support for module version in module descriptor? > > >> Also, if you remove com.bar from root module list for cfg2 final result >> will change: >> >> Configuration cfg2 = Configuration >> .resolve(finder2, layer1,ModuleFinder.empty(),"com.foo") >> .bind(); >> >> So all of this can not cause hard to find bugs in user applications. >> >> Yes, nobody requires com.bar in the configuration for layer2 and so > com.bar at 2 is ignored. But don't you think with special handing of implied readability all of this occurs and maybe some non-discovered ones. May be user or IDE think adding 'requires com.bar' to com.foo is redundant and removed. -- Best Regards, Ali Ebrahimi From vincent.x.ryan at oracle.com Sat Nov 7 00:10:21 2015 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Sat, 07 Nov 2015 00:10:21 +0000 Subject: hg: jigsaw/jake/jdk: 8078813: Test JAAS with modules Message-ID: <201511070010.tA70ALko012407@aojmv0008.oracle.com> Changeset: 9418361408f3 Author: vinnie Date: 2015-11-07 00:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9418361408f3 8078813: Test JAAS with modules Summary: Test JAAS LoginContext with different combination of module type. Reviewed-by: weijun Contributed-by: sibabrata.sahoo at oracle.com + test/java/security/modules/JigsawSecurityUtils.java + test/javax/security/auth/login/modules/JaasModularClientTest.java + test/javax/security/auth/login/modules/TEST.properties + test/javax/security/auth/login/modules/src/jaasclientmodule/client/JaasClient.java + test/javax/security/auth/login/modules/src/jaasclientmodule/client/jaas.conf + test/javax/security/auth/login/modules/src/jaasloginmodule/login/TestLoginModule.java ! test/jdk/jigsaw/lib/JarUtils.java From mandy.chung at oracle.com Sat Nov 7 06:37:22 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 07 Nov 2015 06:37:22 +0000 Subject: hg: jigsaw/jake/jdk: Class.forName(Module, String) supports for unnamed module Message-ID: <201511070637.tA76bMJc009401@aojmv0008.oracle.com> Changeset: a87d4be5e220 Author: mchung Date: 2015-11-06 22:37 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a87d4be5e220 Class.forName(Module, String) supports for unnamed module ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/ModuleClassLoader.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/jdk/internal/misc/BuiltinClassLoader.java + test/java/lang/Class/forName/modules/TestDriver.java + test/java/lang/Class/forName/modules/TestMain.java + test/java/lang/Class/forName/modules/src/m1/module-info.java + test/java/lang/Class/forName/modules/src/m1/p1/A.java + test/java/lang/Class/forName/modules/src/m1/p1/Initializer.java + test/java/lang/Class/forName/modules/src/m1/p1/internal/B.java + test/java/lang/Class/forName/modules/src/m2/module-info.java + test/java/lang/Class/forName/modules/src/m2/p2/C.java + test/java/lang/Class/forName/modules/src/m2/p2/test/Main.java From florian.trossbach at codecentric.de Sat Nov 7 10:15:01 2015 From: florian.trossbach at codecentric.de (=?UTF-8?Q?Florian_Tro=C3=9Fbach?=) Date: Sat, 7 Nov 2015 11:15:01 +0100 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: References: Message-ID: Hi, Following the sessions at JavaOne i started playing around with Jigsaw. I am using Build 86 64-bit on OSX. I have trouble compiling a multicompilation project that uses commons-lang3 as an automatic module on the modulepath. The code is available at https://github.com/ftrossbach/IntroToJigsaw, this specifically is the example 6 folder (1-5 work fine, 5 should be the same as 6 but without the reference to the automatic module). When I compile my modules with javac -d . -mp ../jars -modulesourcepath . -verbose $(find . -name "*.java") I get the attached output. The raised error is "error: cannot find module: jdk.management.resource?. I do not understand what that means or why this module is read. When I compile the module without the reference to commons-lang3, it does not occur. When I look at the commonslang3 jar with jdeps, i only get a dependency on java.base: $ jdeps -s ../jars/commonslang3.jar commonslang3.jar -> java.base Any help with this problem is greatly appreciated. Best regards, Florian -- Florian Tro?bach | IT-Consultant | Agile Software Factory | Consulting codecentric AG | Zeppelinstr 2 | 76185 Karlsruhe | Deutschland tel: +49 (0) 721.9595-681 | fax: +49 (0) 721.9595-666 | mobil: +49 (0) 173.6700743 www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal Vorstand: Michael Hochg?rtel . Mirko Novakovic . Rainer Vehns Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus J?ger . J?rgen Sch?tz Diese E-Mail einschlie?lich evtl. beigef?gter Dateien enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und l?schen Sie diese E-Mail und evtl. beigef?gter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder ?ffnen evtl. beigef?gter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet -- Florian Tro?bach | IT-Consultant | Agile Software Factory | Consulting codecentric AG | Zeppelinstr 2 | 76185 Karlsruhe | Deutschland tel: +49 (0) 721.9595-681 | fax: +49 (0) 721.9595-666 | mobil: +49 (0) 173.6700743 www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal Vorstand: Michael Hochg?rtel . Mirko Novakovic . Rainer Vehns Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus J?ger . J?rgen Sch?tz Diese E-Mail einschlie?lich evtl. beigef?gter Dateien enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und l?schen Sie diese E-Mail und evtl. beigef?gter Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder ?ffnen evtl. beigef?gter Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet -------------- next part -------------- [parsing started RegularFileObject[./de.codecentric.addresschecker/de/codecentric/addresschecker/api/AddressChecker.java]] [parsing completed 18ms] [parsing started RegularFileObject[./de.codecentric.addresschecker/de/codecentric/addresschecker/api/Run.java]] [parsing completed 3ms] [parsing started RegularFileObject[./de.codecentric.addresschecker/de/codecentric/addresschecker/internal/AddressCheckerImpl.java]] [parsing completed 1ms] [parsing started RegularFileObject[./de.codecentric.addresschecker/module-info.java]] [parsing completed 0ms] [parsing started RegularFileObject[./de.codecentric.zipvalidator/de/codecentric/zipvalidator/api/ZipCodeValidator.java]] [parsing completed 1ms] [parsing started RegularFileObject[./de.codecentric.zipvalidator/de/codecentric/zipvalidator/api/ZipCodeValidatorFactory.java]] [parsing completed 0ms] [parsing started RegularFileObject[./de.codecentric.zipvalidator/de/codecentric/zipvalidator/internal/ZipCodeValidatorImpl.java]] [parsing completed 1ms] [parsing started RegularFileObject[./de.codecentric.zipvalidator/module-info.java]] [parsing completed 1ms] [parsing started RegularFileObject[./de.codecentric.zipvalidator.model/de/codecentric/zipvalidator/model/api/ZipCodeValidationResult.java]] [parsing completed 0ms] [parsing started RegularFileObject[./de.codecentric.zipvalidator.model/module-info.java]] [parsing completed 3ms] [loading /modules/java.base/module-info.class] error: cannot find module: jdk.management.resource [loading /modules/jdk.zipfs/module-info.class] [loading /modules/jdk.xml.ws/module-info.class] [loading /modules/java.xml.ws/module-info.class] [loading /modules/java.logging/module-info.class] [loading /modules/java.xml.bind/module-info.class] [loading /modules/java.compiler/module-info.class] [loading /modules/java.desktop/module-info.class] [loading /modules/java.prefs/module-info.class] [loading /modules/java.xml/module-info.class] [loading /modules/java.datatransfer/module-info.class] [loading /modules/java.activation/module-info.class] [loading /modules/java.management/module-info.class] [loading /modules/java.rmi/module-info.class] [loading /modules/java.naming/module-info.class] [loading /modules/java.security.sasl/module-info.class] [loading /modules/jdk.httpserver/module-info.class] [loading /modules/java.annotations.common/module-info.class] [loading /modules/jdk.xml.bind/module-info.class] [loading /modules/jdk.compiler/module-info.class] [loading /modules/jdk.xml.dom/module-info.class] [loading /modules/jdk.snmp/module-info.class] [loading /modules/jdk.security.jgss/module-info.class] [loading /modules/java.security.jgss/module-info.class] [loading /modules/jdk.security.auth/module-info.class] [loading /modules/jdk.sctp/module-info.class] [loading /modules/jdk.scripting.nashorn.shell/module-info.class] [loading /modules/jdk.scripting.nashorn/module-info.class] [loading /modules/java.scripting/module-info.class] [loading /modules/jdk.internal.le/module-info.class] [loading /modules/jdk.rmic/module-info.class] [loading /modules/jdk.javadoc/module-info.class] [loading /modules/java.corba/module-info.class] [loading /modules/java.transaction/module-info.class] [loading /modules/jdk.policytool/module-info.class] [loading /modules/java.sql/module-info.class] [loading /modules/jdk.plugin.dom/module-info.class] [loading /modules/jdk.deploy/module-info.class] [loading /modules/jdk.plugin/module-info.class] [loading /modules/jdk.javaws/module-info.class] [loading /modules/jdk.pack200/module-info.class] [loading /modules/jdk.naming.rmi/module-info.class] [loading /modules/jdk.naming.dns/module-info.class] [loading /modules/jdk.management/module-info.class] [loading /modules/jdk.localedata/module-info.class] [loading /modules/jdk.jvmstat/module-info.class] [loading /modules/jdk.jlink/module-info.class] [loading /modules/jdk.jdeps/module-info.class] [loading /modules/jdk.internal.opt/module-info.class] [loading /modules/jdk.jfr/module-info.class] [loading /modules/java.instrument/module-info.class] [loading /modules/jdk.jdwp.agent/module-info.class] [loading /modules/jdk.jdi/module-info.class] [loading /modules/jdk.attach/module-info.class] [loading /modules/jdk.jconsole/module-info.class] [loading /modules/jdk.jcmd/module-info.class] [loading /modules/jdk.hotspot.agent/module-info.class] [loading /modules/jdk.jartool/module-info.class] [loading /modules/jdk.deploy.osx/module-info.class] [loading /modules/jdk.crypto.pkcs11/module-info.class] [loading /modules/jdk.crypto.ec/module-info.class] [loading /modules/jdk.charsets/module-info.class] [loading /modules/jdk.accessibility/module-info.class] [loading /modules/javafx.web/module-info.class] [loading /modules/javafx.graphics/module-info.class] [loading /modules/javafx.base/module-info.class] [loading /modules/javafx.controls/module-info.class] [loading /modules/javafx.media/module-info.class] [loading /modules/javafx.swing/module-info.class] [loading /modules/javafx.fxml/module-info.class] [loading /modules/javafx.deploy/module-info.class] [loading /modules/java.xml.crypto/module-info.class] [loading /modules/java.sql.rowset/module-info.class] [loading /modules/java.smartcardio/module-info.class] [loading /modules/java.se/module-info.class] [loading /modules/java.compact3/module-info.class] [loading /modules/java.compact2/module-info.class] [loading /modules/java.compact1/module-info.class] [total 218ms] 1 error From Alan.Bateman at oracle.com Sat Nov 7 14:34:07 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 7 Nov 2015 14:34:07 +0000 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: References: Message-ID: <563E0BDF.9040907@oracle.com> On 07/11/2015 10:15, Florian Tro?bach wrote: > : > > When I compile my modules with > > javac -d . -mp ../jars -modulesourcepath . -verbose $(find . -name > "*.java") > > I get the attached output. The raised error is "error: cannot find module: > jdk.management.resource?. > > This is a bug in the EA build where they are qualified exports to jdk.management.resource but this module is not in the builds. So it's a build issue, I'll create a bug to track this. If you build the JDK yourself, from the jigsaw/jake sources, then you won't run into this issue, it is specified to how the EA builds are created. That said, I'm not 100% sure why javac runs into it here, I'm sure Jon or Jan can explain that. -Alan. From alan.bateman at oracle.com Sat Nov 7 16:48:33 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Nov 2015 16:48:33 +0000 Subject: hg: jigsaw/jake/jdk: jdk/jigsaw tests failing due to recent changes to JarUtils Message-ID: <201511071648.tA7GmY2A020640@aojmv0008.oracle.com> Changeset: 1c37b2067e4d Author: alanb Date: 2015-11-07 16:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c37b2067e4d jdk/jigsaw tests failing due to recent changes to JarUtils ! test/javax/security/auth/login/modules/JaasModularClientTest.java ! test/jdk/jigsaw/lib/JarUtils.java From alan.bateman at oracle.com Sat Nov 7 17:41:44 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 07 Nov 2015 17:41:44 +0000 Subject: hg: jigsaw/jake/jdk: Move tests for Class getResource to java/lang/Class Message-ID: <201511071741.tA7Hfi2o028732@aojmv0008.oracle.com> Changeset: bb94cd0c9910 Author: alanb Date: 2015-11-07 17:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bb94cd0c9910 Move tests for Class getResource to java/lang/Class + test/java/lang/Class/getResource/Main.java + test/java/lang/Class/getResource/ResourcesTest.java + test/java/lang/Class/getResource/src/m1/module-info.java + test/java/lang/Class/getResource/src/m1/p1/Main.java + test/java/lang/Class/getResource/src/m2/module-info.java + test/java/lang/Class/getResource/src/m2/p2/Main.java + test/java/lang/Class/getResource/src/m3/module-info.java + test/java/lang/Class/getResource/src/m3/p3/Main.java - test/jdk/jigsaw/etc/resources/Main.java - test/jdk/jigsaw/etc/resources/ResourcesTest.java - test/jdk/jigsaw/etc/resources/src/m1/module-info.java - test/jdk/jigsaw/etc/resources/src/m1/p1/Main.java - test/jdk/jigsaw/etc/resources/src/m2/module-info.java - test/jdk/jigsaw/etc/resources/src/m2/p2/Main.java - test/jdk/jigsaw/etc/resources/src/m3/module-info.java - test/jdk/jigsaw/etc/resources/src/m3/p3/Main.java From mandy.chung at oracle.com Sat Nov 7 21:27:16 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 07 Nov 2015 21:27:16 +0000 Subject: hg: jigsaw/jake/jdk: Enable jlink gen-installed-modules plugin by default Message-ID: <201511072127.tA7LRGPK008490@aojmv0008.oracle.com> Changeset: 3f859f4a29bf Author: mchung Date: 2015-11-07 13:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f859f4a29bf Enable jlink gen-installed-modules plugin by default ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/InstalledModuleDescriptorProvider.java From florian.trossbach at codecentric.de Sun Nov 8 09:56:59 2015 From: florian.trossbach at codecentric.de (=?UTF-8?Q?Florian_Tro=C3=9Fbach?=) Date: Sun, 8 Nov 2015 10:56:59 +0100 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: <563E0BDF.9040907@oracle.com> References: <563E0BDF.9040907@oracle.com> Message-ID: Hi Alan, Thank you for your answer, building the JDK myself this error goes away. Building my own JDK was not without challenges on OSX Mavericks though: I first mistakenly cloned the wrong repository (the JDK9 without Jigsaw. It compiled just fine, but I of course discovered my error when javac complained about the -modulepath switch. Then I cloned the right repo, but it failed to compile with an ?error 2?. As I don?t know much about make, I proceeded to creating an Ubuntu VM and after installing a load of dependencies (which the configure.sh script tells you about very nicely!), I got it working. I did some more ?research" about the OSX build though, and i found this: https://www.mail-archive.com/build-dev at openjdk.java.net/msg15343.html. This prompted me to replace the offending sections from /hotspot/make/bsd/makefiles/gcc.make (around line 324) with the equivalent from the non-jigsaw sources that I managed to compile successfully. Lo and behold, this worked like a charm. Best regards, Florian 2015-11-07 15:34 GMT+01:00 Alan Bateman : > On 07/11/2015 10:15, Florian Tro?bach wrote: > >> : >> >> When I compile my modules with >> >> javac -d . -mp ../jars -modulesourcepath . -verbose $(find . -name >> "*.java") >> >> I get the attached output. The raised error is "error: cannot find module: >> jdk.management.resource?. >> >> >> This is a bug in the EA build where they are qualified exports to > jdk.management.resource but this module is not in the builds. So it's a > build issue, I'll create a bug to track this. If you build the JDK > yourself, from the jigsaw/jake sources, then you won't run into this issue, > it is specified to how the EA builds are created. > > That said, I'm not 100% sure why javac runs into it here, I'm sure Jon or > Jan can explain that. > > -Alan. > From Alan.Bateman at oracle.com Sun Nov 8 10:42:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 8 Nov 2015 10:42:10 +0000 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: References: <563E0BDF.9040907@oracle.com> Message-ID: <563F2702.3010201@oracle.com> On 08/11/2015 09:56, Florian Tro?bach wrote: > : > > I did some more ?research" about the OSX build though, and i found > this: > https://www.mail-archive.com/build-dev at openjdk.java.net/msg15343.html. > This prompted me to replace the offending sections > from /hotspot/make/bsd/makefiles/gcc.make (around line 324) with the > equivalent from the non-jigsaw sources that I managed to compile > successfully. Lo and behold, this worked like a charm. > Good to hear you got it building on both Linux and OS X. On the Xcode/clang issue then this has been fixed in JDK 9 in jdk9-b89 via JDK-8138820 [1]. The jigsaw/jake forest and EA builds currently based on jdk9-b86 so a bit behind. We were sync'ing up jigsaw/jake weekly but most of us have been too busy recently and this is why jigsaw/jake is a bit behind. There is quite a bit of merging needed to do these syncs up but we will get jigsaw/jake sync'ed up soon. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8138820 From jan.lahoda at oracle.com Sun Nov 8 17:51:53 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 08 Nov 2015 18:51:53 +0100 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: <563E0BDF.9040907@oracle.com> References: <563E0BDF.9040907@oracle.com> Message-ID: <563F8BB9.1070702@oracle.com> On 7.11.2015 15:34, Alan Bateman wrote: > On 07/11/2015 10:15, Florian Tro?bach wrote: >> : >> >> When I compile my modules with >> >> javac -d . -mp ../jars -modulesourcepath . -verbose $(find . -name >> "*.java") >> >> I get the attached output. The raised error is "error: cannot find >> module: >> jdk.management.resource?. >> >> > This is a bug in the EA build where they are qualified exports to > jdk.management.resource but this module is not in the builds. So it's a > build issue, I'll create a bug to track this. If you build the JDK > yourself, from the jigsaw/jake sources, then you won't run into this > issue, it is specified to how the EA builds are created. > > That said, I'm not 100% sure why javac runs into it here, I'm sure Jon > or Jan can explain that. Automatic modules depend on all other named modules, and javac currently uses all modules it knows about, which includes those it found while analyzing other module-infos. I think it could be changed to only include modules found on the module paths. Jan > > -Alan. From Alan.Bateman at oracle.com Mon Nov 9 08:55:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 9 Nov 2015 08:55:09 +0000 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: <563F8BB9.1070702@oracle.com> References: <563E0BDF.9040907@oracle.com> <563F8BB9.1070702@oracle.com> Message-ID: <56405F6D.80003@oracle.com> On 08/11/2015 17:51, Jan Lahoda wrote: > > Automatic modules depend on all other named modules, and javac > currently uses all modules it knows about, which includes those it > found while analyzing other module-infos. I think it could be changed > to only include modules found on the module paths. I assume this will need to re-visited. If javac gets -limitmods then it will limit the set of observable modules and so qualified exports to modules that aren't in that set will need to be ignored. It's also tied to -addmods and getting javac consistent with run-time where automatic only require java.base for the purposes of resolution but read all other modules. In any case, it won't be possible to compile code that references to types in the "missing" modules and so I assume shouldn't change javac behavior to not use the qualified exports. -Alan From harold.seigel at oracle.com Mon Nov 9 16:55:42 2015 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 09 Nov 2015 16:55:42 +0000 Subject: hg: jigsaw/jake/hotspot: 8139095: AppCDS will load application archive classes that conflict with modules in the jimage Message-ID: <201511091655.tA9GthgX026461@aojmv0008.oracle.com> Changeset: 87a0cdda6d9e Author: jiangli Date: 2015-11-06 19:47 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/87a0cdda6d9e 8139095: AppCDS will load application archive classes that conflict with modules in the jimage Summary: More fine-grained shared class runtime visibility check. Reviewed-by: lfoltan, acorn, ccheung Contributed-by: jiangli.zhou at oracle.com, calvin.cheung at oracle.com, ioi.lam at oracle.com ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/systemDictionaryShared.hpp From alexandre.iline at oracle.com Mon Nov 9 17:54:05 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 9 Nov 2015 20:54:05 +0300 Subject: RFR: 8139430 Message-ID: Hi, This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03 Could you please take a look on it? A few comments. The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code. I am moving the rest library code which depended on java.management and jdk.management to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies. The methods which worth moving fit well into two classes: jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods. jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments None of moved/renamed test library methods were used anywhere in tests, so no test updates needed: jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments() jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library: ./closed/com/oracle/jfr/common/jrockit/TestThread.java Please let me know what you think. Shura From alexandre.iline at oracle.com Mon Nov 9 18:12:11 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 9 Nov 2015 21:12:11 +0300 Subject: RFR: 8139430 In-Reply-To: References: Message-ID: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> Hi I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ Shura > On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline wrote: > > Hi, > > This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03 > > Could you please take a look on it? > > A few comments. > > The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code. > > I am moving the rest library code which depended on java.management and jdk.management to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies. > > The methods which worth moving fit well into two classes: > jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods. > jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments > > None of moved/renamed test library methods were used anywhere in tests, so no test updates needed: > jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments() > jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library: > ./closed/com/oracle/jfr/common/jrockit/TestThread.java > > Please let me know what you think. > > Shura From jonathan.gibbons at oracle.com Mon Nov 9 18:44:31 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 09 Nov 2015 10:44:31 -0800 Subject: Unable to compile modules with references to automatic modules - "cannot find module: jdk.management.resource" In-Reply-To: <56405F6D.80003@oracle.com> References: <563E0BDF.9040907@oracle.com> <563F8BB9.1070702@oracle.com> <56405F6D.80003@oracle.com> Message-ID: <5640E98F.1010702@oracle.com> On 11/09/2015 12:55 AM, Alan Bateman wrote: > > On 08/11/2015 17:51, Jan Lahoda wrote: >> >> Automatic modules depend on all other named modules, and javac >> currently uses all modules it knows about, which includes those it >> found while analyzing other module-infos. I think it could be changed >> to only include modules found on the module paths. > > I assume this will need to re-visited. If javac gets -limitmods then > it will limit the set of observable modules and so qualified exports > to modules that aren't in that set will need to be ignored. It's also > tied to -addmods and getting javac consistent with run-time where > automatic only require java.base for the purposes of resolution but > read all other modules. > > In any case, it won't be possible to compile code that references to > types in the "missing" modules and so I assume shouldn't change javac > behavior to not use the qualified exports. > > -Alan Yes, this all needs to be fixed. javac's ModuleFinder currently scans all modules on the aggregate module path; it needs to be updated to match the runtime behavior, which is to scan system modules, plus any modules in and reachable from the root set, plus any modules requested with -addmods. -- Jon From richard at lucentsky.com Tue Nov 10 05:26:55 2015 From: richard at lucentsky.com (Richard Callahan) Date: Tue, 10 Nov 2015 05:26:55 +0000 Subject: Technical question about the Java Dependency Analysis Tool Message-ID: Hi, I have a specific question about the output from the Java Dependency Analysis Tool (JDeps), released with Open JDK 8. Thank you very much for such a marvelous tool! I am parsing the output from JDeps with the "-v" flag set, such that a call to JDeps produces all class-level dependencies among and within a set of JAR files in a directory specified by the user. Consider a directed graph G constructed from the JDeps output, with the vertices representing nodes in the graph and the edges representing dependencies among the classes as specified in the JDeps output. My question is, if a specific JAR file in the directory (call it A.jar) can compile using OpenJDK with the other JAR files in the directory designated as dependencies, then does there always exist at least one subgraph G' of G that corresponds to the dependency relationships that would be actually used by a Java compiler to compile A.jar? If the answer is "yes," then I believe I should be able to recover that graph by starting with the set of classes in A.jar and then constructing the subgraph G' in a manner similar to that used by a depth-first search. Thank you for your time, I recognize it is valuable. Best, Richard From jean-francois.denise at oracle.com Tue Nov 10 10:17:40 2015 From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com) Date: Tue, 10 Nov 2015 10:17:40 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511101017.tAAAHeYu017280@aojmv0008.oracle.com> Changeset: 1148a05d184a Author: jfdenise Date: 2015-11-10 10:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1148a05d184a Fix for 8135077, 8134944, 8139296 Reviewed-by: jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginProviderRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugins/DefaultImageBuilderProvider.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/jdk/jigsaw/tools/jlink/CustomImageBuilderTest.java ! test/jdk/jigsaw/tools/jlink/JLinkNegativeTest.java ! test/jdk/jigsaw/tools/jlink/customplugin/plugin/CustomImageBuilderProvider.java Changeset: 8daa6a6c8657 Author: jfdenise Date: 2015-11-10 11:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8daa6a6c8657 Fix compressed resource header length to be a u8. Handle endianness of compressed resource header. Reviewed-by: jlaskey ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp ! src/java.base/share/native/libjimage/imageDecompressor.hpp ! src/java.base/share/native/libjimage/imageFile.cpp From jaroslav.bachorik at oracle.com Tue Nov 10 12:21:13 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 10 Nov 2015 13:21:13 +0100 Subject: RFR: 8139430 In-Reply-To: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> Message-ID: <5641E139.9000209@oracle.com> Hi, On 9.11.2015 19:12, Alexandre (Shura) Iline wrote: > Hi > > I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: > http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ As for the original (03) webrev - I wouldn't rename InputArguments into RuntimeMXBeanTool. The new name really does not reflect the functionality the class actually provides. IMO, you can keep the original class name and still move it to jdk.testlibrary.management. As for the last (04) webrev - this change doesn't seem to be related to the issue. It is just a cleanup of a potential NPE. I would suggest either updating the issue summary to be more generic or address the NPE in a separate changeset. -JB- > > Shura > >> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline wrote: >> >> Hi, >> >> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03 >> >> Could you please take a look on it? >> >> A few comments. >> >> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code. >> >> I am moving the rest library code which depended on java.management and jdk.management to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies. >> >> The methods which worth moving fit well into two classes: >> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods. >> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments >> >> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed: >> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments() >> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library: >> ./closed/com/oracle/jfr/common/jrockit/TestThread.java >> >> Please let me know what you think. >> >> Shura > From jean-francois.denise at oracle.com Tue Nov 10 13:43:15 2015 From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com) Date: Tue, 10 Nov 2015 13:43:15 +0000 Subject: hg: jigsaw/jake/jdk: Fix for 81422389. Close archives in all cases. Message-ID: <201511101343.tAADhFk6012660@aojmv0008.oracle.com> Changeset: 1943b3022700 Author: jfdenise Date: 2015-11-10 14:43 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1943b3022700 Fix for 81422389. Close archives in all cases. Reviewed-by: jlaskey ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java From mandy.chung at oracle.com Tue Nov 10 15:53:34 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Nov 2015 07:53:34 -0800 Subject: Technical question about the Java Dependency Analysis Tool In-Reply-To: References: Message-ID: jdeps already has the option finding the JAR files needed to compile A.jar. There is a new jdeps option added to Jigsaw EA build [1] to make this easier: $ jdeps -s -ct -R -cp lib/* A.jar This will transitively find all dependencies from the references in A.jar and shows the summary of the JAR-level dependencies. jdeps -dotoutput option outputs the dependencies in a DOT file that you can generate the DOT graph. You can use idk 9 jdeps ?include option which analyzes all JAR files in lib directory $ jdeps ?dotoutput dotfiles ?include ?.*? -cp lib/* A.jar Mandy [1] http://openjdk.java.net/projects/jigsaw/ea > On Nov 9, 2015, at 9:26 PM, Richard Callahan wrote: > > Hi, > > I have a specific question about the output from the Java Dependency Analysis Tool (JDeps), released with Open JDK 8. Thank you very much for such a marvelous tool! > > I am parsing the output from JDeps with the "-v" flag set, such that a call to JDeps produces all class-level dependencies among and within a set of JAR files in a directory specified by the user. Consider a directed graph G constructed from the JDeps output, with the vertices representing nodes in the graph and the edges representing dependencies among the classes as specified in the JDeps output. My question is, if a specific JAR file in the directory (call it A.jar) can compile using OpenJDK with the other JAR files in the directory designated as dependencies, then does there always exist at least one subgraph G' of G that corresponds to the dependency relationships that would be actually used by a Java compiler to compile A.jar? If the answer is "yes," then I believe I should be able to recover that graph by starting with the set of classes in A.jar and then constructing the subgraph G' in a manner similar to that used by a depth-first search. > > Thank you for your time, I recognize it is valuable. > > Best, > > Richard From mandy.chung at oracle.com Tue Nov 10 18:04:55 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Nov 2015 10:04:55 -0800 Subject: RFR: 8139430 In-Reply-To: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> Message-ID: <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com> Hi Shura, Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated. The new jdk.testlibrary.management package name is fine. It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about. There is a copy of ProcessTools and InputArguments in the hotspot repository under hotspot/test/testlibrary/jdk/test/lib/ Are we planning to remove this duplicated copy? If not, same patch should be applied to those copy. It?s fine to separate this and push the hotspot test library change via hotspot-rt repo. Christian can probably sponsor the patch for you. I?ll sponsor the jdk change and push it to jdk9/dev once you send me an updated patch. Mandy > On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline wrote: > > Hi > > I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: > http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ > > Shura > >> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline wrote: >> >> Hi, >> >> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03 >> >> Could you please take a look on it? >> >> A few comments. >> >> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code. >> >> I am moving the rest library code which depended on java.management and jdk.management to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies. >> >> The methods which worth moving fit well into two classes: >> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods. >> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments >> >> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed: >> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments() >> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library: >> ./closed/com/oracle/jfr/common/jrockit/TestThread.java >> >> Please let me know what you think. >> >> Shura > From alexandre.iline at oracle.com Tue Nov 10 18:11:30 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 10 Nov 2015 21:11:30 +0300 Subject: RFR: 8139430 In-Reply-To: <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com> Message-ID: <90149651-7797-41FE-9B42-F913C8385A72@oracle.com> > On Nov 10, 2015, at 9:04 PM, Mandy Chung wrote: > > Hi Shura, > > Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated. > > The new jdk.testlibrary.management package name is fine. It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about. > > There is a copy of ProcessTools and InputArguments in the hotspot repository under > hotspot/test/testlibrary/jdk/test/lib/ > > Are we planning to remove this duplicated copy? If not, same patch should be applied to those copy. It?s fine to separate this and push the hotspot test library change via hotspot-rt repo. Christian can probably sponsor the patch for you. This is the bug to track the library merge: https://bugs.openjdk.java.net/browse/JDK-8075327 It is there for a long time for discussion, so I would not suggest to wait for it. If a parallel fix is needed, I would rather just do it. > > I?ll sponsor the jdk change and push it to jdk9/dev once you send me an updated patch. Yes, thank you. Shura > > Mandy > > >> On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline wrote: >> >> Hi >> >> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: >> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ >> >> Shura >> >>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline wrote: >>> >>> Hi, >>> >>> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03 >>> >>> Could you please take a look on it? >>> >>> A few comments. >>> >>> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code. >>> >>> I am moving the rest library code which depended on java.management and jdk.management to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies. >>> >>> The methods which worth moving fit well into two classes: >>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods. >>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments >>> >>> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed: >>> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments() >>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library: >>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java >>> >>> Please let me know what you think. >>> >>> Shura >> > From mandy.chung at oracle.com Tue Nov 10 18:15:34 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Nov 2015 10:15:34 -0800 Subject: RFR: 8139430 In-Reply-To: <90149651-7797-41FE-9B42-F913C8385A72@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com> <90149651-7797-41FE-9B42-F913C8385A72@oracle.com> Message-ID: <118C0811-745B-424F-8DFE-45CB71A40213@oracle.com> > On Nov 10, 2015, at 10:11 AM, Alexandre (Shura) Iline wrote: > >> >> On Nov 10, 2015, at 9:04 PM, Mandy Chung wrote: >> >> Hi Shura, >> >> Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated. >> >> The new jdk.testlibrary.management package name is fine. It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about. >> >> There is a copy of ProcessTools and InputArguments in the hotspot repository under >> hotspot/test/testlibrary/jdk/test/lib/ >> >> Are we planning to remove this duplicated copy? If not, same patch should be applied to those copy. It?s fine to separate this and push the hotspot test library change via hotspot-rt repo. Christian can probably sponsor the patch for you. > > This is the bug to track the library merge: > https://bugs.openjdk.java.net/browse/JDK-8075327 > > It is there for a long time for discussion, so I would not suggest to wait for it. If a parallel fix is needed, I would rather just do it. > I agree. I suggest to file a bug and apply this fix in the hotspot test library as a separate patch. Mandy From Alan.Bateman at oracle.com Tue Nov 10 20:42:47 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Nov 2015 21:42:47 +0100 Subject: RFR: 8139430 In-Reply-To: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> Message-ID: <564256C7.60905@oracle.com> On 09/11/2015 19:12, Alexandre (Shura) Iline wrote: > Hi > > I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: > http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ > > Shura > I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does. Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid? When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped? -Alan. From jonathan.gibbons at oracle.com Tue Nov 10 22:19:49 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 10 Nov 2015 22:19:49 +0000 Subject: hg: jigsaw/jake/langtools: 8140767: adding -XaddReads option to javac Message-ID: <201511102219.tAAMJnUO007235@aojmv0008.oracle.com> Changeset: 2c1838c6e03c Author: jlahoda Date: 2015-11-10 14:19 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2c1838c6e03c 8140767: adding -XaddReads option to javac ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ModuleFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/modules/AddReadsTest.java From mandy.chung at oracle.com Wed Nov 11 00:45:47 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 Nov 2015 16:45:47 -0800 Subject: RFR: 8139430 In-Reply-To: <564256C7.60905@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> Message-ID: > On Nov 10, 2015, at 12:42 PM, Alan Bateman wrote: > > Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid? There are not small number of tests doing Integer.toString(ProcessTools.getProcessId())); Most of them are in hotspot and there are about 10 in jdk repo. Perhaps the tests should simply be changed to call: ProcessHandle.current().getPid(); > > When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped? I think Shura prefers to do this patch on ProcessTools and update the dependency in another bulk update. It?d be good if this can be done together. Mandy From weijun.wang at oracle.com Wed Nov 11 02:20:43 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 Nov 2015 10:20:43 +0800 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> Message-ID: <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> Ping again. Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain? Thanks Max > On Nov 5, 2015, at 10:07 AM, Wang Weijun wrote: > > I was talking with Vincent off the list, but it seems better to be back. > > Here is Vincent's mail on how he thinks of the new API we are about to provide in JDK-8058778. > >> The new API is interesting but if it's not available in Java SE I'm afraid it does not fit our use case. We cannot make JOSM depend on a JDK at runtime just for this feature :( > > There might be some confusion on what "JDK" means. It used to be the developer's toolkit versus JRE the runtime, but as for module names, a jdk.* module contains APIs defined by OpenJDK instead of Java SE. In fact, most of them are not especially designed for developers. > > That said, I am not exactly sure what kind of images we will release after jigsaw. If there is still a JRE, I think it will include not only the java.* modules but also some jdk.* ones. I hope jdk.security.cert is one of them. > > Personally I am not afraid of using jdk.* modules, since almost every JDK distribution is based on OpenJDK. At least it is now a supported API of OpenJDK instead of old sun.* classes that were never claimed to be supported by anyone. > > In fact, keytool was not defined in Java SE either. It was in JRE though. > > Thanks > Max From Alan.Bateman at oracle.com Wed Nov 11 07:24:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Nov 2015 08:24:05 +0100 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> Message-ID: <5642ED15.2050308@oracle.com> On 11/11/2015 03:20, Wang Weijun wrote: > Ping again. > > Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain? > This isn't really a quick for here. However, in your build environment then use jre/bin/java -listmods to see the full list of modules that are currently linked in. In the makes files then /make/Images.gmk is the make file to check out, specifically the MAIN_MODULES and PROVIDER_MODULES as these are the set of root modules that will be resolved when creating the "jre" image. -Alan. From weijun.wang at oracle.com Wed Nov 11 08:54:35 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 Nov 2015 16:54:35 +0800 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <5642ED15.2050308@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> Message-ID: > On Nov 11, 2015, at 3:24 PM, Alan Bateman wrote: > > > On 11/11/2015 03:20, Wang Weijun wrote: >> Ping again. >> >> Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain? >> > This isn't really a quick for here. However, in your build environment then use jre/bin/java -listmods to see the full list of modules that are currently linked in. In the makes files then /make/Images.gmk is the make file to check out, specifically the MAIN_MODULES and PROVIDER_MODULES as these are the set of root modules that will be resolved when creating the "jre" image. Great, I see MAIN_MODULES contains quite some jdk.* modules. Here comes the question: How do I request a new module to be included in it? The CCC for the new module/API? Thanks Max > > -Alan. From Alan.Bateman at oracle.com Wed Nov 11 09:03:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Nov 2015 10:03:11 +0100 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> Message-ID: <5643044F.3030306@oracle.com> On 11/11/2015 09:54, Wang Weijun wrote: > : > > Here comes the question: How do I request a new module to be included in it? The CCC for the new module/API? > Can you cc jigsaw-dev on the changes to modules.xml? modules.xml is the temporary document that we have in JDK 9 to define the modular structure until the module system goes into the main line. -Alan From chris.hegarty at oracle.com Wed Nov 11 09:13:36 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Nov 2015 09:13:36 +0000 Subject: RFR: 8139430 In-Reply-To: <5641E139.9000209@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <5641E139.9000209@oracle.com> Message-ID: On 10 Nov 2015, at 12:21, Jaroslav Bachorik wrote: > Hi, > > On 9.11.2015 19:12, Alexandre (Shura) Iline wrote: >> Hi >> >> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: >> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ Looks good Shura, and it will be nice when the @modules in the tests are cleaned up too. Trivially, space missing in ProcessTools.java 256 if[SPACE](pid == (int)pid) { -Chris. From erik.joelsson at oracle.com Wed Nov 11 09:34:44 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 11 Nov 2015 09:34:44 +0000 Subject: hg: jigsaw/jake: 2 new changesets Message-ID: <201511110934.tAB9YiJD018281@aojmv0008.oracle.com> Changeset: 471d26171bcf Author: erikj Date: 2015-11-11 10:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/471d26171bcf Removing dead code - make/CompileModuleInfos.gmk Changeset: 887db7246c21 Author: erikj Date: 2015-11-11 10:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/887db7246c21 Fixed filtering of excluded modules ! make/GensrcModuleInfo.gmk ! make/Images.gmk From weijun.wang at oracle.com Wed Nov 11 10:07:50 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 Nov 2015 18:07:50 +0800 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <5643044F.3030306@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> <5643044F.3030306@oracle.com> Message-ID: <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com> > On Nov 11, 2015, at 5:03 PM, Alan Bateman wrote: > > On 11/11/2015 09:54, Wang Weijun wrote: >> : >> >> Here comes the question: How do I request a new module to be included in it? The CCC for the new module/API? >> > Can you cc jigsaw-dev on the changes to modules.xml? modules.xml is the temporary document that we have in JDK 9 to define the modular structure until the module system goes into the main line. I'm prototyping in jake and the change is src/java.base/share/classes/module-info.java: exports sun.security.util to + jdk.security.cert, exports sun.security.x509 to + jdk.security.cert, src/jdk.security.cert/share/classes/module-info.java: +module jdk.security.cert { + exports jdk.security.cert; +} --Max > > -Alan From Alan.Bateman at oracle.com Wed Nov 11 11:01:55 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 Nov 2015 12:01:55 +0100 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> <5643044F.3030306@oracle.com> <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com> Message-ID: <56432023.2000102@oracle.com> On 11/11/2015 11:07, Wang Weijun wrote: > : > I'm prototyping in jake and the change is > > src/java.base/share/classes/module-info.java: > > exports sun.security.util to > + jdk.security.cert, > exports sun.security.x509 to > + jdk.security.cert, > > src/jdk.security.cert/share/classes/module-info.java: > > +module jdk.security.cert { > + exports jdk.security.cert; > +} > > Okay but is the jdk.security.cert API really tied to modules? If not then I assume this can be pushed via jdk9/dev and we can create the module declaration as part of sync'ing up the jake forest. -Alan From weijun.wang at oracle.com Wed Nov 11 13:39:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 11 Nov 2015 21:39:45 +0800 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <56432023.2000102@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> <5643044F.3030306@oracle.com> <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com> <56432023.2000102@oracle.com> Message-ID: <3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com> > On Nov 11, 2015, at 7:01 PM, Alan Bateman wrote: > > > > On 11/11/2015 11:07, Wang Weijun wrote: >> : >> I'm prototyping in jake and the change is >> >> src/java.base/share/classes/module-info.java: >> >> exports sun.security.util to >> + jdk.security.cert, >> exports sun.security.x509 to >> + jdk.security.cert, >> >> src/jdk.security.cert/share/classes/module-info.java: >> >> +module jdk.security.cert { >> + exports jdk.security.cert; >> +} >> >> > Okay but is the jdk.security.cert API really tied to modules? No. I develop it in jake to make sure the API separation is clear and every test has correct @modules tags. > If not then I assume this can be pushed via jdk9/dev and we can create the module declaration as part of sync'ing up the jake forest. Sure, that is my plan. --Max > > -Alan From alexandre.iline at oracle.com Wed Nov 11 13:47:01 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 11 Nov 2015 16:47:01 +0300 Subject: RFR: 8139430 In-Reply-To: <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <27608F2A-6450-4F85-9F38-97D450B8FB23@oracle.com> Message-ID: <0927B2F7-E91C-4580-B8A5-F086508DF113@oracle.com> > On Nov 10, 2015, at 9:04 PM, Mandy Chung wrote: > > Hi Shura, > > Thanks for doing it and it?s good to see the unnecessary dependency to java.management eliminated. > > The new jdk.testlibrary.management package name is fine. It?s okay to keep the class name InputArguments as Jaroslav suggests and it?s easier to tell what this class is about. The reason I have refactored this is because there is more useful methods in RuntimeMXBean than just the getInputArguments(). If we are ever in a need in another library method dealing with RuntimeMXBean, then, a class RuntimeMXBeanTool, or similar, is a natural enough place to add them. Since also there is the ThreadMXBeanTool, it looks homogenous. We can, of course, have the InputArguments class the way it is and still have other classes wrapping RuntimeMXBean calls. http://cr.openjdk.java.net/~shurailine/8139430/webrev.05/ Shura > > There is a copy of ProcessTools and InputArguments in the hotspot repository under > hotspot/test/testlibrary/jdk/test/lib/ > > Are we planning to remove this duplicated copy? If not, same patch should be applied to those copy. It?s fine to separate this and push the hotspot test library change via hotspot-rt repo. Christian can probably sponsor the patch for you. > > I?ll sponsor the jdk change and push it to jdk9/dev once you send me an updated patch. > > Mandy > > >> On Nov 9, 2015, at 10:12 AM, Alexandre (Shura) Iline wrote: >> >> Hi >> >> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: >> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ >> >> Shura >> >>> On Nov 9, 2015, at 8:54 PM, Alexandre (Shura) Iline wrote: >>> >>> Hi, >>> >>> This is one of the ways to fix 8139430: http://cr.openjdk.java.net/~shurailine/8139430/webrev.03 >>> >>> Could you please take a look on it? >>> >>> A few comments. >>> >>> The biggest dependency on java.management was in jdk.testlibrary.ProcessTools.getProcessId() method. I have changed the method to use the new process API, which helped to avoid updating a lot of code. >>> >>> I am moving the rest library code which depended on java.management and jdk.management to a new ?management" subpackage of the jdk library: jdk.testlibrary.management. Another possibility I have considered is ?ext? or ?extended? subpackage, which would have all the classes which depend on anything but java.base. With ?ext? there would be no way to keep the desired granularity with the test modules dependencies. >>> >>> The methods which worth moving fit well into two classes: >>> jdk.testlibrary.management.ThreadMXBeanTool - to include a couple of method which previously belonged to the TestThread utility methods. >>> jdk.testlibrary.management.RuntimeMXBeanTool - previously named as jdk.testlibrary.InputArguments >>> >>> None of moved/renamed test library methods were used anywhere in tests, so no test updates needed: >>> jdk.testlibrary.InputArguments is not used, instead every test which needs that functionality directly calls RuntimeMXBean.getInputArguments() >>> jdk.testlibrary.TestThread.waitUntilBlockingOnObject(Thread, Thread.State, Object) and jdk.testlibrary.TestThread.waitUntilInNative(Thread) also were not used as there is a similar class outside of the test library: >>> ./closed/com/oracle/jfr/common/jrockit/TestThread.java >>> >>> Please let me know what you think. >>> >>> Shura >> > From sundararajan.athijegannathan at oracle.com Wed Nov 11 15:46:00 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 11 Nov 2015 21:16:00 +0530 Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages In-Reply-To: <563B76FB.4020709@oracle.com> References: <563B254A.7090001@oracle.com> <563B76FB.4020709@oracle.com> Message-ID: <564362B8.5050708@oracle.com> Hi, Please find the updated webrev @ http://cr.openjdk.java.net/~sundar/8141521/webrev.01/ * Removed NodeAndImage and related stuff. Using just Node always. Using resolve in DirectoryStream - just "file" names of child Nodes appended to parent dir now. * Using AbstractJrtPath in many places instead of byte[] and converting to getResolvedPath whereever jimage Node lookup has to be done. * Expanded Basic.java /packages tests with "..", "." in the path etc. All cases pass now. * Reduced long line length in places. PS. Got distracted by another bug in UTF8String.toString - which I'm fixing as part of the new webrev! That caused the delay in debugging test issues [apart from holidays in between] Thanks, -Sundar On 11/5/2015 9:04 PM, Alan Bateman wrote: > > > On 05/11/2015 09:45, Sundararajan Athijegannathan wrote: >> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8141521 > The NodeAndImage.symLink field looks very strange as a DirectoryStream > just needs the names of the entries where each is resolved against the > Path that newDirectoryStream is called on. I just wonder how it works > with a combination of "." and ".." and other interesting paths. > > In the test then shouldn't L608 be child.startsWith(path) as this > should not be a String comparison. I also wonder having a much more > expanded test for newDirectoryStream as this should have been caught > by unit tests. > > BTW: A small request but would it be possible to reduce the length of > the some of the really long lines. It makes it a bit easier to do > side-by-side reviews when there isn't horizontal scrolling. > > -Alan From alexandre.iline at oracle.com Wed Nov 11 16:41:44 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 11 Nov 2015 19:41:44 +0300 Subject: RFR: 8139430 In-Reply-To: <564256C7.60905@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> Message-ID: > On Nov 10, 2015, at 11:42 PM, Alan Bateman wrote: > > > > On 09/11/2015 19:12, Alexandre (Shura) Iline wrote: >> Hi >> >> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: >> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ >> >> Shura >> > I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does. > > Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid? Yes, there are a few places only, actually. Let me also fix those. Shura > > When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped? > > -Alan. > > > From jonathan.gibbons at oracle.com Wed Nov 11 23:29:13 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 11 Nov 2015 23:29:13 +0000 Subject: hg: jigsaw/jake/langtools: Setting UsesProviderCompleter to ModuleSymbol.usesProvidersCompleter, to avoid running it too soon. Message-ID: <201511112329.tABNTDat026610@aojmv0008.oracle.com> Changeset: 7c66438d4d8a Author: jlahoda Date: 2015-11-11 15:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7c66438d4d8a Setting UsesProviderCompleter to ModuleSymbol.usesProvidersCompleter, to avoid running it too soon. ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/tools/javac/modules/AddReadsTest.java From patrick at reini.net Thu Nov 12 10:39:09 2015 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 12 Nov 2015 11:39:09 +0100 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API Message-ID: Hi there, I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase. I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE). Now I wanted to know what you think about this? I would also be prepared to do some work in that area. ? Patrick From weijun.wang at oracle.com Thu Nov 12 13:41:16 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 12 Nov 2015 21:41:16 +0800 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> <5643044F.3030306@oracle.com> <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com> <56432023.2000102@oracle.com> <3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com> Message-ID: <609A0AD3-DA4F-44CE-93F5-00A001079FEC@oracle.com> make/Images.gmk uses both JDK_COMPACTn and JRE_COMPACTn. Should it be only JRE_COMPACTn? --Max From scolebourne at joda.org Thu Nov 12 13:50:49 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 12 Nov 2015 13:50:49 +0000 Subject: Annotations across modules Message-ID: My understanding of annotations today is that annotations are not required at runtime. ie. if an annotation is placed into a class at compile time but the .class file for the annotation is not available on the runtime classpath. then there is no error. Does this change in any way with modules? My specific case is wrt @ConstructorProperties which is in java.beans. In 9, a user may run my software without the java.beans module. Can I safely assume that if the annotation is available on the compile module path but not the runtime module path, everything will be OK (ie. no error)? thanks Stephen From jean-francois.denise at oracle.com Thu Nov 12 14:10:25 2015 From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com) Date: Thu, 12 Nov 2015 14:10:25 +0000 Subject: hg: jigsaw/jake/jdk: Fix for 8142485. Jake doesn't build on Windows after recent change to libjimage Message-ID: <201511121410.tACEAPqx001282@aojmv0008.oracle.com> Changeset: 1b50ccfd6f27 Author: jfdenise Date: 2015-11-12 15:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1b50ccfd6f27 Fix for 8142485. Jake doesn't build on Windows after recent change to libjimage Reviewed-by: jlaskey ! src/java.base/share/native/libjimage/imageDecompressor.cpp From Roger.Riggs at Oracle.com Thu Nov 12 15:20:02 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 12 Nov 2015 10:20:02 -0500 Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing in msvcr120.dll Message-ID: <5644AE22.4030803@Oracle.com> Please review additions to jimageFile to diagnose an intermittent failure. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/ Issue: https://bugs.openjdk.java.net/browse/JDK-8141571 Thanks, Roger From alex.buckley at oracle.com Thu Nov 12 19:53:10 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 12 Nov 2015 11:53:10 -0800 Subject: Annotations across modules In-Reply-To: References: Message-ID: <5644EE26.7060107@oracle.com> On 11/12/2015 5:50 AM, Stephen Colebourne wrote: > My understanding of annotations today is that annotations are not > required at runtime. ie. if an annotation is placed into a class at > compile time but the .class file for the annotation is not available > on the runtime classpath. then there is no error. > > Does this change in any way with modules? No. > My specific case is wrt @ConstructorProperties which is in java.beans. > In 9, a user may run my software without the java.beans module. Can I > safely assume that if the annotation is available on the compile > module path but not the runtime module path, everything will be OK > (ie. no error)? Yes, subject to assumptions that your software doesn't crash if it can't get a Class object for the java.beans.ConstructorProperties annotation type. The fact that the java.beans package is part of the huge java.desktop module (due to unfortunate use of AWT types in Beans signatures) is the reason why JMX recently introduced its own annotation type for constructor properties (javax.management.ConstructorParameters). With an eye on behavioral compatibility, some JMX spec work was needed to account for when the @java.beans.ConstructorProperties annotation is present but the java.beans.ConstructorProperties annotation type is not available. See the discussion around JDK-7199353 at http://mail.openjdk.java.net/pipermail/jmx-dev/2015-October/thread.html. Alex From sundararajan.athijegannathan at oracle.com Fri Nov 13 01:33:02 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 13 Nov 2015 07:03:02 +0530 Subject: RFR 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages In-Reply-To: <564362B8.5050708@oracle.com> References: <563B254A.7090001@oracle.com> <563B76FB.4020709@oracle.com> <564362B8.5050708@oracle.com> Message-ID: <56453DCE.9010901@oracle.com> May I get review(s) on the updated webrev please? http://cr.openjdk.java.net/~sundar/8141521/webrev.01/ Thanks, -Sundar On 11/11/2015 9:16 PM, Sundararajan Athijegannathan wrote: > Hi, > > Please find the updated webrev @ > http://cr.openjdk.java.net/~sundar/8141521/webrev.01/ > > * Removed NodeAndImage and related stuff. Using just Node always. > Using resolve in DirectoryStream - just "file" names of child Nodes > appended to parent dir now. > > * Using AbstractJrtPath in many places instead of byte[] and > converting to getResolvedPath whereever jimage Node lookup has to be > done. > > * Expanded Basic.java /packages tests with "..", "." in the path etc. > All cases pass now. > > * Reduced long line length in places. > > PS. Got distracted by another bug in UTF8String.toString - which I'm > fixing as part of the new webrev! That caused the delay in debugging > test issues [apart from holidays in between] > > Thanks, > -Sundar > > On 11/5/2015 9:04 PM, Alan Bateman wrote: >> >> >> On 05/11/2015 09:45, Sundararajan Athijegannathan wrote: >>> Please review http://cr.openjdk.java.net/~sundar/8141521/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8141521 >> The NodeAndImage.symLink field looks very strange as a >> DirectoryStream just needs the names of the entries where each is >> resolved against the Path that newDirectoryStream is called on. I >> just wonder how it works with a combination of "." and ".." and other >> interesting paths. >> >> In the test then shouldn't L608 be child.startsWith(path) as this >> should not be a String comparison. I also wonder having a much more >> expanded test for newDirectoryStream as this should have been caught >> by unit tests. >> >> BTW: A small request but would it be possible to reduce the length of >> the some of the really long lines. It makes it a bit easier to do >> side-by-side reviews when there isn't horizontal scrolling. >> >> -Alan > From mandy.chung at oracle.com Fri Nov 13 02:49:43 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 12 Nov 2015 18:49:43 -0800 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: References: Message-ID: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> > On Nov 12, 2015, at 2:39 AM, Patrick Reinhart wrote: > > Hi there, > > I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase. > > I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE). > > Now I wanted to know what you think about this? I would also be prepared to do some work in that area. A tool to detect split packages and some other characteristics to aid migration to modules would be useful. I tend to think that belongs to a different tool that can build other additional analysis in it. For split packages, it?d be useful to differentiate if the split package contains overlapping classes vs partitioned classes. For partitioned classes, renaming the package would likely be one solution if it doesn?t need to live in a specific namespace. For overlapping classes, one possibility is that the class path contains multiple copies of the same version or different version or patched version of a library, or redistribution. Mandy From mandy.chung at oracle.com Fri Nov 13 02:55:22 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 13 Nov 2015 02:55:22 +0000 Subject: hg: jigsaw/jake/jdk: Backout compressed resource header length change that breaks windows build Message-ID: <201511130255.tAD2tME8020503@aojmv0008.oracle.com> Changeset: 103e023995ba Author: mchung Date: 2015-11-12 18:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/103e023995ba Backout compressed resource header length change that breaks windows build ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp ! src/java.base/share/native/libjimage/imageDecompressor.hpp ! src/java.base/share/native/libjimage/imageFile.cpp From jonathan.gibbons at oracle.com Fri Nov 13 03:30:50 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Nov 2015 19:30:50 -0800 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> References: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> Message-ID: <5645596A.80907@oracle.com> On 11/12/2015 06:49 PM, Mandy Chung wrote: >> On Nov 12, 2015, at 2:39 AM, Patrick Reinhart wrote: >> >> Hi there, >> >> I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase. >> >> I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE). >> >> Now I wanted to know what you think about this? I would also be prepared to do some work in that area. > A tool to detect split packages and some other characteristics to aid migration to modules would be useful. I tend to think that belongs to a different tool that can build other additional analysis in it. > > For split packages, it?d be useful to differentiate if the split package contains overlapping classes vs partitioned classes. For partitioned classes, renaming the package would likely be one solution if it doesn?t need to live in a specific namespace. For overlapping classes, one possibility is that the class path contains multiple copies of the same version or different version or patched version of a library, or redistribution. > > Mandy I think it would be good to have a "class path analysis tool" that can take a classpath, and report which packages are found in which entries on the classpath, and whether any packages are split between multiple entries, or whether any packages are completely by hidden by earlier entries. -- Jon From Alan.Bateman at oracle.com Fri Nov 13 06:49:06 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Nov 2015 07:49:06 +0100 Subject: JOSM feedback on Java 7,8,9, including Jigsaw EA In-Reply-To: <609A0AD3-DA4F-44CE-93F5-00A001079FEC@oracle.com> References: <31098CBD-716A-4D4A-ABAF-48EBBEEE97AB@oracle.com> <50AC8E9B-0FE1-484C-92EA-DF78514360E4@oracle.com> <5642ED15.2050308@oracle.com> <5643044F.3030306@oracle.com> <60BCE223-2D0C-4C0B-B49F-4B4FBB9AB1EA@oracle.com> <56432023.2000102@oracle.com> <3CDD8BBB-00F3-4797-9D34-8D1D2C2162B9@oracle.com> <609A0AD3-DA4F-44CE-93F5-00A001079FEC@oracle.com> Message-ID: <564587E2.1030007@oracle.com> On 12/11/2015 14:41, Wang Weijun wrote: > make/Images.gmk uses both JDK_COMPACTn and JRE_COMPACTn. Should it be only JRE_COMPACTn? > Yes, Images.gmk should be more consistent in the naming of its variables. -Alan From Alan.Bateman at oracle.com Fri Nov 13 08:20:15 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Nov 2015 09:20:15 +0100 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> References: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> Message-ID: <56459D3F.6040408@oracle.com> On 13/11/2015 03:49, Mandy Chung wrote: > : > A tool to detect split packages and some other characteristics to aid > migration to modules would be useful. I tend to think that belongs to > a different tool that can build other additional analysis in it. I was chatting briefly with Patrick about this at Devoxx. For detecting split packages on a class path then I agree, it feels like another tool because it doesn't have to do any static analysis of the classes. More generally, I expect there will be many ideas and suggestions for things that jdeps could do. If we get to the point where it has an API then at least some of these ideas could be developed as tools that use the API. -Alan From patrick at reini.net Fri Nov 13 09:03:42 2015 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 13 Nov 2015 10:03:42 +0100 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> References: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> Message-ID: <9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net> > Am 13.11.2015 um 03:49 schrieb Mandy Chung : > >> On Nov 12, 2015, at 2:39 AM, Patrick Reinhart wrote: >> >> Hi there, >> >> I like to do some early adoption tests with software using the new module system. Now we got an unknown amount of split packages in our system, the we will need to fix in order to migrate our codebase. >> >> I could imagine, that there are other potential users of the JDK, that have the same problem to solve. So I think it would be a good thing to have some detection within the jdeps tool or even have some kind of an API that could be used otherwise (as of in a IDE). >> >> Now I wanted to know what you think about this? I would also be prepared to do some work in that area. > > A tool to detect split packages and some other characteristics to aid migration to modules would be useful. I tend to think that belongs to a different tool that can build other additional analysis in it. I see your point there. I firstly just thought of the jdeps tool mainly, because you have to go thru the at least the same jar files. It sure can be done in a separate tool and it > For split packages, it?d be useful to differentiate if the split package contains overlapping classes vs partitioned classes. For partitioned classes, renaming the package would likely be one solution if it doesn?t need to live in a specific namespace. For overlapping classes, one possibility is that the class path contains multiple copies of the same version or different version or patched version of a library, or redistribution. I do not actually understand, what you mean by overlapping vs. partitioned ones? I somehow did not got it? Patrick From rafael.wth at gmail.com Fri Nov 13 12:04:06 2015 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 13 Nov 2015 13:04:06 +0100 Subject: Locating a class file from a class loader by name Message-ID: Hello, I recently started testing several byte code manipulation frameworks against a recent build of Jigsaw and found a common problem of all of these libraries. I am myself the developer of Byte Buddy ( https://github.com/raphw/byte-buddy) and I know most tools for code manipulation fairly well. I hope that this mailing list can provide me some me advice on patching my library and providing help to other maintainers. Especially in the context of using the instrumentation API, it is often not possible to do reflection on load classes. Rather, code manipulation tools read Java class files and parse these files for exposing classes using a similar API but without the possibility to invoke a method or to read a field. Typically these tools read Java class files by querying a class loader for the class file, e.g.: ClassLoader.getSystemClassLoader("java/lang/Object.class"); This does not longer work using Jigsaw and I wonder how one is now supposed to locate a class file. Do I need to find all runtime images and query each single one? How would the path be for such a class file? Thank you for your help! Best regards, Rafael From james.laskey at oracle.com Fri Nov 13 13:29:34 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 13 Nov 2015 09:29:34 -0400 Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing in msvcr120.dll In-Reply-To: <5644AE22.4030803@Oracle.com> References: <5644AE22.4030803@Oracle.com> Message-ID: <4B3A2B61-BF74-4BB2-A45D-802DCCB97033@oracle.com> +1 > On Nov 12, 2015, at 11:20 AM, Roger Riggs wrote: > > Please review additions to jimageFile to diagnose an intermittent failure. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8141571 > > Thanks, Roger > > From sergei.pikalev at oracle.com Fri Nov 13 13:50:11 2015 From: sergei.pikalev at oracle.com (Sergei Pikalev) Date: Fri, 13 Nov 2015 16:50:11 +0300 Subject: RFR 8135972: Implement new tests for native libjimage library Message-ID: <5645EA93.5040102@oracle.com> Hello, This is the code with new tests for libjimage native library. A webrev with the tests is here: http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html Please review. Thanks, Sergei From Alan.Bateman at oracle.com Fri Nov 13 14:12:14 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Nov 2015 14:12:14 +0000 Subject: RFR 8135972: Implement new tests for native libjimage library In-Reply-To: <5645EA93.5040102@oracle.com> References: <5645EA93.5040102@oracle.com> Message-ID: <5645EFBE.1060903@oracle.com> On 13/11/2015 13:50, Sergei Pikalev wrote: > > Hello, > > This is the code with new tests for libjimage native library. > > A webrev with the tests is here: > > http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html Are there tests passing cleanly on all platforms? At least some of them seems to be passing bad values to native methods that take memory addresses. Are the tests tied to changes in jigsaw/jake or can these tests go into jdk9/dev to follow the jimage changes that are also going in via that route? -Alan From florian.trossbach at codecentric.de Fri Nov 13 14:56:57 2015 From: florian.trossbach at codecentric.de (=?UTF-8?Q?Florian_Tro=C3=9Fbach?=) Date: Fri, 13 Nov 2015 15:56:57 +0100 Subject: Question about javac and modules exporting the same packages at compile time Message-ID: Hi, Playing a bit more with Jigsaw, i was surprised by the behaviour of javac and would like to inquire about the motivation for this. I have three modules. One module reads the other two which have different module names but are otherwise identical. Compiling this, I get a load of compiler warnings about the same packages, but it compiles just fine. I assume it compiles it against the first version of a class it finds. When I run the application, I get a java.lang.module.ResolutionException, so this is good. My question is though - this could have been a compile error too, but the compiler tolerates it. What is the motivation behind this? Best regards, Florian From harold.seigel at oracle.com Fri Nov 13 14:57:21 2015 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 13 Nov 2015 09:57:21 -0500 Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing in msvcr120.dll In-Reply-To: <5644AE22.4030803@Oracle.com> References: <5644AE22.4030803@Oracle.com> Message-ID: <5645FA51.4010800@oracle.com> Hi Roger, The changes look good. Eventually, will the out-of-memory asserts be replaced with an error in order to handle OOM's that occur in production code? Thanks, Harold On 11/12/2015 10:20 AM, Roger Riggs wrote: > Please review additions to jimageFile to diagnose an intermittent > failure. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8141571 > > Thanks, Roger > > From Roger.Riggs at Oracle.com Fri Nov 13 15:56:33 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 13 Nov 2015 10:56:33 -0500 Subject: RFR 9: 8141571 : jdk/internal/jimage/JImageReadTest.java crashing in msvcr120.dll In-Reply-To: <5645FA51.4010800@oracle.com> References: <5644AE22.4030803@Oracle.com> <5645FA51.4010800@oracle.com> Message-ID: <56460831.4040905@Oracle.com> Hi Harold, Yes, this area still needs work; the JIMAGE_xxx functions are called from the VM classloader and need to have the appropriate failure modes. Roger On 11/13/2015 9:57 AM, harold seigel wrote: > Hi Roger, > > The changes look good. > > Eventually, will the out-of-memory asserts be replaced with an error > in order to handle OOM's that occur in production code? > > Thanks, Harold > > On 11/12/2015 10:20 AM, Roger Riggs wrote: >> Please review additions to jimageFile to diagnose an intermittent >> failure. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-jimage-segv-8141571/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8141571 >> >> Thanks, Roger >> >> > From Alan.Bateman at oracle.com Fri Nov 13 16:00:17 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Nov 2015 16:00:17 +0000 Subject: Locating a class file from a class loader by name In-Reply-To: References: Message-ID: <56460911.8000300@oracle.com> On 13/11/2015 12:04, Rafael Winterhalter wrote: > Hello, > > I recently started testing several byte code manipulation frameworks > against a recent build of Jigsaw and found a common problem of all of these > libraries. I am myself the developer of Byte Buddy ( > https://github.com/raphw/byte-buddy) and I know most tools for code > manipulation fairly well. I hope that this mailing list can provide me some > me advice on patching my library and providing help to other maintainers. > > Especially in the context of using the instrumentation API, it is often not > possible to do reflection on load classes. Rather, code manipulation tools > read Java class files and parse these files for exposing classes using a > similar API but without the possibility to invoke a method or to read a > field. > > Typically these tools read Java class files by querying a class loader for > the class file, e.g.: > > ClassLoader.getSystemClassLoader("java/lang/Object.class"); > > This does not longer work using Jigsaw and I wonder how one is now supposed > to locate a class file. Do I need to find all runtime images and query each > single one? How would the path be for such a class file? > Java agents that do byte code instrumentation with java.lang.instrument should continue to work, this goes for both load-time and dynamic instrumentation and also where the code is instrumented to calling into supporting classes on the class path. There is still work to do for the scenario where agents modify the classes with references to types in other modules but that will come in time. As regards ClassLoader.getResourceXXX (which I think is what you mean) then it continues to search the class path as before. It doesn't however locate resources in named modules because they are encapsulated. The same named methods in java.lang.Class to get resources allow code to get at resources in its own module but not other modules. As to how to get at resources in named modules then there are a few ways but the simplest for now is to look at java.lang.reflect.Module getResourceAsStream. -Alan From rafael.wth at gmail.com Fri Nov 13 17:48:00 2015 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 13 Nov 2015 18:48:00 +0100 Subject: Locating a class file from a class loader by name In-Reply-To: <56460911.8000300@oracle.com> References: <56460911.8000300@oracle.com> Message-ID: Hi Alan, thanks for your quick answer. I am less worried about the generated code then I am about the generation process. For example, a ClassFileTransformer might want to instrument all classes that implement a certain interface. For this, the transformer needs to parse the provided class file, extract the interfaces and locate their class files and so forth in order to resolve the type hierarchy. For this, it is now possible to query the ClassLoader which is an argument provided to the transformer. I do not know how I would access the module at this point or get hold of the class file. Also, I would expect that a Java agent that worked in Java 8 would also work in Java 9. If I had to use Java 9 APIs in order to patch my application, I would be required to offer two versions of my library, one for Java 9+ and one for Java 8-. That would be unfortunate. Do I see this correctly? Thank you, best regards, Rafael 2015-11-13 17:00 GMT+01:00 Alan Bateman : > On 13/11/2015 12:04, Rafael Winterhalter wrote: > >> Hello, >> >> I recently started testing several byte code manipulation frameworks >> against a recent build of Jigsaw and found a common problem of all of >> these >> libraries. I am myself the developer of Byte Buddy ( >> https://github.com/raphw/byte-buddy) and I know most tools for code >> manipulation fairly well. I hope that this mailing list can provide me >> some >> me advice on patching my library and providing help to other maintainers. >> >> Especially in the context of using the instrumentation API, it is often >> not >> possible to do reflection on load classes. Rather, code manipulation tools >> read Java class files and parse these files for exposing classes using a >> similar API but without the possibility to invoke a method or to read a >> field. >> >> Typically these tools read Java class files by querying a class loader for >> the class file, e.g.: >> >> ClassLoader.getSystemClassLoader("java/lang/Object.class"); >> >> This does not longer work using Jigsaw and I wonder how one is now >> supposed >> to locate a class file. Do I need to find all runtime images and query >> each >> single one? How would the path be for such a class file? >> >> Java agents that do byte code instrumentation with java.lang.instrument > should continue to work, this goes for both load-time and dynamic > instrumentation and also where the code is instrumented to calling into > supporting classes on the class path. There is still work to do for the > scenario where agents modify the classes with references to types in other > modules but that will come in time. > > As regards ClassLoader.getResourceXXX (which I think is what you mean) > then it continues to search the class path as before. It doesn't however > locate resources in named modules because they are encapsulated. The same > named methods in java.lang.Class to get resources allow code to get at > resources in its own module but not other modules. As to how to get at > resources in named modules then there are a few ways but the simplest for > now is to look at java.lang.reflect.Module getResourceAsStream. > > -Alan > > From Alan.Bateman at oracle.com Fri Nov 13 18:28:33 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Nov 2015 18:28:33 +0000 Subject: Locating a class file from a class loader by name In-Reply-To: References: <56460911.8000300@oracle.com> Message-ID: <56462BD1.4030209@oracle.com> On 13/11/2015 17:48, Rafael Winterhalter wrote: > Hi Alan, > thanks for your quick answer. I am less worried about the generated > code then I am about the generation process. > > For example, a ClassFileTransformer might want to instrument all > classes that implement a certain interface. For this, the transformer > needs to parse the provided class file, extract the interfaces and > locate their class files and so forth in order to resolve the type > hierarchy. For this, it is now possible to query the ClassLoader which > is an argument provided to the transformer. I do not know how I would > access the module at this point or get hold of the class file. I assume you know this but if you have the Instrumentation object then you can invoke getAllLoadedClasses and filter this to the set of classes that implement the interface. Then call retransformClasses with this set (as an array) and your ClassFileTransformer should be invoked with the Class + class bytes for each of these classes. This puts the onus on the VM to reconstitute the class bytes, no need for you to attempt to locate the .class file (which may not exist of course). It also allows multiple agents to work together. > > Also, I would expect that a Java agent that worked in Java 8 would > also work in Java 9. If I had to use Java 9 APIs in order to patch my > application, I would be required to offer two versions of my library, > one for Java 9+ and one for Java 8-. That would be unfortunate. > Existing java agents that are instrumenting code on the class path should continue to work as before. These agents are oblivious to modules but in many cases will be able to instrument code in named modules too. The VM is providing some "readability for free" to keep existing instrumentation agents working. Beyond these cases then I expect agents will need to become module aware because they are instrumenting code in ways that interacts with modules and access checks. The current builds don't have these APIs yet. As to making use of newer APIs then it might add a bit of complexity to these agents or maybe to their how they are built. -Alan From mandy.chung at oracle.com Fri Nov 13 18:43:28 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Nov 2015 10:43:28 -0800 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: <9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net> References: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> <9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net> Message-ID: <6D2D6E22-9F48-4F66-B116-4F0D08618DF5@oracle.com> > On Nov 13, 2015, at 1:03 AM, Patrick Reinhart wrote: > > I do not actually understand, what you mean by overlapping vs. partitioned ones? I somehow did not got it? Let?s say package p is split across three jar files: jar1 contains p.P1, p.P2, p.P3 jar2 contains p.P1 jar3 contains p.P4, p.P5 jar2 overlaps classes with jar1 jar1 and jar3 both have a package p but they don?t have any overlapped class. Mandy From patrick at reini.net Fri Nov 13 21:34:45 2015 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 13 Nov 2015 22:34:45 +0100 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: <56459D3F.6040408@oracle.com> References: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> <56459D3F.6040408@oracle.com> Message-ID: > Am 13.11.2015 um 09:20 schrieb Alan Bateman : > > On 13/11/2015 03:49, Mandy Chung wrote: >> : >> A tool to detect split packages and some other characteristics to aid migration to modules would be useful. I tend to think that belongs to a different tool that can build other additional analysis in it. > I was chatting briefly with Patrick about this at Devoxx. For detecting split packages on a class path then I agree, it feels like another tool because it doesn't have to do any static analysis of the classes. More generally, I expect there will be many ideas and suggestions for things that jdeps could do. If we get to the point where it has an API then at least some of these ideas could be developed as tools that use the API. For now, I?m thinking on providing only that much information, to help find out if there exist split packages at all. I agree that this can be done in a separate tool also and may fit better, even tough I believe having warnings in case of a split package shows up while analyzing the dependencies would be a good thing to have to start from. That would be the starting point using a second tool that would maybe help doing some extended analysis. Patrick From rfscholte at apache.org Fri Nov 13 21:58:47 2015 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 13 Nov 2015 22:58:47 +0100 Subject: JDeps: detecting offending packages Message-ID: Hi, for the maven-jdeps-plugin I use the following code to detect offending packages: --- import java.io.IOException; import org.codehaus.plexus.util.StringUtils; public class Base64Codec { @SuppressWarnings( "restriction" ) public static byte[] Base64decode( String input ) throws IOException { if( StringUtils.isNotEmpty( input ) ) { return new sun.misc.BASE64Decoder().decodeBuffer( input ); } else { return null; } } } --- Previous versions of JDK9 gave me the following output: classes -> java.base (classes) -> java.io -> java.lang -> sun.misc JDK internal API (java.base) The current b86 gives me: classes -> java.base (classes) -> java.io -> java.lang -> sun.misc So why this change? And is there another way to detect the usage of non-accessible classes? The maven-plugin has a parameter called failOnWarning (default:true) which should break the build in order to help developers to change their code when they rely on internal classes. regards, Robert Scholte From patrick at reini.net Fri Nov 13 22:16:34 2015 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 13 Nov 2015 23:16:34 +0100 Subject: Proposal to enhance jdeps tool to search split packages/add some kind of general API In-Reply-To: <6D2D6E22-9F48-4F66-B116-4F0D08618DF5@oracle.com> References: <156AF5F1-B4F2-4760-9CA7-81A0333213E1@oracle.com> <9C036A95-6AF7-4888-BAD9-31B294F825B7@reini.net> <6D2D6E22-9F48-4F66-B116-4F0D08618DF5@oracle.com> Message-ID: > Am 13.11.2015 um 19:43 schrieb Mandy Chung : > >> On Nov 13, 2015, at 1:03 AM, Patrick Reinhart wrote: >> >> I do not actually understand, what you mean by overlapping vs. partitioned ones? I somehow did not got it? > > Let?s say package p is split across three jar files: > > jar1 contains p.P1, p.P2, p.P3 > jar2 contains p.P1 > jar3 contains p.P4, p.P5 > > jar2 overlaps classes with jar1 > jar1 and jar3 both have a package p but they don?t have any overlapped class. Ah, I was thinking it that direction, but I was not absolutely sure. Thanks for clarification. Patrick From jonathan.gibbons at oracle.com Sat Nov 14 00:29:18 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 14 Nov 2015 00:29:18 +0000 Subject: hg: jigsaw/jake/langtools: fix whitespace and merge error in ProblemList.jake.txt Message-ID: <201511140029.tAE0TISu022549@aojmv0008.oracle.com> Changeset: 2e97a1c3478f Author: jjg Date: 2015-11-13 16:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2e97a1c3478f fix whitespace and merge error in ProblemList.jake.txt ! test/ProblemList.jake.txt From jonathan.gibbons at oracle.com Sat Nov 14 02:03:21 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 14 Nov 2015 02:03:21 +0000 Subject: hg: jigsaw/jake/langtools: Fix tests on langtools ProblemList.jake.txt Message-ID: <201511140203.tAE23LCg007897@aojmv0008.oracle.com> Changeset: 8630a1e8260d Author: jjg Date: 2015-11-13 18:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8630a1e8260d Fix tests on langtools ProblemList.jake.txt ! test/ProblemList.jake.txt - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out ! test/tools/javac/T4093617/T4093617.java ! test/tools/javac/T4093617/T4093617.out + test/tools/javac/T4093617/java.base/Object.java ! test/tools/javac/generics/diamond/neg/T8078473_2.java ! test/tools/javac/generics/diamond/neg/T8078473_2.out + test/tools/javac/redefineObject/Object1-test.java + test/tools/javac/redefineObject/Object1.out + test/tools/javac/redefineObject/Object2-test.java + test/tools/javac/redefineObject/Object2.out + test/tools/javac/redefineObject/java.base/Object1.java + test/tools/javac/redefineObject/java.base/Object2.java From mandy.chung at oracle.com Sat Nov 14 04:20:45 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:20:45 +0000 Subject: hg: jigsaw/jake: 65 new changesets Message-ID: <201511140420.tAE4KkBb029263@aojmv0008.oracle.com> Changeset: 0c140bff9257 Author: lana Date: 2015-10-19 00:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0c140bff9257 Added tag jdk9-b87 for changeset fd4f4f756107 ! .hgtags Changeset: a7ec2278c13d Author: ihse Date: 2015-10-12 11:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a7ec2278c13d 8139413: Use --with-x to set X11 root directory Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/lib-x11.m4 Changeset: 81b90ca627de Author: lana Date: 2015-10-15 16:49 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/81b90ca627de Merge Changeset: 0bb87e05d83e Author: lana Date: 2015-10-21 15:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0bb87e05d83e Merge Changeset: 9c467f2d46f0 Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9c467f2d46f0 Added tag jdk9-b88 for changeset 0bb87e05d83e ! .hgtags Changeset: c867c33f584b Author: jlahoda Date: 2015-10-19 19:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c867c33f584b 8134254: JShell API/tool: REPL for Java into JDK9 Summary: Adding jdk.jshell module into modules.xml; and listing it among TOOLS_MODULES. Reviewed-by: alanb, erikj, sundar Contributed-by: robert.field at oracle.com, jan.lahoda at oracle.com ! make/Images.gmk ! modules.xml Changeset: a60a0c1bd394 Author: erikj Date: 2015-10-20 09:47 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a60a0c1bd394 8139735: Switch compilers in JPRT for windows and linux Reviewed-by: tbell, ihse ! make/devkit/Tools.gmk ! make/devkit/createWindowsDevkit.sh ! make/jprt.properties Changeset: 24a3936909e3 Author: ihse Date: 2015-10-20 10:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/24a3936909e3 8139668: Generate README-build.html from markdown Reviewed-by: erikj ! README-builds.html + README-builds.md + common/bin/update-build-readme.sh Changeset: 257534f191e8 Author: ihse Date: 2015-10-20 16:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/257534f191e8 8139969: Fix unzip in compare.sh broken by JDK-8136813 Reviewed-by: erikj ! common/autoconf/compare.sh.in ! common/bin/compare.sh Changeset: cb3f10185e63 Author: erikj Date: 2015-10-20 17:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cb3f10185e63 8139813: Base heap size on type of boot jdk, not architecture of build machine Reviewed-by: tbell, ihse ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-configure.sh Changeset: 8851df90bb66 Author: erikj Date: 2015-10-02 17:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8851df90bb66 8138739: Enable devkit on macosx in JPRT (again) Reviewed-by: ihse ! make/jprt.properties Changeset: 11c070dc7985 Author: ddehaven Date: 2015-10-06 12:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/11c070dc7985 Merge Changeset: efbea01d5b5c Author: prr Date: 2015-10-12 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/efbea01d5b5c Merge - common/autoconf/builddeps.conf.example - common/autoconf/builddeps.conf.nfs.example - common/autoconf/builddeps.m4 Changeset: a44eac54cdc3 Author: prr Date: 2015-10-20 08:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a44eac54cdc3 Merge ! make/jprt.properties Changeset: 827ea558b8a3 Author: prr Date: 2015-10-20 10:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/827ea558b8a3 Merge Changeset: 998803eeed50 Author: neliasso Date: 2015-09-18 10:09 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/998803eeed50 8135068: Extract method matchers from CompilerOracle Summary: Ecapsulate code to enable reuse Reviewed-by: roland, kvn ! test/lib/sun/hotspot/WhiteBox.java Changeset: b9acee978e94 Author: iveresov Date: 2015-09-25 12:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b9acee978e94 Merge Changeset: fd80ddb7553f Author: amurillo Date: 2015-10-01 11:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/fd80ddb7553f Merge Changeset: 0b5d2c8bd667 Author: amurillo Date: 2015-10-08 14:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0b5d2c8bd667 Merge Changeset: 483de5dbcd96 Author: dsamersoff Date: 2015-09-24 20:39 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/483de5dbcd96 8086134: Deadlock detection fails to attach to core file Summary: Test reimplemented for jtreg Reviewed-by: jbachorik ! test/lib/share/classes/jdk/test/lib/apps/LingeredApp.java + test/lib/share/classes/jdk/test/lib/apps/LingeredAppWithDeadlock.java Changeset: 34280222936a Author: jwilhelm Date: 2015-09-28 15:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/34280222936a Merge Changeset: 9261bce638e3 Author: jwilhelm Date: 2015-10-07 00:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9261bce638e3 Merge Changeset: dec57655571e Author: twisti Date: 2015-10-08 11:31 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/dec57655571e 8136421: JEP 243: Java-Level JVM Compiler Interface Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett ! .hgignore ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/common/Modules.gmk ! modules.xml ! test/lib/sun/hotspot/WhiteBox.java ! test/lib/sun/hotspot/code/NMethod.java Changeset: 82f1be4bd9c3 Author: dlong Date: 2015-10-09 02:43 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/82f1be4bd9c3 Merge - common/autoconf/builddeps.conf.example - common/autoconf/builddeps.conf.nfs.example - common/autoconf/builddeps.m4 Changeset: a6e5bdf52315 Author: dlong Date: 2015-10-17 15:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a6e5bdf52315 Merge Changeset: 3962780e2eda Author: amurillo Date: 2015-10-19 12:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3962780e2eda Merge ! make/Images.gmk ! modules.xml Changeset: 8d498217b215 Author: amurillo Date: 2015-10-20 11:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8d498217b215 Merge Changeset: e3cd4b33d245 Author: lana Date: 2015-10-21 18:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e3cd4b33d245 Merge Changeset: 23d62be63eef Author: ihse Date: 2015-10-22 15:54 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/23d62be63eef 8140277: Configuration out-of-date check should also check closed sources Reviewed-by: erikj ! make/Init.gmk Changeset: ae4aba7142a1 Author: ihse Date: 2015-10-22 16:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ae4aba7142a1 8140282: Remove test directories on clean-test-* Reviewed-by: erikj ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/MainSupport.gmk Changeset: 8d873b9b0031 Author: lana Date: 2015-10-22 11:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8d873b9b0031 Merge Changeset: 2396a16033e1 Author: erikj Date: 2015-10-27 13:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2396a16033e1 8140484: Vardeps broken when variable value contains '$' Reviewed-by: tbell ! make/common/MakeBase.gmk ! test/make/TestMakeBase.gmk Changeset: 8001eddb1672 Author: erikj Date: 2015-10-27 17:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8001eddb1672 8140312: Enable new sjavac server only mode in jdk build Reviewed-by: ihse, tbell ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/common/JavaCompilation.gmk ! make/common/SetupJavaCompilers.gmk ! make/test/BuildTestLib.gmk Changeset: cd061b69a817 Author: jwilhelm Date: 2015-10-07 00:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cd061b69a817 Merge Changeset: 08b3c7a80f56 Author: jprovino Date: 2015-10-20 11:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/08b3c7a80f56 Merge Changeset: 97134c4eba32 Author: amurillo Date: 2015-10-22 16:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/97134c4eba32 Merge Changeset: 895353113f38 Author: amurillo Date: 2015-10-27 10:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/895353113f38 Merge Changeset: cf1dc4c035fb Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cf1dc4c035fb Added tag jdk9-b89 for changeset 895353113f38 ! .hgtags Changeset: 3b1bba4161f3 Author: lana Date: 2015-10-30 10:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3b1bba4161f3 Added tag jdk9-b90 for changeset cf1dc4c035fb ! .hgtags Changeset: c8470ff83abe Author: ihse Date: 2015-10-29 15:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c8470ff83abe 8140762: Specifying --without-LIB if not needed should not result in warning Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/lib-alsa.m4 ! common/autoconf/lib-cups.m4 ! common/autoconf/lib-ffi.m4 ! common/autoconf/lib-freetype.m4 ! common/autoconf/lib-x11.m4 Changeset: f0b8f91a0c6f Author: ihse Date: 2015-10-29 16:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f0b8f91a0c6f 8140661: Rename LDFLAGS_SUFFIX to LIBS Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/common/MakeBase.gmk ! make/common/NativeCompilation.gmk Changeset: 5f7679c96d7d Author: erikj Date: 2015-10-29 17:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5f7679c96d7d 8140593: Add configure parameter for devkit for the build compiler Reviewed-by: ihse ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: d7c06f4e28b2 Author: erikj Date: 2015-10-29 17:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d7c06f4e28b2 8140591: Add configure argument specifying make executable in JPRT Reviewed-by: ihse, tbell ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! make/jprt.properties Changeset: 0cde07d1082a Author: lana Date: 2015-10-29 12:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0cde07d1082a Merge Changeset: 122142a18538 Author: lana Date: 2015-11-04 13:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/122142a18538 Merge Changeset: fe54fea946e8 Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/fe54fea946e8 Added tag jdk9-b91 for changeset 122142a18538 ! .hgtags Changeset: 6a4c7c3c200b Author: mchung Date: 2015-11-11 15:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6a4c7c3c200b Merge ! common/autoconf/basics.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/bin/compare.sh ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/common/SetupJavaCompilers.gmk ! make/jprt.properties ! test/lib/sun/hotspot/WhiteBox.java Changeset: c90e05d02b5a Author: mchung Date: 2015-11-12 20:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c90e05d02b5a jdk9-b91 fixup ! make/CompileJavaModules.gmk ! make/Images.gmk Changeset: 05228b00bfcf Author: jbachorik Date: 2015-11-02 13:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/05228b00bfcf 8140481: NoClassDefFoundError thrown by ManagementFactory.getPlatformMBeanServer Reviewed-by: alanb, dsamersoff, erikj ! make/Images.gmk Changeset: 5e06ef3a390a Author: neliasso Date: 2015-10-20 18:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5e06ef3a390a 8137167: JEP165: Compiler Control: Implementation task Summary: Compiler Control JEP Reviewed-by: roland, twisti, zmajo, simonis ! test/lib/sun/hotspot/WhiteBox.java Changeset: e81b35d4c8ad Author: dlong Date: 2015-10-27 01:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e81b35d4c8ad Merge Changeset: 27f356748627 Author: amurillo Date: 2015-10-30 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/27f356748627 Merge Changeset: cda1da5fc2dd Author: amurillo Date: 2015-11-02 10:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cda1da5fc2dd Merge Changeset: a0c572d90b9d Author: erikj Date: 2015-11-03 16:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a0c572d90b9d 8141051: Build test libs -source/-target 9 Reviewed-by: tbell, vlivanov ! make/Main.gmk ! make/test/BuildTestLib.gmk Changeset: d7f1098c2fc8 Author: ihse Date: 2015-11-03 17:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d7f1098c2fc8 8141261: Clean up building of demos Reviewed-by: erikj, tbell ! make/Images.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/common/JavaCompilation.gmk Changeset: 426d96f4922f Author: ihse Date: 2015-11-03 17:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/426d96f4922f 8141333: Rename SetupArchive to SetupJarArchive Reviewed-by: erikj, tbell ! make/JrtfsJar.gmk ! make/common/JarArchive.gmk < make/common/JavaCompilation.gmk + make/common/JavaCompilation.gmk ! test/make/TestJavaCompilation.gmk Changeset: d0f163fcd4c8 Author: erikj Date: 2015-11-03 18:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d0f163fcd4c8 8141332: Switch macosx devkit in JPRT Reviewed-by: ihse, tbell ! make/devkit/createMacosxDevkit.sh ! make/jprt.properties Changeset: 82c695c9b53c Author: simonis Date: 2015-11-04 12:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/82c695c9b53c 8141290: AIX: fix build after '8140661: Rename LDFLAGS_SUFFIX to LIBS' Reviewed-by: ihse ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 1ad0a683c83d Author: ihse Date: 2015-11-05 10:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1ad0a683c83d 8141439: Fix compare.sh -o (broken by JDK-8136813) Reviewed-by: tbell, erikj ! common/autoconf/compare.sh.in ! common/bin/compare.sh Changeset: a36dc737a448 Author: ihse Date: 2015-11-05 15:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a36dc737a448 8141414: Deprecate configure source overriding Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! make/common/JavaCompilation.gmk Changeset: 4ba17e992008 Author: ihse Date: 2015-11-05 17:32 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4ba17e992008 8141543: Propagate --disable-warnings-as-errors to hotspot Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in Changeset: c26f2d9906cd Author: lana Date: 2015-11-05 13:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c26f2d9906cd Merge Changeset: 106c06398f7a Author: erikj Date: 2015-11-05 23:25 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/106c06398f7a 8141574: recent change for 8141543 breaks all builds Reviewed-by: darcy ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 0f0a47b76da7 Author: lana Date: 2015-11-12 10:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0f0a47b76da7 Added tag jdk9-b92 for changeset 106c06398f7a ! .hgtags Changeset: 0c780a08f739 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0c780a08f739 Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/compare.sh - make/CheckModules.gmk ! make/CompileJavaModules.gmk ! make/Images.gmk ! make/JrtfsJar.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/common/JarArchive.gmk ! make/common/JavaCompilation.gmk ! make/jprt.properties - modules.xml ! test/lib/sun/hotspot/WhiteBox.java ! test/make/TestJavaCompilation.gmk From mandy.chung at oracle.com Sat Nov 14 04:22:25 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:22:25 +0000 Subject: hg: jigsaw/jake/hotspot: 226 new changesets Message-ID: <201511140422.tAE4MRY9029781@aojmv0008.oracle.com> Changeset: bc48b669bc66 Author: lana Date: 2015-10-19 00:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc48b669bc66 Added tag jdk9-b87 for changeset d7ffd16382fe ! .hgtags Changeset: b0e0a53226fd Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0e0a53226fd Added tag jdk9-b88 for changeset bc48b669bc66 ! .hgtags Changeset: e1517978bf12 Author: enevill Date: 2015-09-15 12:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e1517978bf12 8136524: aarch64: test/compiler/runtime/7196199/Test7196199.java fails Summary: Fix safepoint handlers to save 128 bits on vector poll Reviewed-by: kvn Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: 43451068d53c Author: roland Date: 2015-09-15 13:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43451068d53c 8136461: PhaseIdealLoop::try_move_store_before_loop() may bypass early loop exit Summary: PhaseIdealLoop::try_move_store_before_loop() needs to check for early loop exit before candidate Stores Reviewed-by: kvn ! src/share/vm/opto/loopopts.cpp - test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java + test/compiler/loopopts/TestMoveStoresOutOfLoopsStoreNoCtrl.java Changeset: cc267038a9c1 Author: kvn Date: 2015-09-15 11:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc267038a9c1 8136406: Remove ZapDeadCompiledLocals code Summary: Dead code elimination. Reviewed-by: roland, twisti ! agent/src/share/classes/sun/jvm/hotspot/compiler/ImmutableOopMapSet.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 65c21ccab1bd Author: kvn Date: 2015-09-16 20:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/65c21ccab1bd Merge Changeset: 10e79692c25e Author: mcberg Date: 2015-09-16 13:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/10e79692c25e 8134802: LCM register pressure scheduling Summary: Calculate register pressure in a block to help instructions scheduling. Reviewed-by: kvn, dlong ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/c2_globals_aarch64.hpp ! src/cpu/ppc/vm/c2_globals_ppc.hpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/c2_globals_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/live.hpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/node.hpp Changeset: a60e232aa8f2 Author: kvn Date: 2015-09-16 15:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a60e232aa8f2 8134553: CRC32C implementations for x86/x64 targets Reviewed-by: kvn Contributed-by: tomasz.wojtowicz at intel.com ! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp ! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp + src/cpu/x86/vm/crc32c.h ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6d9d273e7f0d Author: thartmann Date: 2015-09-17 08:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6d9d273e7f0d 8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts Summary: Bail out of superword optimization if loop was removed (i.e., if zero-trip Opaque1Node was removed). Reviewed-by: kvn, roland ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/superword.cpp Changeset: 476739c20b35 Author: iveresov Date: 2015-09-17 13:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/476739c20b35 Merge Changeset: e3201914b83b Author: neliasso Date: 2015-09-18 10:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3201914b83b 8135068: Extract method matchers from CompilerOracle Summary: Ecapsulate code to enable reuse Reviewed-by: roland, kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp + src/share/vm/compiler/methodMatcher.cpp + src/share/vm/compiler/methodMatcher.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! test/compiler/c2/5091921/Test7005594.sh ! test/compiler/oracle/CheckCompileCommandOption.java + test/compiler/oracle/MethodMatcherTest.java ! test/compiler/oracle/TestCompileCommand.java ! test/compiler/oracle/command1.txt ! test/runtime/CommandLine/CompilerConfigFileWarning.java Changeset: 17efe8fc4f48 Author: mdoerr Date: 2015-09-17 09:03 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17efe8fc4f48 8136525: Generate interpreter entries only once and avoid unnecessary jump to jump Reviewed-by: coleenp, twisti, aph ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.hpp ! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp ! src/cpu/aarch64/vm/interpreter_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/interpreterGenerator_ppc.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp Changeset: 3ac528612681 Author: coleenp Date: 2015-09-18 16:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3ac528612681 Merge Changeset: 3b908f10337f Author: tpivovarova Date: 2015-09-19 12:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3b908f10337f 8136693: add package statement 'compiler.testlibrary' to CompilerUtils Reviewed-by: iignatyev ! test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java ! test/compiler/testlibrary/CompilerUtils.java Changeset: d61e3154b6e0 Author: dpochepk Date: 2015-09-19 12:04 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d61e3154b6e0 8136718: [TESTBUG] introduce FileInstaller functionality Reviewed-by: iignatyev + test/testlibrary/jdk/test/lib/FileInstaller.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: bab9d3d37ae8 Author: iignatyev Date: 2015-09-19 11:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bab9d3d37ae8 Merge Changeset: 95e96bd4b70b Author: adinn Date: 2015-09-16 09:52 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/95e96bd4b70b 8080293: AARCH64: Remove unnecessary dmbs from generated CAS code Summary: The current encoding for CAS generates unnecessary leading and trailing dmbs for the MemBarAcquire and MemBarRelease which ought to be elided Reviewed-by: kvn ! src/cpu/aarch64/vm/aarch64.ad Changeset: 66d90f141fd8 Author: zmajo Date: 2015-09-22 13:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/66d90f141fd8 8136914: compiler/loopopts/superword/SumRedSqrt_Double.java times out Summary: Change test to execute only on relevant (x86-based) platforms. Reviewed-by: kvn, dlong ! test/compiler/loopopts/superword/SumRedSqrt_Double.java Changeset: 6cc606e29b74 Author: roland Date: 2015-09-21 10:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6cc606e29b74 8136596: Remove aarch64: MemBarRelease when final field's allocation is NoEscape or ArgEscape Summary: elide MemBar when AllocateNode _is_non_escaping Reviewed-by: kvn, roland Contributed-by: hui.shi at linaro.org ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp Changeset: 7c288547a709 Author: roland Date: 2015-09-22 15:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7c288547a709 8136926: phi == NULL assert in PhaseIdealLoop::try_move_store_after_loop Summary: multiple phis on same slice are possible in a loop Reviewed-by: kvn, mcberg ! src/share/vm/opto/loopopts.cpp ! test/compiler/loopopts/TestMoveStoresOutOfLoops.java Changeset: db3a3feccd9b Author: enevill Date: 2015-09-16 13:50 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db3a3feccd9b 8136615: aarch64: elide DecodeN when followed by CmpP 0 Summary: remove DecodeN when comparing a narrow oop with 0 Reviewed-by: kvn, adinn ! src/cpu/aarch64/vm/aarch64.ad Changeset: 56024013648f Author: kzhaldyb Date: 2015-09-24 18:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/56024013648f 8137020: [TESTBUG] Utils.runAndCheckException doesn't work well if no exception thrown Summary: Changed handling a case when expected exception wasn't thrown Reviewed-by: iignatyev ! test/testlibrary/jdk/test/lib/Utils.java Changeset: 0855eb2338ae Author: ppunegov Date: 2015-09-24 20:13 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0855eb2338ae 8066157: JEP-JDK-8046155: Test task: method matcher Summary: MethodMatcher test and framework Reviewed-by: iignatyev, neliasso + test/compiler/compilercontrol/matcher/MethodMatcherTest.java + test/compiler/compilercontrol/share/method/ClassType.java + test/compiler/compilercontrol/share/method/MethodDescriptor.java + test/compiler/compilercontrol/share/method/MethodElementType.java + test/compiler/compilercontrol/share/method/MethodGenerator.java + test/compiler/compilercontrol/share/method/MethodType.java + test/compiler/compilercontrol/share/method/SignatureType.java + test/compiler/compilercontrol/share/pool/MethodHolder.java + test/compiler/compilercontrol/share/pool/PoolHelper.java + test/compiler/compilercontrol/share/pool/sub/Klass.java + test/compiler/compilercontrol/share/pool/sub/KlassDup.java + test/compiler/compilercontrol/share/pool/subpack/Klass.java + test/compiler/compilercontrol/share/pool/subpack/KlassDup.java + test/testlibrary/jdk/test/lib/Pair.java + test/testlibrary/jdk/test/lib/Triple.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: df910cc4b9ea Author: roland Date: 2015-09-17 16:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/df910cc4b9ea 8136820: Generate better code for some Unsafe addressing patterns Summary: reshape address computation to move invariant part out of loops Reviewed-by: kvn ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/superword.cpp Changeset: 8096c5205545 Author: iveresov Date: 2015-09-25 12:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8096c5205545 Merge ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/gc/logging/TestPrintReferences.java - test/gc/startup_warnings/TestDefaultMaxRAMFraction.java - test/gc/startup_warnings/TestNoParNew.java Changeset: 5ee8eccf7900 Author: aph Date: 2015-09-28 16:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ee8eccf7900 8136165: AARCH64: Tidy up compiled native calls Summary: Do some cleaning Reviewed-by: roland, kvn, enevill ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: fa430fa4f577 Author: enevill Date: 2015-09-23 12:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fa430fa4f577 8135231: aarch64: add support for vectorizing double precision sqrt Reviewed-by: roland, aph ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! test/compiler/loopopts/superword/SumRedSqrt_Double.java Changeset: f244d455e4dd Author: amurillo Date: 2015-10-01 11:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f244d455e4dd Merge - test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java Changeset: 5ab466809f05 Author: iveresov Date: 2015-10-08 09:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ab466809f05 8139094: Tier1 test java/util/zip/TestCRC32C.java fails due to fixes for JDK-8134553 Summary: Match correct intrinsic kind Reviewed-by: iveresov, kvn Contributed-by: tomasz.wojtowicz at intel.com ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp Changeset: daf8acf3afda Author: enevill Date: 2015-09-30 04:35 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/daf8acf3afda 8138583: aarch64: add support for vectorizing fabs/fneg Reviewed-by: aph, roland Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/loopopts/superword/SumRedAbsNeg_Double.java + test/compiler/loopopts/superword/SumRedAbsNeg_Float.java Changeset: 324ea1a2419a Author: iveresov Date: 2015-10-05 20:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/324ea1a2419a 8132207: update for x86 exp in the math lib Summary: Add new java.lang.Math() intrinsics from x86 Reviewed-by: kvn, iveresov Contributed-by: vivek.r.deshpande at intel.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + src/cpu/x86/vm/macroAssembler_x86_libm.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 30f10e51ad6f Author: adinn Date: 2015-10-07 06:56 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/30f10e51ad6f 8139042: AARCH64: Correct regression introduced by 8080293 Summary: Reinstate unsafe volatile optimization broken by JDK-8080293 Reviewed-by: aph, kvn ! src/cpu/aarch64/vm/aarch64.ad Changeset: 017224c13b0e Author: dlong Date: 2015-10-08 19:16 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/017224c13b0e Merge Changeset: f01629221703 Author: amurillo Date: 2015-10-08 14:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f01629221703 Merge - test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java Changeset: eca671f4c014 Author: ecaspole Date: 2015-09-21 10:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eca671f4c014 8131645: [ARM64] crash on Cavium when using G1 Summary: Add a fence when creating the CodeRootSetTable so the readers do not see invalid memory. Reviewed-by: aph, tschatzl ! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp Changeset: c55ee4af240d Author: ctornqvi Date: 2015-09-23 05:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c55ee4af240d 8027565: Enable /d2Zi+ when building with Visual Studio 2013 Reviewed-by: dcubed, ihse ! make/windows/makefiles/compile.make Changeset: 1ce8347eea86 Author: ddmitriev Date: 2015-09-23 22:04 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1ce8347eea86 8073331: [TESTBUG] Test for VM option file feature (VM options specified in file) Reviewed-by: dcubed, gtriantafill, rdurbin + test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java + test/runtime/CommandLine/VMOptionsFile/flags_file + test/runtime/CommandLine/VMOptionsFile/optionFILE_2 + test/runtime/CommandLine/VMOptionsFile/optionfile_1 + test/runtime/CommandLine/VMOptionsFile/optionfile_3 + test/runtime/CommandLine/VMOptionsFile/optionfile_bad_option + test/runtime/CommandLine/VMOptionsFile/optionfile_long_property + test/runtime/CommandLine/VMOptionsFile/optionfile_lot_of_options_quote + test/runtime/CommandLine/VMOptionsFile/optionfile_only_tabsandspaces + test/runtime/CommandLine/VMOptionsFile/optionfile_quote + test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size + test/runtime/CommandLine/VMOptionsFile/optionfile_unmatched_quote_1 + test/runtime/CommandLine/VMOptionsFile/optionfile_unmatched_quote_2 + test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property Changeset: 91c907c47794 Author: aph Date: 2015-09-24 12:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/91c907c47794 8135018: AARCH64: Missing memory barriers for CMS collector Summary: Add StoreStore barrier when CMS needs them Reviewed-by: tschatzl ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: f99ad7bb5df5 Author: mlarsson Date: 2015-09-24 12:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f99ad7bb5df5 8046148: JEP 158: Unified JVM Logging Reviewed-by: coleenp, sla ! make/windows/makefiles/vm.make ! src/share/vm/Xusage.txt + src/share/vm/logging/log.hpp + src/share/vm/logging/logConfiguration.cpp + src/share/vm/logging/logConfiguration.hpp + src/share/vm/logging/logDecorations.cpp + src/share/vm/logging/logDecorations.hpp + src/share/vm/logging/logDecorators.cpp + src/share/vm/logging/logDecorators.hpp + src/share/vm/logging/logDiagnosticCommand.cpp + src/share/vm/logging/logDiagnosticCommand.hpp + src/share/vm/logging/logFileOutput.cpp + src/share/vm/logging/logFileOutput.hpp + src/share/vm/logging/logFileStreamOutput.cpp + src/share/vm/logging/logFileStreamOutput.hpp + src/share/vm/logging/logLevel.cpp + src/share/vm/logging/logLevel.hpp + src/share/vm/logging/logOutput.cpp + src/share/vm/logging/logOutput.hpp + src/share/vm/logging/logOutputList.cpp + src/share/vm/logging/logOutputList.hpp + src/share/vm/logging/logPrefix.hpp + src/share/vm/logging/logTag.cpp + src/share/vm/logging/logTag.hpp + src/share/vm/logging/logTagLevelExpression.cpp + src/share/vm/logging/logTagLevelExpression.hpp + src/share/vm/logging/logTagSet.cpp + src/share/vm/logging/logTagSet.hpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/nmtCommon.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/serviceability/logging/TestBasicLogOutput.java Changeset: 1f6500dbefcb Author: mlarsson Date: 2015-09-24 16:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f6500dbefcb Merge Changeset: 83b9a8e8593d Author: mockner Date: 2015-09-24 11:26 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83b9a8e8593d 8130681: Kitchensink startup crashes JVM with NMT overlapping ranges Summary: add_committed_region now handles overlapping commits. Reviewed-by: hseigel, coleenp ! src/share/vm/services/virtualMemoryTracker.cpp + test/runtime/NMT/CommitOverlappingRegions.java Changeset: f1e0206e75e1 Author: dsamersoff Date: 2015-09-24 20:39 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f1e0206e75e1 8086134: Deadlock detection fails to attach to core file Summary: Test reimplemented for jtreg Reviewed-by: jbachorik + test/serviceability/sa/DeadlockDetectionTest.java Changeset: 4ed0a395857b Author: dsamersoff Date: 2015-09-25 10:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4ed0a395857b Merge Changeset: d4dec7270392 Author: kzhaldyb Date: 2015-09-24 18:48 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d4dec7270392 8136398: Create test that checks that G1 MixedGC produces correct output to logfile Summary: Added test that checks that G1 MixedGC produces correct output to logfile Reviewed-by: tschatzl + test/gc/g1/mixedgc/TestLogging.java Changeset: a4ae74ca2403 Author: brutisso Date: 2015-09-28 09:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a4ae74ca2403 8136991: [REDO] Additional number of processed references printed with -XX:+PrintReferenceGC after JDK-8047125 Reviewed-by: kbarrett, tschatzl ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/shared/gcTraceTime.cpp ! src/share/vm/gc/shared/gcTraceTime.hpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/referenceProcessor.hpp + test/gc/logging/TestPrintReferences.java Changeset: 142f04931a09 Author: jwilhelm Date: 2015-09-28 15:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/142f04931a09 Merge Changeset: dc9930a04ab0 Author: david Date: 2015-09-29 11:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dc9930a04ab0 8080775: Better argument formatting for assert() and friends Reviewed-by: kbarrett, pliden ! make/linux/makefiles/gcc.make ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/methodHandles_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/methodHandles_ppc.cpp ! src/cpu/ppc/vm/nativeInst_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/os/aix/vm/os_aix.cpp ! src/os/aix/vm/vmError_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/vmError_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/vmError_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/vmError_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/vmError_windows.cpp ! src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp ! src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/altHashing.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc/cms/adaptiveFreeList.cpp ! src/share/vm/gc/cms/allocationStats.hpp ! src/share/vm/gc/cms/compactibleFreeListSpace.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc/cms/parCardTableModRefBS.cpp ! src/share/vm/gc/cms/promotionInfo.hpp ! src/share/vm/gc/g1/bufferingOopClosure.cpp ! src/share/vm/gc/g1/collectionSetChooser.cpp ! src/share/vm/gc/g1/collectionSetChooser.hpp ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/concurrentMark.inline.hpp ! src/share/vm/gc/g1/g1AllocRegion.cpp ! src/share/vm/gc/g1/g1AllocRegion.hpp ! src/share/vm/gc/g1/g1AllocRegion.inline.hpp ! src/share/vm/gc/g1/g1Allocator.cpp ! src/share/vm/gc/g1/g1Allocator.hpp ! src/share/vm/gc/g1/g1Allocator.inline.hpp ! src/share/vm/gc/g1/g1BiasedArray.cpp ! src/share/vm/gc/g1/g1BiasedArray.hpp ! src/share/vm/gc/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/gc/g1/g1CardCounts.cpp ! src/share/vm/gc/g1/g1CardCounts.hpp ! src/share/vm/gc/g1/g1CodeCacheRemSet.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1EvacFailure.cpp ! src/share/vm/gc/g1/g1EvacStats.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1HotCardCache.cpp ! src/share/vm/gc/g1/g1InCSetState.hpp ! src/share/vm/gc/g1/g1OopClosures.cpp ! src/share/vm/gc/g1/g1PageBasedVirtualSpace.cpp ! src/share/vm/gc/g1/g1ParScanThreadState.cpp ! src/share/vm/gc/g1/g1ParScanThreadState.hpp ! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp ! src/share/vm/gc/g1/g1RegionToSpaceMapper.cpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/gc/g1/heapRegion.cpp ! src/share/vm/gc/g1/heapRegion.hpp ! src/share/vm/gc/g1/heapRegion.inline.hpp ! src/share/vm/gc/g1/heapRegionManager.cpp ! src/share/vm/gc/g1/heapRegionManager.inline.hpp ! src/share/vm/gc/g1/heapRegionRemSet.cpp ! src/share/vm/gc/g1/heapRegionSet.cpp ! src/share/vm/gc/g1/heapRegionSet.inline.hpp ! src/share/vm/gc/g1/heapRegionType.hpp ! src/share/vm/gc/g1/satbQueue.cpp ! src/share/vm/gc/g1/vm_operations_g1.cpp ! src/share/vm/gc/parallel/cardTableExtension.cpp ! src/share/vm/gc/parallel/gcTaskManager.cpp ! src/share/vm/gc/parallel/mutableNUMASpace.cpp ! src/share/vm/gc/parallel/objectStartArray.cpp ! src/share/vm/gc/parallel/objectStartArray.hpp ! src/share/vm/gc/parallel/parMarkBitMap.hpp ! src/share/vm/gc/parallel/parallelScavengeHeap.inline.hpp ! src/share/vm/gc/parallel/pcTasks.cpp ! src/share/vm/gc/parallel/psOldGen.hpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/tenuredGeneration.cpp ! src/share/vm/gc/shared/ageTable.cpp ! src/share/vm/gc/shared/blockOffsetTable.cpp ! src/share/vm/gc/shared/cardTableModRefBS.hpp ! src/share/vm/gc/shared/cardTableRS.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/collectedHeap.inline.hpp ! src/share/vm/gc/shared/collectorPolicy.cpp ! src/share/vm/gc/shared/gcCause.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/plab.cpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/space.cpp ! src/share/vm/gc/shared/taskqueue.cpp ! src/share/vm/gc/shared/workgroup.cpp ! src/share/vm/gc/shared/workgroup.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/logging/logConfiguration.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/iterator.inline.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspaceGCThresholdUpdater.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/memory/virtualspace.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/castnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/chunkedList.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/fakeRttiSupport.hpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 143fe39b8533 Author: brutisso Date: 2015-09-29 17:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/143fe39b8533 8133706: Kitchensink hanged Reviewed-by: pliden, jmasa ! src/share/vm/gc/g1/concurrentMarkThread.cpp Changeset: 983c56341c80 Author: brutisso Date: 2015-09-30 09:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/983c56341c80 8134953: Make the GC ID available in a central place Reviewed-by: pliden, jmasa ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/concurrentMarkSweepThread.cpp ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/cms/vmCMSOperations.cpp ! src/share/vm/gc/cms/vmCMSOperations.hpp ! src/share/vm/gc/cms/yieldingWorkgroup.cpp ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/concurrentMark.hpp ! src/share/vm/gc/g1/concurrentMarkThread.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1MMUTracker.cpp ! src/share/vm/gc/g1/g1MMUTracker.hpp ! src/share/vm/gc/g1/g1MarkSweep.cpp ! src/share/vm/gc/g1/vm_operations_g1.cpp ! src/share/vm/gc/g1/vm_operations_g1.hpp ! src/share/vm/gc/parallel/pcTasks.cpp ! src/share/vm/gc/parallel/psMarkSweep.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/gcId.cpp ! src/share/vm/gc/shared/gcId.hpp ! src/share/vm/gc/shared/gcTrace.cpp ! src/share/vm/gc/shared/gcTrace.hpp ! src/share/vm/gc/shared/gcTraceSend.cpp ! src/share/vm/gc/shared/gcTraceTime.cpp ! src/share/vm/gc/shared/gcTraceTime.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/objectCountEventSender.cpp ! src/share/vm/gc/shared/objectCountEventSender.hpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/referenceProcessor.hpp ! src/share/vm/gc/shared/workgroup.cpp ! src/share/vm/gc/shared/workgroup.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 59e6f265dd40 Author: aharlap Date: 2015-09-30 18:09 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/59e6f265dd40 8130265: gctests/LargeObjects/large001 fails with OutOfMemoryError: Java heap space Summary: Avoided G1 OutOfMemoryError by adding extra expand heap call Reviewed-by: jwilhelm, tschatzl ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp Changeset: 43a1e4ca7ee4 Author: hseigel Date: 2015-10-01 15:14 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/43a1e4ca7ee4 8138574: [TESTBUG] TestBasicLogOutput.java doesn't account for padding Summary: TestBasicLogOutput.java edited to account for padding in tag descriptors Reviewed-by: ddmitriev, hseigel, coleenp Contributed-by: rachel.protacio at oracle.com ! test/serviceability/logging/TestBasicLogOutput.java Changeset: 38bd261644c0 Author: erikj Date: 2015-10-02 10:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/38bd261644c0 8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx Reviewed-by: ihse, mikael ! make/bsd/makefiles/jsig.make Changeset: b04892bbefa5 Author: david Date: 2015-10-02 10:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b04892bbefa5 8138637: Remove err_msg from LOG_PREFIX macro Reviewed-by: brutisso ! src/share/vm/logging/logPrefix.hpp Changeset: c0b0699bf991 Author: david Date: 2015-10-02 11:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c0b0699bf991 Merge Changeset: 12a66b77145e Author: dcubed Date: 2015-10-01 13:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/12a66b77145e 8135195: VM Options file should not be limited to 1k in bytes Summary: Change Arguments::parse_vm_options_file() to remove 1024 byte limit on the VM options file. Reviewed-by: dcubed, hseigel, gthornbr, dsamersoff, ddmitriev, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 6020dab5cdcb Author: dcubed Date: 2015-10-01 13:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6020dab5cdcb 8137105: [TESTBUG] Add test cases for VM Options file feature with removed file size limit Summary: Update TestVMOptionsFile.java to match fix for 8135195; other minor cleanups. Reviewed-by: dcubed, rdurbin ! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java ! test/runtime/CommandLine/VMOptionsFile/optionfile_1 - test/runtime/CommandLine/VMOptionsFile/optionfile_long_property ! test/runtime/CommandLine/VMOptionsFile/optionfile_lot_of_options_quote ! test/runtime/CommandLine/VMOptionsFile/optionfile_quote - test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size - test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property Changeset: da0795953c69 Author: dcubed Date: 2015-10-02 11:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/da0795953c69 Merge Changeset: ccf99d847b02 Author: dcubed Date: 2015-10-02 12:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccf99d847b02 Merge - test/runtime/CommandLine/VMOptionsFile/optionfile_long_property - test/runtime/CommandLine/VMOptionsFile/optionfile_quote_max_size - test/runtime/CommandLine/VMOptionsFile/optionfile_very_long_property Changeset: f5379b29c4d7 Author: ctornqvi Date: 2015-10-02 06:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5379b29c4d7 8137194: Exclude runtime/memory/RunUnitTestsConcurrently.java from JPRT Reviewed-by: coleenp ! test/TEST.groups Changeset: 0952227d9cfe Author: ddmitriev Date: 2015-10-02 09:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0952227d9cfe 8138769: [TESTBUG] restore lost line from JDK-8137105 fix Reviewed-by: dcubed, rdurbin ! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java Changeset: 4edb0704e9f3 Author: dcubed Date: 2015-10-02 16:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4edb0704e9f3 Merge Changeset: d9d44c9d7bf0 Author: goetz Date: 2015-09-28 12:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9d44c9d7bf0 8137260: fix warning after "8046148: JEP 158: Unified JVM Logging" Reviewed-by: mlarsson, stuefe ! src/share/vm/logging/logFileOutput.cpp Changeset: 786145ca3cdc Author: iklam Date: 2015-10-05 13:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/786145ca3cdc 8078295: hotspot test_env.sh can set VM_CPU incorrectly Summary: Use sed script to filter out irrelevant parts of -Xinternalversion Reviewed-by: dlong, dcubed, dsamersoff ! test/test_env.sh Changeset: f6da147987bb Author: kbarrett Date: 2015-10-05 21:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f6da147987bb 8138833: Remove CMMarkStack::drain Summary: Remove unused functions and data members. Reviewed-by: pliden, brutisso ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/concurrentMark.hpp Changeset: 231ab9f9a824 Author: pliden Date: 2015-10-06 08:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/231ab9f9a824 8138846: Remove unused enum ConcurrentGCThread::CGC_flag_type Reviewed-by: jwilhelm, brutisso ! src/share/vm/gc/shared/concurrentGCThread.cpp ! src/share/vm/gc/shared/concurrentGCThread.hpp Changeset: 89c745739292 Author: brutisso Date: 2015-10-06 14:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/89c745739292 8138862: Remove some unused code and subclasses in gcTaskManager.hpp/cpp Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc/parallel/gcTaskManager.cpp ! src/share/vm/gc/parallel/gcTaskManager.hpp Changeset: 4704ecd9e198 Author: brutisso Date: 2015-10-06 14:26 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4704ecd9e198 8138863: Refactor WaitForBarrierGCTask Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc/parallel/gcTaskManager.cpp ! src/share/vm/gc/parallel/gcTaskManager.hpp Changeset: 17cfe2c6dc00 Author: brutisso Date: 2015-10-06 14:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17cfe2c6dc00 8138707: TestPromotionEventWithParallelScavenge.java crashes using undefined GC id. Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc/parallel/gcTaskManager.cpp ! src/share/vm/gc/parallel/gcTaskManager.hpp ! src/share/vm/gc/parallel/gcTaskThread.cpp Changeset: f10efc097bae Author: mockner Date: 2015-10-06 14:27 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f10efc097bae 8138917: Back out change for 8130681 Summary: Change 8130681 has been backed out. Reviewed-by: coleenp, gtriantafill ! src/share/vm/services/virtualMemoryTracker.cpp - test/runtime/NMT/CommitOverlappingRegions.java Changeset: a6499084ccd4 Author: coleenp Date: 2015-10-06 18:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a6499084ccd4 Merge Changeset: 00e5743fd189 Author: jwilhelm Date: 2015-10-07 01:03 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/00e5743fd189 Merge ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/runtime/frame.cpp Changeset: 5f9da6c532fe Author: ehelin Date: 2015-10-07 15:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5f9da6c532fe 8138969: G1CollectorPolicy should use const for applicable methods Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1CollectorState.hpp ! src/share/vm/gc/g1/g1MMUTracker.hpp Changeset: 4d9b98fd9644 Author: david Date: 2015-10-07 15:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4d9b98fd9644 8138832: CreateCoredumpOnCrash on linux ARM causes assert message to be repeated. Reviewed-by: jwilhelm, mgerdin ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: c9d09b5085ea Author: david Date: 2015-10-07 14:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c9d09b5085ea Merge Changeset: 313e94244ed8 Author: ehelin Date: 2015-10-07 17:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/313e94244ed8 8138971: G1CollectorPolicy::_rs_lengths_prediction is not initialized before use Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc/g1/g1CollectorPolicy.cpp Changeset: 81ae0334f957 Author: ehelin Date: 2015-10-07 17:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/81ae0334f957 Merge Changeset: ee11c7701f8c Author: gtriantafill Date: 2015-10-07 11:37 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ee11c7701f8c 8134432: [TESTBUG] Rewrite test/runtime/6888954/vmerrors.sh in Java Reviewed-by: ddmitriev, ctornqvi, coleenp ! src/share/vm/utilities/debug.cpp ! test/TEST.groups - test/runtime/6888954/vmerrors.sh + test/runtime/ErrorHandling/ErrorHandler.java Changeset: 4740e6551edf Author: ctornqvi Date: 2015-10-07 20:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4740e6551edf Merge - test/runtime/6888954/vmerrors.sh Changeset: 01c086e6e523 Author: stuefe Date: 2015-10-01 09:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/01c086e6e523 8137329: [windows] Build broken on VS2010 after "8046148: JEP 158: Unified JVM Logging" Reviewed-by: simonis, ihse, prr, goetz, dcubed ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 332b3d89d2bd Author: dcubed Date: 2015-10-07 16:41 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/332b3d89d2bd Merge Changeset: ad24aa13b296 Author: dcubed Date: 2015-10-07 22:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ad24aa13b296 Merge Changeset: a9a4581814a8 Author: kzhaldyb Date: 2015-10-07 18:02 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a9a4581814a8 8138958: Quarantine gc/g1/mixedgc/TestLogging.java test Reviewed-by: brutisso, iignatyev ! test/gc/g1/mixedgc/TestLogging.java Changeset: e3053e6726f1 Author: iignatyev Date: 2015-10-08 01:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3053e6726f1 Merge Changeset: 17986acb4825 Author: goetz Date: 2015-10-02 11:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/17986acb4825 8138733: Fix build: gcc < 4.8 doesn't grok -Wno-format-zero-length added in 8080775 Summary: Also fix one problematic format on ppc. Reviewed-by: david, simonis ! make/linux/makefiles/gcc.make ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/share/vm/utilities/debug.hpp Changeset: 371ac7d4ccb2 Author: ehelin Date: 2015-10-08 12:47 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/371ac7d4ccb2 8139134: Wrong tenuring threshold in young GC trace event Reviewed-by: ehelin, jwilhelm Contributed-by: Carsten Varming ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/defNewGeneration.cpp Changeset: 5459f44b1a75 Author: sangheki Date: 2015-10-05 14:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5459f44b1a75 8134995: [REDO] GC: implement ranges (optionally constraints) for those flags that have them missing Summary: Add ranges and constraint functions for GC flags. Reviewed-by: kbarrett, jmasa, jwilhelm, gziemski, zmajo ! src/share/vm/gc/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.hpp ! src/share/vm/runtime/commandLineFlagConstraintsGC.cpp ! src/share/vm/runtime/commandLineFlagConstraintsGC.hpp ! src/share/vm/runtime/commandLineFlagRangeList.cpp ! src/share/vm/runtime/globals.hpp + test/gc/arguments/TestG1ConcMarkStepDurationMillis.java ! test/gc/arguments/TestG1HeapRegionSize.java ! test/gc/arguments/TestHeapFreeRatio.java ! test/gc/arguments/TestInitialTenuringThreshold.java ! test/gc/arguments/TestObjectTenuringFlags.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: 4fa9cbb14029 Author: jwilhelm Date: 2015-10-08 22:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4fa9cbb14029 Merge Changeset: e3b180765091 Author: brutisso Date: 2015-10-08 12:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3b180765091 8138717: TestGCEventMixedWithG1ConcurrentMark.java fails Reviewed-by: jwilhelm, david ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/gcId.cpp ! src/share/vm/gc/shared/gcId.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp Changeset: 0cda477a3c85 Author: mgerdin Date: 2015-10-09 09:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0cda477a3c85 8139086: Solaris/Sparc slowdebug build fails for memset_with_concurrent_readers.cpp Reviewed-by: dcubed, kbarrett, coleenp ! src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp Changeset: 115188e14c15 Author: david Date: 2015-10-09 09:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/115188e14c15 8042893: compiler: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files 8042894: runtime: PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC needs to be removed from source files Reviewed-by: goetz, brutisso ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/posix/vm/os_posix.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/pcDesc.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/vtableStubs.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/virtualspace.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/privilegedStack.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/osThread.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/unhandledOops.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/writeableFlags.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/vmError.cpp Changeset: f39faaf2ca61 Author: david Date: 2015-10-09 08:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f39faaf2ca61 Merge Changeset: d6c2fafabfb4 Author: ehelin Date: 2015-10-09 15:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d6c2fafabfb4 8138972: G1CollectorPolicy::_max_survivor_regions should be intialized in the initializer list Reviewed-by: jwilhelm, mgerdin ! src/share/vm/gc/g1/g1CollectorPolicy.cpp Changeset: abd2f07dc9fa Author: kbarrett Date: 2015-10-09 14:08 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/abd2f07dc9fa 8138659: Speed up InstanceKlass subclass discrimination Summary: Add _misc_kind field and flags, move around predicates. Reviewed-by: coleenp, stefank ! src/share/vm/oops/instanceClassLoaderKlass.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 2ecdb2c2d9be Author: brutisso Date: 2015-10-09 20:31 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2ecdb2c2d9be 8139293: TestGCEventMixedWithG1ConcurrentMark.java fails after JDK-8134953 Reviewed-by: ecaspole, jwilhelm ! src/share/vm/gc/g1/concurrentMarkThread.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/shared/gcId.cpp ! src/share/vm/gc/shared/gcId.hpp Changeset: 05b4a6f553fc Author: brutisso Date: 2015-10-09 20:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/05b4a6f553fc 8139294: TestGCEventMixedWithCMSConcurrent.java still fails after JDK-8134953 Reviewed-by: jwilhelm, ecaspole ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.hpp Changeset: dd72902de3dc Author: brutisso Date: 2015-10-09 20:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dd72902de3dc Merge Changeset: 53c5cb9d3fed Author: jwilhelm Date: 2015-10-15 13:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/53c5cb9d3fed Merge ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 263abae1965e Author: thartmann Date: 2015-10-08 08:54 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/263abae1965e 8139048: Quarantine compiler/startup/SmallCodeCacheStartup.java Summary: Quarantine the test because it fails on JPRT for the CPU, CompactStrings and JVMCI repositories. Reviewed-by: roland ! test/compiler/startup/SmallCodeCacheStartup.java Changeset: f4f0e306133e Author: thartmann Date: 2015-10-08 07:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f4f0e306133e Merge Changeset: 09fb2c936faa Author: zmajo Date: 2015-10-08 12:10 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/09fb2c936faa 8137160: Use Compile::live_nodes instead of Compile::unique() in appropriate places -- followup Summary: Change two code locations to use live_nodes() instead of unique() for allocating memory. Adjust comments. Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/matcher.cpp Changeset: 0011fab3f1b5 Author: zmajo Date: 2015-10-08 10:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0011fab3f1b5 Merge Changeset: a41fe5ffa839 Author: twisti Date: 2015-10-08 12:49 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a41fe5ffa839 8136421: JEP 243: Java-Level JVM Compiler Interface Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett ! make/bsd/makefiles/compiler1.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/minimal1.make ! make/excludeSrc.make + make/gensrc/Gensrc-jdk.vm.ci.gmk ! make/linux/makefiles/compiler1.make ! make/linux/makefiles/minimal1.make ! make/solaris/makefiles/compiler1.make ! make/windows/build_vm_def.sh ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make ! src/cpu/aarch64/vm/compiledIC_aarch64.cpp ! src/cpu/aarch64/vm/cppInterpreterGenerator_aarch64.hpp ! src/cpu/aarch64/vm/interpreterGenerator_aarch64.hpp + src/cpu/aarch64/vm/jvmciCodeInstaller_aarch64.cpp ! src/cpu/aarch64/vm/relocInfo_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/ppc/vm/compiledIC_ppc.cpp + src/cpu/ppc/vm/jvmciCodeInstaller_ppc.cpp ! src/cpu/ppc/vm/relocInfo_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/sparc/vm/compiledIC_sparc.cpp ! src/cpu/sparc/vm/cppInterpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp + src/cpu/sparc/vm/jvmciCodeInstaller_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/compiledIC_x86.cpp ! src/cpu/x86/vm/cppInterpreterGenerator_x86.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp + src/cpu/x86/vm/jvmciCodeInstaller_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp + src/cpu/x86/vm/registerMap_x86.cpp ! src/cpu/x86/vm/registerMap_x86.hpp ! src/cpu/x86/vm/register_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86.cpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_64.ad + src/jdk.vm.ci/share/classes/jdk.vm.ci.amd64/src/jdk/vm/ci/amd64/AMD64.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/overview.html + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/AbstractAddress.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Architecture.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BailoutException.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodeFrame.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/BytecodePosition.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CallingConvention.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeCacheProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CodeUtil.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/CompilationResult.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DataSection.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/DebugInfo.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InfopointReason.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InstalledCode.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/InvalidInstalledCodeException.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Location.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/MemoryBarriers.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ReferenceMap.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/Register.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterAttributes.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterConfig.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterSaveLayout.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/RegisterValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/SourceStackTrace.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackLockValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlot.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/StackSlotValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/TargetDescription.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/UnsignedMath.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/ValueUtil.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualObject.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/VirtualStackSlot.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/package-info.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrame.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/InspectedFrameVisitor.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/JVMCIError.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.common/src/jdk/vm/ci/common/UnsafeUtil.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/Compiler.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/CompilerFactory.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.compiler/src/jdk/vm/ci/compiler/StartupEventListener.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotRegisterConfig.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotJVMCIBackendFactory.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot.sparc/src/jdk/vm/ci/hotspot/sparc/SPARCHotSpotRegisterConfig.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCodeCacheProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledCode.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotCompressedNullConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantPool.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotForeignCallTarget.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotInstalledCode.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIBackendFactory.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCICompilerConfig.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIMetaAccessContext.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntimeProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJavaType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaAccessProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaData.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethod.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodData.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodUnresolved.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotNmethod.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotOopMap.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProfilingInfo.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotProxified.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotReferenceMap.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaField.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedPrimitiveType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSentinelConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSignature.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotStackFrameReference.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedField.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotUnresolvedJavaType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfigVerifier.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMEventListener.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVmSymbols.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/MetaspaceWrapperObject.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/Stable.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/SuppressFBWarnings.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/UnsafeAccess.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EmptyEventProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/events/EventProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/logging/package-info.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMAddress.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMData.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMField.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMFlag.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMManual.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspotvmconfig/src/jdk/vm/ci/hotspotvmconfig/HotSpotVMType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.inittimer/src/jdk/vm/ci/inittimer/InitTimer.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.inittimer/src/jdk/vm/ci/inittimer/SuppressFBWarnings.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/overview.html + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AbstractJavaProfile.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AbstractProfiledItem.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/AllocatableValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Assumptions.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Constant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantPool.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ConstantReflectionProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DefaultProfilingInfo.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationAction.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/DeoptimizationReason.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ExceptionHandler.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/InvokeTarget.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JVMCIMetaAccessContext.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaField.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaKind.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethod.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaMethodProfile.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaTypeProfile.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/JavaValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LIRKind.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LineNumberTable.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LineNumberTableImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Local.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTable.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocalVariableTableImpl.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/LocationIdentity.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MemoryAccessProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaAccessProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MethodHandleAccessProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ModifiersProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/NullConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PlatformKind.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/PrimitiveConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ProfilingInfo.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/RawConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaField.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaMethod.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/ResolvedJavaType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SerializableConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Signature.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/SpeculationLog.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/TriState.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/TrustedInterface.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/VMConstant.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/Value.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/package-info.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/META-INF/services/javax.annotation.processing.Processor + src/jdk.vm.ci/share/classes/jdk.vm.ci.options.processor/src/jdk/vm/ci/options/processor/OptionProcessor.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/DerivedOptionValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/JVMCIJarsOptionDescriptorsProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/NestedBooleanOptionValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/Option.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionDescriptor.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionDescriptors.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionType.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsLoader.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/OptionsParser.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.options/src/jdk/vm/ci/options/StableOptionValue.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCI.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIBackend.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.runtime/src/jdk/vm/ci/runtime/JVMCIRuntime.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/META-INF/services/javax.annotation.processing.Processor + src/jdk.vm.ci/share/classes/jdk.vm.ci.service.processor/src/jdk/vm/ci/service/processor/ServiceProviderProcessor.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.service/.checkstyle_checks.xml + src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/ServiceProvider.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.service/src/jdk/vm/ci/service/Services.java + src/jdk.vm.ci/share/classes/jdk.vm.ci.sparc/src/jdk/vm/ci/sparc/SPARC.java + src/os/aix/vm/vmStructs_aix.hpp + src/os/bsd/vm/vmStructs_bsd.hpp + src/os/linux/vm/vmStructs_linux.hpp + src/os/solaris/vm/vmStructs_solaris.hpp ! src/os/windows/vm/os_windows.cpp + src/os/windows/vm/vmStructs_windows.hpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/debugInfoRec.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/dependencies.hpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/exceptionHandlerTable.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/oopRecorder.cpp ! src/share/vm/code/oopRecorder.hpp ! src/share/vm/code/pcDesc.hpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/code/scopeDesc.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileTask.cpp ! src/share/vm/compiler/compileTask.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1MarkSweep.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc/parallel/psMarkSweep.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/barrierSet.hpp ! src/share/vm/gc/shared/cardTableRS.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/collectedHeap.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp + src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.cpp + src/share/vm/jvmci/commandLineFlagConstraintsJVMCI.hpp + src/share/vm/jvmci/jvmciCodeInstaller.cpp + src/share/vm/jvmci/jvmciCodeInstaller.hpp + src/share/vm/jvmci/jvmciCompiler.cpp + src/share/vm/jvmci/jvmciCompiler.hpp + src/share/vm/jvmci/jvmciCompilerToVM.cpp + src/share/vm/jvmci/jvmciCompilerToVM.hpp + src/share/vm/jvmci/jvmciEnv.cpp + src/share/vm/jvmci/jvmciEnv.hpp + src/share/vm/jvmci/jvmciJavaClasses.cpp + src/share/vm/jvmci/jvmciJavaClasses.hpp + src/share/vm/jvmci/jvmciRuntime.cpp + src/share/vm/jvmci/jvmciRuntime.hpp + src/share/vm/jvmci/jvmci_globals.cpp + src/share/vm/jvmci/jvmci_globals.hpp + src/share/vm/jvmci/systemDictionary_jvmci.hpp + src/share/vm/jvmci/vmStructs_jvmci.hpp + src/share/vm/jvmci/vmSymbols_jvmci.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiCodeBlobEvents.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/advancedThresholdPolicy.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.cpp ! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp ! src/share/vm/runtime/commandLineFlagRangeList.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/timer.cpp ! src/share/vm/runtime/timer.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/fakeRttiSupport.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/top.hpp ! src/share/vm/utilities/vmError.cpp + test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java + test/compiler/jvmci/SecurityRestrictionsTest.java + test/compiler/jvmci/common/CTVMUtilities.java + test/compiler/jvmci/common/CompilerToVMHelper.java + test/compiler/jvmci/common/JVMCIHelpers.java + test/compiler/jvmci/common/services/jdk.vm.ci.compiler.Compiler + test/compiler/jvmci/common/services/jdk.vm.ci.compiler.CompilerFactory + test/compiler/jvmci/common/services/jdk.vm.ci.hotspot.HotSpotVMEventListener + test/compiler/jvmci/common/testcases/AbstractClass.java + test/compiler/jvmci/common/testcases/AbstractClassExtender.java + test/compiler/jvmci/common/testcases/AnotherSingleImplementer.java + test/compiler/jvmci/common/testcases/AnotherSingleImplementerInterface.java + test/compiler/jvmci/common/testcases/DoNotExtendClass.java + test/compiler/jvmci/common/testcases/DoNotImplementInterface.java + test/compiler/jvmci/common/testcases/MultiSubclassedClass.java + test/compiler/jvmci/common/testcases/MultiSubclassedClassSubclass1.java + test/compiler/jvmci/common/testcases/MultiSubclassedClassSubclass2.java + test/compiler/jvmci/common/testcases/MultipleAbstractImplementer.java + test/compiler/jvmci/common/testcases/MultipleImplementer1.java + test/compiler/jvmci/common/testcases/MultipleImplementer2.java + test/compiler/jvmci/common/testcases/MultipleImplementersInterface.java + test/compiler/jvmci/common/testcases/MultipleImplementersInterfaceExtender.java + test/compiler/jvmci/common/testcases/PackagePrivateClass.java + test/compiler/jvmci/common/testcases/SimpleClass.java + test/compiler/jvmci/common/testcases/SingleImplementer.java + test/compiler/jvmci/common/testcases/SingleImplementerInterface.java + test/compiler/jvmci/common/testcases/SingleSubclass.java + test/compiler/jvmci/common/testcases/SingleSubclassedClass.java + test/compiler/jvmci/common/testcases/TestCase.java + test/compiler/jvmci/compilerToVM/AllocateCompileIdTest.java + test/compiler/jvmci/compilerToVM/CanInlineMethodTest.java + test/compiler/jvmci/compilerToVM/CollectCountersTest.java + test/compiler/jvmci/compilerToVM/CompileCodeTestCase.java + test/compiler/jvmci/compilerToVM/ConstantPoolTestCase.java + test/compiler/jvmci/compilerToVM/ConstantPoolTestsHelper.java + test/compiler/jvmci/compilerToVM/DebugOutputTest.java + test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java + test/compiler/jvmci/compilerToVM/DoNotInlineOrCompileTest.java + test/compiler/jvmci/compilerToVM/DummyAbstractClass.java + test/compiler/jvmci/compilerToVM/DummyClass.java + test/compiler/jvmci/compilerToVM/DummyInterface.java + test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java + test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java + test/compiler/jvmci/compilerToVM/GetBytecodeTest.java + test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java + test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java + test/compiler/jvmci/compilerToVM/GetExceptionTableTest.java + test/compiler/jvmci/compilerToVM/GetImplementorTest.java + test/compiler/jvmci/compilerToVM/GetLineNumberTableTest.java + test/compiler/jvmci/compilerToVM/GetLocalVariableTableTest.java + test/compiler/jvmci/compilerToVM/GetMaxCallTargetOffsetTest.java + test/compiler/jvmci/compilerToVM/GetNextStackFrameTest.java + test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodAtSlotTest.java + test/compiler/jvmci/compilerToVM/GetResolvedJavaMethodTest.java + test/compiler/jvmci/compilerToVM/GetResolvedJavaTypeTest.java + test/compiler/jvmci/compilerToVM/GetStackTraceElementTest.java + test/compiler/jvmci/compilerToVM/GetSymbolTest.java + test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java + test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java + test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java + test/compiler/jvmci/compilerToVM/InitializeConfigurationTest.java + test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java + test/compiler/jvmci/compilerToVM/IsMatureTest.java + test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java + test/compiler/jvmci/compilerToVM/LookupKlassInPoolTest.java + test/compiler/jvmci/compilerToVM/LookupTypeTest.java + test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java + test/compiler/jvmci/compilerToVM/MethodIsIgnoredBySecurityStackWalkTest.java + test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java + test/compiler/jvmci/compilerToVM/ReprofileTest.java + test/compiler/jvmci/compilerToVM/ResolveConstantInPoolTest.java + test/compiler/jvmci/compilerToVM/ResolveMethodTest.java + test/compiler/jvmci/compilerToVM/ResolveTypeInPoolTest.java + test/compiler/jvmci/compilerToVM/ShouldDebugNonSafepointsTest.java + test/compiler/jvmci/compilerToVM/ShouldInlineMethodTest.java + test/compiler/jvmci/events/JvmciCompleteInitializationTest.config + test/compiler/jvmci/events/JvmciCompleteInitializationTest.java + test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.config + test/compiler/jvmci/events/JvmciCreateMetaAccessContextTest.java + test/compiler/jvmci/events/JvmciNotifyInstallEventTest.config + test/compiler/jvmci/events/JvmciNotifyInstallEventTest.java + test/compiler/jvmci/events/JvmciShutdownEventListener.java + test/compiler/jvmci/events/JvmciShutdownEventTest.config + test/compiler/jvmci/events/JvmciShutdownEventTest.java + test/compiler/jvmci/events/MetaAccessWrapper.java + test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/NestedBooleanOptionValueTest.java + test/compiler/jvmci/jdk.vm.ci.options.test/src/jdk/vm/ci/options/test/TestOptionValue.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ConstantTest.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/FieldUniverse.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/MethodUniverse.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/NameAndSignature.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/RedefineClassTest.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveConcreteMethodTest.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/ResolvedJavaTypeResolveMethodTest.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestConstantReflectionProvider.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaField.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaMethod.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestJavaType.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaMethod.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaType.java + test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TypeUniverse.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: 13c4fa17712e Author: dlong Date: 2015-10-09 02:43 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/13c4fa17712e Merge ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp Changeset: 926d9bae67d3 Author: thartmann Date: 2015-10-09 11:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/926d9bae67d3 8139150: ClassVerifier frees exception message while it's still in use Summary: Remove ResourceMark in StackMapReader::parse_verification_type() to avoid freeing of error message. Reviewed-by: zmajo, dcubed, hseigel ! src/share/vm/classfile/stackMapTable.cpp Changeset: 0300297e7df3 Author: zmajo Date: 2015-10-09 14:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0300297e7df3 8078554: Compiler: implement ranges (optionally constraints) for those flags that have them missing Summary: Add range check or constraint where necessary. Reviewed-by: roland, thartmann ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/oops/methodCounters.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/runtime/commandLineFlagConstraintsCompiler.cpp ! src/share/vm/runtime/commandLineFlagConstraintsCompiler.hpp ! src/share/vm/runtime/globals.hpp ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java Changeset: 71e75172487b Author: zmajo Date: 2015-10-09 15:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/71e75172487b 8081288: erronous free in RegClass::~RegClass() Summary: Remove the erronous free. Reviewed-by: kvn ! src/share/vm/adlc/formsopt.cpp Changeset: 6c4a9b1af999 Author: twisti Date: 2015-10-09 09:09 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6c4a9b1af999 8138820: JDK Hotspot build fails with Xcode 7.0.1 Reviewed-by: iveresov ! make/bsd/makefiles/gcc.make Changeset: a37a6ca422b1 Author: iveresov Date: 2015-10-09 12:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a37a6ca422b1 8136725: Provide utility for creation a counted loop reserve copy (clone) Summary: Make it easier to revert to the original loop should that be needed Reviewed-by: kvn Contributed-by: jan.civlin at intel.com ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp Changeset: dda16b631985 Author: iveresov Date: 2015-10-09 21:04 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dda16b631985 Merge Changeset: de73f59378c1 Author: redestad Date: 2015-10-12 14:54 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/de73f59378c1 8134607: Remove per-compiler performance counters Reviewed-by: twisti, neliasso ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp Changeset: 1f0d9d89003a Author: iveresov Date: 2015-10-12 16:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1f0d9d89003a 8139454: java/lang/Math/WorstCaseTests.java crashes on Linux-amd64 Summary: Emit the form of pextrw that works with sse2 Reviewed-by: iveresov, twisti Contributed-by: vivek.r.deshpande at intel.com ! src/cpu/x86/vm/assembler_x86.cpp Changeset: c6a1e7983723 Author: mdoerr Date: 2015-10-12 12:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c6a1e7983723 8139421: PPC64LE: MacroAssembler::bxx64_patchable kill register R12 Summary: Register R12 must be preserved for stub calls (e.g. deopt handler). Reviewed-by: goetz ! src/cpu/ppc/vm/macroAssembler_ppc.cpp Changeset: 7477b0afa5d6 Author: zmajo Date: 2015-10-13 10:09 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7477b0afa5d6 8139377: JVM can't be started w/ -XX:+EnableJVMCI -XX:+UseJVMCICompiler and default TypeProfileWidth Summary: Raise upper bound of TypeProfileWidth from 4 to 8. Reviewed-by: iveresov, twisti ! src/share/vm/runtime/globals.hpp Changeset: 738f57684fed Author: enevill Date: 2015-10-13 09:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/738f57684fed 8139259: aarch64: jtreg test TestLogSum segvs after 8132207 Summary: Fix jump to 0 caused by uninitialised _dexp in 8132207 Reviewed-by: roland, kvn ! src/share/vm/opto/library_call.cpp Changeset: f2983a0f7a57 Author: roland Date: 2015-10-13 13:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2983a0f7a57 Merge Changeset: 2598332ad46c Author: aph Date: 2015-09-30 13:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2598332ad46c 8138641: Disable C2 peephole by default for aarch64 Reviewed-by: roland Contributed-by: felix.yang at linaro.org ! src/cpu/aarch64/vm/c2_globals_aarch64.hpp Changeset: 0ca52fb7d980 Author: aph Date: 2015-09-29 17:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0ca52fb7d980 8138575: Improve generated code for profile counters Reviewed-by: kvn ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp Changeset: 870c2e0f67f6 Author: enevill Date: 2015-10-08 13:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/870c2e0f67f6 8139043: aarch64: add support for adler32 intrinsic Summary: Add adler32 support like 8132081 for sparc Reviewed-by: kvn ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp Changeset: c274072ab8f7 Author: twisti Date: 2015-10-13 09:21 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c274072ab8f7 8139524: JVMCI cannot be initialized with CMS or Serial GCs Reviewed-by: iveresov ! src/jdk.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java Changeset: d9eb619390d9 Author: twisti Date: 2015-10-14 09:22 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9eb619390d9 8139545: JVMCI : guarantee(heap_end < allocation_end) failed on some sparcv9 hosts Reviewed-by: iveresov, kvn ! src/share/vm/jvmci/jvmciRuntime.cpp Changeset: 78888d676ed7 Author: twisti Date: 2015-10-14 12:29 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/78888d676ed7 8139386: JVMCI test failed with assert(_jvmci._alternate_call_target == 0L) failed: must be Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp Changeset: baccb954c369 Author: roland Date: 2015-10-15 09:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/baccb954c369 8138956: Elide more final field's write memory barrier with escape analysis result Summary: membar for final/stable fields eliminated if possible Reviewed-by: roland, mdoerr, enevill, aph Contributed-by: hui.shi at linaro.org ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp Changeset: 9ab5571ccea8 Author: roland Date: 2015-10-15 07:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ab5571ccea8 Merge Changeset: db88a5e95717 Author: iignatyev Date: 2015-10-13 16:21 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db88a5e95717 8139376: [TESTBUG] ExecuteInstalledCodeTest should be run only on amd64 and sparcv9 Reviewed-by: twisti, kvn ! test/compiler/jvmci/compilerToVM/ExecuteInstalledCodeTest.java Changeset: ceec25b3f949 Author: tpivovarova Date: 2015-10-15 01:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ceec25b3f949 8139375: [TESTBUG] compiler/jvmci/SecurityRestrictionsTest checks are too tight Reviewed-by: twisti, iignatyev ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: acf9f6650193 Author: dpochepk Date: 2015-10-15 02:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/acf9f6650193 8139438: [TESTBUG] JVMCI test fails with RuntimeException: Has no virtual object before materialization Reviewed-by: iignatyev, twisti ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java Changeset: 964538c2362a Author: iignatyev Date: 2015-10-15 09:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/964538c2362a Merge Changeset: 2abd2feb000b Author: iignatyev Date: 2015-10-15 11:20 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2abd2feb000b Merge Changeset: e9fede3afe79 Author: kshefov Date: 2015-10-15 18:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e9fede3afe79 8072369: [TESTBUG] Remove potentially insecure class cast in some hotspot tests Reviewed-by: twisti, kvn, iignatyev, tpivovarova ! test/compiler/c2/5057225/Test5057225.java ! test/compiler/c2/6603011/Test.java ! test/compiler/c2/6800154/Test6800154.java ! test/compiler/c2/6805724/Test6805724.java ! test/compiler/codegen/6823354/Test6823354.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: cf43bef12125 Author: zmajo Date: 2015-10-15 17:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cf43bef12125 8080650: Enable stubs to use frame pointers correctly Summary: Change MacroAssembler::verified_entry() to set up RBP correctly when generating stub code. Reviewed-by: kvn ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad Changeset: e012dfc7ba2c Author: zmajo Date: 2015-10-15 17:40 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e012dfc7ba2c Merge Changeset: 6bef5a526bee Author: iignatyev Date: 2015-10-16 01:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bef5a526bee 8138794: [TESTBUG] ctw tests fail to compile after 8137056 Reviewed-by: dlong, kvn ! test/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java Changeset: fe46f2941ea9 Author: iignatyev Date: 2015-10-16 02:05 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fe46f2941ea9 8139707: [TESTBUG] Quarantine unstable compiler/jvmci tests Reviewed-by: twisti ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java Changeset: 41b06143f4f8 Author: enevill Date: 2015-10-15 15:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/41b06143f4f8 8139674: aarch64: guarantee failure in TestOptionsWithRanges.java Summary: Fix negative overflow in instruction field Reviewed-by: kvn, roland, adinn, aph ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp Changeset: 93ae449c9b52 Author: aph Date: 2015-10-13 16:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/93ae449c9b52 8139041: Redundant DMB instructions Summary: Merge consecutive DMB intstructions Reviewed-by: roland, kvn, twisti ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/nativeInst_aarch64.hpp ! src/share/vm/asm/codeBuffer.hpp Changeset: 5ffaf14b397d Author: roland Date: 2015-10-16 11:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5ffaf14b397d Merge Changeset: bfd1cd5fbb7c Author: zmajo Date: 2015-10-16 15:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bfd1cd5fbb7c 8139380: VMError::report_and_die() does not produce replay file Summary: Change VMError::report() to use a correct format string in both JVMCI-enabled builds and builds without JVMCI. Reviewed-by: roland, kvn ! src/share/vm/utilities/vmError.cpp Changeset: 09338e9e661c Author: roland Date: 2015-10-16 15:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/09338e9e661c 8139750: [BACKOUT] Elide more final field's write memory barrier with escape analysis result Reviewed-by: kvn ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse3.cpp Changeset: 179aa0067f01 Author: roland Date: 2015-10-16 16:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/179aa0067f01 Merge Changeset: a8a8604f890f Author: dlong Date: 2015-10-17 19:40 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a8a8604f890f Merge ! make/windows/makefiles/vm.make ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/sharedRuntime_ppc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/register_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/exceptionHandlerTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1MarkSweep.cpp ! src/share/vm/gc/parallel/psMarkSweep.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/cardTableRS.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp + src/share/vm/jvmci/jvmciCodeInstaller.cpp + src/share/vm/jvmci/jvmciJavaClasses.cpp + src/share/vm/jvmci/jvmciJavaClasses.hpp + src/share/vm/jvmci/jvmciRuntime.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.cpp ! src/share/vm/runtime/commandLineFlagRangeList.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/fakeRttiSupport.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/vmError.cpp ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: 846276b97202 Author: amurillo Date: 2015-10-19 12:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/846276b97202 Merge - test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java - test/runtime/6888954/vmerrors.sh Changeset: 4be1d228e368 Author: twisti Date: 2015-10-21 11:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4be1d228e368 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes Reviewed-by: erikj ! make/gensrc/Gensrc-jdk.vm.ci.gmk Changeset: e197d5a708f1 Author: lana Date: 2015-10-21 18:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e197d5a708f1 Merge - test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java - test/runtime/6888954/vmerrors.sh Changeset: 1904cb079212 Author: lana Date: 2015-10-22 11:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1904cb079212 Merge - test/compiler/TestMoveStoresOutOfLoopsStoreNoCtrl.java - test/runtime/6888954/vmerrors.sh Changeset: 2bc339eaafcd Author: david Date: 2015-10-13 08:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2bc339eaafcd 8139427: Break out YoungList to own class. Reviewed-by: mgerdin, jwilhelm ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp + src/share/vm/gc/g1/youngList.cpp + src/share/vm/gc/g1/youngList.hpp Changeset: 8b8a3e7af130 Author: tschatzl Date: 2015-10-13 14:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8b8a3e7af130 8069330: Adjustment of concurrent refinement thresholds does not take hot card cache into account Summary: Measure HCC processing time separately and remove that time from the calculation of the refinement thresholds. HCC processing time is still taken into account for general pause time predictions. Reviewed-by: tbenson, jmasa ! src/share/vm/gc/g1/concurrentG1Refine.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1ErgoVerbose.cpp ! src/share/vm/gc/g1/g1ErgoVerbose.hpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc/g1/g1HotCardCache.cpp ! src/share/vm/gc/g1/g1HotCardCache.hpp ! src/share/vm/gc/g1/g1RemSet.cpp ! test/gc/g1/TestGCLogMessages.java Changeset: 3417a8fa7b45 Author: david Date: 2015-10-13 14:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3417a8fa7b45 8139506: Remove the WaterMark class Reviewed-by: stefank, mgerdin ! src/share/vm/gc/g1/heapRegion.hpp ! src/share/vm/gc/shared/generation.hpp ! src/share/vm/gc/shared/space.cpp ! src/share/vm/gc/shared/space.hpp - src/share/vm/gc/shared/watermark.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b7618d69edaf Author: david Date: 2015-10-13 17:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b7618d69edaf Merge - src/share/vm/gc/shared/watermark.hpp Changeset: c8a4fbc7f6f4 Author: hseigel Date: 2015-10-14 13:30 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c8a4fbc7f6f4 8139069: JVM should throw ClassFormatError for methods in interfaces Summary: If method being parsed is in an interface, throw ClassFormatError if its name is "" Reviewed-by: acorn, lfoltan ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp + test/runtime/classFileParserBug/InitInInterface.java + test/runtime/classFileParserBug/nonvoidinit.jasm + test/runtime/classFileParserBug/voidinit.jasm Changeset: 088ca8a0e910 Author: poonam Date: 2015-10-14 15:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/088ca8a0e910 8136577: Make AbortVMOnException available in product builds Reviewed-by: coleenp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: bc00f9701b9c Author: minqi Date: 2015-10-14 08:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bc00f9701b9c 8135284: Remove Method::_method_size field Summary: Remove Method::_method_size to improve memory footprint after JDK-8135085,which increased 4 bytes for 32 platform. Also removed related unused code in SA. Reviewed-by: coleenp, hseigel ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5a7f73370cf8 Author: minqi Date: 2015-10-14 20:59 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5a7f73370cf8 Merge Changeset: 1d78034f1852 Author: minqi Date: 2015-10-15 00:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d78034f1852 Merge Changeset: 8c666050d769 Author: david Date: 2015-10-14 09:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c666050d769 8139434: Unify GenRemSet and CardTableRS Reviewed-by: jwilhelm, mgerdin ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/serial/defNewGeneration.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/serial/tenuredGeneration.cpp ! src/share/vm/gc/serial/tenuredGeneration.hpp ! src/share/vm/gc/shared/cardGeneration.cpp ! src/share/vm/gc/shared/cardGeneration.hpp ! src/share/vm/gc/shared/cardTableRS.cpp ! src/share/vm/gc/shared/cardTableRS.hpp ! src/share/vm/gc/shared/collectorPolicy.cpp ! src/share/vm/gc/shared/collectorPolicy.hpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/gc/shared/genCollectedHeap.hpp ! src/share/vm/gc/shared/genOopClosures.inline.hpp - src/share/vm/gc/shared/genRemSet.cpp - src/share/vm/gc/shared/genRemSet.hpp ! src/share/vm/gc/shared/generation.cpp ! src/share/vm/gc/shared/generation.hpp ! src/share/vm/gc/shared/generationSpec.cpp ! src/share/vm/gc/shared/generationSpec.hpp ! src/share/vm/gc/shared/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5f32f22ba25e Author: mgerdin Date: 2015-10-14 14:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5f32f22ba25e 8138762: Refactor setup of evacuation closures in G1 Summary: Introduce policy class containing the root scan closures. Reviewed-by: ehelin, stefank ! src/share/vm/gc/g1/g1CodeBlobClosure.hpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1OopClosures.cpp ! src/share/vm/gc/g1/g1OopClosures.hpp ! src/share/vm/gc/g1/g1OopClosures.inline.hpp ! src/share/vm/gc/g1/g1ParScanThreadState.cpp ! src/share/vm/gc/g1/g1ParScanThreadState.hpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/gc/g1/g1RemSet.hpp + src/share/vm/gc/g1/g1RootClosures.cpp + src/share/vm/gc/g1/g1RootClosures.hpp ! src/share/vm/gc/g1/g1RootProcessor.cpp ! src/share/vm/gc/g1/g1RootProcessor.hpp Changeset: 5b33eeb13775 Author: tschatzl Date: 2015-10-15 10:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b33eeb13775 8137082: Factor out G1 prediction code from G1CollectorPolicy and clean up Summary: Factor out G1 prediction code from G1CollectorPolicy into its own class, constify methods of G1CollectorPolicy and move more implementations to the cpp file. Reviewed-by: jmasa, sangheki, ecaspole, kbarrett ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.cpp ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1CollectorState.hpp + src/share/vm/gc/g1/g1Predictions.cpp + src/share/vm/gc/g1/g1Predictions.hpp ! src/share/vm/gc/g1/survRateGroup.cpp ! src/share/vm/gc/g1/survRateGroup.hpp ! src/share/vm/prims/jni.cpp Changeset: 2feeca2b688f Author: tschatzl Date: 2015-10-15 10:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2feeca2b688f 8139583: Fix formatting in survRateGroup.cpp Reviewed-by: kbarrett, stefank ! src/share/vm/gc/g1/survRateGroup.cpp Changeset: daa76166601c Author: tschatzl Date: 2015-10-15 10:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/daa76166601c 8138750: Remove dead code in survivor rate group Reviewed-by: mgerdin, tbenson ! src/share/vm/gc/g1/g1CollectorPolicy.hpp ! src/share/vm/gc/g1/g1CollectorState.hpp ! src/share/vm/gc/g1/survRateGroup.cpp ! src/share/vm/gc/g1/survRateGroup.hpp Changeset: a0f7fb36730a Author: tschatzl Date: 2015-10-15 10:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a0f7fb36730a 8138752: G1CollectorPolicy::should_should_update_surv_rate_group_predictors() uses wrong predicate Summary: Instead of only updating the survivor rate groups in the young gc after marking and before mixed gc, update them during young gcs outside of marking Reviewed-by: mgerdin, drwhite ! src/share/vm/gc/g1/g1CollectorPolicy.hpp Changeset: 47181fafd4e9 Author: tschatzl Date: 2015-10-15 13:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/47181fafd4e9 Merge ! src/share/vm/gc/g1/g1CollectorPolicy.cpp Changeset: 901d0ab08236 Author: jbachorik Date: 2015-10-15 17:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/901d0ab08236 8135188: RunFinalizationTest.java Exception java.lang.Error: Test failure: Object was not finalized Reviewed-by: dcubed, martin + test/serviceability/dcmd/gc/FinalizationRunner.java ! test/serviceability/dcmd/gc/RunFinalizationTest.java Changeset: 1a85bb362183 Author: dcubed Date: 2015-10-15 10:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1a85bb362183 8136552: Last argument wins does not work for special options with "-XX:VMOptionsFile" option Summary: match_special_option_and_act() should insert_vm_options_file() earlier and process the inserted options right away to honor "last option wins" semantics. Reviewed-by: dcubed, coleenp ! src/share/vm/runtime/arguments.cpp ! test/runtime/CommandLine/VMOptionsFile/TestVMOptionsFile.java Changeset: cdd81465ef70 Author: dcubed Date: 2015-10-15 19:17 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cdd81465ef70 Merge Changeset: 3f28db271235 Author: gziemski Date: 2015-10-15 13:34 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f28db271235 8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing. Summary: JEP 245: implement ranges and constraints for runtime flags. Reviewed-by: coleenp, ddmitriev, jiangli, goetz Contributed-by: goetz.lindenmaier at sap.com, gerard.ziemski at oracle.com ! src/cpu/aarch64/vm/globals_aarch64.hpp ! src/cpu/ppc/vm/globals_ppc.hpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/aix/vm/globals_aix.hpp ! src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.hpp ! src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp ! src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp ! src/share/vm/runtime/commandLineFlagRangeList.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/vmThread.cpp ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: db268cb78542 Author: coleenp Date: 2015-10-16 00:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/db268cb78542 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 01b171218ecd Author: kbarrett Date: 2015-10-15 10:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/01b171218ecd 8139200: Eliminate G1ParClosureSuper::_worker_id Summary: Moved _worker_id from G1ParClosureSuper to G1ParCopyHelper. Reviewed-by: mgerdin, tschatzl ! src/share/vm/gc/g1/g1OopClosures.cpp ! src/share/vm/gc/g1/g1OopClosures.hpp ! src/share/vm/gc/g1/g1OopClosures.inline.hpp ! src/share/vm/gc/g1/g1ParScanThreadState.cpp ! src/share/vm/gc/g1/g1ParScanThreadState.hpp ! src/share/vm/gc/g1/g1ParScanThreadState.inline.hpp Changeset: 09c316072f18 Author: mdoerr Date: 2015-10-16 10:20 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/09c316072f18 8139734: ppc: fix build after "8078556: Runtime: implement ranges..." Reviewed-by: goetz ! src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp Changeset: a014961e513b Author: kbarrett Date: 2015-10-16 14:55 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a014961e513b 8139341: Hide ExtendedOopClosure::_ref_processor Summary: Make ExtendedOopClosure::_ref_processor private. Reviewed-by: mgerdin, sjohanss ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/g1/concurrentMark.cpp ! src/share/vm/gc/g1/g1OopClosures.hpp ! src/share/vm/gc/serial/markSweep.hpp ! src/share/vm/gc/shared/genOopClosures.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/instanceRefKlass.inline.hpp Changeset: e70a21e29520 Author: david Date: 2015-10-16 14:11 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e70a21e29520 8139277: Remove ScavengeWithObjectsInToSpace, ParallelOldGCSplitALot, ParallelOldGCSplitInterval, PSAdjustTenuredGenForMinorPause and PSAdjustYoungGenForMajorPause Reviewed-by: tschatzl, sjohanss ! src/share/vm/gc/parallel/psAdaptiveSizePolicy.cpp ! src/share/vm/gc/parallel/psAdaptiveSizePolicy.hpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psParallelCompact.hpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ec3193176165 Author: ehelin Date: 2015-10-19 15:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ec3193176165 8135078: Refactor InCSetState::is_in_cset_or_humongous Reviewed-by: tschatzl, jwilhelm ! src/share/vm/gc/g1/g1InCSetState.hpp Changeset: 9b74c5f1b10e Author: brutisso Date: 2015-10-20 14:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9b74c5f1b10e 8139868: CMSScavengeBeforeRemark broken after JDK-8134953 Reviewed-by: sjohanss, jwilhelm ! src/share/vm/gc/shared/gcId.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp + test/gc/cms/TestCMSScavengeBeforeRemark.java Changeset: 29c399fbbf25 Author: jprovino Date: 2015-10-20 11:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/29c399fbbf25 Merge ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/cardTableRS.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp - src/share/vm/gc/shared/genRemSet.cpp - src/share/vm/gc/shared/genRemSet.hpp - src/share/vm/gc/shared/watermark.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/commandLineFlagConstraintList.cpp ! src/share/vm/runtime/commandLineFlagRangeList.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.cpp ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changeset: 6bea4fdaae80 Author: amurillo Date: 2015-10-22 16:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6bea4fdaae80 Merge - src/share/vm/gc/shared/genRemSet.cpp - src/share/vm/gc/shared/genRemSet.hpp - src/share/vm/gc/shared/watermark.hpp Changeset: 20dff0211ded Author: mgerdin Date: 2015-10-26 17:13 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/20dff0211ded 8140452: Internal Error memory/allocation.cpp:179 Summary: use const ref & and avoid copy ctor Reviewed-by: coleenp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp Changeset: 7fe46dc64bb3 Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fe46dc64bb3 Added tag jdk9-b89 for changeset 20dff0211ded ! .hgtags Changeset: 3fd5c2ca4c20 Author: lana Date: 2015-10-30 10:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3fd5c2ca4c20 Added tag jdk9-b90 for changeset 7fe46dc64bb3 ! .hgtags Changeset: c83fdb22d5a4 Author: mchung Date: 2015-11-11 15:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c83fdb22d5a4 Merge ! .hgtags ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/ostream.cpp ! test/compiler/c2/5057225/Test5057225.java ! test/compiler/c2/6603011/Test.java ! test/compiler/c2/6800154/Test6800154.java ! test/compiler/c2/6805724/Test6805724.java ! test/compiler/codegen/6823354/Test6823354.java ! test/gc/arguments/TestG1HeapRegionSize.java - test/runtime/BadObjectClass/Object.java ! test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java ! test/testlibrary_tests/whitebox/vm_flags/IntxTest.java Changeset: 70497711c2e4 Author: mchung Date: 2015-11-11 15:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/70497711c2e4 Merge + src/jdk.vm.ci/share/classes/module-info.java Changeset: 7fd0a4aeffa5 Author: mchung Date: 2015-11-12 15:26 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fd0a4aeffa5 Merge ! make/gensrc/Gensrc-jdk.vm.ci.gmk ! src/share/vm/runtime/frame.cpp Changeset: 18b6c7bfb8a4 Author: mchung Date: 2015-11-12 20:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/18b6c7bfb8a4 jdk9-b91 fixup ! make/gensrc/Gensrc-jdk.vm.ci.gmk Changeset: 2760de77e5c5 Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2760de77e5c5 Added tag jdk9-b91 for changeset 3fd5c2ca4c20 ! .hgtags Changeset: f5112887ebd7 Author: vlivanov Date: 2015-09-06 10:13 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f5112887ebd7 8065151: Support IdealGraphVisualizer in optimized build Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp Changeset: 420908d02f8d Author: erikj Date: 2015-10-20 10:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/420908d02f8d 8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file Reviewed-by: twisti ! make/gensrc/Gensrc-jdk.vm.ci.gmk Changeset: 9108fab781a4 Author: roland Date: 2015-10-16 16:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9108fab781a4 8136473: failed: no mismatched stores, except on raw memory: StoreB StoreI Summary: Mismatched stores on same slice possible with Unsafe.Put*Unaligned methods Reviewed-by: kvn, thartmann ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java Changeset: eb7736a32a0f Author: roland Date: 2015-10-20 13:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/eb7736a32a0f Merge Changeset: a176d4737606 Author: neliasso Date: 2015-10-20 18:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a176d4737606 8137167: JEP165: Compiler Control: Implementation task Summary: Compiler Control JEP Reviewed-by: roland, twisti, zmajo, simonis ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/compileTask.cpp + src/share/vm/compiler/compilerDirectives.cpp + src/share/vm/compiler/compilerDirectives.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp + src/share/vm/compiler/directivesParser.cpp + src/share/vm/compiler/directivesParser.hpp ! src/share/vm/compiler/methodMatcher.cpp ! src/share/vm/compiler/methodMatcher.hpp ! src/share/vm/jvmci/jvmciCompiler.cpp ! src/share/vm/jvmci/jvmciCompiler.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/idealGraphPrinter.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + src/share/vm/utilities/json.cpp + src/share/vm/utilities/json.hpp + test/compiler/compilercontrol/InlineMatcherTest.java + test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java + test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java + test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java + test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java + test/compiler/compilercontrol/control_off.txt + test/compiler/compilercontrol/control_on.txt + test/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java + test/serviceability/dcmd/compiler/control1.txt + test/serviceability/dcmd/compiler/control2.txt Changeset: 535c335eb11c Author: ppunegov Date: 2015-10-20 21:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/535c335eb11c 8066153: JEP-JDK-8046155: Test task: cover existing Summary: Tests for CompilerCommand and CompilerControl's directives Reviewed-by: kvn + test/compiler/compilercontrol/commandfile/CompileOnlyTest.java + test/compiler/compilercontrol/commandfile/ExcludeTest.java + test/compiler/compilercontrol/commandfile/LogTest.java + test/compiler/compilercontrol/commandfile/PrintTest.java + test/compiler/compilercontrol/commands/CompileOnlyTest.java + test/compiler/compilercontrol/commands/ExcludeTest.java + test/compiler/compilercontrol/commands/LogTest.java + test/compiler/compilercontrol/commands/PrintTest.java + test/compiler/compilercontrol/directives/CompileOnlyTest.java + test/compiler/compilercontrol/directives/ExcludeTest.java + test/compiler/compilercontrol/directives/LogTest.java + test/compiler/compilercontrol/directives/PrintTest.java + test/compiler/compilercontrol/mixed/RandomCommandsTest.java + test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java + test/compiler/compilercontrol/share/AbstractTestBase.java + test/compiler/compilercontrol/share/JSONFile.java + test/compiler/compilercontrol/share/MultiCommand.java + test/compiler/compilercontrol/share/SingleCommand.java + test/compiler/compilercontrol/share/actions/BaseAction.java + test/compiler/compilercontrol/share/actions/CompileAction.java ! test/compiler/compilercontrol/share/method/MethodGenerator.java ! test/compiler/compilercontrol/share/method/SignatureType.java + test/compiler/compilercontrol/share/processors/CommandProcessor.java + test/compiler/compilercontrol/share/processors/LogProcessor.java + test/compiler/compilercontrol/share/processors/PrintProcessor.java + test/compiler/compilercontrol/share/processors/QuietProcessor.java + test/compiler/compilercontrol/share/scenario/AbstractCommandBuilder.java + test/compiler/compilercontrol/share/scenario/Command.java + test/compiler/compilercontrol/share/scenario/CommandFileBuilder.java + test/compiler/compilercontrol/share/scenario/CommandGenerator.java + test/compiler/compilercontrol/share/scenario/CommandOptionsBuilder.java + test/compiler/compilercontrol/share/scenario/CompileCommand.java + test/compiler/compilercontrol/share/scenario/DirectiveBuilder.java + test/compiler/compilercontrol/share/scenario/DirectiveWriter.java + test/compiler/compilercontrol/share/scenario/Scenario.java Changeset: 11c3bed1e41e Author: ppunegov Date: 2015-10-20 21:12 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/11c3bed1e41e 8066166: JEP-JDK-8046155: Test task: dcmd tests Summary: Tests for diagnostic command in CompilerControl Reviewed-by: kvn + test/compiler/compilercontrol/jcmd/AddAndRemoveTest.java + test/compiler/compilercontrol/jcmd/AddCompileOnlyTest.java + test/compiler/compilercontrol/jcmd/AddExcludeTest.java + test/compiler/compilercontrol/jcmd/AddLogTest.java + test/compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java + test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java + test/compiler/compilercontrol/jcmd/ClearDirectivesStackTest.java ! test/compiler/compilercontrol/share/scenario/CommandGenerator.java + test/compiler/compilercontrol/share/scenario/JcmdCommand.java + test/compiler/compilercontrol/share/scenario/JcmdStateBuilder.java ! test/compiler/compilercontrol/share/scenario/Scenario.java Changeset: 1cd251540653 Author: vlivanov Date: 2015-10-20 19:22 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1cd251540653 8132168: Support IdealGraphVisualizer in optimized build Reviewed-by: kvn ! src/share/vm/opto/c2_globals.hpp Changeset: 03fa0a35a468 Author: vlivanov Date: 2015-10-20 22:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/03fa0a35a468 Merge ! src/share/vm/opto/c2_globals.hpp Changeset: 111d1c4c90e7 Author: goetz Date: 2015-10-21 18:22 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/111d1c4c90e7 8140239: Fix product build after "8132168: Support IdealGraphVisualizer in optimized build" Reviewed-by: vlivanov ! src/share/vm/compiler/compilerDirectives.hpp Changeset: 713aa577bd38 Author: neliasso Date: 2015-10-21 19:31 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/713aa577bd38 8140240: Missing test files in CompilerControl tests Summary: Add missing files Reviewed-by: kvn, neliasso + test/compiler/compilercontrol/share/scenario/State.java + test/compiler/compilercontrol/share/scenario/StateBuilder.java ! test/testlibrary/jdk/test/lib/ProcessTools.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: a60bd3d34158 Author: neliasso Date: 2015-10-21 21:59 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a60bd3d34158 Merge Changeset: d80d1084cfdc Author: dlong Date: 2015-10-21 18:05 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d80d1084cfdc 8140267: assert(is_native_ptr || alias_type->adr_type() == TypeOopPtr::BOTTOM || alias_type->field() != __null || alias_type->element() != __null) failed: field, array element or unknown Summary: back out 8136473 Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp - test/compiler/intrinsics/unsafe/TestUnsafeUnalignedMismatchedAccesses.java Changeset: ffae03d59aa9 Author: dlong Date: 2015-10-21 18:34 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ffae03d59aa9 Merge Changeset: ea9eaad05466 Author: enevill Date: 2015-10-21 12:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ea9eaad05466 8140238: Zero fails to build from source Summary: Zero fails to build after 8136421 and 8078554 Reviewed-by: kvn ! src/cpu/zero/vm/compiledIC_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/vm_version_zero.cpp Changeset: a0c5acb7c322 Author: mdoerr Date: 2015-10-09 20:58 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a0c5acb7c322 8138890: C1: Ambiguous operator delete Summary: xlC on AIX rejects to compile LIRGenerator and RangeCheckEliminator::Verification Reviewed-by: simonis, goetz, twisti ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp Changeset: 5dc1db0a5290 Author: twisti Date: 2015-10-21 21:49 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5dc1db0a5290 Merge Changeset: cc7b816cca18 Author: twisti Date: 2015-10-22 19:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/cc7b816cca18 Merge Changeset: 4b46d2b42fcb Author: iveresov Date: 2015-10-22 21:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4b46d2b42fcb 8139575: Update for x86 log in the math lib Summary: Add new java.lang.Math() intrinsics from x86 Reviewed-by: kvn, iveresov Contributed-by: vivek.r.deshpande at intel.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86_libm.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d9315ec5c471 Author: twisti Date: 2015-10-22 13:18 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d9315ec5c471 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug Reviewed-by: erikj, kvn ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make ! src/share/vm/runtime/vmStructs.cpp Changeset: e32667cd477c Author: twisti Date: 2015-10-23 07:18 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e32667cd477c Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 5d13c9b094c4 Author: neliasso Date: 2015-10-26 10:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d13c9b094c4 8139996: CompileCommand prints quoted ascii strings Summary: Print symbols as utf8 Reviewed-by: kvn ! src/share/vm/compiler/methodMatcher.cpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp Changeset: ae64ff428e18 Author: iveresov Date: 2015-10-26 19:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ae64ff428e18 8139340: SuperWord enhancement to support vector conditional move (CMovVD) on Intel AVX cpu Summary: Emit vector conditional moves Reviewed-by: kvn Contributed-by: jan.civlin at intel.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: e7b4c40ebb11 Author: dlong Date: 2015-10-27 01:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e7b4c40ebb11 Merge ! make/gensrc/Gensrc-jdk.vm.ci.gmk ! src/share/vm/c1/c1_Runtime1.cpp - src/share/vm/gc/shared/genRemSet.cpp - src/share/vm/gc/shared/genRemSet.hpp - src/share/vm/gc/shared/watermark.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0ecd612047de Author: enevill Date: 2015-10-27 10:08 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0ecd612047de 8140582: aarch64: jvm fails to initialise after 8078556 Summary: jvm fails to initialise on aarch64 systems with pagesize > 4K Reviewed-by: duke ! src/cpu/aarch64/vm/globals_aarch64.hpp Changeset: 427a91c68b67 Author: enevill Date: 2015-10-27 18:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/427a91c68b67 8140611: aarch64: jtreg test jdk/tools/pack200/UnpackerMemoryTest.java SEGVs Summary: Fix register usage on calling native synchronized methods Reviewed-by: kvn, adinn ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: 9c4989b6889a Author: zmajo Date: 2015-10-28 15:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9c4989b6889a 8139907: compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java fails with timeout Summary: Change MontgomeryMultiplyTest.java test to execute only on platforms on which the tested intrinsics are available. Reviewed-by: kvn, neliasso ! test/compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java Changeset: ea4fcd70985d Author: ppunegov Date: 2015-10-28 16:00 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ea4fcd70985d 8140350: compiler control tests fail with compiled: true, but should: false on required level: 1 Summary: Replace isMethodCompiled with isMethodCompilable with particular level Reviewed-by: kvn ! test/compiler/compilercontrol/share/actions/CompileAction.java Changeset: 48b73c88892f Author: ppunegov Date: 2015-10-28 16:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/48b73c88892f 8140453: compiler control test failed with RuntimeException: CompileCommand: nonexistent missing Summary: Replace incorrect check for validity of method pattern with full command check Reviewed-by: kvn ! test/compiler/compilercontrol/share/processors/CommandProcessor.java ! test/compiler/compilercontrol/share/processors/QuietProcessor.java Changeset: 4883b314d4b9 Author: ppunegov Date: 2015-10-28 16:38 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4883b314d4b9 8066158: JEP-JDK-8046155: Test task: directive parser Summary: check directive file parser with correct and incorrect files Reviewed-by: kvn + test/compiler/compilercontrol/parser/DirectiveParser.java ! test/testlibrary/jdk/test/lib/Utils.java Changeset: 0b2937220009 Author: iignatyev Date: 2015-10-28 16:01 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0b2937220009 Merge Changeset: 96bcdd3a6e79 Author: neliasso Date: 2015-10-28 15:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/96bcdd3a6e79 8140581: Excluding compile messages should only be printed with PrintCompilation Summary: Use PrintCompilation flag instead Reviewed-by: kvn ! src/share/vm/compiler/compileBroker.cpp Changeset: 0fa6910c516d Author: neliasso Date: 2015-10-23 10:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0fa6910c516d 8140343: SEGV in DirectivesStack::getMatchingDirective Summary: Could not match JVMCI compiler Reviewed-by: kvn ! src/share/vm/compiler/compilerDirectives.cpp Changeset: 1d49bd532a6f Author: zmajo Date: 2015-10-29 09:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1d49bd532a6f 8138651: -XX:DisableIntrinsic matches intrinsics overly eagerly Summary: Improve parsing of DisableIntrinsic flag. Reviewed-by: kvn, shade, neliasso ! src/share/vm/compiler/compilerDirectives.cpp ! src/share/vm/compiler/compilerDirectives.hpp ! src/share/vm/compiler/directivesParser.cpp ! src/share/vm/compiler/directivesParser.hpp + test/compiler/intrinsics/IntrinsicDisabledTest.java Changeset: b62347567e9b Author: ppunegov Date: 2015-10-29 01:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b62347567e9b 8140668: Quarantine RandomValidCommandsTest 8140669: Quarantine ClearDirectivesFileStackTest Summary: Quarantine two tests Reviewed-by: iignatyev, neliasso, kvn ! test/compiler/compilercontrol/jcmd/ClearDirectivesFileStackTest.java ! test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java Changeset: e18469511c58 Author: iignatyev Date: 2015-10-29 10:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e18469511c58 Merge Changeset: 0835ef4e6232 Author: shade Date: 2015-10-29 14:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0835ef4e6232 8140483: Atomic*FieldUpdaters final fields should be trusted Summary: Add exceptions for A*FU subclasses that do the actual work. Reviewed-by: jrose, vlivanov ! src/share/vm/ci/ciField.cpp ! src/share/vm/classfile/vmSymbols.hpp Changeset: 7fb261378480 Author: shade Date: 2015-10-29 13:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7fb261378480 Merge Changeset: e3690e58d28e Author: iveresov Date: 2015-10-29 09:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3690e58d28e 8140604: Internal Error runtime/stubRoutines.hpp:392 assert(_intrinsic_log != 0L) failed: must be defined Summary: Fix the faulty assert, remove remaining _intrinsic_log references Reviewed-by: roland ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: b03c5e9f24ba Author: ppunegov Date: 2015-10-29 21:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b03c5e9f24ba 8140776: CompilerControl: Remove UTF-16 from the tests Summary: remove UTF-16 from the generation until the failure reason isn't found Reviewed-by: iignatyev ! test/compiler/compilercontrol/share/method/MethodGenerator.java Changeset: 8c85cc5c9fb8 Author: iignatyev Date: 2015-10-29 19:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c85cc5c9fb8 Merge Changeset: 79b56d21b736 Author: amurillo Date: 2015-10-30 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/79b56d21b736 Merge Changeset: 53cb98d68a1a Author: lana Date: 2015-11-05 13:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/53cb98d68a1a Merge Changeset: 8fd684b8c649 Author: lana Date: 2015-11-12 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8fd684b8c649 Added tag jdk9-b92 for changeset 53cb98d68a1a ! .hgtags Changeset: bbc92f9082c0 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/bbc92f9082c0 Merge ! .hgtags ! make/gensrc/Gensrc-jdk.vm.ci.gmk ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/jvmci/jvmciEnv.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vmStructs.cpp - test/runtime/BadObjectClass/Object.java From mandy.chung at oracle.com Sat Nov 14 04:22:58 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:22:58 +0000 Subject: hg: jigsaw/jake/jaxp: 18 new changesets Message-ID: <201511140422.tAE4MwnQ029869@aojmv0008.oracle.com> Changeset: 4700fd67e942 Author: lana Date: 2015-10-19 00:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4700fd67e942 Added tag jdk9-b87 for changeset eb435c878c2c ! .hgtags Changeset: 27b625ce80f4 Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/27b625ce80f4 Added tag jdk9-b88 for changeset 4700fd67e942 ! .hgtags Changeset: 00fa5efc9ace Author: joehw Date: 2015-04-18 00:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/00fa5efc9ace 8068842: Better JAXP data handling Reviewed-by: dfuchs, lancea, hawtin ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltSets.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/LCount.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/NodeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/DOMUtil.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java + src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/PrimeNumberSequenceGenerator.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolHash.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/ElementState.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Utils.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/DOMHelper.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/ElemDesc.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java ! src/java.xml/share/classes/com/sun/org/apache/xpath/internal/compiler/Keywords.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java ! src/java.xml/share/classes/org/xml/sax/helpers/NamespaceSupport.java Changeset: 3345330dd03a Author: joehw Date: 2015-05-12 10:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/3345330dd03a 8079323: Serialization compatibility for Templates: need to exclude Hashtable from serialization Reviewed-by: dfuchs, lancea, hawtin ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java + test/javax/xml/jaxp/unittest/transform/TemplatesTest.java Changeset: e9fb9655fd36 Author: joehw Date: 2015-05-26 10:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e9fb9655fd36 8078427: More supportive home environment Reviewed-by: dfuchs, lancea, skoivu ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/TreeWalker.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/dom3/DOM3TreeWalker.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/TreeWalker.java Changeset: 5f2ff10c2974 Author: joehw Date: 2015-07-07 15:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5f2ff10c2974 8086733: Improve namespace handling Reviewed-by: dfuchs, lancea, ahgross ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/XMLSecurityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLLimitAnalyzer.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java ! src/java.xml/share/classes/com/sun/xml/internal/stream/Entity.java Changeset: 686f3a3e49ac Author: joehw Date: 2015-07-07 16:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/686f3a3e49ac 8130078: Document better processing Reviewed-by: dfuchs, lancea, ahgross ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java Changeset: 198a7fd9ec1f Author: lana Date: 2015-10-21 18:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/198a7fd9ec1f Merge - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java Changeset: 5021da4c9496 Author: lana Date: 2015-10-22 11:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5021da4c9496 Merge - src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java - src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java Changeset: 35f68242b624 Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/35f68242b624 Added tag jdk9-b89 for changeset 5021da4c9496 ! .hgtags Changeset: ffaff3d0ad0e Author: lana Date: 2015-10-30 10:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ffaff3d0ad0e Added tag jdk9-b90 for changeset 35f68242b624 ! .hgtags Changeset: 4c198fa1ddc5 Author: mchung Date: 2015-11-12 11:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4c198fa1ddc5 Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java Changeset: c44ed58b7928 Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c44ed58b7928 Added tag jdk9-b91 for changeset ffaff3d0ad0e ! .hgtags Changeset: d6dcb5df3d6d Author: joehw Date: 2015-10-29 21:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d6dcb5df3d6d 8081248: Implement JEP 268: XML Catalog API Reviewed-by: lancea, dfuchs + src/java.xml/share/classes/javax/xml/catalog/AltCatalog.java + src/java.xml/share/classes/javax/xml/catalog/BaseEntry.java + src/java.xml/share/classes/javax/xml/catalog/Catalog.java + src/java.xml/share/classes/javax/xml/catalog/CatalogEntry.java + src/java.xml/share/classes/javax/xml/catalog/CatalogException.java + src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java + src/java.xml/share/classes/javax/xml/catalog/CatalogImpl.java + src/java.xml/share/classes/javax/xml/catalog/CatalogManager.java + src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.java + src/java.xml/share/classes/javax/xml/catalog/CatalogMessages.properties + src/java.xml/share/classes/javax/xml/catalog/CatalogReader.java + src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java + src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java + src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolver.java + src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java + src/java.xml/share/classes/javax/xml/catalog/DelegatePublic.java + src/java.xml/share/classes/javax/xml/catalog/DelegateSystem.java + src/java.xml/share/classes/javax/xml/catalog/DelegateUri.java + src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java + src/java.xml/share/classes/javax/xml/catalog/NextCatalog.java + src/java.xml/share/classes/javax/xml/catalog/Normalizer.java + src/java.xml/share/classes/javax/xml/catalog/PublicEntry.java + src/java.xml/share/classes/javax/xml/catalog/RewriteSystem.java + src/java.xml/share/classes/javax/xml/catalog/RewriteUri.java + src/java.xml/share/classes/javax/xml/catalog/SystemEntry.java + src/java.xml/share/classes/javax/xml/catalog/SystemSuffix.java + src/java.xml/share/classes/javax/xml/catalog/UriEntry.java + src/java.xml/share/classes/javax/xml/catalog/UriSuffix.java + src/java.xml/share/classes/javax/xml/catalog/Util.java + src/java.xml/share/classes/javax/xml/catalog/package.html + src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java ! test/javax/xml/jaxp/unittest/TEST.properties + test/javax/xml/jaxp/unittest/catalog/CatalogTest.java + test/javax/xml/jaxp/unittest/catalog/catalog.xml + test/javax/xml/jaxp/unittest/catalog/catalog_invalid.xml + test/javax/xml/jaxp/unittest/catalog/delegatepublic.xml + test/javax/xml/jaxp/unittest/catalog/delegatesystem.xml + test/javax/xml/jaxp/unittest/catalog/files/delegatecatalog.xml + test/javax/xml/jaxp/unittest/catalog/files/delegatepublic.dtd + test/javax/xml/jaxp/unittest/catalog/files/delegatesystem.dtd + test/javax/xml/jaxp/unittest/catalog/files/rewritesystem.dtd + test/javax/xml/jaxp/unittest/catalog/files/systemsuffix.dtd + test/javax/xml/jaxp/unittest/catalog/public.dtd + test/javax/xml/jaxp/unittest/catalog/public.xml + test/javax/xml/jaxp/unittest/catalog/rewritesystem.xml + test/javax/xml/jaxp/unittest/catalog/rewritesystem1.xml + test/javax/xml/jaxp/unittest/catalog/system.dtd + test/javax/xml/jaxp/unittest/catalog/system.xml + test/javax/xml/jaxp/unittest/catalog/systemsuffix.xml Changeset: 395cd2b14c1d Author: joehw Date: 2015-10-29 22:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/395cd2b14c1d 8077931: Develop tests for XML Catalog API Reviewed-by: joehw, lancea Contributed-by: sha.jiang at oracle.com + test/javax/xml/jaxp/functional/catalog/CatalogReferCircularityTest.java + test/javax/xml/jaxp/functional/catalog/DefaultFeaturesTest.java + test/javax/xml/jaxp/functional/catalog/DeferFeatureTest.java + test/javax/xml/jaxp/functional/catalog/DelegatePublicTest.java + test/javax/xml/jaxp/functional/catalog/DelegateSystemTest.java + test/javax/xml/jaxp/functional/catalog/DelegateUriTest.java + test/javax/xml/jaxp/functional/catalog/GroupTest.java + test/javax/xml/jaxp/functional/catalog/LoadCatalogTest.java + test/javax/xml/jaxp/functional/catalog/NextCatalogTest.java + test/javax/xml/jaxp/functional/catalog/NormalizationTest.java + test/javax/xml/jaxp/functional/catalog/PreferFeatureTest.java + test/javax/xml/jaxp/functional/catalog/PreferTest.java + test/javax/xml/jaxp/functional/catalog/PublicFamilyTest.java + test/javax/xml/jaxp/functional/catalog/PublicTest.java + test/javax/xml/jaxp/functional/catalog/ResolveFeatureTest.java + test/javax/xml/jaxp/functional/catalog/RewriteSystemTest.java + test/javax/xml/jaxp/functional/catalog/RewriteUriTest.java + test/javax/xml/jaxp/functional/catalog/SpecifyCatalogTest.java + test/javax/xml/jaxp/functional/catalog/SystemFamilyTest.java + test/javax/xml/jaxp/functional/catalog/SystemSuffixTest.java + test/javax/xml/jaxp/functional/catalog/SystemTest.java + test/javax/xml/jaxp/functional/catalog/UriFamilyTest.java + test/javax/xml/jaxp/functional/catalog/UriSuffixTest.java + test/javax/xml/jaxp/functional/catalog/UriTest.java + test/javax/xml/jaxp/functional/catalog/UrnUnwrappingTest.java + test/javax/xml/jaxp/functional/catalog/ValidateCatalogTest.java + test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-itself.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-left.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/catalogReferCircle-right.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/deferFeature.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-alice.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-bob.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic-carl.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegatePublic.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-alice.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-bob.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem-carl.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateSystem.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-alice.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-bob.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri-carl.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/delegateUri.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/group.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/loadCatalogFiles.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-left.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftAlice.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftBob.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-leftCarl.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-right.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-rightAlice.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/nextCatalog-rightBob.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/normalization.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/prefer.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/preferFeature.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/public.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/publicFamily.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/rewriteSystem.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/rewriteUri.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-api.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-feature.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/specifyCatalog-sysProps.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/system.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/systemFamily.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/systemSuffix.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/uri.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/uriFamily.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/uriSuffix.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/urnUnwrapping.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-malformed.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-noNamingSpace.xml + test/javax/xml/jaxp/functional/catalog/catalogFiles/validateCatalog-wrongRoot.xml + test/javax/xml/jaxp/isolatedjdk/IsolatedJDK.sh + test/javax/xml/jaxp/isolatedjdk/TEST.properties + test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.java + test/javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh + test/javax/xml/jaxp/isolatedjdk/catalog/catalogFiles/properties.xml + test/javax/xml/jaxp/libs/catalog/CatalogTestUtils.java + test/javax/xml/jaxp/libs/catalog/ResolutionChecker.java Changeset: fcabfb3c38ac Author: lana Date: 2015-11-05 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/fcabfb3c38ac Merge Changeset: f665f69fa8e3 Author: lana Date: 2015-11-12 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f665f69fa8e3 Added tag jdk9-b92 for changeset fcabfb3c38ac ! .hgtags Changeset: 91fb735c7175 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/91fb735c7175 Merge From mandy.chung at oracle.com Sat Nov 14 04:22:53 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:22:53 +0000 Subject: hg: jigsaw/jake/jdk: 161 new changesets Message-ID: <201511140422.tAE4MxRA029872@aojmv0008.oracle.com> Changeset: 0198481aa9bd Author: lana Date: 2015-10-19 00:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0198481aa9bd Added tag jdk9-b87 for changeset 110fc90bdfa0 ! .hgtags Changeset: e860e54043fd Author: aefimov Date: 2015-10-10 12:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e860e54043fd 8139107: DateTimeFormatter with Locale.UK throw a NullPointerException when parsing zone Reviewed-by: naoto ! src/jdk.localedata/share/classes/sun/util/resources/en/GB/TimeZoneNames_en_GB.java ! src/jdk.localedata/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java + test/sun/util/resources/TimeZone/Bug8139107.java Changeset: 3bd60f298de4 Author: chegar Date: 2015-10-10 17:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bd60f298de4 8139307: Remove sun.misc.ConditionLock and Lock Reviewed-by: alanb, lancea, martin, mchung, shade, smarks - src/java.base/share/classes/sun/misc/ConditionLock.java - src/java.base/share/classes/sun/misc/Lock.java Changeset: 7fea29aaa921 Author: chegar Date: 2015-10-10 17:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7fea29aaa921 8139179: URLStreamHandler* should link to URL ctor that specifies how factories/providers are located Reviewed-by: alanb ! src/java.base/share/classes/java/net/URLStreamHandlerFactory.java ! src/java.base/share/classes/java/net/spi/URLStreamHandlerProvider.java Changeset: de8723d4d615 Author: amlu Date: 2015-10-12 17:07 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de8723d4d615 8139407: Mark java/rmi/registry/readTest/readTest.sh as intermittently failing Reviewed-by: chegar ! test/java/rmi/registry/readTest/readTest.sh Changeset: d1aa33d3720c Author: dfuchs Date: 2015-10-12 20:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1aa33d3720c 8033661: readConfiguration does not cleanly reinitialize the logging system Summary: two new updateConfiguration methods have been added to LogManager: call updateConfiguration to update a configuration *after* the LogManager is initialized. Reviewed-by: mchung ! src/java.logging/share/classes/java/util/logging/LogManager.java + test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java + test/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java + test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigWithInputStreamTest.java + test/java/util/logging/LogManager/Configuration/updateConfiguration/SimpleUpdateConfigurationTest.java + test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java Changeset: 640d543aea86 Author: chegar Date: 2015-10-12 19:14 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/640d543aea86 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate Reviewed-by: alanb, jlaskey ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java Changeset: fed8b8b53b4b Author: plevart Date: 2015-10-14 00:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fed8b8b53b4b 8136893: Improve early java.lang.invoke infrastructure initialization Reviewed-by: mhaupt, psandoz, redestad, vlivanov ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java ! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java Changeset: 96524d5330db Author: dl Date: 2015-10-13 16:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/96524d5330db 8134851: Integrate CompletableFuture with API enhancements 8039378: CompletableFuture: Avoid StackOverflowError for long linear chains Reviewed-by: martin, psandoz, chegar ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/CompletionStage.java ! test/java/util/concurrent/CompletableFuture/Basic.java ! test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java ! test/java/util/concurrent/CompletableFuture/ThenComposeExceptionTest.java Changeset: a0c71499805e Author: dl Date: 2015-10-13 16:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0c71499805e 8134852: Integrate fork/join with API enhancements Reviewed-by: martin, psandoz, chegar ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! test/java/util/concurrent/forkjoin/FJExceptionTableLeak.java ! test/java/util/concurrent/forkjoin/Integrate.java Changeset: adec55c103f6 Author: dl Date: 2015-10-13 16:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/adec55c103f6 8134850: Integrate the Flow API Reviewed-by: martin, psandoz, chegar + src/java.base/share/classes/java/util/concurrent/Flow.java + src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java Changeset: 02bb920a3b12 Author: dl Date: 2015-10-13 16:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/02bb920a3b12 8134855: Bulk integration of java.util.concurrent.locks classes 8051848: ReentrantReadWriteLock.ReadLock fails on unlock by different thread 8049843: Lack of save / restore interrupt mechanism undermines the StampedLock Reviewed-by: martin, psandoz, chegar ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/Condition.java ! src/java.base/share/classes/java/util/concurrent/locks/Lock.java ! src/java.base/share/classes/java/util/concurrent/locks/LockSupport.java ! src/java.base/share/classes/java/util/concurrent/locks/ReadWriteLock.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/Lock/CheckedLockLoops.java + test/java/util/concurrent/locks/Lock/LoopHelpers.java + test/java/util/concurrent/locks/Lock/Mutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java + test/java/util/concurrent/locks/LockSupport/ParkLoops.java ! test/java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java ! test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/MapLoops.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/RWMap.java ! test/java/util/concurrent/locks/StampedLock/Basic.java Changeset: 6dd59c01f011 Author: dl Date: 2015-10-13 16:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6dd59c01f011 8134853: Bulk integration of java.util.concurrent classes 8080939: ForkJoinPool and Phaser deadlock 8044616: Clients of Unsafe.compareAndSwapLong need to beware of using direct stores to the same field 8071638: [JAVADOC] Buggy example in javadoc for afterExecute to access a submitted job's Throwable 8043743: Data missed in java.util.concurrent.LinkedTransferQueue 8054446: Repeated offer and remove on ConcurrentLinkedQueue lead to an OutOfMemoryError 8031374: TEST_BUG: java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java fails Intermittently 8034208: Cleanup to test/java/util/concurrent/BlockingQueue/Interrupt.java 8035661: Test fix java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java from jsr166 CVS 8062841: ConcurrentHashMap.computeIfAbsent stuck in an endless loop 8073208: javadoc typo in java.util.concurrent.Executor 8073704: FutureTask.isDone returns true when task has not yet completed 8037093: java/util/concurrent/locks/Lock/TimedAcquireLeak.java fails intermittently 8022642: ScheduledThreadPoolExecutor with zero corePoolSize create endlessly threads 8065320: Busy loop in ThreadPoolExecutor.getTask for ScheduledThreadPoolExecutor 8129861: High processor load for ScheduledThreadPoolExecutor with 0 core threads 8051859: ScheduledExecutorService.scheduleWithFixedDelay fails with max delay 7146994: example afterExecute for ScheduledThreadPoolExecutor hangs Reviewed-by: martin, psandoz, chegar ! src/java.base/share/classes/java/util/AbstractQueue.java ! src/java.base/share/classes/java/util/ArrayDeque.java ! src/java.base/share/classes/java/util/ArrayPrefixHelpers.java ! src/java.base/share/classes/java/util/Deque.java ! src/java.base/share/classes/java/util/NavigableMap.java ! src/java.base/share/classes/java/util/NavigableSet.java ! src/java.base/share/classes/java/util/PriorityQueue.java ! src/java.base/share/classes/java/util/Queue.java ! src/java.base/share/classes/java/util/SplittableRandom.java ! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/java.base/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java ! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/java.base/share/classes/java/util/concurrent/CountDownLatch.java ! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java ! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java ! src/java.base/share/classes/java/util/concurrent/DelayQueue.java ! src/java.base/share/classes/java/util/concurrent/Exchanger.java ! src/java.base/share/classes/java/util/concurrent/Executor.java ! src/java.base/share/classes/java/util/concurrent/ExecutorCompletionService.java ! src/java.base/share/classes/java/util/concurrent/ExecutorService.java ! src/java.base/share/classes/java/util/concurrent/Executors.java ! src/java.base/share/classes/java/util/concurrent/Future.java ! src/java.base/share/classes/java/util/concurrent/FutureTask.java + src/java.base/share/classes/java/util/concurrent/Helpers.java ! src/java.base/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/java.base/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/java.base/share/classes/java/util/concurrent/Phaser.java ! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/RecursiveAction.java ! src/java.base/share/classes/java/util/concurrent/RecursiveTask.java ! src/java.base/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/java.base/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/java.base/share/classes/java/util/concurrent/Semaphore.java ! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java ! src/java.base/share/classes/java/util/concurrent/ThreadFactory.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/java.base/share/classes/java/util/concurrent/TimeUnit.java ! src/java.base/share/classes/java/util/concurrent/TransferQueue.java ! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/java.base/share/classes/java/util/concurrent/package-info.java ! test/java/util/AbstractList/CheckForComodification.java ! test/java/util/AbstractList/FailFastIterator.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collection/testlibrary/CollectionAsserts.java ! test/java/util/Collections/BigBinarySearch.java ! test/java/util/Collections/BinarySearchNullComparator.java ! test/java/util/Collections/CheckedListBash.java ! test/java/util/Collections/CheckedMapBash.java ! test/java/util/Collections/CheckedSetBash.java ! test/java/util/Collections/EmptyCollectionSerialization.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/Collections/EmptyNavigableMap.java ! test/java/util/Collections/EmptyNavigableSet.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/Collections/ReverseOrder.java ! test/java/util/Collections/RotateEmpty.java ! test/java/util/Collections/T6433170.java ! test/java/util/Collections/WrappedNull.java ! test/java/util/Hashtable/IllegalLoadFactor.java ! test/java/util/Hashtable/ReadObject.java ! test/java/util/IdentityHashMap/ToString.java ! test/java/util/LinkedHashMap/Basic.java ! test/java/util/LinkedHashMap/Cache.java ! test/java/util/LinkedHashSet/Basic.java ! test/java/util/LinkedList/Clone.java ! test/java/util/LinkedList/ComodifiedRemove.java ! test/java/util/List/ListDefaults.java ! test/java/util/Map/Defaults.java ! test/java/util/Map/Get.java ! test/java/util/NavigableMap/LockStep.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java ! test/java/util/Spliterator/SpliteratorLateBindingFailFastTest.java ! test/java/util/TimSort/Sorter.java ! test/java/util/TreeMap/ContainsValue.java ! test/java/util/TreeMap/HeadTailTypeError.java ! test/java/util/TreeMap/SubMap.java ! test/java/util/Vector/ComodifiedRemoveAllElements.java ! test/java/util/Vector/IllegalConstructorArgs.java ! test/java/util/Vector/LastIndexOf.java ! test/java/util/Vector/SyncLastIndexOf.java ! test/java/util/WeakHashMap/GCDuringIteration.java + test/java/util/concurrent/ArrayBlockingQueue/IteratorConsistency.java + test/java/util/concurrent/BlockingQueue/DrainToFails.java ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java ! test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java ! test/java/util/concurrent/ConcurrentHashMap/MapCheck.java ! test/java/util/concurrent/ConcurrentHashMap/MapLoops.java + test/java/util/concurrent/ConcurrentLinkedQueue/RemoveLeak.java ! test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java ! test/java/util/concurrent/ConcurrentQueues/GCRetention.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java ! test/java/util/concurrent/CopyOnWriteArrayList/COWSubList.java ! test/java/util/concurrent/CountDownLatch/Basic.java ! test/java/util/concurrent/Exchanger/ExchangeLoops.java ! test/java/util/concurrent/ExecutorCompletionService/ExecutorCompletionServiceLoops.java ! test/java/util/concurrent/Executors/AutoShutdown.java + test/java/util/concurrent/FutureTask/DoneMeansDone.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/concurrent/FutureTask/ExplicitSet.java ! test/java/util/concurrent/FutureTask/NegativeTimeout.java ! test/java/util/concurrent/Phaser/Basic.java ! test/java/util/concurrent/ScheduledThreadPoolExecutor/DelayOverflow.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/GCRetention.java + test/java/util/concurrent/ScheduledThreadPoolExecutor/ZeroCoreThreads.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java + test/java/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java + test/java/util/concurrent/ThreadPoolExecutor/ThreadRestarts.java Changeset: 7dc9726cfa82 Author: darcy Date: 2015-10-14 16:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7dc9726cfa82 8136799: Port fdlibm cbrt to Java Reviewed-by: bpb ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/lang/FdLibm.java ! src/java.base/share/classes/java/lang/StrictMath.java - src/java.base/share/native/libfdlibm/s_cbrt.c ! src/java.base/share/native/libjava/StrictMath.c ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/HypotTests.java ! test/java/lang/Math/IeeeRecommendedTests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/StrictMath/CubeRootTests.java ! test/java/lang/StrictMath/FdlibmTranslit.java ! test/java/lang/StrictMath/HypotTests.java Changeset: d97306dd54cd Author: coffeys Date: 2015-10-15 09:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d97306dd54cd 6907252: ZipFileInputStream Not Thread-Safe Reviewed-by: sherman ! src/java.base/share/classes/java/util/zip/ZStreamRef.java ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/native/libzip/zip_util.c + test/java/util/zip/ZipFile/ZipEntryFreeTest.java Changeset: 63ddd8dea0ff Author: igerasim Date: 2015-10-15 13:56 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/63ddd8dea0ff 8138938: Clarify javadoc for java.util.Collections.copy() Reviewed-by: smarks ! src/java.base/share/classes/java/util/Collections.java Changeset: 91fc3c3826e6 Author: coffeys Date: 2015-10-15 14:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/91fc3c3826e6 8038502: Deflater.needsInput() should use synchronization Reviewed-by: chegar ! src/java.base/share/classes/java/util/zip/Deflater.java Changeset: 34d73930289e Author: lana Date: 2015-10-15 16:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/34d73930289e Merge - src/java.base/share/classes/sun/misc/ConditionLock.java - src/java.base/share/classes/sun/misc/Lock.java - src/java.base/share/native/libfdlibm/s_cbrt.c Changeset: 0440acded788 Author: aefimov Date: 2015-10-16 19:05 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0440acded788 8073519: schemagen does not report errors while generating xsd files Reviewed-by: dfuchs + test/javax/xml/bind/jxc/8073519/InputWithError.java + test/javax/xml/bind/jxc/8073519/SchemagenErrorReporting.java Changeset: 6e50b992bef4 Author: lana Date: 2015-10-21 15:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e50b992bef4 Merge - src/java.base/share/classes/sun/misc/ConditionLock.java - src/java.base/share/classes/sun/misc/Lock.java - src/java.base/share/native/libfdlibm/s_cbrt.c Changeset: 4a00f31b3995 Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a00f31b3995 Added tag jdk9-b88 for changeset 6e50b992bef4 ! .hgtags Changeset: 2a83d5647e07 Author: redestad Date: 2015-10-18 01:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2a83d5647e07 8139706: JarFile.getBytes could use InputStream.readNBytes Reviewed-by: sherman, chegar, alanb ! src/java.base/share/classes/java/util/jar/JarFile.java Changeset: 9c12c03654a4 Author: xuelei Date: 2015-10-19 08:19 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9c12c03654a4 8077806: mismatch comment and code in CipherSuite.java Reviewed-by: xuelei Contributed-by: Time Du ! src/java.base/share/classes/sun/security/ssl/CipherSuite.java Changeset: fb7d69e4c624 Author: jlahoda Date: 2015-10-19 19:14 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fb7d69e4c624 8134254: JShell API/tool: REPL for Java into JDK9 Summary: Adding makefile for jshell tool launcher. Reviewed-by: alanb, erikj, sundar Contributed-by: robert.field at oracle.com, jan.lahoda at oracle.com + make/launcher/Launcher-jdk.jshell.gmk Changeset: 423df075cf72 Author: psandoz Date: 2015-10-19 11:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/423df075cf72 8080418: Add Optional.or() Reviewed-by: chegar, forax, scolebourne ! src/java.base/share/classes/java/util/Optional.java ! src/java.base/share/classes/java/util/OptionalDouble.java ! src/java.base/share/classes/java/util/OptionalInt.java ! src/java.base/share/classes/java/util/OptionalLong.java ! test/java/util/Optional/Basic.java Changeset: 9d2d39daa496 Author: darcy Date: 2015-10-19 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9d2d39daa496 8139925: Problem list LFMultiThreadCachingTest.java on windows Reviewed-by: rriggs, chegar ! test/ProblemList.txt Changeset: a4bb084549a1 Author: ascarpino Date: 2015-10-19 17:26 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a4bb084549a1 8139860: Add ucrypto/TestRSA.java to ProblemList: Message is larger than modulus Reviewed-by: xuelei ! test/ProblemList.txt Changeset: 5f032cc89bfd Author: ascarpino Date: 2015-10-19 17:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f032cc89bfd 8133151: Preferred provider configuration for JCE Reviewed-by: valeriep ! make/gendata/Gendata-java.base.gmk ! make/src/classes/build/tools/makejavasecurity/MakeJavaSecurity.java ! src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java ! src/java.base/share/classes/java/security/AlgorithmParameters.java ! src/java.base/share/classes/java/security/KeyFactory.java ! src/java.base/share/classes/java/security/KeyPairGenerator.java ! src/java.base/share/classes/java/security/KeyStore.java ! src/java.base/share/classes/java/security/MessageDigest.java ! src/java.base/share/classes/java/security/Policy.java ! src/java.base/share/classes/java/security/SecureRandom.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/security/cert/CertPathBuilder.java ! src/java.base/share/classes/java/security/cert/CertPathValidator.java ! src/java.base/share/classes/java/security/cert/CertStore.java ! src/java.base/share/classes/java/security/cert/CertificateFactory.java ! src/java.base/share/classes/javax/crypto/Cipher.java ! src/java.base/share/classes/javax/crypto/ExemptionMechanism.java ! src/java.base/share/classes/javax/crypto/KeyAgreement.java ! src/java.base/share/classes/javax/crypto/KeyGenerator.java ! src/java.base/share/classes/javax/crypto/Mac.java ! src/java.base/share/classes/javax/crypto/SecretKeyFactory.java ! src/java.base/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLContext.java ! src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/java.base/share/classes/javax/security/auth/login/Configuration.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/conf/security/java.security ! src/java.security.sasl/share/classes/javax/security/sasl/Sasl.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java Changeset: 37de30468e37 Author: peytoia Date: 2015-10-20 19:34 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/37de30468e37 8072600: Unicode 8 support Reviewed-by: okutsu ! make/data/characterdata/CharacterData00.java.template ! make/data/characterdata/CharacterData01.java.template ! make/data/unicodedata/PropList.txt ! make/data/unicodedata/Scripts.txt ! make/data/unicodedata/SpecialCasing.txt ! make/data/unicodedata/UnicodeData.txt ! make/data/unicodedata/VERSION ! src/java.base/share/classes/java/lang/Character.java ! src/java.base/share/classes/sun/text/resources/nfc.icu ! src/java.base/share/classes/sun/text/resources/nfkc.icu ! src/java.base/share/classes/sun/text/resources/nfkc_cf.icu ! src/java.base/share/classes/sun/text/resources/ubidi.icu ! src/java.base/share/classes/sun/text/resources/uprops.icu ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/PropList.txt ! test/java/lang/Character/PropertyValueAliases.txt ! test/java/lang/Character/Scripts.txt Changeset: 86713515444c Author: ntv Date: 2015-10-20 13:10 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/86713515444c 8134928: java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970 Reviewed-by: rriggs, scolebourne ! src/java.base/share/classes/java/time/Instant.java ! test/java/time/tck/java/time/TCKInstant.java Changeset: 392e83351179 Author: azvegint Date: 2015-09-30 13:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/392e83351179 8076540: [macosx] NPE due to incorrect threading Reviewed-by: alexsch, azvegint + test/sun/java2d/loops/CopyAreaSpeed.html + test/sun/java2d/loops/CopyAreaSpeed.java Changeset: 1ca9365c8173 Author: alexsch Date: 2015-09-30 17:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ca9365c8173 8040322: TextArea.replaceRange() and insert() are broken with setText(null) Reviewed-by: serb, azvegint Contributed-by: Ambarish Rapte ! src/java.desktop/share/classes/java/awt/TextArea.java + test/java/awt/TextArea/TextAreaEditing/TextAreaEditing.java Changeset: 605ab377eed1 Author: alexsch Date: 2015-10-02 10:29 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/605ab377eed1 8138674: Some platforms may not support showing the user-specified title in a file dialog Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/FileDialog.java Changeset: 6fa168f3c0c0 Author: alexsch Date: 2015-10-02 17:12 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6fa168f3c0c0 8067346: Swing submenu has a changed starting offset Reviewed-by: serb, alexsch Contributed-by: Rajeev Chamyal ! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/share/classes/sun/awt/OSInfo.java + test/javax/swing/JMenu/8067346/bug8067346.java Changeset: 53700840d4d5 Author: ssadetsky Date: 2015-10-05 15:13 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/53700840d4d5 8058959: closed/java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically Reviewed-by: alexsch, serb ! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java Changeset: b5125fa7ef4b Author: ssadetsky Date: 2015-10-05 15:29 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5125fa7ef4b 8079595: Resizing dialog which is JWindow parent makes JVM crash Reviewed-by: alexsch, serb ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp + test/java/awt/Frame/FrameResize/ShowChildWhileResizingTest.java Changeset: 9b0e9d8ccccf Author: psadhukhan Date: 2015-10-05 15:36 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9b0e9d8ccccf 8132985: Crash in freetypescaler.c due to double free Reviewed-by: prr, simonis ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c + test/java/awt/FontClass/FontDisposer/FontDisposeTest.java Changeset: eafaa1778c63 Author: mcherkas Date: 2015-10-06 10:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eafaa1778c63 8086038: [macosx] No available data flavors when copying from Microsoft Word for Mac Reviewed-by: serb, alexsch ! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m Changeset: 95263779ee37 Author: ddehaven Date: 2015-10-06 12:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/95263779ee37 Merge Changeset: b89f353e2f9a Author: serb Date: 2015-10-07 19:47 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b89f353e2f9a 4763438: Replace uses of @beaninfo with meta facility in core j2se Reviewed-by: alexsch, erikj ! make/gensrc/GensrcSwing.gmk ! src/java.desktop/share/classes/java/awt/Button.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Container.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/beans/SimpleBeanInfo.java ! src/java.desktop/share/classes/javax/accessibility/AccessibleContext.java ! src/java.desktop/share/classes/javax/swing/AbstractButton.java ! src/java.desktop/share/classes/javax/swing/Box.java ! src/java.desktop/share/classes/javax/swing/ImageIcon.java ! src/java.desktop/share/classes/javax/swing/JApplet.java ! src/java.desktop/share/classes/javax/swing/JButton.java ! src/java.desktop/share/classes/javax/swing/JCheckBox.java ! src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/java.desktop/share/classes/javax/swing/JColorChooser.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JDesktopPane.java ! src/java.desktop/share/classes/javax/swing/JDialog.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JFileChooser.java ! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java ! src/java.desktop/share/classes/javax/swing/JFrame.java ! src/java.desktop/share/classes/javax/swing/JInternalFrame.java ! src/java.desktop/share/classes/javax/swing/JLabel.java ! src/java.desktop/share/classes/javax/swing/JLayeredPane.java ! src/java.desktop/share/classes/javax/swing/JList.java ! src/java.desktop/share/classes/javax/swing/JMenu.java ! src/java.desktop/share/classes/javax/swing/JMenuBar.java ! src/java.desktop/share/classes/javax/swing/JMenuItem.java ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/javax/swing/JPanel.java ! src/java.desktop/share/classes/javax/swing/JPasswordField.java ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java ! src/java.desktop/share/classes/javax/swing/JProgressBar.java ! src/java.desktop/share/classes/javax/swing/JRadioButton.java ! src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/javax/swing/JScrollBar.java ! src/java.desktop/share/classes/javax/swing/JScrollPane.java ! src/java.desktop/share/classes/javax/swing/JSeparator.java ! src/java.desktop/share/classes/javax/swing/JSlider.java ! src/java.desktop/share/classes/javax/swing/JSpinner.java ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! src/java.desktop/share/classes/javax/swing/JTabbedPane.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/JTextArea.java ! src/java.desktop/share/classes/javax/swing/JTextField.java ! src/java.desktop/share/classes/javax/swing/JTextPane.java ! src/java.desktop/share/classes/javax/swing/JToggleButton.java ! src/java.desktop/share/classes/javax/swing/JToolBar.java ! src/java.desktop/share/classes/javax/swing/JToolTip.java ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/JViewport.java ! src/java.desktop/share/classes/javax/swing/JWindow.java ! src/java.desktop/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java ! src/java.desktop/share/classes/javax/swing/table/TableColumn.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/java.desktop/share/classes/javax/swing/tree/VariableHeightLayoutCache.java Changeset: aafc0a279f95 Author: psadhukhan Date: 2015-10-12 15:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aafc0a279f95 8072682: getBounds call on graphics.getDeviceConfiguration() returning cached information Reviewed-by: serb, flar ! src/java.desktop/share/classes/sun/awt/image/BufferedImageGraphicsConfig.java + test/java/awt/Graphics2D/DeviceBounds.java Changeset: bdc017c292af Author: serb Date: 2015-10-12 16:26 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bdc017c292af 8136858: Examine the usage of ThreadGroup.stop() in sun.awt.AppContext Reviewed-by: alexsch, chegar ! src/java.desktop/share/classes/sun/awt/AppContext.java + test/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java + test/java/awt/AppContext/ApplicationThreadsStop/java.policy Changeset: 4b901a05d4ee Author: prr Date: 2015-10-12 14:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4b901a05d4ee Merge - src/java.base/share/classes/sun/misc/ConditionLock.java - src/java.base/share/classes/sun/misc/IOUtils.java - src/java.base/share/classes/sun/misc/Lock.java Changeset: daf3f9e17405 Author: serb Date: 2015-10-13 14:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/daf3f9e17405 8066904: NullPointerException when calling ImageIO.read(InputStream) with corrupt BMP Reviewed-by: serb, prr Contributed-by: Jayathirth D V ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/iio-plugin.properties + test/javax/imageio/plugins/bmp/Bug8066904.java Changeset: 54a5ff7b22b6 Author: prr Date: 2015-10-20 08:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/54a5ff7b22b6 Merge - src/java.base/share/native/libfdlibm/s_cbrt.c Changeset: 3b02e93e1f9d Author: prr Date: 2015-10-20 10:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3b02e93e1f9d Merge Changeset: f4b410327913 Author: jbachorik Date: 2015-10-20 20:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f4b410327913 8139870: sun.management.LazyCompositeData.isTypeMatched() fails for composite types with items of ArrayType Reviewed-by: dfuchs ! src/java.management/share/classes/sun/management/LazyCompositeData.java + test/sun/management/LazyCompositeDataTest.java Changeset: 4bedcee102c4 Author: zmajo Date: 2015-10-05 10:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4bedcee102c4 8137173: @HotSpotIntrinsicCandidate is not Oracle-specific Summary: Change the description of the @HotSpotIntrinsicCandidate annotation. Reviewed-by: mr, alanb ! src/java.base/share/classes/jdk/internal/HotSpotIntrinsicCandidate.java Changeset: a1029a7e5efe Author: amurillo Date: 2015-10-08 14:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a1029a7e5efe Merge Changeset: a0917b713fda Author: dsamersoff Date: 2015-09-24 20:40 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0917b713fda 8086134: Deadlock detection fails to attach to core file Summary: Test reimplemented for jtreg Reviewed-by: jbachorik + test/sun/tools/jstack/DeadlockDetectionTest.java Changeset: 8a9a7b1a3210 Author: jwilhelm Date: 2015-09-28 15:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a9a7b1a3210 Merge Changeset: 703df4322ebb Author: dsamersoff Date: 2015-10-01 10:33 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/703df4322ebb 8133063: Remove BasicLauncherTest from the problem list Summary: Remove BasicLauncherTest from the problem list Reviewed-by: jbachorik ! test/ProblemList.txt Changeset: 593313eedbb0 Author: jwilhelm Date: 2015-10-07 00:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/593313eedbb0 Merge Changeset: 12c67db03ee7 Author: jbachorik Date: 2015-10-02 18:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/12c67db03ee7 8138748: ManagementAgent.status DCMD fails with NPE for JMX configured on command line Reviewed-by: sspitsyn, dsamersoff, olagneau ! src/java.management/share/classes/sun/management/Agent.java + test/sun/management/jmxremote/startstop/JMXStatus1Test.java + test/sun/management/jmxremote/startstop/JMXStatus2Test.java ! test/sun/management/jmxremote/startstop/JMXStatusTest.java Changeset: 3691b2ca322d Author: jbachorik Date: 2015-10-08 09:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3691b2ca322d 8138579: Custom launcher fails to start because of permission problem Reviewed-by: sspitsyn, dsamersoff ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java Changeset: 6bacc922bef7 Author: jwilhelm Date: 2015-10-15 13:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6bacc922bef7 Merge Changeset: de4d2d6b5530 Author: twisti Date: 2015-10-08 13:32 -1000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de4d2d6b5530 8136421: JEP 243: Java-Level JVM Compiler Interface Reviewed-by: ihse, alanb, roland, coleenp, iveresov, kvn, kbarrett ! make/src/classes/build/tools/module/boot.modules Changeset: dd09922656aa Author: dlong Date: 2015-10-09 02:43 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dd09922656aa Merge Changeset: 8ed2bee756d6 Author: redestad Date: 2015-10-12 15:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ed2bee756d6 8134607: Remove per-compiler performance counters Reviewed-by: twisti, neliasso ! src/java.management/share/classes/sun/management/CompilerThreadStat.java ! src/java.management/share/classes/sun/management/HotspotCompilation.java ! src/java.management/share/classes/sun/management/HotspotCompilationMBean.java Changeset: ab8c2b15a29a Author: dlong Date: 2015-10-17 15:41 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab8c2b15a29a Merge Changeset: eb6219ff2930 Author: amurillo Date: 2015-10-19 12:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb6219ff2930 Merge Changeset: 92ff2c7d2c50 Author: amurillo Date: 2015-10-20 11:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/92ff2c7d2c50 Merge ! test/ProblemList.txt Changeset: 796a4f0d5082 Author: amurillo Date: 2015-10-20 17:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/796a4f0d5082 Merge Changeset: d715a59bca20 Author: rriggs Date: 2015-10-21 14:18 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d715a59bca20 8138963: java.lang.Objects new method to default to non-null Summary: add java.util.Object.nonNullElse and nonNullElseGet Reviewed-by: dfuchs, jrose, psandoz, smarks, igerasim, chegar ! src/java.base/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 9a84eb7c34e1 Author: igerasim Date: 2015-10-21 22:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a84eb7c34e1 8139373: [TEST_BUG] java/net/MulticastSocket/MultiDead.java failed with timeout Reviewed-by: chegar ! test/java/net/MulticastSocket/MultiDead.java ! test/lib/testlibrary/jdk/testlibrary/Utils.java Changeset: 26690783d6fd Author: sjiang Date: 2015-05-07 09:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/26690783d6fd 8078440: Safer managed types Reviewed-by: dfuchs, ahgross ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java Changeset: a0e3501ef531 Author: smarks Date: 2015-05-08 15:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0e3501ef531 8076413: Better JRMP message handling Reviewed-by: coffeys, igerasim, ahgross ! src/java.rmi/share/classes/sun/rmi/transport/DGCClient.java Changeset: e803843a9a36 Author: serb Date: 2015-05-23 02:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e803843a9a36 8080541: More direct property handling Reviewed-by: prr, alexsch ! src/java.desktop/share/classes/java/beans/PropertyDescriptor.java Changeset: 3975503a71c5 Author: weijun Date: 2015-05-24 16:35 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3975503a71c5 8048030: Expectations should be consistent Reviewed-by: valeriep, mullan, ahgross ! src/java.base/share/classes/javax/security/auth/AuthPermission.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/java.security.jgss/share/classes/org/ietf/jgss/GSSName.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/java.security.jgss/share/classes/sun/security/jgss/wrapper/GSSNameElement.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbServiceLocator.java ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java ! src/java.security.jgss/share/classes/sun/security/krb5/Realm.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/name/Constructors.java Changeset: 662689223d73 Author: joehw Date: 2015-05-26 10:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/662689223d73 8078427: More supportive home environment Reviewed-by: dfuchs, lancea, skoivu ! src/java.base/share/conf/security/java.security ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/lang/SecurityManager/RestrictedPackages.java Changeset: 7cdc4d83ad66 Author: dtitov Date: 2015-06-09 11:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7cdc4d83ad66 8080246: JNLP app cannot be launched due to deadlock Reviewed-by: serb, vdrozdov ! src/java.desktop/share/classes/sun/awt/SunToolkit.java Changeset: 2fed1d855201 Author: prr Date: 2015-06-16 14:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2fed1d855201 8086092: More palette improvements Reviewed-by: bae, serb, mschoene ! make/lib/Awt2dLibraries.gmk Changeset: 323d428e6f0f Author: jbachorik Date: 2015-06-15 12:58 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/323d428e6f0f 8087350: Improve array conversions Reviewed-by: dfuchs, ahgross ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java Changeset: aa49cbb03b23 Author: ptbrunet Date: 2015-06-25 15:00 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aa49cbb03b23 8129611: Accessbridge error handling improvement Reviewed-by: prr, ahgross, asmotrak Contributed-by: peter.brunet at oracle.com ! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp ! src/jdk.accessibility/windows/native/common/AccessBridgeDebug.h ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp Changeset: 56af9a78c8b7 Author: smarks Date: 2015-06-25 16:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/56af9a78c8b7 8080688: Service for DGC services Reviewed-by: skoivu, igerasim, jeff ! src/java.rmi/share/classes/sun/rmi/transport/DGCImpl.java Changeset: 21be49e17e72 Author: chegar Date: 2015-06-29 11:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/21be49e17e72 8103671: More objective stream classes Reviewed-by: rriggs, igerasim ! src/java.base/share/classes/java/io/ObjectStreamClass.java Changeset: 6b7960246d55 Author: juh Date: 2015-06-30 14:22 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6b7960246d55 8081744: Clear out list corner case Reviewed-by: mullan, rhalade ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java Changeset: 5bf77113d49b Author: chegar Date: 2015-07-03 14:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5bf77113d49b 8130253: ObjectStreamClass.getFields too restrictive Reviewed-by: igerasim, skoivu ! src/java.base/share/classes/java/io/ObjectStreamClass.java Changeset: 76abc44582c5 Author: michaelm Date: 2015-07-09 13:23 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76abc44582c5 8130193: Improve HTTP connections Reviewed-by: alanb ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: 271003ea3228 Author: xuelei Date: 2015-07-13 13:37 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/271003ea3228 8130864: Better server identity handling Reviewed-by: jnimeh, asmotrak, ahgross ! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java Changeset: 1fc869ad86a0 Author: ptbrunet Date: 2015-07-14 17:06 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1fc869ad86a0 8130185: More accessible access switch Reviewed-by: prr, ahgross, asmotrak Contributed-by: peter.brunet at oracle.com ! src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp Changeset: 5a5525f17ba1 Author: xuelei Date: 2015-07-20 01:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a5525f17ba1 8081760: Better group dynamics Summary: Allows user to specify custom DH groups. Also reviewed by Alexander Fomin . Reviewed-by: coffeys, mullan, weijun, jnimeh, ahgross, asmotrak ! src/java.base/share/classes/sun/security/ssl/DHCrypt.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java ! src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java ! src/java.base/share/conf/security/java.security ! test/sun/security/ssl/DHKeyExchange/DHEKeySizing.java Changeset: 4a64fcb2f34f Author: smarks Date: 2015-07-20 14:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4a64fcb2f34f 8076339: Better handling of remote object invocation Reviewed-by: asmotrak, igerasim, skoivu ! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java Changeset: a9dbc8a56c73 Author: vinnie Date: 2015-07-24 16:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a9dbc8a56c73 8131291: Perfect parameter patterning Reviewed-by: mullan ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java Changeset: a4dd1239afd6 Author: prr Date: 2015-07-24 09:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a4dd1239afd6 8103675: Better Binary searches Reviewed-by: srl, serb, mschoene ! src/java.desktop/share/native/libfontmanager/layout/LookupTables.cpp Changeset: 7b7c731a73d1 Author: prr Date: 2015-07-29 11:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7b7c731a73d1 8132042: Preserve layout presentation Reviewed-by: mschoene, srl, serb ! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor.cpp ! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor.h ! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor2.cpp ! src/java.desktop/share/native/libfontmanager/layout/IndicRearrangementProcessor2.h ! src/java.desktop/share/native/libfontmanager/layout/MorphTables.cpp ! src/java.desktop/share/native/libfontmanager/layout/MorphTables2.cpp ! src/java.desktop/share/native/libfontmanager/layout/SegmentArrayProcessor.cpp ! src/java.desktop/share/native/libfontmanager/layout/SegmentArrayProcessor2.cpp ! src/java.desktop/share/native/libfontmanager/layout/SegmentSingleProcessor2.cpp ! src/java.desktop/share/native/libfontmanager/layout/SimpleArrayProcessor2.cpp ! src/java.desktop/share/native/libfontmanager/layout/SingleTableProcessor.cpp Changeset: 49760292750d Author: bpb Date: 2015-08-06 10:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/49760292750d 8130891: (bf) More direct buffering Summary: Improve non-byte direct buffering. Reviewed-by: alanb, jeff, ahgross, robm, rriggs ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: b30f4c331df7 Author: coffeys Date: 2015-09-01 18:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b30f4c331df7 8133196: HTTPS hostname invalid issue with InetAddress Reviewed-by: chegar, xuelei ! src/java.base/share/classes/java/net/Inet4Address.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/native/libnet/InetAddress.c ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h + test/java/net/InetAddress/getOriginalHostName.java Changeset: 5dcf71508c1f Author: chegar Date: 2015-09-08 12:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5dcf71508c1f 8135043: ObjectStreamClass.getField(String) too restrictive Reviewed-by: igerasim ! src/java.base/share/classes/java/io/ObjectStreamClass.java + test/java/io/ObjectInputStream/TestObjectStreamClass.java Changeset: a6edbf822256 Author: chegar Date: 2015-10-12 10:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a6edbf822256 8139352: java/net/InetAddress/getOriginalHostName.java fails to compile Reviewed-by: mchung, henryjen ! test/java/net/InetAddress/getOriginalHostName.java Changeset: 35f286a7dd46 Author: lana Date: 2015-10-21 18:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/35f286a7dd46 Merge Changeset: f92824cdbaf3 Author: erikj Date: 2015-10-22 12:12 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f92824cdbaf3 8140223: fix the build with a toolchain with a linker defaulting to ld --as-needed Reviewed-by: erikj, ihse Contributed-by: doko at ubuntu.com ! make/launcher/Launcher-jdk.pack200.gmk ! make/lib/Awt2dLibraries.gmk Changeset: d93844d0cdd5 Author: lancea Date: 2015-10-22 11:36 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d93844d0cdd5 8139056: Add convenience methods to Statement.java Reviewed-by: joehw, rriggs ! src/java.sql/share/classes/java/sql/Statement.java + test/java/sql/testng/test/sql/CallableStatementTests.java + test/java/sql/testng/test/sql/PreparedStatementTests.java + test/java/sql/testng/test/sql/StatementTests.java + test/java/sql/testng/util/StubCallableStatement.java + test/java/sql/testng/util/StubPreparedStatement.java + test/java/sql/testng/util/StubStatement.java Changeset: 7ee964fb0608 Author: jjg Date: 2015-10-22 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ee964fb0608 8140325: Incorrect package.html file Reviewed-by: darcy ! src/java.base/share/classes/overview-core.html ! src/java.naming/share/classes/javax/naming/spi/package.html Changeset: eec915634930 Author: lana Date: 2015-10-22 11:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eec915634930 Merge Changeset: eb131795e76e Author: naoto Date: 2015-10-22 21:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb131795e76e 8136668: Default locale provider adapter incorrectly set to JRE Reviewed-by: okutsu ! make/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java Changeset: 7e55cb303917 Author: naoto Date: 2015-10-22 21:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7e55cb303917 8134720: Lazy initialization support for currency names in DecimalFormatSymbols Reviewed-by: okutsu ! src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java ! src/java.base/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/java.base/share/classes/sun/util/locale/provider/CalendarProviderImpl.java ! src/java.base/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/java.base/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/java.base/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java Changeset: 3349db932831 Author: stuefe Date: 2015-10-07 15:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3349db932831 8139037: [aix] Crash in ResolverConfigurationImpl.c - pointer shearing Reviewed-by: goetz, simonis ! src/java.base/unix/native/libnet/ResolverConfigurationImpl.c Changeset: 0f6c981f1cbf Author: mhaupt Date: 2015-10-27 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0f6c981f1cbf 8136967: revert all changes applied to obtain information about 8131129 Reviewed-by: sundar ! src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java Changeset: 6d88d51aa352 Author: vtewari Date: 2015-10-27 10:14 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d88d51aa352 8068887: java.lang.Throwable could use Collections.emptyList for suppressedException Summary: java.lang.Throwable could use Collections.emptyList for suppressedException Reviewed-by: mchung, alanb, shade, redestad ! src/java.base/share/classes/java/lang/Throwable.java Changeset: 8271f42bae4a Author: bchristi Date: 2015-10-27 09:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8271f42bae4a 8138824: java.lang.String: spec doesn't match impl when ignoring case - equalsIgnoreCase(), regionMatches() Reviewed-by: naoto, rriggs ! src/java.base/share/classes/java/lang/String.java + test/java/lang/String/EqualsIgnoreCase.java Changeset: 2cdd66d42587 Author: jbachorik Date: 2015-09-23 14:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2cdd66d42587 7199353: Define ConstructorProperties annotation type for MXBeans Reviewed-by: duke ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java + src/java.management/share/classes/javax/management/ConstructorProperties.java ! src/java.management/share/classes/javax/management/MXBean.java ! test/javax/management/Introspector/AnnotationSecurityTest.java ! test/javax/management/Introspector/Described.java ! test/javax/management/Introspector/DescribedMX.java + test/javax/management/Introspector/LegacyConstructorPropertiesTest.java ! test/javax/management/mxbean/AmbiguousConstructorTest.java ! test/javax/management/mxbean/ExceptionDiagnosisTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MXBeanTest.java ! test/javax/management/mxbean/PropertyNamesTest.java ! test/javax/management/mxbean/TigerMXBean.java Changeset: d68de0bab8ee Author: jbachorik Date: 2015-10-16 06:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d68de0bab8ee 8139725: Backout escaped partial fix for JDK-7199353 Reviewed-by: alanb ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java - src/java.management/share/classes/javax/management/ConstructorProperties.java ! src/java.management/share/classes/javax/management/MXBean.java ! test/javax/management/Introspector/AnnotationSecurityTest.java ! test/javax/management/Introspector/Described.java ! test/javax/management/Introspector/DescribedMX.java - test/javax/management/Introspector/LegacyConstructorPropertiesTest.java ! test/javax/management/mxbean/AmbiguousConstructorTest.java ! test/javax/management/mxbean/ExceptionDiagnosisTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MXBeanTest.java ! test/javax/management/mxbean/PropertyNamesTest.java ! test/javax/management/mxbean/TigerMXBean.java Changeset: d8a2e5cf4627 Author: jprovino Date: 2015-10-20 11:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d8a2e5cf4627 Merge Changeset: de3398e1b429 Author: amurillo Date: 2015-10-22 16:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/de3398e1b429 Merge Changeset: f70dcc362579 Author: amurillo Date: 2015-10-26 17:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f70dcc362579 Merge Changeset: 0d0a63b32559 Author: amurillo Date: 2015-10-27 10:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d0a63b32559 Merge Changeset: b433e4dfb830 Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b433e4dfb830 Added tag jdk9-b89 for changeset 0d0a63b32559 ! .hgtags Changeset: 19c5d1129851 Author: lana Date: 2015-10-30 10:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/19c5d1129851 Added tag jdk9-b90 for changeset b433e4dfb830 ! .hgtags Changeset: 2e63fa2efdb1 Author: shurailine Date: 2015-10-27 20:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2e63fa2efdb1 8140336: Add @modules for exported dependencies to jdk_core tests Reviewed-by: alanb, mchung ! test/java/lang/ProcessHandle/TEST.properties ! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java ! test/java/lang/instrument/AddTransformerTest.java ! test/java/lang/instrument/AppendToBootstrapClassPathTest.java ! test/java/lang/instrument/AppendToClassPathTest.java ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/FromShutdownHook.java ! test/java/lang/instrument/GetAllLoadedClassesTest.java ! test/java/lang/instrument/GetInitiatedClassesTest.java ! test/java/lang/instrument/GetObjectSizeTest.java ! test/java/lang/instrument/IsModifiableClassAgent.java ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/NativeMethodPrefixAgent.java ! test/java/lang/instrument/NoTransformerAddedTest.java ! test/java/lang/instrument/NullGetObjectSizeTest.java ! test/java/lang/instrument/NullRedefineClassesTests.java ! test/java/lang/instrument/NullTransformerAddTest.java ! test/java/lang/instrument/NullTransformerRemoveTest.java ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/PremainClass/InheritAgent0010.java ! test/java/lang/instrument/PremainClass/InheritAgent0011.java ! test/java/lang/instrument/PremainClass/InheritAgent0110.java ! test/java/lang/instrument/PremainClass/InheritAgent0111.java ! test/java/lang/instrument/PremainClass/InheritAgent1000.java ! test/java/lang/instrument/PremainClass/InheritAgent1001.java ! test/java/lang/instrument/PremainClass/InheritAgent1010.java ! test/java/lang/instrument/PremainClass/InheritAgent1011.java ! test/java/lang/instrument/PremainClass/InheritAgent1100.java ! test/java/lang/instrument/PremainClass/InheritAgent1101.java ! test/java/lang/instrument/PremainClass/InheritAgent1110.java ! test/java/lang/instrument/PremainClass/InheritAgent1111.java ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineClassesDisabledTest.java ! test/java/lang/instrument/RedefineClassesTests.java ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/RedefineMethodDelInvoke.sh ! test/java/lang/instrument/RedefineMethodInBacktrace.sh ! test/java/lang/instrument/RedefineMethodWithAnnotations.sh ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh ! test/java/lang/instrument/RemoveAbsentTransformerTest.java ! test/java/lang/instrument/RemoveTransformerTest.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/SingleTransformerTest.java ! test/java/lang/instrument/StressGetObjectSizeTest.sh + test/java/lang/instrument/TEST.properties ! test/java/lang/instrument/TransformMethodTest.java ! test/java/lang/instrument/TransformerManagementThreadAddTests.java ! test/java/lang/instrument/TransformerManagementThreadRemoveTests.java ! test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java ! test/java/lang/invoke/lambda/LambdaAsm.java ! test/java/lang/invoke/lambda/LambdaStackTrace.java ! test/jdk/lambda/TEST.properties ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java ! test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java ! test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java Changeset: 03453e4301fc Author: redestad Date: 2015-10-28 12:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03453e4301fc 6823565: Excessive use of HandleList class in de-serialization code causes OutOfMemory Reviewed-by: chegar, shade ! src/java.base/share/classes/java/io/ObjectInputStream.java Changeset: 71e43dd2e0b9 Author: naoto Date: 2015-10-26 19:49 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/71e43dd2e0b9 8061287: Update i18n tests to remove references of jre dir Summary: Updated PropertiesTest.sh to remove references of jre dir. Reviewed-by: naoto, peytoia Contributed-by: Rachna Goel ! test/java/util/Currency/PropertiesTest.sh Changeset: d7caf74c48ab Author: redestad Date: 2015-10-28 23:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7caf74c48ab 8066644: Fix deprecation warnings in jdk.zipfs module Reviewed-by: sherman, shade Contributed-by: Peter Levart , Claes Redestad ! src/java.base/share/classes/java/util/zip/ZipUtils.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java Changeset: a0eb148fa9d5 Author: ihse Date: 2015-10-29 16:31 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0eb148fa9d5 8140661: Rename LDFLAGS_SUFFIX to LIBS Reviewed-by: erikj ! make/CompileDemos.gmk ! make/launcher/Launcher-java.base.gmk ! make/launcher/Launcher-jdk.accessibility.gmk ! make/launcher/Launcher-jdk.jconsole.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-java.management.gmk ! make/lib/Lib-java.prefs.gmk ! make/lib/Lib-java.security.jgss.gmk ! make/lib/Lib-java.smartcardio.gmk ! make/lib/Lib-jdk.accessibility.gmk ! make/lib/Lib-jdk.attach.gmk ! make/lib/Lib-jdk.crypto.ec.gmk ! make/lib/Lib-jdk.crypto.mscapi.gmk ! make/lib/Lib-jdk.crypto.pkcs11.gmk ! make/lib/Lib-jdk.crypto.ucrypto.gmk ! make/lib/Lib-jdk.deploy.osx.gmk ! make/lib/Lib-jdk.internal.le.gmk ! make/lib/Lib-jdk.jdi.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk ! make/lib/Lib-jdk.management.gmk ! make/lib/Lib-jdk.pack200.gmk ! make/lib/Lib-jdk.sctp.gmk ! make/lib/Lib-jdk.security.auth.gmk ! make/lib/NetworkingLibraries.gmk ! make/lib/NioLibraries.gmk ! make/lib/PlatformLibraries.gmk ! make/lib/SecurityLibraries.gmk ! make/lib/SoundLibraries.gmk Changeset: bd6ca4cbfa4f Author: ascarpino Date: 2015-10-29 09:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bd6ca4cbfa4f 8139859: TestRSA.java: 'message larger than modulus' using SunRsaSign KeyFactory Reviewed-by: xuelei ! test/ProblemList.txt ! test/com/oracle/security/ucrypto/TestRSA.java Changeset: 071b08d30f81 Author: lana Date: 2015-10-29 12:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/071b08d30f81 Merge Changeset: 97624df5026a Author: lana Date: 2015-11-04 13:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/97624df5026a Merge Changeset: 30cae8145c33 Author: mchung Date: 2015-11-11 15:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30cae8145c33 Merge ! .hgtags ! make/CompileDemos.gmk ! make/CompileInterimRmic.gmk ! make/gendata/Gendata-java.base.gmk - make/gendata/Gendata-jdk.jdeps.gmk - make/gensrc/Gensrc-jdk.dev.gmk ! make/gensrc/GensrcSwing.gmk ! make/launcher/Launcher-java.base.gmk ! make/launcher/Launcher-jdk.accessibility.gmk - make/launcher/Launcher-jdk.dev.gmk ! make/launcher/Launcher-jdk.jconsole.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-java.management.gmk ! make/lib/Lib-java.prefs.gmk ! make/lib/Lib-java.security.jgss.gmk ! make/lib/Lib-java.smartcardio.gmk ! make/lib/Lib-jdk.accessibility.gmk ! make/lib/Lib-jdk.attach.gmk ! make/lib/Lib-jdk.crypto.ec.gmk ! make/lib/Lib-jdk.crypto.mscapi.gmk ! make/lib/Lib-jdk.crypto.pkcs11.gmk ! make/lib/Lib-jdk.deploy.osx.gmk ! make/lib/Lib-jdk.internal.le.gmk ! make/lib/Lib-jdk.jdi.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk ! make/lib/Lib-jdk.management.gmk ! make/lib/Lib-jdk.pack200.gmk ! make/lib/Lib-jdk.sctp.gmk ! make/lib/Lib-jdk.security.auth.gmk ! make/lib/NetworkingLibraries.gmk ! make/lib/NioLibraries.gmk ! make/lib/PlatformLibraries.gmk ! make/lib/SecurityLibraries.gmk ! make/lib/SoundLibraries.gmk ! make/mapfiles/libjava/mapfile-vers - make/scripts/localelist.sh - make/src/classes/build/tools/module/GenJdepsModulesXml.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java - make/src/classes/build/tools/module/ModuleArchive.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java - src/java.base/share/classes/jdk/internal/jimage/Archive.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java + src/java.base/share/classes/module-info.java - src/java.base/share/classes/sun/misc/Launcher.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java ! src/java.base/share/conf/security/java.security - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c ! src/java.base/share/native/libzip/zip_util.c - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/beans/PropertyDescriptor.java ! src/java.desktop/share/classes/javax/swing/JEditorPane.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/sun/management/Agent.java - src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService - src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider ! test/ProblemList.txt ! test/java/lang/SecurityManager/CheckPackageAccess.java ! test/java/lang/instrument/NativeMethodPrefixAgent.java ! test/java/lang/instrument/RedefineMethodInBacktrace.sh ! test/java/lang/instrument/SingleTransformerTest.java ! test/java/lang/instrument/TransformMethodTest.java ! test/java/lang/invoke/lambda/LambdaAsm.java - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java ! test/java/rmi/registry/readTest/readTest.sh ! test/javax/management/mxbean/LeakTest.java - test/jdk/internal/jimage/ExecutableTest.java - test/jdk/internal/jimage/JImageTest.java - test/jdk/internal/jimage/VerifyJimage.java ! test/sun/management/jmxremote/bootstrap/CustomLauncherTest.java ! test/sun/misc/JarIndex/metaInfFilenames/Basic.java ! test/sun/security/krb5/auto/SSL.java Changeset: 46891039e911 Author: mchung Date: 2015-11-12 15:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46891039e911 Merge ! make/gensrc/GensrcModuleLoaderMap.gmk ! src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java Changeset: 52814ae373b7 Author: mchung Date: 2015-11-12 19:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/52814ae373b7 Update module-info.java for jdk9-b91 ! src/java.base/share/classes/module-info.java ! src/jdk.internal.le/share/classes/module-info.java Changeset: a28acd9a8c74 Author: mchung Date: 2015-11-12 19:25 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a28acd9a8c74 Merge Changeset: 13e434966a52 Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/13e434966a52 Added tag jdk9-b91 for changeset 97624df5026a ! .hgtags Changeset: 7f6a82dc978e Author: rriggs Date: 2015-10-30 11:12 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f6a82dc978e 8139390: Very long classname in jimage causes SIGSEGV Summary: Correct issues with ImageNativeSubstrate and JImageReadTest Reviewed-by: mchung ! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp ! src/java.base/share/native/libjimage/jimage.cpp ! test/jdk/internal/jimage/JImageReadTest.java Changeset: 8bd5a6e85a2f Author: simonis Date: 2015-11-02 14:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bd5a6e85a2f 8140514: [TESTBUG] enable sun/security/pkcs11 tests on Linux/ppc64 Reviewed-by: wetmore ! test/sun/security/pkcs11/PKCS11Test.java Changeset: 185252122a39 Author: naoto Date: 2015-11-02 08:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/185252122a39 8062006: Add a new locale data name "COMPAT" for java.locale.providers system property to reduce ambiguity Reviewed-by: okutsu ! src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! test/java/util/Locale/LocaleProviders.sh Changeset: 9fef91483af7 Author: vlivanov Date: 2015-10-19 17:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9fef91483af7 8139881: Exclude java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java from execution Reviewed-by: kvn ! test/java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java Changeset: 5ff0a80ee6c7 Author: dlong Date: 2015-10-27 01:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5ff0a80ee6c7 Merge - src/java.base/share/classes/sun/misc/ConditionLock.java - src/java.base/share/classes/sun/misc/IOUtils.java - src/java.base/share/classes/sun/misc/Lock.java - src/java.base/share/native/libfdlibm/s_cbrt.c Changeset: 780bec42fe40 Author: amurillo Date: 2015-10-30 12:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/780bec42fe40 Merge Changeset: 5afa5a406c20 Author: amurillo Date: 2015-11-02 10:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5afa5a406c20 Merge Changeset: a21b0e82392d Author: jbachorik Date: 2015-09-23 14:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a21b0e82392d 8139727: Define ConstructorParameters annotation type for MXBeans Reviewed-by: alanb, mchung, dfuchs, abuckley, plevart, mr ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java + src/java.management/share/classes/javax/management/ConstructorParameters.java ! src/java.management/share/classes/javax/management/MXBean.java ! test/javax/management/Introspector/AnnotationSecurityTest.java ! test/javax/management/Introspector/Described.java ! test/javax/management/Introspector/DescribedMX.java + test/javax/management/Introspector/LegacyConstructorPropertiesTest.java ! test/javax/management/mxbean/AmbiguousConstructorTest.java ! test/javax/management/mxbean/ExceptionDiagnosisTest.java ! test/javax/management/mxbean/LeakTest.java ! test/javax/management/mxbean/MXBeanTest.java ! test/javax/management/mxbean/PropertyNamesTest.java ! test/javax/management/mxbean/TigerMXBean.java Changeset: 226cd203e48a Author: ihse Date: 2015-11-03 16:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/226cd203e48a 6512052: Remove java-rmi.exe and java-rmi.cgi Reviewed-by: alanb ! make/launcher/Launcher-java.rmi.gmk - src/java.rmi/unix/bin/java-rmi.cgi.sh Changeset: 7d07e7aa69ef Author: rriggs Date: 2015-11-03 10:20 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d07e7aa69ef 8139345: java/lang/ProcessHandle/TreeTest.java test fails with ... Wrong number of children expected [3] but found [2] Reviewed-by: darcy ! test/java/lang/ProcessHandle/TreeTest.java Changeset: b6c25628a82d Author: ihse Date: 2015-11-03 17:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b6c25628a82d 8141261: Clean up building of demos Reviewed-by: erikj, tbell ! make/CompileDemos.gmk Changeset: 30a4e10baf9c Author: ihse Date: 2015-11-03 17:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30a4e10baf9c 8141333: Rename SetupArchive to SetupJarArchive Reviewed-by: erikj, tbell ! make/gendata/GendataPolicyJars.gmk Changeset: b66591d98c6b Author: serb Date: 2015-10-18 13:33 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b66591d98c6b 6815345: java.awt.Component.createImage(int width,int height) should remove behavioral optionality Reviewed-by: prr, ssadetsky ! src/java.desktop/share/classes/java/awt/Component.java + test/java/awt/Component/CreateImage/CreateImage.java Changeset: ddc8bbf88d36 Author: yan Date: 2015-10-20 12:42 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ddc8bbf88d36 8136592: [TEST_BUG] Fix 2 platform-specific closed regtests for jigsaw Reviewed-by: serb, yan Contributed-by: Renjith Alexander + test/java/awt/EmbeddedFrame/GraphicsConfigTest/GraphicsConfigTest.java + test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html + test/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.java Changeset: f574643a1c16 Author: ssadetsky Date: 2015-10-20 15:42 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f574643a1c16 8011616: JWindow.getLocation and JWindow.getLocationOnScreen return different values on Unity Reviewed-by: alexsch, serb ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java + test/java/awt/Window/ScreenLocation/ScreenLocationTest.java Changeset: 7993027bcb2f Author: ssadetsky Date: 2015-10-20 15:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7993027bcb2f 8022334: After calling frame.toBack() dialog goes to the back on Ubuntu 12.04 Reviewed-by: alexsch, serb ! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java + test/java/awt/Window/MultiWindowApp/MultiWindowAppTest.java Changeset: 4d719805b1f1 Author: aivanov Date: 2015-10-20 16:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d719805b1f1 8130136: Swing window sometimes fails to repaint partially when it becomes exposed Reviewed-by: alexp, serb ! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.cpp ! src/java.desktop/windows/native/libawt/java2d/windows/GDIWindowSurfaceData.h ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Component.h Changeset: b70f060eadf7 Author: serb Date: 2015-10-20 22:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b70f060eadf7 7182758: BMPMetadata returns invalid PhysicalPixelSpacing Reviewed-by: serb, vadim Contributed-by: Jayathirth D V ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java + test/javax/imageio/plugins/bmp/BMPPixelSpacingTest.java Changeset: c62b791a8960 Author: serb Date: 2015-10-21 18:32 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c62b791a8960 8138764: In some cases the usage of TreeLock can be replaced by other synchronization Reviewed-by: alexp, alexsch ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/sun/swing/CachedPainter.java + test/java/awt/Component/TreeLockDeadlock/TreeLockDeadlock.java Changeset: 3fdbedd9ff1b Author: mcherkas Date: 2015-10-21 18:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3fdbedd9ff1b 8136763: [macosx] java always returns only one value for "text/uri-list" dataflavor even if several files were copied Reviewed-by: alexsch, serb ! src/java.datatransfer/macosx/classes/sun/datatransfer/resources/flavormap.properties ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java + test/java/awt/datatransfer/DataFlavor/MacOsXFileAndMultipleFileCopingTest/MacOsXFileAndMultipleFileCopingTest.java - test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java Changeset: edec0fe63ceb Author: prr Date: 2015-10-21 09:21 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/edec0fe63ceb 8132890: Text overlapping on dot matrix printers. Reviewed-by: jgodinez, serb ! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java ! test/java/awt/print/PrinterJob/PrintTextTest.java Changeset: 0746c20f1365 Author: serb Date: 2015-10-21 21:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0746c20f1365 8041900: [macosx] Java forces the use of discrete GPU Reviewed-by: ssadetsky, alexsch ! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m Changeset: deb544c19dec Author: sebastian Date: 2015-10-22 13:46 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/deb544c19dec 8139754: Change Boolean constructor use to the use of Boolean factorymethods. For the macosx-port-dev area Reviewed-by: serb, alexsch ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 8bf32c4c2332 Author: prr Date: 2015-10-23 10:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bf32c4c2332 Merge - src/java.base/share/native/libfdlibm/s_cbrt.c Changeset: 14f8bca09c9b Author: ddehaven Date: 2015-11-03 09:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/14f8bca09c9b Merge - test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java Changeset: 240ca1b2eb59 Author: darcy Date: 2015-11-03 17:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/240ca1b2eb59 8141368: Typo in java/lang/Class/IsEnum.java test Reviewed-by: jjg ! test/java/lang/Class/IsEnum.java Changeset: 76203cb95f2c Author: simonis Date: 2015-11-04 12:46 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/76203cb95f2c 8141290: AIX: fix build after '8140661: Rename LDFLAGS_SUFFIX to LIBS' Reviewed-by: ihse ! make/lib/Awt2dLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk Changeset: 034043795e42 Author: psandoz Date: 2015-11-04 16:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/034043795e42 8033148: Lexicographic comparators for arrays Reviewed-by: jrose, chegar, bchristi, mduigou ! src/java.base/share/classes/java/lang/Byte.java ! src/java.base/share/classes/java/lang/Short.java ! src/java.base/share/classes/java/util/Arrays.java + test/java/util/Arrays/ArraysEqCmpTest.java Changeset: ff09a5eddc89 Author: darcy Date: 2015-11-04 09:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ff09a5eddc89 8141359: @Deprecated on packages should be clarified Reviewed-by: rriggs ! src/java.base/share/classes/java/lang/Deprecated.java Changeset: d3f793857ca3 Author: darcy Date: 2015-11-04 11:27 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d3f793857ca3 8141454: Move java/lang/ProcessHandle/TreeTest.java until stability improves Reviewed-by: rriggs ! test/TEST.groups Changeset: 9ecb10ce62c6 Author: bpb Date: 2015-11-04 14:06 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9ecb10ce62c6 8140630: java/nio/Buffer/Basic.java crashes vm on linux-x64 using latest devkit to build Summary: Build Bits.c at a lower optimization level on linux-x64. Reviewed-by: tbell ! make/lib/CoreLibraries.gmk Changeset: 20ccac7e0705 Author: ihse Date: 2015-11-05 10:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/20ccac7e0705 8141444: Clean up building of JDK launchers Reviewed-by: erikj ! make/launcher/Launcher-java.base.gmk ! make/launcher/Launcher-java.corba.gmk ! make/launcher/Launcher-java.desktop.gmk ! make/launcher/Launcher-java.rmi.gmk ! make/launcher/Launcher-java.scripting.gmk ! make/launcher/Launcher-java.security.jgss.gmk ! make/launcher/Launcher-jdk.compiler.gmk ! make/launcher/Launcher-jdk.dev.gmk ! make/launcher/Launcher-jdk.hotspot.agent.gmk ! make/launcher/Launcher-jdk.jartool.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jcmd.gmk ! make/launcher/Launcher-jdk.jconsole.gmk ! make/launcher/Launcher-jdk.jdeps.gmk ! make/launcher/Launcher-jdk.jdi.gmk ! make/launcher/Launcher-jdk.jshell.gmk ! make/launcher/Launcher-jdk.jvmstat.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/Launcher-jdk.policytool.gmk ! make/launcher/Launcher-jdk.rmic.gmk ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk ! make/launcher/Launcher-jdk.xml.bind.gmk ! make/launcher/Launcher-jdk.xml.ws.gmk ! make/launcher/LauncherCommon.gmk Changeset: 67d91e7479c1 Author: lancea Date: 2015-11-05 10:37 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67d91e7479c1 8136496: Add Connection.begin/endRequest Reviewed-by: joehw, rriggs, psandoz ! src/java.sql/share/classes/java/sql/Connection.java ! src/java.sql/share/classes/javax/sql/PooledConnection.java Changeset: a16ce5acb643 Author: redestad Date: 2015-11-05 16:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a16ce5acb643 8141539: Avoid calculating string constants in InnerClassLambdaMetaFactory Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 6c9b3dc5bf6b Author: redestad Date: 2015-11-05 16:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6c9b3dc5bf6b 8141536: MethodType field offset calculation could be lazy Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/MethodType.java Changeset: 5b710994aafb Author: lancea Date: 2015-11-05 14:57 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b710994aafb 8141546: Fix javadoc warnings in Connection due to 8136496 Reviewed-by: alanb ! src/java.sql/share/classes/java/sql/Connection.java Changeset: 6a5c99506f44 Author: lana Date: 2015-11-05 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6a5c99506f44 Merge - src/java.rmi/unix/bin/java-rmi.cgi.sh - test/java/awt/datatransfer/DataFlavor/XJavaUrlDataFlavorTest/XJavaUrlDataFlavorTest.java Changeset: 16fc042acee6 Author: lana Date: 2015-11-12 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/16fc042acee6 Added tag jdk9-b92 for changeset 6a5c99506f44 ! .hgtags Changeset: 950cdf782005 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/950cdf782005 Merge ! .hgtags ! make/CompileDemos.gmk - make/gendata/Gendata-jdk.jdeps.gmk ! make/gendata/GendataPolicyJars.gmk - make/gensrc/Gensrc-jdk.dev.gmk ! make/launcher/Launcher-java.base.gmk ! make/launcher/Launcher-java.corba.gmk ! make/launcher/Launcher-java.desktop.gmk ! make/launcher/Launcher-java.rmi.gmk ! make/launcher/Launcher-java.scripting.gmk ! make/launcher/Launcher-java.security.jgss.gmk ! make/launcher/Launcher-jdk.compiler.gmk - make/launcher/Launcher-jdk.dev.gmk ! make/launcher/Launcher-jdk.hotspot.agent.gmk ! make/launcher/Launcher-jdk.jartool.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jcmd.gmk ! make/launcher/Launcher-jdk.jconsole.gmk ! make/launcher/Launcher-jdk.jdeps.gmk ! make/launcher/Launcher-jdk.jdi.gmk + make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.jshell.gmk ! make/launcher/Launcher-jdk.jvmstat.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/Launcher-jdk.policytool.gmk ! make/launcher/Launcher-jdk.rmic.gmk ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk ! make/launcher/Launcher-jdk.xml.bind.gmk ! make/launcher/Launcher-jdk.xml.ws.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk - make/scripts/localelist.sh - make/src/classes/build/tools/module/GenJdepsModulesXml.java - make/src/classes/build/tools/module/GenModulesList.java - make/src/classes/build/tools/module/ImageBuilder.java - make/src/classes/build/tools/module/ModuleArchive.java - make/src/classes/build/tools/module/boot.modules - make/src/classes/build/tools/module/ext.modules - src/java.base/share/classes/jdk/internal/jimage/Archive.java - src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java - src/java.base/share/classes/jdk/internal/jimage/ExternalFilesWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageFileCreator.java - src/java.base/share/classes/jdk/internal/jimage/ImageLocationWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageModuleDataWriter.java - src/java.base/share/classes/jdk/internal/jimage/ImageResourcesTree.java - src/java.base/share/classes/jdk/internal/jimage/ImageStringsWriter.java - src/java.base/share/classes/jdk/internal/jimage/PerfectHashBuilder.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java - src/java.base/share/classes/jdk/internal/jimage/ResourcePoolImpl.java - src/java.base/share/classes/sun/misc/Launcher.java - src/java.base/share/classes/sun/util/CoreResourceBundleControl-XLocales.java.template ! src/java.base/share/native/launcher/defines.h ! src/java.base/share/native/launcher/main.c - src/java.base/share/native/libjava/Package.c - src/java.base/share/native/libjava/Proxy.c ! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp ! src/java.base/share/native/libjimage/jimage.cpp ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java - src/java.desktop/share/classes/META-INF/services/java.net.ContentHandlerFactory - src/java.desktop/share/classes/META-INF/services/javax.print.PrintServiceLookup - src/java.desktop/share/classes/META-INF/services/javax.print.StreamPrintServiceFactory - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiDeviceProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.MidiFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.midi.spi.SoundbankReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileReader - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.AudioFileWriter - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider - src/java.desktop/share/classes/META-INF/services/javax.sound.sampled.spi.MixerProvider - src/java.desktop/share/classes/META-INF/services/sun.datatransfer.DesktopDatatransferService ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java - src/java.security.jgss/share/classes/META-INF/services/sun.security.ssl.ClientKeyExchangeService - src/jdk.accessibility/windows/classes/META-INF/services/javax.accessibility.AccessibilityProvider - src/jdk.attach/share/classes/META-INF/services/com.sun.tools.attach.spi.AttachProvider - src/jdk.charsets/share/classes/META-INF/services/java.nio.charset.spi.CharsetProvider - src/jdk.dev/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java - src/jdk.dev/share/classes/jdk/tools/jimage/Main.java - src/jdk.dev/share/classes/jdk/tools/jimage/TaskHelper.java - src/jdk.dev/share/classes/jdk/tools/jimage/resources/jimage.properties - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector - src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.spi.TransportService - src/jdk.jvmstat/share/classes/META-INF/services/sun.jvmstat.monitor.MonitoredHostService - src/jdk.localedata/share/classes/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo - src/jdk.management/share/classes/META-INF/services/sun.management.spi.PlatformMBeanProvider - src/jdk.naming.dns/share/classes/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - src/jdk.zipfs/share/classes/META-INF/services/java.nio.file.spi.FileSystemProvider ! test/TEST.groups - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh - test/java/net/DatagramSocket/SetDatagramSocketImplFactory/java/net/MyDatagramSocketImplFactory.java ! test/java/util/Locale/LocaleProviders.sh ! test/javax/management/mxbean/LeakTest.java - test/jdk/internal/jimage/ExecutableTest.java ! test/jdk/internal/jimage/JImageReadTest.java - test/jdk/internal/jimage/JImageTest.java - test/jdk/internal/jimage/VerifyJimage.java ! test/sun/security/pkcs11/PKCS11Test.java From mandy.chung at oracle.com Sat Nov 14 04:23:50 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:23:50 +0000 Subject: hg: jigsaw/jake/jaxws: 12 new changesets Message-ID: <201511140423.tAE4NptV000049@aojmv0008.oracle.com> Changeset: 136e8bcba562 Author: lana Date: 2015-10-19 00:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/136e8bcba562 Added tag jdk9-b87 for changeset f7dba191a38c ! .hgtags Changeset: 3d533243505d Author: aefimov Date: 2015-10-16 19:07 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/3d533243505d 8073519: schemagen does not report errors while generating xsd files Reviewed-by: dfuchs ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java Changeset: f6425fec60ab Author: lana Date: 2015-10-21 15:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/f6425fec60ab Merge Changeset: 2d84c6f4cbba Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2d84c6f4cbba Added tag jdk9-b88 for changeset f6425fec60ab ! .hgtags Changeset: b3e45213d574 Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/b3e45213d574 Added tag jdk9-b89 for changeset 2d84c6f4cbba ! .hgtags Changeset: 3b2a3cb658e4 Author: lana Date: 2015-10-30 10:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/3b2a3cb658e4 Added tag jdk9-b90 for changeset b3e45213d574 ! .hgtags Changeset: 35b9769a8003 Author: mchung Date: 2015-11-12 11:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/35b9769a8003 Merge Changeset: 59060592a8fc Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/59060592a8fc Added tag jdk9-b91 for changeset 3b2a3cb658e4 ! .hgtags Changeset: 63c89fbee619 Author: mkos Date: 2015-10-30 10:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/63c89fbee619 8139743: Update JAX-WS RI integration to latest version (2.3.0-SNAPSHOT) Reviewed-by: lancea ! src/java.xml.bind/share/classes/com/sun/istack/internal/logging/Logger.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/AccessorFactoryImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/DatatypeConverterImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/api/JAXBRIContext.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/DataWriter.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/NamespacePrefixMapper.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/marshaller/XMLWriter.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ContextFactory.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/WellKnownNamespace.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementInfo.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/ElementPropertyInfo.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/RegistryInfo.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/core/package-info.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/DummyPropertyInfo.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimeClassInfo.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/runtime/RuntimePropertyInfo.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/package-info.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/AssociationMap.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/MarshallerImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/NamespaceContext2.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/RuntimeUtil.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/C14nXmlOutput.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/FastInfosetStreamWriterOutput.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/NamespaceContextImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/LocatorEx.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XmlVisitor.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/schemagen/Util.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/CleanUpExecutorFactory.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/DecodingException.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FinalArrayList.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEConfig.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEMessage.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/MIMEParser.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/WeakDataFile.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/staxex/util/XMLStreamReaderToXMLStreamWriter.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/Document.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/ResultFactory.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/txw2/output/XMLWriter.java ! src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java ! src/java.xml.ws/share/classes/com/oracle/webservices/internal/api/message/MessageContextFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/MessagingException.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/BMMimeMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentDisposition.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ContentType.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/HeaderTokenizer.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/InternetHeaders.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeBodyPart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimePullMultipart.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/MimeUtility.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/ParameterList.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/internet/UniqueValue.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/packaging/mime/util/OutputUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ContextClassloaderLocal.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/EnvelopeFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ImageDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/SOAPFactoryImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxReaderBridge.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StringDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/XmlDataContentHandler.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/dynamic/SOAPMessageFactoryDynamicImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/DetailImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/ElementImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/EnvelopeImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/HeaderImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Fault1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/Header1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_1/SOAPPart1_1Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Body1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Fault1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/Header1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/HeaderElement1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/ver1_2/SOAPPart1_2Impl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/Base64.java - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/FastInfosetReflection.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/FinalArrayList.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JAXMStreamSource.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/JaxmURI.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/ParseUtil.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/XMLDeclarationParser.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriterEx.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/BindingIDFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/MessageContextFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/Packet.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/message/saaj/SAAJFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/FiberContextSwitchInterceptor.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/client/package-info.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/db/DatabindingImpl.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/package-info.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/privateutil/ServiceFinder.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/server/package-info.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/db/BindingContext.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/spi/db/BindingContextFactory.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - src/java.xml.ws/share/classes/javax/xml/soap/package.html ! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JAnnotationUse.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JClass.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExpr.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JExpression.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/JJavaName.java ! src/jdk.xml.bind/share/classes/com/sun/codemodel/internal/package-info.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ConfigReader.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/Const.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/ModelLoader.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/Plugin.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/J2SJAXBModel.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/Mapping.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/S2JJAXBModel.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/SchemaCompiler.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/XJC.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/package.html ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CElementInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CEnumLeafInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/nav/NavigatorImpl.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/model/package-info.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/package-info.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/Const.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIAttribute.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIConstructor.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIContent.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIConversion.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIElement.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIEnumeration.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIInterface.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BIUserConversion.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMBuilder.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/InternalizationLogic.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/internalizer/Internalizer.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/relaxng/DatatypeLib.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/BGMBuilder.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/DefaultClassBinder.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/SimpleTypeBuilder.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIConversion.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIEnum.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIGlobalBinding.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIInlineBinaryData.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BISchemaBinding.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BIXDom.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/EnumMemberMode.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/CustomizationContextChecker.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/SchemaConstraintChecker.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/parser/XMLSchemaInternalizationLogic.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/DTDEventListener.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/DTDParser.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/EntityDecl.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/InputEntity.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/MessageCatalog.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/Resolver.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/XmlChars.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/XmlReader.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/dtdparser/resources/Messages.properties ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/Datatype.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeBuilder.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeException.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeLibrary.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeLibraryFactory.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/DatatypeStreamingValidator.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/ValidationContext.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/ParameterlessDatatypeBuilder.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/org/relaxng/datatype/helpers/StreamingValidatorImpl.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/Grammar.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/GrammarSection.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/IncludedGrammar.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/ast/builder/SchemaBuilder.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DChoicePattern.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DDataPattern.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/digested/DGrammarPattern.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/rngom/nc/NameClass.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/XSSchema.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/XSTerm.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/parser/state/NGCCRuntime.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/scd/Iterators.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/scd/ParseException.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/impl/util/SchemaTreeTraverser.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/parser/AnnotationParser.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/parser/XSOMParser.java ! src/jdk.xml.bind/share/classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/package-info.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/Options.java Changeset: fe772cbc64f4 Author: lana Date: 2015-11-05 13:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fe772cbc64f4 Merge - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharReader.java - src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/util/CharWriter.java - src/java.xml.ws/share/classes/javax/xml/soap/package.html - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_de.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_es.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_it.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_de.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_es.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_fr.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_it.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ja.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_ko.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_pt_BR.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_CN.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ap/MessageBundle_zh_TW.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/FilerCodeWriter.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.java - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_de.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_es.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_fr.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_it.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ja.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_ko.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_pt_BR.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_CN.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/Messages_zh_TW.properties - src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/api/util/package.html Changeset: 5e94fbbb7032 Author: lana Date: 2015-11-12 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/5e94fbbb7032 Added tag jdk9-b92 for changeset fe772cbc64f4 ! .hgtags Changeset: fa025bbc0479 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fa025bbc0479 Merge ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/ClassFactory.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/model/impl/ClassInfoImpl.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/runtime/reflect/Accessor.java ! src/java.xml.bind/share/classes/com/sun/xml/internal/org/jvnet/mimepull/FactoryFinder.java ! src/java.xml.ws/share/classes/javax/xml/ws/spi/FactoryFinder.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/ConfigReader.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/dtd/bindinfo/BindInfo.java ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/reader/xmlschema/bindinfo/BindInfo.java From mandy.chung at oracle.com Sat Nov 14 04:24:43 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:24:43 +0000 Subject: hg: jigsaw/jake/corba: 13 new changesets Message-ID: <201511140424.tAE4OhrR000263@aojmv0008.oracle.com> Changeset: 00f48ecbc099 Author: lana Date: 2015-10-19 00:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/00f48ecbc099 Added tag jdk9-b87 for changeset a5c40ac9b916 ! .hgtags Changeset: 98075de2b055 Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/98075de2b055 Added tag jdk9-b88 for changeset 00f48ecbc099 ! .hgtags Changeset: e2c563af9ef4 Author: msheppar Date: 2015-06-25 13:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e2c563af9ef4 8076383: Better CORBA exception handling Reviewed-by: rriggs, coffeys, skoivu, ahgross ! src/jdk.rmic/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: dc8238c2c66a Author: msheppar Date: 2015-07-14 16:49 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/dc8238c2c66a 8076392: Improve IIOPInputStream consistency Reviewed-by: rriggs, coffeys, skoivu, ahgross ! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java Changeset: a88d571b42b6 Author: msheppar Date: 2015-07-14 18:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/a88d571b42b6 8076387: Better CORBA value handling Reviewed-by: rriggs, coffeys, skoivu, ahgross ! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java Changeset: ab90c50a6a13 Author: lana Date: 2015-10-21 18:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/ab90c50a6a13 Merge Changeset: c847a53b38d2 Author: lana Date: 2015-10-22 11:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/c847a53b38d2 Merge Changeset: 29cc8228d623 Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/29cc8228d623 Added tag jdk9-b89 for changeset c847a53b38d2 ! .hgtags Changeset: 75843e0a9371 Author: lana Date: 2015-10-30 10:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/75843e0a9371 Added tag jdk9-b90 for changeset 29cc8228d623 ! .hgtags Changeset: e9dd95120409 Author: mchung Date: 2015-11-12 11:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/e9dd95120409 Merge ! src/java.corba/share/classes/com/sun/corba/se/impl/io/IIOPOutputStream.java Changeset: f7d70caad89a Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f7d70caad89a Added tag jdk9-b91 for changeset 75843e0a9371 ! .hgtags Changeset: f82629452836 Author: lana Date: 2015-11-12 10:38 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f82629452836 Added tag jdk9-b92 for changeset f7d70caad89a ! .hgtags Changeset: 86606630eb99 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/86606630eb99 Merge From mandy.chung at oracle.com Sat Nov 14 04:24:55 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:24:55 +0000 Subject: hg: jigsaw/jake/langtools: 39 new changesets Message-ID: <201511140424.tAE4OtV4000289@aojmv0008.oracle.com> Changeset: 288f18dd9157 Author: lana Date: 2015-10-19 00:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/288f18dd9157 Added tag jdk9-b87 for changeset 45f796d8cdcd ! .hgtags Changeset: 79e637c1e083 Author: mcimadamore Date: 2015-10-12 12:24 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/79e637c1e083 8138840: NPE when compiling bitwise operations with illegal operand types 8139243: compiler crashes with exception on sum operation of String var and void method call result 8139249: Compiler crashes on unary bitwise complement with non-integral operand Summary: Certain binary operator checks are accepting more operands than required. Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Operators.java + test/tools/javac/8138840/T8138840.java + test/tools/javac/8138840/T8138840.out + test/tools/javac/8138840/T8139243.java + test/tools/javac/8138840/T8139243.out + test/tools/javac/8138840/T8139249.java + test/tools/javac/8138840/T8139249.out Changeset: 700677b16a97 Author: sadayapalam Date: 2015-10-12 19:43 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/700677b16a97 8139245: compiler crashes with exception on int:new method reference and generic method inference Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.java + test/tools/javac/lambda/methodReference/MethodRefIntColonColonNewTest.out Changeset: 814a0cab8c90 Author: sadayapalam Date: 2015-10-13 09:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/814a0cab8c90 8000316: Huge performance bottleneck in com.sun.tools.javac.comp.Check.localClassName Summary: Speed up Check.localClassName by avoiding generating names known to be in use already Reviewed-by: mcimadamore, jlahoda, sadayapalam Contributed-by: dmitry.chuyko at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/T8000316/T8000316.java Changeset: 575ea88f69a5 Author: chegar Date: 2015-10-13 09:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/575ea88f69a5 8139371: Three langtools test failures after the removal of sun.misc.Lock Reviewed-by: jjg, mchung ! test/tools/javac/proprietary/WarnClass.java ! test/tools/javac/proprietary/WarnClass.out ! test/tools/javac/warnings/6594914/T6594914b.java ! test/tools/javac/warnings/6594914/T6594914b.out ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/m/Gee.java Changeset: 126e5c6abd1d Author: lana Date: 2015-10-15 16:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/126e5c6abd1d Merge Changeset: ac57d80b205d Author: lana Date: 2015-10-21 15:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ac57d80b205d Merge Changeset: 4789df418bc3 Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4789df418bc3 Added tag jdk9-b88 for changeset ac57d80b205d ! .hgtags Changeset: 23f76aadbb36 Author: ksrini Date: 2015-09-11 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/23f76aadbb36 8078320: Improve DocTrees parsing. Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocPretty.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/tools/javac/doctree/DocCommentTester.java ! test/tools/javac/doctree/ElementTest.java ! test/tools/javac/doctree/FirstSentenceTest.java + test/tools/javac/doctree/InPreTest.java ! test/tools/javac/doctree/TagTest.java Changeset: 777c5a760a84 Author: jlahoda Date: 2015-10-19 12:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/777c5a760a84 8139751: Javac crash with -XDallowStringFolding=false Summary: When string folding is disabled, need to keep the original expression. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/parser/StringFoldingTest.java Changeset: 15bdc18525ff Author: jlahoda Date: 2015-10-19 19:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/15bdc18525ff 8134254: JShell API/tool: REPL for Java into JDK9 Summary: Adding the implementation of the jshell (read-eval-print-loop) tool. Reviewed-by: briangoetz, mcimadamore, psandoz, forax Contributed-by: robert.field at oracle.com, bitterfoxc at gmail.com, jan.lahoda at oracle.com ! make/build.properties ! make/build.xml + make/gensrc/Gensrc-jdk.jshell.gmk ! make/intellij/langtools.iml ! make/intellij/workspace.xml ! make/launcher.sh-template ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml + make/tools/anttasks/DumpClassesTask.java ! make/tools/anttasks/SelectToolTask.java + src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java + src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java + src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteClassLoader.java + src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteCodes.java + src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteResolutionException.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditPad.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditingHistory.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ExternalEditor.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/StopDetectingInputStream.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/version.properties-template + src/jdk.jshell/share/classes/jdk/jshell/ClassTracker.java + src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java + src/jdk.jshell/share/classes/jdk/jshell/DeclarationSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/Diag.java + src/jdk.jshell/share/classes/jdk/jshell/DiagList.java + src/jdk.jshell/share/classes/jdk/jshell/ErroneousSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/Eval.java + src/jdk.jshell/share/classes/jdk/jshell/EvalException.java + src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java + src/jdk.jshell/share/classes/jdk/jshell/ExpressionSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/GeneralWrap.java + src/jdk.jshell/share/classes/jdk/jshell/ImportSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/JDIConnection.java + src/jdk.jshell/share/classes/jdk/jshell/JDIEnv.java + src/jdk.jshell/share/classes/jdk/jshell/JDIEventHandler.java + src/jdk.jshell/share/classes/jdk/jshell/JDINotConnectedException.java + src/jdk.jshell/share/classes/jdk/jshell/JShell.java + src/jdk.jshell/share/classes/jdk/jshell/Key.java + src/jdk.jshell/share/classes/jdk/jshell/KeyMap.java + src/jdk.jshell/share/classes/jdk/jshell/MaskCommentsAndModifiers.java + src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java + src/jdk.jshell/share/classes/jdk/jshell/MethodSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/OuterWrap.java + src/jdk.jshell/share/classes/jdk/jshell/PersistentSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/ReplParser.java + src/jdk.jshell/share/classes/jdk/jshell/ReplParserFactory.java + src/jdk.jshell/share/classes/jdk/jshell/ReplResolve.java + src/jdk.jshell/share/classes/jdk/jshell/Snippet.java + src/jdk.jshell/share/classes/jdk/jshell/SnippetEvent.java + src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java + src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java + src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + src/jdk.jshell/share/classes/jdk/jshell/StatementSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java + src/jdk.jshell/share/classes/jdk/jshell/TreeDependencyScanner.java + src/jdk.jshell/share/classes/jdk/jshell/TreeDissector.java + src/jdk.jshell/share/classes/jdk/jshell/TypeDeclSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/TypePrinter.java + src/jdk.jshell/share/classes/jdk/jshell/Unit.java + src/jdk.jshell/share/classes/jdk/jshell/UnresolvedReferenceException.java + src/jdk.jshell/share/classes/jdk/jshell/Util.java + src/jdk.jshell/share/classes/jdk/jshell/VarSnippet.java + src/jdk.jshell/share/classes/jdk/jshell/Wrap.java + src/jdk.jshell/share/classes/jdk/jshell/package-info.java + test/jdk/jshell/AnalysisTest.java + test/jdk/jshell/ClassMembersTest.java + test/jdk/jshell/ClassPathTest.java + test/jdk/jshell/ClassesTest.java + test/jdk/jshell/CommandCompletionTest.java + test/jdk/jshell/Compiler.java + test/jdk/jshell/CompletenessStressTest.java + test/jdk/jshell/CompletenessTest.java + test/jdk/jshell/CompletionSuggestionTest.java + test/jdk/jshell/CustomEditor.java + test/jdk/jshell/DropTest.java + test/jdk/jshell/EditorPadTest.java + test/jdk/jshell/EditorTestBase.java + test/jdk/jshell/EmptyTest.java + test/jdk/jshell/ErrorTranslationTest.java + test/jdk/jshell/ExceptionsTest.java + test/jdk/jshell/ExpectedDiagnostic.java + test/jdk/jshell/ExternalEditorTest.java + test/jdk/jshell/HistoryTest.java + test/jdk/jshell/IOTest.java + test/jdk/jshell/IdGeneratorTest.java + test/jdk/jshell/IgnoreTest.java + test/jdk/jshell/IllegalArgumentExceptionTest.java + test/jdk/jshell/ImportTest.java + test/jdk/jshell/JShellStateClosedTest.java + test/jdk/jshell/KullaCompletenessStressTest.java + test/jdk/jshell/KullaTesting.java + test/jdk/jshell/MethodsTest.java + test/jdk/jshell/ModifiersTest.java + test/jdk/jshell/NullTest.java + test/jdk/jshell/RejectedFailedTest.java + test/jdk/jshell/ReplToolTesting.java + test/jdk/jshell/ReplaceTest.java + test/jdk/jshell/ShutdownTest.java + test/jdk/jshell/SimpleRegressionTest.java + test/jdk/jshell/SnippetStatusListenerTest.java + test/jdk/jshell/SnippetTest.java + test/jdk/jshell/StartOptionTest.java + test/jdk/jshell/StopExecutionTest.java + test/jdk/jshell/TestingInputStream.java + test/jdk/jshell/ToolBasicTest.java + test/jdk/jshell/TypeNameTest.java + test/jdk/jshell/VariablesTest.java Changeset: 161940723360 Author: sadayapalam Date: 2015-10-20 15:25 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/161940723360 8139836: Can't use super::x method reference when x is protected Summary: Javac incorrectly diasllows reference to a protected method from a super class in method reference expressions. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/MethodReference74.java + test/tools/javac/lambda/pkg/Parent.java Changeset: 0cce85265987 Author: sadayapalam Date: 2015-10-21 17:52 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0cce85265987 8138729: javac -parameters should not emit parameter names for lambda expressions Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/MethodParameters/ClassFileVisitor.java ! test/tools/javac/MethodParameters/LambdaTest.java ! test/tools/javac/MethodParameters/LambdaTest.out ! test/tools/javac/MethodParameters/ReflectionVisitor.java Changeset: 96a99cfb21be Author: lana Date: 2015-10-21 18:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/96a99cfb21be Merge Changeset: 820841f0e8bd Author: alundblad Date: 2015-10-22 09:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/820841f0e8bd 8087349: Test tools/sjavac/IncCompInheritance.java is failing Summary: Refactoring of Dependencies framework. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/dependencies/NewDependencyCollector.java ! test/tools/javac/importscope/dependencies/DependenciesTest.java Changeset: 4b374a9b4b22 Author: sadayapalam Date: 2015-10-22 16:18 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4b374a9b4b22 8074803: Name clash Summary: Javac incorrectly reports a name clash. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/NameClash/NameClashTest.java Changeset: 86e463879ae7 Author: mcimadamore Date: 2015-10-22 18:58 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/86e463879ae7 8140333: Tweak langtools IntelliJ project to better support Kulla changes Summary: Add support for target.java.home option to the idea target Reviewed-by: jlahoda ! make/build.xml ! make/intellij/ant.xml ! make/intellij/workspace.xml Changeset: b3f440e93b97 Author: lana Date: 2015-10-22 11:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b3f440e93b97 Merge Changeset: b3ed4ac7cd91 Author: sadayapalam Date: 2015-10-23 08:21 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b3ed4ac7cd91 8057685: javac should not crash compiling type annotations Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java ! test/tools/javac/annotations/typeAnnotations/newlocations/AllLocations.java Changeset: 16873e56156e Author: aeriksso Date: 2015-10-27 10:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/16873e56156e 8134759: jdb: Incorrect stepping inside finally block Summary: Add LineNumberTable attribute for return bytecodes split around finally code Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/linenumbers/FinallyLineNumberTest.java Changeset: 00a25f93cee8 Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/00a25f93cee8 Added tag jdk9-b89 for changeset 16873e56156e ! .hgtags Changeset: 49da3649b796 Author: lana Date: 2015-10-30 10:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/49da3649b796 Added tag jdk9-b90 for changeset 00a25f93cee8 ! .hgtags Changeset: 522e516b8a83 Author: ksrini Date: 2015-10-28 10:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/522e516b8a83 8132096: Augment the Compiler Tree API to support the new Simplified Doclet API Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! test/tools/javac/doctree/DocCommentTester.java ! test/tools/javac/doctree/FirstSentenceTest.java + test/tools/javac/doctree/dcapi/DocCommentTreeApiTester.java + test/tools/javac/doctree/dcapi/OverviewTest.java + test/tools/javac/doctree/dcapi/overview0.html + test/tools/javac/doctree/dcapi/overview1.html + test/tools/javac/doctree/dcapi/overview2.html + test/tools/javac/doctree/dcapi/overview3.html + test/tools/javac/doctree/dcapi/overview4.html + test/tools/javac/doctree/dcapi/overview5.html + test/tools/javac/doctree/dcapi/overview6.html + test/tools/javac/doctree/dcapi/package.html + test/tools/javac/doctree/dcapi/pkg/Anchor.java + test/tools/javac/doctree/dcapi/pkg/package.html ! test/tools/javac/tree/NoPrivateTypesExported.java Changeset: b278abcd113b Author: lana Date: 2015-10-29 12:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b278abcd113b Merge Changeset: 79501a97ca57 Author: lana Date: 2015-11-04 13:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/79501a97ca57 Merge Changeset: 1669922f641d Author: mchung Date: 2015-11-12 11:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1669922f641d Merge ! .hgtags ! make/build.properties ! make/build.xml ! make/launcher.sh-template ! make/netbeans/langtools/build.xml ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java - test/tools/javac/T6873845.java - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out ! test/tools/jdeps/APIDeps.java - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java - test/tools/jdeps/javax/activity/NotCompactProfile.java ! test/tools/jdeps/m/Gee.java Changeset: f6fd3e9f6bc9 Author: mchung Date: 2015-11-12 20:36 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f6fd3e9f6bc9 Merge ! src/jdk.compiler/share/classes/module-info.java + src/jdk.jshell/share/classes/module-info.java Changeset: 9adfacce560e Author: mchung Date: 2015-11-12 20:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9adfacce560e Merge Changeset: ab33a84365a0 Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ab33a84365a0 Added tag jdk9-b91 for changeset 79501a97ca57 ! .hgtags Changeset: 03bb9c99b573 Author: jlahoda Date: 2015-10-30 17:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/03bb9c99b573 8140766: langtools/make/test/sym/CreateSymbolsTest.java contains incorrect paths Summary: Fixing paths in CreateSymbolsTest; fixing imports in CreateSymbolsTestImpl. Reviewed-by: mcimadamore ! make/test/sym/CreateSymbolsTest.java ! make/test/sym/CreateSymbolsTestImpl.java Changeset: 19e44405ab4f Author: ihse Date: 2015-11-03 17:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/19e44405ab4f 8141333: Rename SetupArchive to SetupJarArchive Reviewed-by: erikj, tbell ! make/gendata/Gendata-jdk.compiler.gmk Changeset: 155f6671cab4 Author: alundblad Date: 2015-11-03 21:29 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/155f6671cab4 8137075: Sjavac tests are leaking file managers Summary: Closing sjavac file managers. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/JavacState.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java ! test/tools/sjavac/ApiExtraction.java Changeset: a32f899caa49 Author: alundblad Date: 2015-11-03 22:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a32f899caa49 8141355: PackagePathMismatch.java does not use --state-dir option Summary: Added --state-dir to the PackagePathMismatch.java test. Reviewed-by: jlahoda ! test/tools/sjavac/PackagePathMismatch.java Changeset: 17d15aa9140d Author: alundblad Date: 2015-11-04 12:27 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/17d15aa9140d 8139961: Various sjavac tests result in error on Windows (JPRT) Summary: Test now closes Stream properly. Reviewed-by: jlahoda ! test/tools/sjavac/NoState.java Changeset: 3298cbc00d2f Author: mcimadamore Date: 2015-11-05 11:32 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3298cbc00d2f 8141343: Subtle semantics changes for union types in cast conversion Summary: cast applied to union types do not behave correctly and sometimes pass erroneously Reviewed-by: jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/8141343/T8141343.java + test/tools/javac/cast/8141343/T8141343.out Changeset: a3415b57507c Author: lana Date: 2015-11-05 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a3415b57507c Merge Changeset: 5245927b10eb Author: lana Date: 2015-11-12 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5245927b10eb Added tag jdk9-b92 for changeset a3415b57507c ! .hgtags Changeset: e9ebd8cea634 Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e9ebd8cea634 Merge ! .hgtags ! make/gendata/Gendata-jdk.compiler.gmk ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/CreateSymbols.java - src/jdk.compiler/share/classes/com/sun/tools/javac/sym/Profiles.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ServiceLoader.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/PubApiExtractor.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SjavacImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/AbstractProfileIndexWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ProfileWriterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfilePackageSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/ProfileSummaryWriter.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfilePackageSummaryBuilder.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ProfileSummaryBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulesXmlReader.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/PlatformClassPath.java - test/tools/javac/T6873845.java - test/tools/javac/profiles/ProfileTest.java - test/tools/javac/proprietary/WarnClass.java - test/tools/javac/proprietary/WarnClass.out - test/tools/javac/proprietary/WarnImport.java - test/tools/javac/proprietary/WarnImport.out - test/tools/javac/proprietary/WarnMethod.java - test/tools/javac/proprietary/WarnMethod.out - test/tools/javac/proprietary/WarnStaticImport.java - test/tools/javac/proprietary/WarnStaticImport.out - test/tools/javac/proprietary/WarnVariable.java - test/tools/javac/proprietary/WarnVariable.out - test/tools/javac/proprietary/WarnWildcard.java - test/tools/javac/proprietary/WarnWildcard.out - test/tools/jdeps/VerboseFormat/use/indirect/DontUseUnsafe2.java - test/tools/jdeps/VerboseFormat/use/indirect/UseUnsafeIndirectly.java - test/tools/jdeps/VerboseFormat/use/indirect2/DontUseUnsafe3.java - test/tools/jdeps/VerboseFormat/use/indirect2/UseUnsafeIndirectly2.java - test/tools/jdeps/VerboseFormat/use/unsafe/DontUseUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseClassWithUnsafe.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass.java - test/tools/jdeps/VerboseFormat/use/unsafe/UseUnsafeClass2.java - test/tools/jdeps/javax/activity/NotCompactProfile.java Changeset: 1bace0d78e0a Author: mchung Date: 2015-11-13 20:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1bace0d78e0a Merge - test/tools/javac/Object1.java - test/tools/javac/Object1.out - test/tools/javac/Object2.java - test/tools/javac/Object2.out From mandy.chung at oracle.com Sat Nov 14 04:25:25 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 04:25:25 +0000 Subject: hg: jigsaw/jake/nashorn: 43 new changesets Message-ID: <201511140425.tAE4PPHL000418@aojmv0008.oracle.com> Changeset: 061682b25ca9 Author: lana Date: 2015-10-19 00:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/061682b25ca9 Added tag jdk9-b87 for changeset 0bf2fe0c7b32 ! .hgtags Changeset: 0cae16c0043d Author: attila Date: 2015-10-12 10:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0cae16c0043d 8139273: Small improvements to DynamicLinker and DynamicLinkerFactory Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java Changeset: 494bc9750691 Author: attila Date: 2015-10-12 10:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/494bc9750691 8139274: Use JDK 8 default method for LinkerServices.asTypeLosslessReturn Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java Changeset: 6c6df82265f0 Author: mhaupt Date: 2015-10-12 13:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6c6df82265f0 8139266: add JSAdapter example with fallthrough Reviewed-by: attila, hannesw + samples/jsadapter-fallthrough.js Changeset: 0a640d17732d Author: attila Date: 2015-10-12 13:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0a640d17732d 8139270: Drastically reduce memory footprint of ChainedCallSite Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java Changeset: 022f7146248d Author: attila Date: 2015-10-12 14:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/022f7146248d 8139282: Remove @author and @id tags from Dynalink JavaDoc; some minor edits Reviewed-by: mhaupt, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NoSuchDynamicMethodException.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AccessibleMembersLookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/GuardedInvocationComponent.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java Changeset: 781e7d23a367 Author: lana Date: 2015-10-15 16:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/781e7d23a367 Merge Changeset: a2aa804daac9 Author: lana Date: 2015-10-21 15:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a2aa804daac9 Merge Changeset: 40bda1a456b9 Author: lana Date: 2015-10-22 08:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/40bda1a456b9 Added tag jdk9-b88 for changeset a2aa804daac9 ! .hgtags Changeset: 04ed602df062 Author: attila Date: 2015-10-19 08:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/04ed602df062 8139304: Remove elaborate call site descriptor class hierarchy and factory for them. Remove AutoDiscovery, DefaultPrelinkFilter, and BottomGuardingDynamicLinker as they can be inlined into DynamicLinkerFactory. Remove CallerSensitiveDetector as it can be inlined into AbstractJavaLinker. Make ClassMap non-public. Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassLoaderGetterContextProvider.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java Changeset: 33f2143b60a3 Author: attila Date: 2015-10-19 08:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/33f2143b60a3 8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 7dd80d7f47c3 Author: attila Date: 2015-10-19 08:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7dd80d7f47c3 8139588: Remove concept of runtime context arguments, call site tokens, and link counts Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java Changeset: 335632718c1e Author: attila Date: 2015-10-19 08:45 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/335632718c1e 8139590: Improve Dynalink JavaDoc Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/ConversionComparator.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodHandleTransformer.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodTypeConversionStrategy.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package-info.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html Changeset: f93753325c7b Author: sundar Date: 2015-10-19 15:49 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f93753325c7b 8139852: jjs interactive mode fails to work with security manager Reviewed-by: attila, hannesw ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/PackagesHelper.java Changeset: 1faacf3cd85f Author: attila Date: 2015-10-19 18:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1faacf3cd85f 8139756: Eliminate GuardedTypeConversion, DynamicLinker.getCurrentLinkRequest and its associated permission Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/LinkerServicesImpl.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java Changeset: 17b58e15ad54 Author: attila Date: 2015-10-19 22:36 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/17b58e15ad54 8139884: Use privileged blocks when working with class loaders Reviewed-by: hannesw, mhaupt, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java Changeset: dd36e980905b Author: attila Date: 2015-10-20 23:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/dd36e980905b 8139761: Improve Dynalink class nomenclature and package organization Reviewed-by: hannesw, sundar - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocationTransformer.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeGuardingDynamicLinker.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/DefaultInternalObjectFilter.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/SimpleLinkRequest.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ChainedCallSite.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleLinkRequest.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleRelinkableCallSite.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BoundCallableLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java Changeset: a8d5f14eebcc Author: attila Date: 2015-10-20 23:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a8d5f14eebcc 8139887: Reduce visibility of few methods in TypeUtilities and Guards API Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/internal/InternalTypeUtilities.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/TypeUtilities.java Changeset: c3a5e415a09f Author: attila Date: 2015-10-20 23:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c3a5e415a09f 8139888: Improve Dynalink JavaDoc some more Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package-info.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocationTransformer.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodHandleTransformer.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/MethodTypeConversionStrategy.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package-info.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/DefaultInternalObjectFilter.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/SimpleLinkRequest.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/package-info.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java Changeset: 490cafd88488 Author: attila Date: 2015-10-20 23:34 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/490cafd88488 8139895: Introduce GuardingDynamicLinkerExporter Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinker.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardingDynamicLinkerExporter.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java Changeset: e6bb9489faac Author: attila Date: 2015-10-21 10:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e6bb9489faac 8139905: Add a convenience AccessControlContext factory Reviewed-by: hannesw, sundar - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassLoaderGetterContextProvider.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ClassMap.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/TypeConverterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/ClassString.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/internal/AccessControlContextFactory.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessControlContextFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java Changeset: d35aa8beb997 Author: attila Date: 2015-10-21 10:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/d35aa8beb997 8139919: Make CallSiteDescriptor a concrete class Reviewed-by: hannesw, lagergren, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/SimpleCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 7cb19fa78763 Author: attila Date: 2015-10-21 19:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7cb19fa78763 8139931: Introduce Operation objects in Dynalink instead of string encoding Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CallSiteDescriptor.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/NamedOperation.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/Operation.java + src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/StandardOperation.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package-info.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionCall.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeString.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BoundCallableLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java Changeset: b640f10ccd6d Author: lana Date: 2015-10-21 18:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b640f10ccd6d Merge - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html Changeset: 77d303d8a943 Author: attila Date: 2015-10-22 10:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/77d303d8a943 8140273: restore use of CompositeOperation.contains where it is needed Reviewed-by: hannesw, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/CompositeOperation.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java Changeset: 62641244c378 Author: lana Date: 2015-10-22 11:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/62641244c378 Merge - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/ChainedCallSite.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DefaultBootstrapper.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/GuardedInvocationFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/MonomorphicCallSite.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDetector.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/package.html - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/package.html - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/package.html - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/AutoDiscovery.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/ClassMap.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultInternalObjectFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/DefaultPrelinkFilter.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Guards.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkRequestImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LinkerServicesImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/Lookup.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeConverterFactory.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/TypeUtilities.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/package.html Changeset: bc92163c4e0a Author: lana Date: 2015-10-29 08:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bc92163c4e0a Added tag jdk9-b89 for changeset 62641244c378 ! .hgtags Changeset: f570370bc7b8 Author: lana Date: 2015-10-30 10:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f570370bc7b8 Added tag jdk9-b90 for changeset bc92163c4e0a ! .hgtags Changeset: 6d9a3ef84ebf Author: mhaupt Date: 2015-10-28 10:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6d9a3ef84ebf 8134941: Implement ES6 template literal support Reviewed-by: attila, hannesw Contributed-by: andreas.woess at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Lexer.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Token.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/TokenType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties Changeset: 1ceda730b9a3 Author: mhaupt Date: 2015-10-29 11:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1ceda730b9a3 8140759: add ES6 template literal test Reviewed-by: hannesw, sundar Contributed-by: andreas.woess at oracle.com + test/script/basic/es6/template-literals.js + test/script/basic/es6/template-literals.js.EXPECTED Changeset: f414ae010340 Author: lana Date: 2015-10-29 12:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f414ae010340 Merge Changeset: fee4d2015e24 Author: lana Date: 2015-11-04 13:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fee4d2015e24 Merge Changeset: e7a3b9f01ae4 Author: mchung Date: 2015-11-12 11:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e7a3b9f01ae4 Merge ! .hgtags ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/CheckRestrictedPackage.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Guards.java ! src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 09f1d75775ef Author: lana Date: 2015-11-05 08:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/09f1d75775ef Added tag jdk9-b91 for changeset fee4d2015e24 ! .hgtags Changeset: c7ef0fb26eff Author: attila Date: 2015-11-02 18:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c7ef0fb26eff 8141144: Move NameCodec to jdk.nashorn.internal space Reviewed-by: hannesw, sundar - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: ae3c6d8c1fc4 Author: sundar Date: 2015-11-03 21:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ae3c6d8c1fc4 8141285: NameCode should pass tests from BytecodeNameTest.java Reviewed-by: attila, mhaupt + samples/find_underscores.js ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java + test/src/jdk/nashorn/internal/runtime/linker/test/NameCodecTest.java Changeset: 1d7341033121 Author: ihse Date: 2015-11-03 17:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/1d7341033121 8141333: Rename SetupArchive to SetupJarArchive Reviewed-by: erikj, tbell ! make/BuildNashorn.gmk Changeset: cc95f96b51d8 Author: attila Date: 2015-11-05 12:13 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/cc95f96b51d8 8141425: Improve caching in NashornCallSiteDescriptor Reviewed-by: hannesw, lagergren ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: a8b20725bcf2 Author: attila Date: 2015-11-05 12:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a8b20725bcf2 8141524: CompilerTest execution time dominated by Field.setAccessible Reviewed-by: hannesw, mhaupt, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ASTWriter.java Changeset: 0c621f5166c5 Author: attila Date: 2015-11-05 15:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/0c621f5166c5 8141446: Cache Class.forName for permanently loaded classes Reviewed-by: hannesw, mhaupt, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java Changeset: 34b77a618e98 Author: lana Date: 2015-11-05 13:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/34b77a618e98 Merge - src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/NameCodec.java Changeset: 435d7217b35d Author: lana Date: 2015-11-12 10:39 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/435d7217b35d Added tag jdk9-b92 for changeset 34b77a618e98 ! .hgtags Changeset: 6b4d91e1593d Author: mchung Date: 2015-11-13 19:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/6b4d91e1593d Merge ! .hgtags ! make/BuildNashorn.gmk ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java From mandy.chung at oracle.com Sat Nov 14 05:51:31 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 05:51:31 +0000 Subject: hg: jigsaw/jake: Add hotspot to javadoc -modulesourcepath Message-ID: <201511140551.tAE5pVOr014193@aojmv0008.oracle.com> Changeset: cdf7dd951649 Author: mchung Date: 2015-11-13 21:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/cdf7dd951649 Add hotspot to javadoc -modulesourcepath ! make/Javadoc.gmk From mandy.chung at oracle.com Sat Nov 14 06:20:12 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 14 Nov 2015 06:20:12 +0000 Subject: hg: jigsaw/jake/jdk: Add new modular resource bundle test Message-ID: <201511140620.tAE6KCCk018739@aojmv0008.oracle.com> Changeset: f83388bef364 Author: okutsu Date: 2015-11-13 22:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f83388bef364 Add new modular resource bundle test + test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithNoModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/jdk/embargo/TestWithUnnamedModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/embargo/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResources.java + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/props/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResources.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java + test/java/util/ResourceBundle/modules/visibility/src/named.bundles/module-info.java + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/classes/MyResources.java + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/resources/props/MyResources.properties + test/java/util/ResourceBundle/modules/visibility/src/pkg/jdk/pkg/test/Main.java + test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithNoModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/test/jdk/test/TestWithUnnamedModuleArg.java + test/java/util/ResourceBundle/modules/visibility/src/test/module-info.java + test/java/util/ResourceBundle/modules/visibility/visibility.sh From alan.bateman at oracle.com Sat Nov 14 08:23:46 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 14 Nov 2015 08:23:46 +0000 Subject: hg: jigsaw/jake/jdk: Update JDWP CLassPaths commands to not include bootclasspaths Message-ID: <201511140823.tAE8Nkgb009819@aojmv0008.oracle.com> Changeset: 6276fb427a98 Author: alanb Date: 2015-11-14 08:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6276fb427a98 Update JDWP CLassPaths commands to not include bootclasspaths ! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h From alan.bateman at oracle.com Sat Nov 14 08:35:28 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 14 Nov 2015 08:35:28 +0000 Subject: hg: jigsaw/jake/jdk: appletviewer needs -addmods ALL-SYSTEM Message-ID: <201511140835.tAE8ZSUj012011@aojmv0008.oracle.com> Changeset: c98256f2e102 Author: alanb Date: 2015-11-14 08:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c98256f2e102 appletviewer needs -addmods ALL-SYSTEM ! make/launcher/Launcher-java.desktop.gmk From alan.bateman at oracle.com Sat Nov 14 10:31:33 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 14 Nov 2015 10:31:33 +0000 Subject: hg: jigsaw/jake/langtools: Initial changes to get jshell working Message-ID: <201511141031.tAEAVXlo000276@aojmv0008.oracle.com> Changeset: bcb5a42de9a0 Author: alanb Date: 2015-11-14 10:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/bcb5a42de9a0 Initial changes to get jshell working ! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! test/jdk/jshell/ClassPathTest.java ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/CompletionSuggestionTest.java ! test/jdk/jshell/ErrorTranslationTest.java ! test/jdk/jshell/HistoryTest.java ! test/jdk/jshell/ImportTest.java ! test/jdk/jshell/KullaCompletenessStressTest.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/StopExecutionTest.java From alan.bateman at oracle.com Sat Nov 14 14:44:37 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 14 Nov 2015 14:44:37 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511141444.tAEEibJg011577@aojmv0008.oracle.com> Changeset: 4fd9addf4669 Author: alanb Date: 2015-11-14 11:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4fd9addf4669 Expand test coverage for java -XaddExports Contributed-by: sergei.pikalev at oracle.com ! test/jdk/jigsaw/launcher/addexports/AddExportsTest.java + test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/Transaction.java + test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/InternalTransaction.java + test/jdk/jigsaw/launcher/addexports/src/java.transaction/module-info.java + test/jdk/jigsaw/launcher/addexports/src/one.more/module-info.java + test/jdk/jigsaw/launcher/addexports/src/one.more/one/internal/InternalClass.java + test/jdk/jigsaw/launcher/addexports/src/one.more/one/more/OneMoreClass.java + test/jdk/jigsaw/launcher/addexports/src/testAdd/jdk/test/UsesInternalClass.java + test/jdk/jigsaw/launcher/addexports/src/testAdd/module-info.java + test/jdk/jigsaw/launcher/addexports/src/testUpgrade/jdk/test/UsesInternalTransaction.java + test/jdk/jigsaw/launcher/addexports/src/testUpgrade/module-info.java Changeset: b7d2a7346aa6 Author: alanb Date: 2015-11-14 14:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b7d2a7346aa6 Minor clean-up of tests for -XaddExports ! test/jdk/jigsaw/launcher/addexports/AddExportsTest.java ! test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/Helper.java < test/jdk/jigsaw/launcher/addexports/src/java.transaction/javax/transaction/internal/InternalTransaction.java + test/jdk/jigsaw/launcher/addexports/src/m1/jdk/test1/Main.java + test/jdk/jigsaw/launcher/addexports/src/m1/module-info.java ! test/jdk/jigsaw/launcher/addexports/src/m2/jdk/test2/Main.java < test/jdk/jigsaw/launcher/addexports/src/testUpgrade/jdk/test/UsesInternalTransaction.java ! test/jdk/jigsaw/launcher/addexports/src/m2/module-info.java < test/jdk/jigsaw/launcher/addexports/src/testUpgrade/module-info.java + test/jdk/jigsaw/launcher/addexports/src/m3/jdk/test3/Main.java + test/jdk/jigsaw/launcher/addexports/src/m3/module-info.java + test/jdk/jigsaw/launcher/addexports/src/m4/jdk/test4/Type.java + test/jdk/jigsaw/launcher/addexports/src/m4/module-info.java - test/jdk/jigsaw/launcher/addexports/src/one.more/module-info.java - test/jdk/jigsaw/launcher/addexports/src/one.more/one/internal/InternalClass.java - test/jdk/jigsaw/launcher/addexports/src/one.more/one/more/OneMoreClass.java - test/jdk/jigsaw/launcher/addexports/src/test/jdk/test/UsesUnsafe.java - test/jdk/jigsaw/launcher/addexports/src/test/module-info.java - test/jdk/jigsaw/launcher/addexports/src/testAdd/jdk/test/UsesInternalClass.java - test/jdk/jigsaw/launcher/addexports/src/testAdd/module-info.java From alan.bateman at oracle.com Sat Nov 14 14:55:42 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 14 Nov 2015 14:55:42 +0000 Subject: hg: jigsaw/jake/jdk: J2DBench demo doesn't need BCP Message-ID: <201511141455.tAEEtg9a013557@aojmv0008.oracle.com> Changeset: 5c676ed31145 Author: alanb Date: 2015-11-14 14:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c676ed31145 J2DBench demo doesn't need BCP ! src/demo/share/java2d/J2DBench/src/j2dbench/ResultSet.java From Alan.Bateman at oracle.com Sat Nov 14 15:20:36 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Nov 2015 15:20:36 +0000 Subject: JDeps: detecting offending packages In-Reply-To: References: Message-ID: <56475144.9030205@oracle.com> On 13/11/2015 21:58, Robert Scholte wrote: > : > > Previous versions of JDK9 gave me the following output: > > classes -> java.base > (classes) > -> java.io > -> java.lang > -> sun.misc JDK > internal API (java.base) > > > The current b86 gives me: > > classes -> java.base > (classes) > -> java.io > -> java.lang > -> sun.misc > > So why this change? And is there another way to detect the usage of > non-accessible classes? > > The maven-plugin has a parameter called failOnWarning (default:true) > which should break the build in order to help developers to change > their code when they rely on internal classes. In the regular JDK 9 EA builds then a usage of sun.misc.BASE64Decoder will be reported as a usage of a JDK internal API. Not so with the Jigsaw builds because package sun.misc is temporarily exported by module java.base. This means that all public types in that package are accessible. This might seem surprising but it is because we're not there yet with JEP 260 [1]. Once JEP 260 is further along thne the critical internal APIs listed in JEP 260 will be accessible. The non-critical internal APIs will be encapsulated. For the Maven plugin then maybe it might be better to choose a JDK-internal type that is not in sun.misc or sun.reflect. That would keep your test stable while we work through all the transition issues. -Alan [1] http://openjdk.java.net/jeps/260 From mandy.chung at oracle.com Sat Nov 14 16:05:25 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 14 Nov 2015 08:05:25 -0800 Subject: JDeps: detecting offending packages In-Reply-To: <56475144.9030205@oracle.com> References: <56475144.9030205@oracle.com> Message-ID: <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com> > On Nov 14, 2015, at 7:20 AM, Alan Bateman wrote: > > On 13/11/2015 21:58, Robert Scholte wrote: >> : >> >> Previous versions of JDK9 gave me the following output: >> >> classes -> java.base >> (classes) >> -> java.io >> -> java.lang >> -> sun.misc JDK internal API (java.base) >> >> >> The current b86 gives me: >> >> classes -> java.base >> (classes) >> -> java.io >> -> java.lang >> -> sun.misc >> >> So why this change? And is there another way to detect the usage of non-accessible classes? >> >> The maven-plugin has a parameter called failOnWarning (default:true) which should break the build in order to help developers to change their code when they rely on internal classes. > > In the regular JDK 9 EA builds then a usage of sun.misc.BASE64Decoder will be reported as a usage of a JDK internal API. > > Not so with the Jigsaw builds because package sun.misc is temporarily exported by module java.base. This means that all public types in that package are accessible. This might seem surprising but it is because we're not there yet with JEP 260 [1]. Once JEP 260 is further along thne the critical internal APIs listed in JEP 260 will be accessible. The non-critical internal APIs will be encapsulated. I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime. I file a bug: https://bugs.openjdk.java.net/browse/JDK-8143011 > > For the Maven plugin then maybe it might be better to choose a JDK-internal type that is not in sun.misc or sun.reflect. That would keep your test stable while we work through all the transition issues. Yes that allows to work through the transition. Mandy From Alan.Bateman at oracle.com Sat Nov 14 16:29:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Nov 2015 16:29:58 +0000 Subject: JDeps: detecting offending packages In-Reply-To: <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com> References: <56475144.9030205@oracle.com> <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com> Message-ID: <56476186.7030807@oracle.com> On 14/11/2015 16:05, Mandy Chung wrote: > : > I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime. I file a bug: > > https://bugs.openjdk.java.net/browse/JDK-8143011 > I agree and I expect it will be straight-forward once they are moved to their own module. -Alan. From Alan.Bateman at oracle.com Sat Nov 14 16:50:07 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 Nov 2015 16:50:07 +0000 Subject: Locating a class file from a class loader by name In-Reply-To: References: <56460911.8000300@oracle.com> <56462BD1.4030209@oracle.com> Message-ID: <5647663F.20801@oracle.com> On 14/11/2015 16:07, Rafael Winterhalter wrote: > Hi Alan, > > As for your suggestion to rather retransform/redefine classes, this > would unfortunately not be a feasible alternative for most > applications that I have seen. The HotSwap functionaltiy does not > allow to add fields or to override methods of super types as the class > layout cannot be changed. Also, many code generation frameworks > function by renaming existing methods and by reimplementing the same > methods to call a user method. The renamed methods can then be invoked > by injecting a proxy class into the user code that makes the original > code available using a standard interface. If the user method is > non-static, this dispatcher also needs to be stored within a new field > of the class being instrumented. Yes, I'm aware of the limitations to redefine/retransformClasses, I was pointing out that refransformClasses will invoke the ClassFileTransformer with the class bytes and may be the most reliable way to get them. > > It is correct, of course that a class file does not always exist so > the above approach might fail but in practice this is not a problem. > Users do normally only want to instrument specific classes of their > application via Java agents that are available on the class path and > not runtime generated code. > > As for the necessity to locate class file, cglib can be named as > another example (used by e.g. Spring, Hibernate, Mockito) which needs > to parse class files to determine the target of a bridge methods. For > this, cglib calls: > > Class clazz = ... > clazz.getClassLoader().getResourceAsStream(clazz.getName().replace('.', '/') > + '.class'); > > If this would return null as it does with the current build of Jigsaw, > most real-world applications would stop to function. Therefore my > concern with the current implementation where the above call to the > class loader returns null. The current proposal is that resources in named modules be encapsulated. There is discussion on EG list for JSR 376 on this topic. The ClassLoader.getResourcesXXX do of course work exactly as before for resources on the class path or loaded by custom other class loaders. A general point on frameworks is that we expect they will need need at least some changes to work with modules. -Alan From rafael.wth at gmail.com Sun Nov 15 09:51:32 2015 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Sun, 15 Nov 2015 10:51:32 +0100 Subject: Locating a class file from a class loader by name In-Reply-To: <5647663F.20801@oracle.com> References: <56460911.8000300@oracle.com> <56462BD1.4030209@oracle.com> <5647663F.20801@oracle.com> Message-ID: Hi Alan, thank you for your feedback. I agree that the current way of implementing a class file lookup is not a fail-safe solution but it works for almost all real use-cases and has therefore become a standard approach used by a lot of code. I wanted to make sure that you are aware of the dependence on such class file lookup of code generation libraries and their heavy use in enterprise software. Of course, we will adapt the new APIs into our software but as these libraries are non-commercial and developed after hours, the adoption process will take some time. Currently, all of cglib, Byte Buddy or Javassist do not function with Jigsaw when running the test cases of their current stable build because of null pointer exceptions triggered by unsuccessful class file lookups and I would not know how to fix this problem. I will continue to test Jigsaw pre-releases and hope that the mentioned APIs allow for migrating the libraries such that I can offer a version of Byte Buddy that supports Jigsaw rather sooner than later. Best regards, Rafael 2015-11-14 17:50 GMT+01:00 Alan Bateman : > On 14/11/2015 16:07, Rafael Winterhalter wrote: > >> Hi Alan, >> >> As for your suggestion to rather retransform/redefine classes, this would >> unfortunately not be a feasible alternative for most applications that I >> have seen. The HotSwap functionaltiy does not allow to add fields or to >> override methods of super types as the class layout cannot be changed. >> Also, many code generation frameworks function by renaming existing methods >> and by reimplementing the same methods to call a user method. The renamed >> methods can then be invoked by injecting a proxy class into the user code >> that makes the original code available using a standard interface. If the >> user method is non-static, this dispatcher also needs to be stored within a >> new field of the class being instrumented. >> > Yes, I'm aware of the limitations to redefine/retransformClasses, I was > pointing out that refransformClasses will invoke the ClassFileTransformer > with the class bytes and may be the most reliable way to get them. > > >> It is correct, of course that a class file does not always exist so the >> above approach might fail but in practice this is not a problem. Users do >> normally only want to instrument specific classes of their application via >> Java agents that are available on the class path and not runtime generated >> code. >> >> As for the necessity to locate class file, cglib can be named as another >> example (used by e.g. Spring, Hibernate, Mockito) which needs to parse >> class files to determine the target of a bridge methods. For this, cglib >> calls: >> >> Class clazz = ... >> clazz.getClassLoader().getResourceAsStream(clazz.getName().replace('.', >> '/') + '.class'); >> >> If this would return null as it does with the current build of Jigsaw, >> most real-world applications would stop to function. Therefore my concern >> with the current implementation where the above call to the class loader >> returns null. >> > The current proposal is that resources in named modules be encapsulated. > There is discussion on EG list for JSR 376 on this topic. The > ClassLoader.getResourcesXXX do of course work exactly as before for > resources on the class path or loaded by custom other class loaders. > > A general point on frameworks is that we expect they will need need at > least some changes to work with modules. > > -Alan > From reinier at zwitserloot.com Sun Nov 15 11:03:20 2015 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sun, 15 Nov 2015 12:03:20 +0100 Subject: A way to opt out of access restrictions on non-exported members. Message-ID: TL;DR: There are rather a lot of libraries out there that access private members via reflection. I posit that almost all such libraries break without an easy way to fix the problem, if there is no way to use reflection to access non-exported members. setAccessible(true) doesn't let you opt out of module access rules. There are ways to effectively 'read' everything (and if not, there's addRead), but that still doesn't help if you need to reflectively access a member that isn't exported. According to the questions at the end of the J1 session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex Buckley, and Alex Bateman, there is no way to in-process get around the JVM-enforced access restriction. Now, under normal circumstances you shouldn't be accessing such classes / methods / fields / constructors in the first place, but that exact same line of reasoning can be used to defend not including setAccessible, getDeclaredMethod(s), getDeclaredField(s), and all the other ways the reflection API can be used to access (in JDK1-JDK8, at least) protected, package private, and private elements. Those things were never designed to be accessed either, and yet, accessing private members of existing stuff occurs in lots of libraries, usually for: * Dependency injection (guice and company) * Debugging tools (not all of these use JVMTI; sometimes you just have a utility method that dumps some information to a log that includes private members just because that seems like it'll help debug an exotic condition that you can't quite put your finger on). * Code automation tools (apache has a few utilities that return a useful hashCode, which work by inspecting your instance's fields). * Serialization libraries. I'm pretty sure a number of core JDK devs have gone on record not liking the built in serialization mechanism (java.io.Serializable and co), but third party solutions access private members all the time to do their job. * Workarounds. This one is a perhaps controversial, but as the saying goes, java is a 'blue collar' programming language. Sometimes you use access to private members to work around a bug or to get access to functionality that optimally speaking should be done differently or should be accomodated with an update to the library to make that part designed for public access. What are such libraries to do? They could provide the user with ways to use command line switches to hack in the required exports, but this is the kind of hassle that is going to reflect badly on JDK9 and slow adoption rates. I propose some mechanism to get around the restriction is added, with all due warnings in the documentation that this should be considered a hacky workaround. (interestingly, such commentary is not part of the javadoc on .setAccessible!) Alternatively, there are 3 ways this can go: * The authors of these libraries, or the help forums associated with such libraries, start espousing the principle that you should just export everything from your modules, or 'things might break'. This doesn't sound like a desirable outcome for the jigsaw project. It certainly doesn't sound desirable to me. * The authors of these libraries, or the help forums associated with this libraries, start espousing the principle that upgrading to JDK9 is an arduous slog, and that it is better to just stick with JDK8 for the foreseeable future. Certainly, not a desirable outcome. * The heavens part, ponies and rainbows for all, and everyone takes the time to update their serialized data structures or whatnot to make sense in a 'these are exported, these are not' world. I'm not sure this is even possible; it would make sense to have a public interface, and then 2 (non-exported!) classes that are implementations of this. How would a no-hassle serialization library ever get this done without a way to dodge the rules? A module can export _TO_ a serialization library, but this breaks encapsulation: Now the author of framework A needs to know that the user of said framework so happens to have a desire to serialize the stuff from framework A using serialization library X. In practice you'd have to export everything to all the serialization frameworks out there, and now no new framework can ever be created because all these libraries failed to export their internals to them. In any case this boils down to 'just export every package to this subset of tools', and that's the best case scenario, which doesn't sound desirable either. I guess option 4 is: "Surely it won't be that bad", but that's a bit of a gamble to make, given that the stakes are serious lack of adoption of JDK9, or widespread misconfiguration of exports clauses. NB1: Note also that JDK9 has taken its time (and rightly so) to fix its ball-o-twine dependency mess. However, once JDK9 is unleashed upon the masses, a 'quick fix' to make libraries at least workable with JDK9 probably require such hacks. If it's not possible to do it, then libraries won't be JDK9 ready for years. Perhaps other projects aren't as messy as JDK pre-9 was, but let's not make that assumption. NB2: The module system already has a larger impact on adoption (compared to 6, 7, or 8) simply because of the unavoidable differences inherent in what jigsaw is doing (I bet a bunch of command line scripts are going to end up breaking, for example, or at least will be obsolete). Adding more barriers to adoption is something that should, in my opinion, by taken particularly seriously for this release. --Reinier Zwitserloot From Alan.Bateman at oracle.com Sun Nov 15 12:04:30 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 Nov 2015 12:04:30 +0000 Subject: Locating a class file from a class loader by name In-Reply-To: References: <56460911.8000300@oracle.com> <56462BD1.4030209@oracle.com> <5647663F.20801@oracle.com> Message-ID: <564874CE.6020404@oracle.com> On 15/11/2015 09:51, Rafael Winterhalter wrote: > Hi Alan, > > thank you for your feedback. I agree that the current way of > implementing a class file lookup is not a fail-safe solution but it > works for almost all real use-cases and has therefore become a > standard approach used by a lot of code. I wanted to make sure that > you are aware of the dependence on such class file lookup of code > generation libraries and their heavy use in enterprise software. We have of course used static analysis on a huge number of libraries to get data on usage of these methods. One thing to say about this is that such code should work exactly the same as it did with JDK 8 except where it is using the ClassLoader APIs to get at JDK-internal resources (including .class files). This is because the only modules when initially trying out the Jigsaw builds are the platform modules. We know this is a compatibility issue, it's the second item in the Risks and Assumptions section of JEP 261. That compatibility issue could get bigger as more code is migrated to modules but this assumes the frameworks and tools that are relying on the ClassLoader.getResourceXXX methods don't add support for modules. I would hope in time that the frameworks and tools will add support for modules, in which case this issue should slowly go away. As to where to lobby for the ClassLoader APIs to support locating resources in modules then jpms-spec-comments is the mailing list to send feedback. > Of course, we will adapt the new APIs into our software but as these > libraries are non-commercial and developed after hours, the adoption > process will take some time. Currently, all of cglib, Byte Buddy or > Javassist do not function with Jigsaw when running the test cases of > their current stable build because of null pointer exceptions > triggered by unsuccessful class file lookups and I would not know how > to fix this problem. > > I will continue to test Jigsaw pre-releases and hope that the > mentioned APIs allow for migrating the libraries such that I can offer > a version of Byte Buddy that supports Jigsaw rather sooner than later. > Thank you, it's important to have as many people trying out the builds and seeing what works and doesn't work. Modules is a huge change to the platform and we have to get it right. -Alan From alan.bateman at oracle.com Sun Nov 15 14:49:01 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 15 Nov 2015 14:49:01 +0000 Subject: hg: jigsaw/jake/corba: Remove core reflection usage in CORBA utility class Message-ID: <201511151449.tAFEn1KS006570@aojmv0008.oracle.com> Changeset: 54d9b908806a Author: alanb Date: 2015-11-15 14:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/54d9b908806a Remove core reflection usage in CORBA utility class ! src/java.corba/share/classes/com/sun/corba/se/impl/util/Modules.java From mik3hall at gmail.com Sun Nov 15 17:04:07 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Nov 2015 11:04:07 -0600 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: <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> Would it still be the case that the exploded build in the jdk directory is invalid to use? I am having some difficulties on this again. As long as I had done this once I thought it would make sense to be most up to date by just continuing to build from source. So I redid the command to get new source. And tried building. At some point this told me my configuration was no longer valid and the best thing to do was something like make reconfigure I did that, got through the build but the ?make install? shows errors and the images directory ends up with only? _the.nashorn.jar.vardeps I did get a OS X application to boot with the ?exploded?? build in the jdk directory but if I try listing files with the JRT filesystem to be sure I?m running a new release I get errors like? ava.nio.file.FileSystemNotFoundException: /Users/mjh/HalfPipe/bundles/HalfPipe9/HalfPipe9.app/Contents/PlugIns/Java/Contents/Home/lib/modules/bootmodules.jimage at jdk.internal.jrtfs.JrtFileSystem.checkExists(JrtFileSystem.java:87) Although I didn?t seem to have a build step fail on a compiler warning I did also try? ./configure --disable-warnings-as-errors So what I am doing is basically? [get updated source bash get_source.sh or whatever it is] [confifgure] make clean make sudo make install Sort of consistently getting? Building target 'install' in configuration 'macosx-x86_64-normal-server-release' Installing jdk image into /usr/local/jvm/openjdk-1.9.0-internal and creating 0 links from /usr/local/bin into the jdk. cp: /Users/mjh/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/*: No such file or directory make[3]: *** [install] Error 1 make[2]: *** [install] Error 2 I tried searching on ] Error as also suggested and don?t think I saw any for the last build besides the ones immediately above. > On Jul 26, 2015, at 2:08 AM, Alan Bateman wrote: > > > > 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 Michael Hall From rfscholte at apache.org Sun Nov 15 17:49:42 2015 From: rfscholte at apache.org (Robert Scholte) Date: Sun, 15 Nov 2015 18:49:42 +0100 Subject: JDeps: detecting offending packages In-Reply-To: <56476186.7030807@oracle.com> References: <56475144.9030205@oracle.com> <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com> <56476186.7030807@oracle.com> Message-ID: Ah, I see. Adding usage of java.awt.peer.ComponentPeer did indeed expose an offending package again. Just out of interest: will jdeps only detect violations of JDK internal APIs or will it also detect violations on modules? In case I switch from executable jar to executable module it could happen that it breaks due to usage of non-exported packages, right? regards, Robert Op Sat, 14 Nov 2015 17:29:58 +0100 schreef Alan Bateman : > > > On 14/11/2015 16:05, Mandy Chung wrote: >> : >> I think jdeps should continue to flag the critical JDK internal APIs >> listed in JEP 260 but they are accessible at runtime. I file a bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8143011 >> > I agree and I expect it will be straight-forward once they are moved to > their own module. > > -Alan. From forax at univ-mlv.fr Sun Nov 15 18:14:17 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 15 Nov 2015 19:14:17 +0100 (CET) Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: Message-ID: <90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr> There are several ways to opt-out if you control the command line, - put all your modules in the classpath or remove all the module-info from the modules in the module-path, - create a jlink plugin that will crawle all modules (or the ones you want) and change the module-info, - at runtime to create a new layer that will bypass the application classloader and change the module configuration on-the-fly. And there are more exotic ways if you are able to change the bytecodes. Anyway, one goal of jigsaw is to harden the Java plateform, so you can weaken the plateform if you want but it should not be neither the default mode nor it should not be too easy (reflection i'm looking at you) to do that. Now, in the details, - you can still access to members of exported classes by reflection, you may have to add a read edge between the corresponding modules for that, but it's possible. - you can access to members of a non exported classes by using their interfaces if these interfaces are exported (the same way you can access members of a non public class in pre-jigsaw world). regards, R?mi ----- Mail original ----- > De: "Reinier Zwitserloot" > ?: "jigsaw-dev" > Envoy?: Dimanche 15 Novembre 2015 12:03:20 > Objet: A way to opt out of access restrictions on non-exported members. > > TL;DR: There are rather a lot of libraries out there that access private > members via reflection. I posit that almost all such libraries break > without an easy way to fix the problem, if there is no way to use > reflection to access non-exported members. > > > > setAccessible(true) doesn't let you opt out of module access rules. There > are ways to effectively 'read' everything (and if not, there's addRead), > but that still doesn't help if you need to reflectively access a member > that isn't exported. According to the questions at the end of the J1 > session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex > Buckley, and Alex Bateman, there is no way to in-process get around the > JVM-enforced access restriction. > > Now, under normal circumstances you shouldn't be accessing such classes / > methods / fields / constructors in the first place, but that exact same > line of reasoning can be used to defend not including setAccessible, > getDeclaredMethod(s), getDeclaredField(s), and all the other ways the > reflection API can be used to access (in JDK1-JDK8, at least) protected, > package private, and private elements. Those things were never designed to > be accessed either, and yet, accessing private members of existing stuff > occurs in lots of libraries, usually for: > > * Dependency injection (guice and company) > > * Debugging tools (not all of these use JVMTI; sometimes you just have a > utility method that dumps some information to a log that includes private > members just because that seems like it'll help debug an exotic condition > that you can't quite put your finger on). > > * Code automation tools (apache has a few utilities that return a useful > hashCode, which work by inspecting your instance's fields). > > * Serialization libraries. I'm pretty sure a number of core JDK devs have > gone on record not liking the built in serialization mechanism > (java.io.Serializable and co), but third party solutions access private > members all the time to do their job. > > * Workarounds. This one is a perhaps controversial, but as the saying goes, > java is a 'blue collar' programming language. Sometimes you use access to > private members to work around a bug or to get access to functionality that > optimally speaking should be done differently or should be accomodated with > an update to the library to make that part designed for public access. > > What are such libraries to do? They could provide the user with ways to use > command line switches to hack in the required exports, but this is the kind > of hassle that is going to reflect badly on JDK9 and slow adoption rates. I > propose some mechanism to get around the restriction is added, with all due > warnings in the documentation that this should be considered a hacky > workaround. (interestingly, such commentary is not part of the javadoc on > .setAccessible!) > > Alternatively, there are 3 ways this can go: > > * The authors of these libraries, or the help forums associated with such > libraries, start espousing the principle that you should just export > everything from your modules, or 'things might break'. This doesn't sound > like a desirable outcome for the jigsaw project. It certainly doesn't sound > desirable to me. > > * The authors of these libraries, or the help forums associated with this > libraries, start espousing the principle that upgrading to JDK9 is an > arduous slog, and that it is better to just stick with JDK8 for the > foreseeable future. Certainly, not a desirable outcome. > > * The heavens part, ponies and rainbows for all, and everyone takes the > time to update their serialized data structures or whatnot to make sense in > a 'these are exported, these are not' world. I'm not sure this is even > possible; it would make sense to have a public interface, and then 2 > (non-exported!) classes that are implementations of this. How would a > no-hassle serialization library ever get this done without a way to dodge > the rules? A module can export _TO_ a serialization library, but this > breaks encapsulation: Now the author of framework A needs to know that the > user of said framework so happens to have a desire to serialize the stuff > from framework A using serialization library X. In practice you'd have to > export everything to all the serialization frameworks out there, and now no > new framework can ever be created because all these libraries failed to > export their internals to them. In any case this boils down to 'just export > every package to this subset of tools', and that's the best case scenario, > which doesn't sound desirable either. > > I guess option 4 is: "Surely it won't be that bad", but that's a bit of a > gamble to make, given that the stakes are serious lack of adoption of JDK9, > or widespread misconfiguration of exports clauses. > > NB1: Note also that JDK9 has taken its time (and rightly so) to fix its > ball-o-twine dependency mess. However, once JDK9 is unleashed upon the > masses, a 'quick fix' to make libraries at least workable with JDK9 > probably require such hacks. If it's not possible to do it, then libraries > won't be JDK9 ready for years. Perhaps other projects aren't as messy as > JDK pre-9 was, but let's not make that assumption. > > NB2: The module system already has a larger impact on adoption (compared to > 6, 7, or 8) simply because of the unavoidable differences inherent in what > jigsaw is doing (I bet a bunch of command line scripts are going to end up > breaking, for example, or at least will be obsolete). Adding more barriers > to adoption is something that should, in my opinion, by taken particularly > seriously for this release. > > --Reinier Zwitserloot > From claes.redestad at oracle.com Sun Nov 15 23:58:11 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 16 Nov 2015 00:58:11 +0100 Subject: jrt file system now has /package and /modules directories In-Reply-To: <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> Message-ID: <56491C13.9010203@oracle.com> Hi, maybe a long shot, but could you replace the "make" with "make images" and try again? /Claes On 2015-11-15 18:04, Michael Hall wrote: > make clean > make > sudo make install From mik3hall at gmail.com Mon Nov 16 00:44:40 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 15 Nov 2015 18:44:40 -0600 Subject: jrt file system now has /package and /modules directories In-Reply-To: <56491C13.9010203@oracle.com> References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> <56491C13.9010203@oracle.com> Message-ID: > On Nov 15, 2015, at 5:58 PM, Claes Redestad wrote: > > maybe a long shot, but could you replace the "make" with "make images" and try again? Not a bad long shot. Seemed to work fine. Creating jre jimage Creating jdk jimage duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping Access verification succeeded. ## Finished verify-modules (build time 00:03:40) Finished building target 'images' in configuration 'macosx-x86_64-normal-server-release? Running this? ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java JRTLister /packages /modules also works now. I am sure it will likewise work from the app. Thanks much Michael Hall From Alan.Bateman at oracle.com Mon Nov 16 07:42:34 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Nov 2015 07:42:34 +0000 Subject: jrt file system now has /package and /modules directories In-Reply-To: References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> <56491C13.9010203@oracle.com> Message-ID: <564988EA.3080005@oracle.com> On 16/11/2015 00:44, Michael Hall wrote: > Not a bad long shot. Seemed to work fine. > > Creating jre jimage > Creating jdk jimage > duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping > Access verification succeeded. > ## Finished verify-modules (build time 00:03:40) > > Finished building target 'images' in configuration 'macosx-x86_64-normal-server-release? > > Running this? > ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java JRTLister > /packages > /modules > > also works now. > I am sure it will likewise work from the app. > > To your original question then the jrt file system provider in the jigsaw/jake forest has support for exploded builds, the version in the main line JDK 9 forest does not have this support (yet). From the above output then it looks like you have a clone of the JDK 9 main line, maybe jdk9/jdk9 or jdk9/dev, so that explains that part. As regards the make target then the README-builds suggests "make all" so that everything is built. When you run just "make" without any make target then it defaults to developer/exploded builds, this is what most people working on the JDK use. I'm not 100% sure why the "install" target doesn't build and install the images, Erik or someone in the build area can probably say more on this. -Alan From erik.joelsson at oracle.com Mon Nov 16 09:04:49 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 16 Nov 2015 10:04:49 +0100 Subject: jrt file system now has /package and /modules directories In-Reply-To: <564988EA.3080005@oracle.com> References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> <56491C13.9010203@oracle.com> <564988EA.3080005@oracle.com> Message-ID: <56499C31.4060608@oracle.com> The "install" target should most definitely depend on "images". I see that it currently doesn't, which is certainly a bug. The workaround is to do "make images && make install". Filing a bug. /Erik On 2015-11-16 08:42, Alan Bateman wrote: > > > On 16/11/2015 00:44, Michael Hall wrote: >> Not a bad long shot. Seemed to work fine. >> >> Creating jre jimage >> Creating jdk jimage >> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", >> skipping >> Access verification succeeded. >> ## Finished verify-modules (build time 00:03:40) >> >> Finished building target 'images' in configuration >> 'macosx-x86_64-normal-server-release? >> >> Running this? >> ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java >> JRTLister >> /packages >> /modules >> >> also works now. >> I am sure it will likewise work from the app. >> >> > To your original question then the jrt file system provider in the > jigsaw/jake forest has support for exploded builds, the version in the > main line JDK 9 forest does not have this support (yet). From the > above output then it looks like you have a clone of the JDK 9 main > line, maybe jdk9/jdk9 or jdk9/dev, so that explains that part. > > As regards the make target then the README-builds suggests "make all" > so that everything is built. When you run just "make" without any make > target then it defaults to developer/exploded builds, this is what > most people working on the JDK use. I'm not 100% sure why the > "install" target doesn't build and install the images, Erik or someone > in the build area can probably say more on this. > > -Alan From mik3hall at gmail.com Mon Nov 16 09:42:32 2015 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 16 Nov 2015 03:42:32 -0600 Subject: jrt file system now has /package and /modules directories In-Reply-To: <564988EA.3080005@oracle.com> References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> <56491C13.9010203@oracle.com> <564988EA.3080005@oracle.com> Message-ID: > On Nov 16, 2015, at 1:42 AM, Alan Bateman wrote: > To your original question then the jrt file system provider in the jigsaw/jake forest has support for exploded builds, the version in the main line JDK 9 forest does not have this support (yet). From the above output then it looks like you have a clone of the JDK 9 main line, maybe jdk9/jdk9 or jdk9/dev, so that explains that part. > > As regards the make target then the README-builds suggests "make all" so that everything is built. When you run just "make" without any make target then it defaults to developer/exploded builds, this is what most people working on the JDK use. I'm not 100% sure why the "install" target doesn't build and install the images, Erik or someone in the build area can probably say more on this. The install failed because of the missing images. Up to Eric I guess if that is a bug. Yes, I am using a mainline jdk 9 forest. I wouldn?t know how to get a jigsaw specific one. I did end up doing the install and it worked fine with images there. I shouldn?t of installed. I?m still trying to use Java 8 as the default on my machine and only use 9 embedded runtime from a test app. Now I?ll probably have to reinstall 8 over the top to get it back to default. A default build that doesn?t create a jvm fully usable from an application doesn?t make a lot of sense to me but I?ll believe you that it does for a majority of people. Thanks for referring me to the README that I should of looked at, my own page documenting what I did last time on this did say to do ?make all? and I didn?t even read that. But I did update it for what thats worth. Maybe I?ll read it next time. A couple of other things? ?make clean? I remembered had to be sudo?d for me? Doesn?t seem like what I?ve usually done. After not succeeding with this I tried to just grab a early access I could work with. Any time I tried to download instead of downloading it took me to a Oracle developer community page. Kenai, Oracle didn?t seem to matter, I couldn?t get a download, everything hauled me off to the community page? Why are there still separate jre and jdk images? I thought these were going to end up sort of merged depending on modules? Or is the main line build process not really supporting the module part of this at this time? This one I?m assuming is one of those will change over time as the branches merge? Michael Hall > > > > > On 16/11/2015 00:44, Michael Hall wrote: >> Not a bad long shot. Seemed to work fine. >> >> Creating jre jimage >> Creating jdk jimage >> duplicate resource "META-INF/services/com.sun.jdi.connect.Connector", skipping >> Access verification succeeded. >> ## Finished verify-modules (build time 00:03:40) >> >> Finished building target 'images' in configuration 'macosx-x86_64-normal-server-release? >> >> Running this? >> ~/jdk9/build/macosx-x86_64-normal-server-release/images/jdk/bin/java JRTLister >> /packages >> /modules >> >> also works now. >> I am sure it will likewise work from the app. >> >> > > > -Alan From alan.bateman at oracle.com Mon Nov 16 10:53:16 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 16 Nov 2015 10:53:16 +0000 Subject: hg: jigsaw/jake/jdk: Remove dependency on sun.boot.class.path from more tests Message-ID: <201511161053.tAGArG1M025577@aojmv0008.oracle.com> Changeset: 1d9005d2200d Author: alanb Date: 2015-11-16 10:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1d9005d2200d Remove dependency on sun.boot.class.path from more tests ! test/java/lang/instrument/BootClassPath/Agent.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/rmi/reliability/benchmark/bench/HtmlReporter.java ! test/java/rmi/reliability/benchmark/bench/TextReporter.java From pm at netcetera.ch Mon Nov 16 11:19:48 2015 From: pm at netcetera.ch (Philippe Marschall) Date: Mon, 16 Nov 2015 12:19:48 +0100 Subject: Annotations across modules In-Reply-To: References: Message-ID: <5649BBD4.4060405@netcetera.ch> On 12.11.15 14:50, Stephen Colebourne wrote: > My understanding of annotations today is that annotations are not > required at runtime. ie. if an annotation is placed into a class at > compile time but the .class file for the annotation is not available > on the runtime classpath. then there is no error. > > Does this change in any way with modules? > > My specific case is wrt @ConstructorProperties which is in java.beans. > In 9, a user may run my software without the java.beans module. Can I > safely assume that if the annotation is available on the compile > module path but not the runtime module path, everything will be OK > (ie. no error)? My understanding is that you can't have optional dependencies. So if you have @ConstructorProperties in your source you also need to have a java.desktop module dependency in your module-info.java. If your library is in the module path the java.desktop module then it needs to be present at runtime. The only option you have is to make your jar not a modular jar by one of those: - not providing a module-info.class - not putting your module in the module path Cheers Philippe From scolebourne at joda.org Mon Nov 16 12:28:22 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 16 Nov 2015 12:28:22 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: Message-ID: Access to private members of classes by reflection is indeed very, very common. I agree that JDK 9 needs to be cautious around this. For me, I'm not yet sure I'm comfortable with setAccessible(true) no longer being sufficient to access them. I did wonder if perhaps a change could be made such that any instance of 'Class' passed into a module would automatically be granted the necessary enhanced module readability. Unfortunately, I don't think it will be enough for most serialization frameworks, as they traverse a graph of objects. I do think that there may need to be separate JDK 8 and 9 versions of many OSS libraries (for which the multi-version jar file is one option). This will certainly slow adoption. Stephen PS. I'm reminded of Java's missing "properties" feature again, cf. http://jodastephen.github.io/property-alliance/ On 15 November 2015 at 11:03, Reinier Zwitserloot wrote: > TL;DR: There are rather a lot of libraries out there that access private > members via reflection. I posit that almost all such libraries break > without an easy way to fix the problem, if there is no way to use > reflection to access non-exported members. > > > > setAccessible(true) doesn't let you opt out of module access rules. There > are ways to effectively 'read' everything (and if not, there's addRead), > but that still doesn't help if you need to reflectively access a member > that isn't exported. According to the questions at the end of the J1 > session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex > Buckley, and Alex Bateman, there is no way to in-process get around the > JVM-enforced access restriction. > > Now, under normal circumstances you shouldn't be accessing such classes / > methods / fields / constructors in the first place, but that exact same > line of reasoning can be used to defend not including setAccessible, > getDeclaredMethod(s), getDeclaredField(s), and all the other ways the > reflection API can be used to access (in JDK1-JDK8, at least) protected, > package private, and private elements. Those things were never designed to > be accessed either, and yet, accessing private members of existing stuff > occurs in lots of libraries, usually for: > > * Dependency injection (guice and company) > > * Debugging tools (not all of these use JVMTI; sometimes you just have a > utility method that dumps some information to a log that includes private > members just because that seems like it'll help debug an exotic condition > that you can't quite put your finger on). > > * Code automation tools (apache has a few utilities that return a useful > hashCode, which work by inspecting your instance's fields). > > * Serialization libraries. I'm pretty sure a number of core JDK devs have > gone on record not liking the built in serialization mechanism > (java.io.Serializable and co), but third party solutions access private > members all the time to do their job. > > * Workarounds. This one is a perhaps controversial, but as the saying goes, > java is a 'blue collar' programming language. Sometimes you use access to > private members to work around a bug or to get access to functionality that > optimally speaking should be done differently or should be accomodated with > an update to the library to make that part designed for public access. > > What are such libraries to do? They could provide the user with ways to use > command line switches to hack in the required exports, but this is the kind > of hassle that is going to reflect badly on JDK9 and slow adoption rates. I > propose some mechanism to get around the restriction is added, with all due > warnings in the documentation that this should be considered a hacky > workaround. (interestingly, such commentary is not part of the javadoc on > .setAccessible!) > > Alternatively, there are 3 ways this can go: > > * The authors of these libraries, or the help forums associated with such > libraries, start espousing the principle that you should just export > everything from your modules, or 'things might break'. This doesn't sound > like a desirable outcome for the jigsaw project. It certainly doesn't sound > desirable to me. > > * The authors of these libraries, or the help forums associated with this > libraries, start espousing the principle that upgrading to JDK9 is an > arduous slog, and that it is better to just stick with JDK8 for the > foreseeable future. Certainly, not a desirable outcome. > > * The heavens part, ponies and rainbows for all, and everyone takes the > time to update their serialized data structures or whatnot to make sense in > a 'these are exported, these are not' world. I'm not sure this is even > possible; it would make sense to have a public interface, and then 2 > (non-exported!) classes that are implementations of this. How would a > no-hassle serialization library ever get this done without a way to dodge > the rules? A module can export _TO_ a serialization library, but this > breaks encapsulation: Now the author of framework A needs to know that the > user of said framework so happens to have a desire to serialize the stuff > from framework A using serialization library X. In practice you'd have to > export everything to all the serialization frameworks out there, and now no > new framework can ever be created because all these libraries failed to > export their internals to them. In any case this boils down to 'just export > every package to this subset of tools', and that's the best case scenario, > which doesn't sound desirable either. > > I guess option 4 is: "Surely it won't be that bad", but that's a bit of a > gamble to make, given that the stakes are serious lack of adoption of JDK9, > or widespread misconfiguration of exports clauses. > > NB1: Note also that JDK9 has taken its time (and rightly so) to fix its > ball-o-twine dependency mess. However, once JDK9 is unleashed upon the > masses, a 'quick fix' to make libraries at least workable with JDK9 > probably require such hacks. If it's not possible to do it, then libraries > won't be JDK9 ready for years. Perhaps other projects aren't as messy as > JDK pre-9 was, but let's not make that assumption. > > NB2: The module system already has a larger impact on adoption (compared to > 6, 7, or 8) simply because of the unavoidable differences inherent in what > jigsaw is doing (I bet a bunch of command line scripts are going to end up > breaking, for example, or at least will be obsolete). Adding more barriers > to adoption is something that should, in my opinion, by taken particularly > seriously for this release. > > --Reinier Zwitserloot From alexandre.iline at oracle.com Mon Nov 16 13:01:20 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 16 Nov 2015 16:01:20 +0300 Subject: RFR: 8139430 In-Reply-To: References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> Message-ID: <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> V6: http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/ Thank you. Shura > On Nov 11, 2015, at 7:41 PM, Alexandre (Shura) Iline wrote: > > >> On Nov 10, 2015, at 11:42 PM, Alan Bateman wrote: >> >> >> >> On 09/11/2015 19:12, Alexandre (Shura) Iline wrote: >>> Hi >>> >>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: >>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ >>> >>> Shura >>> >> I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does. >> >> Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid? > > Yes, there are a few places only, actually. Let me also fix those. > > Shura > >> >> When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped? >> >> -Alan. >> >> >> > From jaroslav.bachorik at oracle.com Mon Nov 16 13:11:42 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 16 Nov 2015 14:11:42 +0100 Subject: RFR: 8139430 In-Reply-To: <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> Message-ID: <5649D60E.6090008@oracle.com> On 16.11.2015 14:01, Alexandre (Shura) Iline wrote: > V6: > http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/ Looks good! Thanks, -JB- > > Thank you. > > Shura > >> On Nov 11, 2015, at 7:41 PM, Alexandre (Shura) Iline wrote: >> >> >>> On Nov 10, 2015, at 11:42 PM, Alan Bateman wrote: >>> >>> >>> >>> On 09/11/2015 19:12, Alexandre (Shura) Iline wrote: >>>> Hi >>>> >>>> I have just realized that an NPE could also be possible in test/lib/testlibrary/jdk/testlibrary/Platform.java so it should be updated also: >>>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.04/ >>>> >>>> Shura >>>> >>> I skimmed through the webrev and it looks okay. Assuming InputArguments is not renamed then you could rename containsPrefix to something like hasArgStartingWith or something that makes it clear what this method does. >>> >>> Would it break many tests if getProcessId were changed to return long to match ProcessHandle::getPid? >> >> Yes, there are a few places only, actually. Let me also fix those. >> >> Shura >> >>> >>> When this is pushed then can we drop @modules java.management from any tests or were those changes held back assuming the dependency would be dropped? >>> >>> -Alan. >>> >>> >>> >> > From reinier at zwitserloot.com Mon Nov 16 13:21:15 2015 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 16 Nov 2015 14:21:15 +0100 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr> References: <90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr> Message-ID: Security hardening? The security manager already stops .setAccessible() if you want it to, and if you don't stop that, you have no security anyway, so there's no point. I do not understand the argument of '... blocking .setAccessible() from letting you access members from non-exported packages is better for security' at all. With some more depth: On Sun, Nov 15, 2015 at 7:14 PM, Remi Forax wrote: > - put all your modules in the classpath or remove all the module-info from > the modules in the module-path, > - create a jlink plugin that will crawle all modules (or the ones you > want) and change the module-info, > - at runtime to create a new layer that will bypass the application > classloader and change the module configuration on-the-fly. > And there are more exotic ways if you are able to change the bytecodes. > Exactly. Exotic ways. These options sounds sufficiently user hostile that it'll slow JDK9 adoption significantly. A lot of them also don't sound like something that team jigsaw would want. For example, if most java deployments start dumping all the modules on the CP to get around this issue, then... what was the point of the module system in the first place? I'm trying to make the point: This COULD lead to the community en masse establishing some hacky workaround as 'the new normal' because libraries simply do not have the tools to become JDK9 ready in time (or ever). That sounds like something to be avoided. I don't understand the security element at all. The only way to cause security issues if .setAccessible() would let you break through exports requirements, is if untrusted code is allowed to run, in-process, on your own JVM in the first place*. There is NO WAY to have such code (untrusted, running in-process) be in any way or form safe unless a security manager is involved, and the security manager is _already_ set up to allow you to deny .setAccessible. *) Technically, you could have code that calls .setAccessible(true) on an element that is found based on untrusted user input, but this sounds like a very exotic case, is already a security nightmare both in JDK8 and even in a fully modularized JDK9 world; if we take as written that accessing any element of a non-exported package is a huge security leak, how is accessing private members of exported packages perfectly fine? That makes no sense either. --Reinier Zwitserloot From Alan.Bateman at oracle.com Mon Nov 16 13:38:57 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Nov 2015 13:38:57 +0000 Subject: RFR: 8139430 In-Reply-To: <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> Message-ID: <5649DC71.60106@oracle.com> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote: > V6: > http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/ > > This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting. -Alan From forax at univ-mlv.fr Mon Nov 16 14:20:57 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Nov 2015 15:20:57 +0100 (CET) Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <90409445.3423948.1447611257010.JavaMail.zimbra@u-pem.fr> Message-ID: <1625155799.438546.1447683657461.JavaMail.zimbra@u-pem.fr> Reinier, please answer to my mail, not to something i may have said. My previous mail is not about security*, it's about stronger encapsulation. To develop applications with several dozens of jars/modules, internal implementation details of a module should never leak outside of a module. R?mi * my mom told me to never use a 's' word. ----- Mail original ----- > De: "Reinier Zwitserloot" > ?: "jigsaw-dev" > Envoy?: Lundi 16 Novembre 2015 14:21:15 > Objet: Re: A way to opt out of access restrictions on non-exported members. > > Security hardening? The security manager already stops .setAccessible() if > you want it to, and if you don't stop that, you have no security anyway, so > there's no point. I do not understand the argument of '... blocking > .setAccessible() from letting you access members from non-exported packages > is better for security' at all. > > With some more depth: > > On Sun, Nov 15, 2015 at 7:14 PM, Remi Forax wrote: > > > - put all your modules in the classpath or remove all the module-info from > > the modules in the module-path, > > - create a jlink plugin that will crawle all modules (or the ones you > > want) and change the module-info, > > - at runtime to create a new layer that will bypass the application > > classloader and change the module configuration on-the-fly. > > And there are more exotic ways if you are able to change the bytecodes. > > > > Exactly. Exotic ways. These options sounds sufficiently user hostile that > it'll slow JDK9 adoption significantly. A lot of them also don't sound like > something that team jigsaw would want. For example, if most java > deployments start dumping all the modules on the CP to get around this > issue, then... what was the point of the module system in the first place? > > I'm trying to make the point: This COULD lead to the community en masse > establishing some hacky workaround as 'the new normal' because libraries > simply do not have the tools to become JDK9 ready in time (or ever). That > sounds like something to be avoided. > > I don't understand the security element at all. The only way to cause > security issues if .setAccessible() would let you break through exports > requirements, is if untrusted code is allowed to run, in-process, on your > own JVM in the first place*. There is NO WAY to have such code (untrusted, > running in-process) be in any way or form safe unless a security manager is > involved, and the security manager is _already_ set up to allow you to deny > .setAccessible. > > *) Technically, you could have code that calls .setAccessible(true) on an > element that is found based on untrusted user input, but this sounds like a > very exotic case, is already a security nightmare both in JDK8 and even in > a fully modularized JDK9 world; if we take as written that accessing any > element of a non-exported package is a huge security leak, how is accessing > private members of exported packages perfectly fine? That makes no sense > either. > > --Reinier Zwitserloot > From ali.ebrahimi1781 at gmail.com Mon Nov 16 16:25:49 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 16 Nov 2015 19:55:49 +0330 Subject: build error on windows Message-ID: Hi, . . Creating jsoundds.dll from 4 file(s) f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. c(106) : error C2220: warning treated as error - no 'object' file generated f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. c(106) : warning C4101: 'stream' : unreferenced local variable Awt2dLibraries.gmk:639: recipe for target '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj' failedmake[3]: *** [/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj] Error 2 make/Main.gmk:204: recipe for target 'java.desktop-libs' failedmake[2]: *** [java.desktop-libs] Error 1 make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! ERROR: Build failed for target 'all' in configuration 'win' (exit code 2) === Output from failing command(s) repeated here === * For target BUILD_LIBFONTMANAGER_freetypeScaler.c:freetypeScaler.c f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. c(106) : error C2220: warning treated as error - no 'object' file generated f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. c(106) : warning C4101: 'stream' : unreferenced local variable === End of repeated output === === Make failure sequence repeated here === Awt2dLibraries.gmk:639: recipe for target '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj' failed make/Main.gmk:204: recipe for target 'java.desktop-libs' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: If caused by a warning, try configure --disable-warnings-as-errors. /cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main' failed make[1]: *** [main] Error 1 /cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed make: *** [all] Error 2 -- Best Regards, Ali Ebrahimi From philip.race at oracle.com Mon Nov 16 16:34:15 2015 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Nov 2015 08:34:15 -0800 Subject: build error on windows In-Reply-To: References: Message-ID: <564A0587.9040608@oracle.com> This is a known issue and the fix should go into jdk9/dev in about 24 hours. --disable-warnings-as-errors will work around it. -phil. On 11/16/15, 8:25 AM, Ali Ebrahimi wrote: > Hi, > > . > . > Creating jsoundds.dll from 4 file(s) > f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. > c(106) : error C2220: warning treated as error - no 'object' file generated > f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. > c(106) : warning C4101: 'stream' : unreferenced local variable > Awt2dLibraries.gmk:639: recipe for target > '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj' > failedmake[3]: *** > [/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj] > Error 2 > > make/Main.gmk:204: recipe for target 'java.desktop-libs' failedmake[2]: *** > [java.desktop-libs] Error 1 > > make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! > > ERROR: Build failed for target 'all' in configuration 'win' (exit code 2) > === Output from failing command(s) repeated here === > * For target BUILD_LIBFONTMANAGER_freetypeScaler.c:freetypeScaler.c > f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. > c(106) : error C2220: warning treated as error - no 'object' file generated > f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. > c(106) : warning C4101: 'stream' : unreferenced local variable > === End of repeated output === > === Make failure sequence repeated here === > Awt2dLibraries.gmk:639: recipe for target > '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj' > failed > make/Main.gmk:204: recipe for target 'java.desktop-libs' failed > === End of repeated output === > Hint: Try searching the build log for the name of the first failed target. > Hint: If caused by a warning, try configure --disable-warnings-as-errors. > > /cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main' failed > make[1]: *** [main] Error 1 > /cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed > make: *** [all] Error 2 From ali.ebrahimi1781 at gmail.com Mon Nov 16 16:37:56 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Mon, 16 Nov 2015 20:07:56 +0330 Subject: build error on windows In-Reply-To: <564A0587.9040608@oracle.com> References: <564A0587.9040608@oracle.com> Message-ID: Thanks. On Mon, Nov 16, 2015 at 8:04 PM, Philip Race wrote: > This is a known issue and the fix should go into jdk9/dev in about 24 > hours. > --disable-warnings-as-errors will work around it. > > -phil. > > > On 11/16/15, 8:25 AM, Ali Ebrahimi wrote: > >> Hi, >> >> . >> . >> Creating jsoundds.dll from 4 file(s) >> >> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. >> c(106) : error C2220: warning treated as error - no 'object' file >> generated >> >> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. >> c(106) : warning C4101: 'stream' : unreferenced local variable >> Awt2dLibraries.gmk:639: recipe for target >> >> '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj' >> failedmake[3]: *** >> >> [/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj] >> Error 2 >> >> make/Main.gmk:204: recipe for target 'java.desktop-libs' failedmake[2]: >> *** >> [java.desktop-libs] Error 1 >> >> make[2]: INTERNAL: Exiting with 1 jobserver tokens available; should be 2! >> >> ERROR: Build failed for target 'all' in configuration 'win' (exit code 2) >> === Output from failing command(s) repeated here === >> * For target BUILD_LIBFONTMANAGER_freetypeScaler.c:freetypeScaler.c >> >> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. >> c(106) : error C2220: warning treated as error - no 'object' file >> generated >> >> f:/openjdk/jake/jdk/src/java.desktop/share/native/libfontmanager/freetypeScaler. >> c(106) : warning C4101: 'stream' : unreferenced local variable >> === End of repeated output === >> === Make failure sequence repeated here === >> Awt2dLibraries.gmk:639: recipe for target >> >> '/cygdrive/f/openjdk/jake/build/win/support/native/java.desktop/libfontmanager/freetypeScaler.obj' >> failed >> make/Main.gmk:204: recipe for target 'java.desktop-libs' failed >> === End of repeated output === >> Hint: Try searching the build log for the name of the first failed target. >> Hint: If caused by a warning, try configure --disable-warnings-as-errors. >> >> /cygdrive/f/openjdk/jake/make/Init.gmk:278: recipe for target 'main' >> failed >> make[1]: *** [main] Error 1 >> /cygdrive/f/openjdk/jake/make/Init.gmk:182: recipe for target 'all' failed >> make: *** [all] Error 2 >> > -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Mon Nov 16 16:45:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Nov 2015 16:45:18 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: Message-ID: <564A081E.3010809@oracle.com> On 16/11/2015 12:28, Stephen Colebourne wrote: > Access to private members of classes by reflection is indeed very, > very common. I agree that JDK 9 needs to be cautious around this. > > I think this thread is just highlighting the obvious tension between modules with encapsulation vs. serialization and other frameworks that need to break encapsulation. At this time then explicit modules have to opt-in to allow frameworks get access types in those packages. This can be done in the module declaration or at run-time via the API. The alternative is of course the all-powerful command line. As regards setAccessible(true) then it would be nice to have it eventually go away in some future release. This would clearly require coming up with solutions to some difficult problems and use-cases. -Alan From njbartlett at gmail.com Mon Nov 16 17:48:54 2015 From: njbartlett at gmail.com (Neil Bartlett) Date: Mon, 16 Nov 2015 17:48:54 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564A081E.3010809@oracle.com> References: <564A081E.3010809@oracle.com> Message-ID: Alan, In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is not exported? module foo { provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl; } This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type. How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like: ? Regards, Neil > On 16 Nov 2015, at 16:45, Alan Bateman wrote: > > > > On 16/11/2015 12:28, Stephen Colebourne wrote: >> Access to private members of classes by reflection is indeed very, >> very common. I agree that JDK 9 needs to be cautious around this. >> >> > I think this thread is just highlighting the obvious tension between modules with encapsulation vs. serialization and other frameworks that need to break encapsulation. At this time then explicit modules have to opt-in to allow frameworks get access types in those packages. This can be done in the module declaration or at run-time via the API. The alternative is of course the all-powerful command line. > > As regards setAccessible(true) then it would be nice to have it eventually go away in some future release. This would clearly require coming up with solutions to some difficult problems and use-cases. > > -Alan From Alan.Bateman at oracle.com Mon Nov 16 18:57:54 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Nov 2015 18:57:54 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> Message-ID: <564A2732.4030307@oracle.com> On 16/11/2015 17:48, Neil Bartlett wrote: > Alan, > > In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is not exported? > > module foo { > provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl; > } > > This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type. Sure, but this just part of the support for services. In this example then the service provider is fully encapsulated. The consumer of the service can't access ServiceImpl, it instead accesses it via ServiceInterface (assuming of course that the consumer reads the module with ServiceInterface and org.example.api is exported to the consumer). > How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like: > > ? > There isn't way to give Spring super powers so this needs foo to export org.example.impl to Spring. -Alan. From njbartlett at gmail.com Mon Nov 16 19:41:25 2015 From: njbartlett at gmail.com (Neil Bartlett) Date: Mon, 16 Nov 2015 19:41:25 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564A2732.4030307@oracle.com> References: <564A081E.3010809@oracle.com> <564A2732.4030307@oracle.com> Message-ID: Thanks Alan, So you?re saying that ServiceLoader is permitted to have ?super powers? to punch through encapsulation, but other libraries are not. This is disappointing ? ServiceLoader is extremely limited in functionality, and is no match for any of the widely used DI frameworks like Spring, Guice, CDI etc. Why should this library be blessed above all others? Neil > On 16 Nov 2015, at 18:57, Alan Bateman wrote: > > On 16/11/2015 17:48, Neil Bartlett wrote: >> Alan, >> >> In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is not exported? >> >> module foo { >> provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl; >> } >> >> This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type. > Sure, but this just part of the support for services. In this example then the service provider is fully encapsulated. The consumer of the service can't access ServiceImpl, it instead accesses it via ServiceInterface (assuming of course that the consumer reads the module with ServiceInterface and org.example.api is exported to the consumer). > >> How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like: >> >> ? >> > There isn't way to give Spring super powers so this needs foo to export org.example.impl to Spring. > > -Alan. From Alan.Bateman at oracle.com Mon Nov 16 20:28:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Nov 2015 20:28:05 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> <564A2732.4030307@oracle.com> Message-ID: <564A3C55.303@oracle.com> On 16/11/2015 19:41, Neil Bartlett wrote: > Thanks Alan, > > So you?re saying that ServiceLoader is permitted to have ?super powers? to punch through encapsulation, but other libraries are not. This is disappointing ? ServiceLoader is extremely limited in functionality, and is no match for any of the widely used DI frameworks like Spring, Guice, CDI etc. Why should this library be blessed above all others? It's never been a goal to create a new DI framework. However there is a requirement to expose the service bindings via the ServiceLoader API [1]. Time will tell if we have to introduce a way for frameworks and serialization libraries to break encapsulation. -Alan. [1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#binding From harold.seigel at oracle.com Mon Nov 16 20:56:24 2015 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Mon, 16 Nov 2015 20:56:24 +0000 Subject: hg: jigsaw/jake/hotspot: Set property sun.boot.class.path to NULL, and include Jiangli's build fix and other build fix. Message-ID: <201511162056.tAGKuOVZ024421@aojmv0008.oracle.com> Changeset: d83120ae736e Author: hseigel Date: 2015-11-16 15:35 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d83120ae736e Set property sun.boot.class.path to NULL, and include Jiangli's build fix and other build fix. ! src/share/vm/classfile/systemDictionaryShared.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/BootClassAppendProp/SunBootClassPath.java From alex.buckley at oracle.com Mon Nov 16 22:04:32 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 16 Nov 2015 14:04:32 -0800 Subject: Annotations across modules In-Reply-To: <5649BBD4.4060405@netcetera.ch> References: <5649BBD4.4060405@netcetera.ch> Message-ID: <564A52F0.7090309@oracle.com> On 11/16/2015 3:19 AM, Philippe Marschall wrote: > On 12.11.15 14:50, Stephen Colebourne wrote: >> My understanding of annotations today is that annotations are not >> required at runtime. ie. if an annotation is placed into a class at >> compile time but the .class file for the annotation is not available >> on the runtime classpath. then there is no error. >> >> Does this change in any way with modules? >> >> My specific case is wrt @ConstructorProperties which is in java.beans. >> In 9, a user may run my software without the java.beans module. Can I >> safely assume that if the annotation is available on the compile >> module path but not the runtime module path, everything will be OK >> (ie. no error)? > > My understanding is that you can't have optional dependencies. So if you > have @ConstructorProperties in your source you also need to have a > java.desktop module dependency in your module-info.java. If your library > is in the module path the java.desktop module then it needs to be > present at runtime. > > The only option you have is to make your jar not a modular jar by one of > those: > - not providing a module-info.class > - not putting your module in the module path This is all true -- a static reference to java.beans.ConstructorProperties necessitates a dependency on java.desktop at compile time. The reason for my stripped-down answer was that Stephen phrased the question using some rather abstract language -- "an annotation is placed into a class", "a user may run my software ...". This made me think something clever was going on -- for example, the user's dependency on java.desktop is factored out and Stephen's software receives a Class object for java.beans.ConstructorProperties from someone else. Alex From forax at univ-mlv.fr Mon Nov 16 22:12:04 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Nov 2015 23:12:04 +0100 (CET) Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: Message-ID: <739333142.678615.1447711924259.JavaMail.zimbra@u-pem.fr> Hi Stephen, ----- Mail original ----- > De: "Stephen Colebourne" > ?: "jigsaw-dev" > Envoy?: Lundi 16 Novembre 2015 13:28:22 > Objet: Re: A way to opt out of access restrictions on non-exported members. > > Access to private members of classes by reflection is indeed very, > very common. I agree that JDK 9 needs to be cautious around this. > > For me, I'm not yet sure I'm comfortable with setAccessible(true) no > longer being sufficient to access them. > > I did wonder if perhaps a change could be made such that any instance > of 'Class' passed into a module would automatically be granted the > necessary enhanced module readability. Unfortunately, I don't think it > will be enough for most serialization frameworks, as they traverse a > graph of objects. We discuss something like this at Devoxx, add a read edge between the current module and the module of the declaring class when you do a setAccessible on a member of that class. This will not solved all the issues, frameworks will still not be able to call setAccessible on a non exported class but i think it will fix most of the issues if (and it's a big if) creators of modules do not allow non-exported classes to leak. > > I do think that there may need to be separate JDK 8 and 9 versions of > many OSS libraries (for which the multi-version jar file is one > option). This will certainly slow adoption. > > Stephen R?mi > > > > On 15 November 2015 at 11:03, Reinier Zwitserloot > wrote: > > TL;DR: There are rather a lot of libraries out there that access private > > members via reflection. I posit that almost all such libraries break > > without an easy way to fix the problem, if there is no way to use > > reflection to access non-exported members. > > > > > > > > setAccessible(true) doesn't let you opt out of module access rules. There > > are ways to effectively 'read' everything (and if not, there's addRead), > > but that still doesn't help if you need to reflectively access a member > > that isn't exported. According to the questions at the end of the J1 > > session 'Advanced Modular Development (CON6821)', by Mark Reinhold, Alex > > Buckley, and Alex Bateman, there is no way to in-process get around the > > JVM-enforced access restriction. > > > > Now, under normal circumstances you shouldn't be accessing such classes / > > methods / fields / constructors in the first place, but that exact same > > line of reasoning can be used to defend not including setAccessible, > > getDeclaredMethod(s), getDeclaredField(s), and all the other ways the > > reflection API can be used to access (in JDK1-JDK8, at least) protected, > > package private, and private elements. Those things were never designed to > > be accessed either, and yet, accessing private members of existing stuff > > occurs in lots of libraries, usually for: > > > > * Dependency injection (guice and company) > > > > * Debugging tools (not all of these use JVMTI; sometimes you just have a > > utility method that dumps some information to a log that includes private > > members just because that seems like it'll help debug an exotic condition > > that you can't quite put your finger on). > > > > * Code automation tools (apache has a few utilities that return a useful > > hashCode, which work by inspecting your instance's fields). > > > > * Serialization libraries. I'm pretty sure a number of core JDK devs have > > gone on record not liking the built in serialization mechanism > > (java.io.Serializable and co), but third party solutions access private > > members all the time to do their job. > > > > * Workarounds. This one is a perhaps controversial, but as the saying goes, > > java is a 'blue collar' programming language. Sometimes you use access to > > private members to work around a bug or to get access to functionality that > > optimally speaking should be done differently or should be accomodated with > > an update to the library to make that part designed for public access. > > > > What are such libraries to do? They could provide the user with ways to use > > command line switches to hack in the required exports, but this is the kind > > of hassle that is going to reflect badly on JDK9 and slow adoption rates. I > > propose some mechanism to get around the restriction is added, with all due > > warnings in the documentation that this should be considered a hacky > > workaround. (interestingly, such commentary is not part of the javadoc on > > .setAccessible!) > > > > Alternatively, there are 3 ways this can go: > > > > * The authors of these libraries, or the help forums associated with such > > libraries, start espousing the principle that you should just export > > everything from your modules, or 'things might break'. This doesn't sound > > like a desirable outcome for the jigsaw project. It certainly doesn't sound > > desirable to me. > > > > * The authors of these libraries, or the help forums associated with this > > libraries, start espousing the principle that upgrading to JDK9 is an > > arduous slog, and that it is better to just stick with JDK8 for the > > foreseeable future. Certainly, not a desirable outcome. > > > > * The heavens part, ponies and rainbows for all, and everyone takes the > > time to update their serialized data structures or whatnot to make sense in > > a 'these are exported, these are not' world. I'm not sure this is even > > possible; it would make sense to have a public interface, and then 2 > > (non-exported!) classes that are implementations of this. How would a > > no-hassle serialization library ever get this done without a way to dodge > > the rules? A module can export _TO_ a serialization library, but this > > breaks encapsulation: Now the author of framework A needs to know that the > > user of said framework so happens to have a desire to serialize the stuff > > from framework A using serialization library X. In practice you'd have to > > export everything to all the serialization frameworks out there, and now no > > new framework can ever be created because all these libraries failed to > > export their internals to them. In any case this boils down to 'just export > > every package to this subset of tools', and that's the best case scenario, > > which doesn't sound desirable either. > > > > I guess option 4 is: "Surely it won't be that bad", but that's a bit of a > > gamble to make, given that the stakes are serious lack of adoption of JDK9, > > or widespread misconfiguration of exports clauses. > > > > NB1: Note also that JDK9 has taken its time (and rightly so) to fix its > > ball-o-twine dependency mess. However, once JDK9 is unleashed upon the > > masses, a 'quick fix' to make libraries at least workable with JDK9 > > probably require such hacks. If it's not possible to do it, then libraries > > won't be JDK9 ready for years. Perhaps other projects aren't as messy as > > JDK pre-9 was, but let's not make that assumption. > > > > NB2: The module system already has a larger impact on adoption (compared to > > 6, 7, or 8) simply because of the unavoidable differences inherent in what > > jigsaw is doing (I bet a bunch of command line scripts are going to end up > > breaking, for example, or at least will be obsolete). Adding more barriers > > to adoption is something that should, in my opinion, by taken particularly > > seriously for this release. > > > > --Reinier Zwitserloot > From forax at univ-mlv.fr Mon Nov 16 22:37:49 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 16 Nov 2015 23:37:49 +0100 (CET) Subject: Property Was: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: Message-ID: <194121383.681185.1447713469955.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Stephen Colebourne" > ?: "jigsaw-dev" > Envoy?: Lundi 16 Novembre 2015 13:28:22 > Objet: Re: A way to opt out of access restrictions on non-exported members. > [...] > Stephen > PS. I'm reminded of Java's missing "properties" feature again, cf. > http://jodastephen.github.io/property-alliance/ I still think we should introduce properties into the language and i agree with you that it should have a meta-model. Here is how i see properties nowadays: - a property represents a public value that can be implemented either as a field or using a getter and optionally a setter. - declaring a property is done by using the keyword 'property' in front of a field. - accessing a property is done by using '.' followed by the name of the property. - a final property is a property that can only be read. - an abstract property is a property with no backing field, a getter and a setter must be defined (only a getter if the property is final). - The reflection API (this is the meta-model of Java) is enhanced by adding a class java.lang.reflect.Property that can be obtained by using getProperty(String)/getProperties() on a Class. The property is non mutable object (no setAccesssible), that is not parameterized and there is only one kind of property. everything else can be implemented on top of this property spec. and we (the community) should agree on the property spec we want and wait a Java release with no big language change in order to propose it. regards, R?mi From scolebourne at joda.org Mon Nov 16 23:43:16 2015 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 16 Nov 2015 23:43:16 +0000 Subject: Annotations across modules In-Reply-To: <564A52F0.7090309@oracle.com> References: <5649BBD4.4060405@netcetera.ch> <564A52F0.7090309@oracle.com> Message-ID: On 16 November 2015 at 22:04, Alex Buckley wrote: > This is all true -- a static reference to java.beans.ConstructorProperties > necessitates a dependency on java.desktop at compile time. > > The reason for my stripped-down answer was that Stephen phrased the question > using some rather abstract language -- "an annotation is placed into a > class", "a user may run my software ...". This made me think something > clever was going on -- for example, the user's dependency on java.desktop is > factored out and Stephen's software receives a Class object for > java.beans.ConstructorProperties from someone else. FWIW, the case I was considering no longer applies. Joda-Beans is a source code generator. I was planning on always adding @ConstructorProperties and relying on the fact that if the annotation is not found at runtime it does not matter. But the discussion above indicates that it will be hard to have a different set of modules at compile time to runtime. In the end, I made generation of @ConstructorProperties opt-in, so the problem effectively goes away. I suspect that I will return to discuss optional dependencies before too long, as it is a big concern of mine. Stephen From mandy.chung at oracle.com Tue Nov 17 00:02:08 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 17 Nov 2015 00:02:08 +0000 Subject: hg: jigsaw/jake/jdk: 3 new changesets Message-ID: <201511170002.tAH0281w017478@aojmv0008.oracle.com> Changeset: 5babde7bd078 Author: jjg Date: 2015-11-13 15:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5babde7bd078 8142996: move jdk java/util/streams tests into java.base directories Reviewed-by: mchung ! test/java/util/stream/bootlib/TEST.properties + test/java/util/stream/bootlib/java.base/java/util/stream/CollectorOps.java + test/java/util/stream/bootlib/java.base/java/util/stream/DefaultMethodStreams.java + test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestDataProvider.java + test/java/util/stream/bootlib/java.base/java/util/stream/DoubleStreamTestScenario.java + test/java/util/stream/bootlib/java.base/java/util/stream/FlagDeclaringOp.java + test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestDataProvider.java + test/java/util/stream/bootlib/java.base/java/util/stream/IntStreamTestScenario.java + test/java/util/stream/bootlib/java.base/java/util/stream/IntermediateTestOp.java + test/java/util/stream/bootlib/java.base/java/util/stream/LambdaTestHelpers.java + test/java/util/stream/bootlib/java.base/java/util/stream/LambdaTestMode.java + test/java/util/stream/bootlib/java.base/java/util/stream/LoggingTestCase.java + test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestDataProvider.java + test/java/util/stream/bootlib/java.base/java/util/stream/LongStreamTestScenario.java + test/java/util/stream/bootlib/java.base/java/util/stream/OpTestCase.java + test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java + test/java/util/stream/bootlib/java.base/java/util/stream/StatefulTestOp.java + test/java/util/stream/bootlib/java.base/java/util/stream/StatelessTestOp.java + test/java/util/stream/bootlib/java.base/java/util/stream/StreamOpFlagTestHelper.java + test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestDataProvider.java + test/java/util/stream/bootlib/java.base/java/util/stream/StreamTestScenario.java + test/java/util/stream/bootlib/java.base/java/util/stream/TestData.java + test/java/util/stream/bootlib/java.base/java/util/stream/TestFlagExpectedOp.java + test/java/util/stream/bootlib/java.base/java/util/stream/ThowableHelper.java - test/java/util/stream/bootlib/java/util/stream/CollectorOps.java - test/java/util/stream/bootlib/java/util/stream/DefaultMethodStreams.java - test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java - test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java - test/java/util/stream/bootlib/java/util/stream/FlagDeclaringOp.java - test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java - test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java - test/java/util/stream/bootlib/java/util/stream/IntermediateTestOp.java - test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java - test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java - test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java - test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java - test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java - test/java/util/stream/bootlib/java/util/stream/OpTestCase.java - test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java - test/java/util/stream/bootlib/java/util/stream/StatefulTestOp.java - test/java/util/stream/bootlib/java/util/stream/StatelessTestOp.java - test/java/util/stream/bootlib/java/util/stream/StreamOpFlagTestHelper.java - test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java - test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java - test/java/util/stream/bootlib/java/util/stream/TestData.java - test/java/util/stream/bootlib/java/util/stream/TestFlagExpectedOp.java - test/java/util/stream/bootlib/java/util/stream/ThowableHelper.java ! test/java/util/stream/boottest/TEST.properties + test/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java + test/java/util/stream/boottest/java.base/java/util/stream/FlagOpTest.java + test/java/util/stream/boottest/java.base/java/util/stream/IntNodeTest.java + test/java/util/stream/boottest/java.base/java/util/stream/LongNodeTest.java + test/java/util/stream/boottest/java.base/java/util/stream/NodeBuilderTest.java + test/java/util/stream/boottest/java.base/java/util/stream/NodeTest.java + test/java/util/stream/boottest/java.base/java/util/stream/SliceSpliteratorTest.java + test/java/util/stream/boottest/java.base/java/util/stream/SpinedBufferTest.java + test/java/util/stream/boottest/java.base/java/util/stream/StreamFlagsTest.java + test/java/util/stream/boottest/java.base/java/util/stream/StreamOpFlagsTest.java + test/java/util/stream/boottest/java.base/java/util/stream/StreamReuseTest.java - test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java - test/java/util/stream/boottest/java/util/stream/FlagOpTest.java - test/java/util/stream/boottest/java/util/stream/IntNodeTest.java - test/java/util/stream/boottest/java/util/stream/LongNodeTest.java - test/java/util/stream/boottest/java/util/stream/NodeBuilderTest.java - test/java/util/stream/boottest/java/util/stream/NodeTest.java - test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java - test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java - test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java - test/java/util/stream/boottest/java/util/stream/StreamOpFlagsTest.java - test/java/util/stream/boottest/java/util/stream/StreamReuseTest.java ! test/java/util/stream/test/TEST.properties Changeset: 7d50c0ed10ea Author: weijun Date: 2015-11-16 12:54 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d50c0ed10ea 8143015: 5 tests fail with error "Can't find source for class: java.util.stream.OpTestCase" Reviewed-by: weijun Contributed-by: felix.yang at oracle.com ! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java ! test/java/nio/file/Files/StreamLinesTest.java ! test/java/security/PermissionCollection/PermissionCollectionStreamTest.java ! test/java/util/Scanner/ScannerStreamTest.java ! test/java/util/regex/PatternStreamTest.java Changeset: 5b75092f3ecc Author: mchung Date: 2015-11-16 16:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5b75092f3ecc Enable java.util.stream tests ! test/ProblemList.jake.txt ! test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java ! test/java/nio/file/Files/StreamLinesTest.java ! test/java/security/PermissionCollection/PermissionCollectionStreamTest.java ! test/java/util/Scanner/ScannerStreamTest.java ! test/java/util/regex/PatternStreamTest.java ! test/java/util/stream/bootlib/TEST.properties ! test/java/util/stream/boottest/TEST.properties ! test/java/util/stream/test/TEST.properties From mik3hall at gmail.com Tue Nov 17 00:33:24 2015 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 16 Nov 2015 18:33:24 -0600 Subject: jrt file system now has /package and /modules directories In-Reply-To: References: <55B3C320.8060705@oracle.com> <4E32AFF7-3698-43DE-BE5E-654FCFB2E5C7@gmail.com> <55B48789.6020907@oracle.com> <7D888C24-1F5D-4A65-9C11-9C87DAA9BC52@gmail.com> <56491C13.9010203@oracle.com> <564988EA.3080005@oracle.com> Message-ID: <93BA8310-EEC8-4CEB-8F90-1855C59F0802@gmail.com> > On Nov 16, 2015, at 3:42 AM, Michael Hall wrote: > > Now I?ll probably have to reinstall 8 over the top to get it back to default. Going OT again, but if of interest, this didn?t work. I installed the 8 release from the web page. It did download the OS X dmg and seemed to install fine. /usr/libexec/java_home /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home However, java -version openjdk version "1.9.0-internal" OpenJDK Runtime Environment (build 1.9.0-internal-mjh_2015_11_15_10_18-b00) OpenJDK 64-Bit Server VM (build 1.9.0-internal-mjh_2015_11_15_10_18-b00, mixed mode) I am OK with 9, I haven?t had any problems related to it?s use yet for the jdk. But it seems I have to now maintain the jdk going forward through manual builds? Michael Hall From mandy.chung at oracle.com Tue Nov 17 03:12:32 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Nov 2015 19:12:32 -0800 Subject: JDeps: detecting offending packages In-Reply-To: References: <56475144.9030205@oracle.com> <46139409-8DDF-4A17-94CB-4A9026242CDA@oracle.com> <56476186.7030807@oracle.com> Message-ID: > On Nov 15, 2015, at 9:49 AM, Robert Scholte wrote: > > Ah, I see. Adding usage of java.awt.peer.ComponentPeer did indeed expose an offending package again. > > Just out of interest: will jdeps only detect violations of JDK internal APIs or will it also detect violations on modules? In case I switch from executable jar to executable module it could happen that it breaks due to usage of non-exported packages, right? > jdeps does the static analysis on class level and it will flag any use of JDK internal API regardless modules or non-modules. The RFE for jdeps would be to take into the module descriptor into account and see what other thing it could report (e.g. missing require public, stale require, etc). Mandy > regards, > Robert > > Op Sat, 14 Nov 2015 17:29:58 +0100 schreef Alan Bateman : > >> >> >> On 14/11/2015 16:05, Mandy Chung wrote: >>> : >>> I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime. I file a bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8143011 >>> >> I agree and I expect it will be straight-forward once they are moved to their own module. >> >> -Alan. From mandy.chung at oracle.com Tue Nov 17 04:33:19 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 Nov 2015 20:33:19 -0800 Subject: RFR: 8139430 In-Reply-To: <5649DC71.60106@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> <5649DC71.60106@oracle.com> Message-ID: > On Nov 16, 2015, at 5:38 AM, Alan Bateman wrote: > > > > On 16/11/2015 13:01, Alexandre (Shura) Iline wrote: >> V6: >> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/ >> >> > This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting. +1 Mandy From mandy.chung at oracle.com Tue Nov 17 06:11:16 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 17 Nov 2015 06:11:16 +0000 Subject: hg: jigsaw/jake/hotspot: Add uses/provides for jdk.vm.ci module Message-ID: <201511170611.tAH6BGR5009468@aojmv0008.oracle.com> Changeset: 40952d9e4128 Author: mchung Date: 2015-11-16 22:11 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/40952d9e4128 Add uses/provides for jdk.vm.ci module ! src/jdk.vm.ci/share/classes/module-info.java From frank.yuan at oracle.com Tue Nov 17 10:02:19 2015 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 17 Nov 2015 18:02:19 +0800 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564A2732.4030307@oracle.com> References: <564A081E.3010809@oracle.com> <564A2732.4030307@oracle.com> Message-ID: <045401d1211f$0d6c7710$28456530$@oracle.com> > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf Of Alan Bateman > Subject: Re: A way to opt out of access restrictions on non-exported members. > > On 16/11/2015 17:48, Neil Bartlett wrote: > > Alan, > > > > In your consideration does the following declaration break encapsulation of a module, assuming that package ?org.example.impl? is > not exported? > > > > module foo { > > provides org.example.api.ServiceInterface with org.example.impl.ServiceImpl; > > } > > > > This appears to allow the ServiceLoader to punch through encapsulation and obtain instances of a non-exported type. > Sure, but this just part of the support for services. In this example then the service provider is fully encapsulated. The consumer of the > service can't access ServiceImpl, it instead accesses it via ServiceInterface (assuming of course that the consumer reads the module > with ServiceInterface and org.example.api is exported to the consumer). > > > How does this differ from a declaration that one might see in a Dependency Injection framework such as Spring? I.e. something like: > > > > ? > > > There isn't way to give Spring super powers so this needs foo to export org.example.impl to Spring. I think exporting org.example.impl and then Spring reading is reasonable and enough for supporting DI framework, but is it ok to give super power to java.base? I am not sure if it punches only for supporting ServiceLoader in AccessibleObject.java: void checkCanSetAccessible(Class caller, Class declaringClass) { Module callerModule = caller.getModule(); Module declaringModule = declaringClass.getModule(); if (callerModule != declaringModule && callerModule != Object.class.getModule()) { // check reads if (!callerModule.canRead(declaringModule)) { String msg = "Unable to make member of " + declaringClass + " accessible: " + callerModule + " does not read " + declaringModule; Reflection.throwInaccessibleObjectException(msg); } .... Why we don't make special handling for use and provide in our code? that should also achieve Service loading. At least, javadoc of AccessibleObject.setAccessible doesn't state java.base has special permission, we need to update if we keep this impl. Frank > > -Alan. From alan.bateman at oracle.com Tue Nov 17 10:55:28 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 17 Nov 2015 10:55:28 +0000 Subject: hg: jigsaw/jake/jaxp: API package for JEP 268 needs to be exported Message-ID: <201511171055.tAHAtSdS027203@aojmv0008.oracle.com> Changeset: ae316cf164c6 Author: alanb Date: 2015-11-17 10:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ae316cf164c6 API package for JEP 268 needs to be exported ! src/java.xml/share/classes/module-info.java From sundararajan.athijegannathan at oracle.com Tue Nov 17 11:59:12 2015 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 17 Nov 2015 11:59:12 +0000 Subject: hg: jigsaw/jake/jdk: 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages Message-ID: <201511171159.tAHBxb2W015935@aojmv0008.oracle.com> Changeset: 67c711a267db Author: sundar Date: 2015-11-17 12:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/67c711a267db 8141521: jrt file system's DirectoryStream reports child paths with wrong paths for directories under /packages Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/jimage/UTF8String.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtPath.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java ! test/jdk/internal/jrtfs/Basic.java From jean-francois.denise at oracle.com Tue Nov 17 12:39:58 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Tue, 17 Nov 2015 13:39:58 +0100 Subject: RFR: 8143126 Message-ID: <94617ED1-75DB-4CAA-99AA-06A2A74AEC42@oracle.com> Hi, I removed a noisy call to System.out. Webrev http://cr.openjdk.java.net/~jfdenise/8143126/ Thanks. JF From alan.bateman at oracle.com Tue Nov 17 13:26:59 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 17 Nov 2015 13:26:59 +0000 Subject: hg: jigsaw/jake/langtools: Temporarily exclude jshell tests Message-ID: <201511171326.tAHDQxFj011487@aojmv0008.oracle.com> Changeset: 4618e0097e6a Author: alanb Date: 2015-11-17 13:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4618e0097e6a Temporarily exclude jshell tests ! test/ProblemList.jake.txt From jean-francois.denise at oracle.com Tue Nov 17 14:41:19 2015 From: jean-francois.denise at oracle.com (jean-francois.denise at oracle.com) Date: Tue, 17 Nov 2015 14:41:19 +0000 Subject: hg: jigsaw/jake/jdk: Fix for 8142485, Jake doesn't build on Windows after recent change to libjimage Message-ID: <201511171441.tAHEfKdl001314@aojmv0008.oracle.com> Changeset: e1579b30cbec Author: jfdenise Date: 2015-11-17 15:41 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e1579b30cbec Fix for 8142485, Jake doesn't build on Windows after recent change to libjimage Reviewed-by: mchung, jlaskey ! src/java.base/share/classes/jdk/internal/jimage/decompressor/CompressedResourceHeader.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ResourceDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/StringSharingDecompressor.java ! src/java.base/share/classes/jdk/internal/jimage/decompressor/ZipDecompressor.java ! src/java.base/share/native/libjimage/ImageNativeSubstrate.cpp ! src/java.base/share/native/libjimage/imageDecompressor.cpp ! src/java.base/share/native/libjimage/imageDecompressor.hpp ! src/java.base/share/native/libjimage/imageFile.cpp From erik.joelsson at oracle.com Tue Nov 17 15:30:32 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:30:32 +0000 Subject: hg: jigsaw/jake: Preparing makefiles for sjavac Message-ID: <201511171530.tAHFUWUa014351@aojmv0008.oracle.com> Changeset: 2cffaee2b44e Author: erikj Date: 2015-11-17 16:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2cffaee2b44e Preparing makefiles for sjavac ! make/JrtfsJar.gmk ! make/common/JavaCompilation.gmk From erik.joelsson at oracle.com Tue Nov 17 15:30:38 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:30:38 +0000 Subject: hg: jigsaw/jake/corba: Preparing makefiles for sjavac Message-ID: <201511171531.tAHFV4Fc014660@aojmv0008.oracle.com> Changeset: 341389d6ae08 Author: erikj Date: 2015-11-17 16:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/341389d6ae08 Preparing makefiles for sjavac ! make/gensrc/Gensrc-java.corba.gmk From erik.joelsson at oracle.com Tue Nov 17 15:31:24 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:31:24 +0000 Subject: hg: jigsaw/jake/jdk: Preparing makefiles for sjavac Message-ID: <201511171531.tAHFVO1v014927@aojmv0008.oracle.com> Changeset: c40287b843b3 Author: erikj Date: 2015-11-17 16:26 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c40287b843b3 Preparing makefiles for sjavac ! make/CompileInterimRmic.gmk From sundararajan.athijegannathan at oracle.com Tue Nov 17 15:33:40 2015 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 17 Nov 2015 15:33:40 +0000 Subject: hg: jigsaw/jake/nashorn: 8142991: Re-examine jdk.scripting.nashorn.shell linked in JRE that drags in jdk.compiler Message-ID: <201511171533.tAHFXe4M015859@aojmv0008.oracle.com> Changeset: baa4d288d717 Author: sundar Date: 2015-11-17 16:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/baa4d288d717 8142991: Re-examine jdk.scripting.nashorn.shell linked in JRE that drags in jdk.compiler Reviewed-by: jlaskey ! src/jdk.scripting.nashorn.shell/share/classes/module-info.java From erik.joelsson at oracle.com Tue Nov 17 15:38:22 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:38:22 +0000 Subject: hg: jigsaw/jake: Jake part of JDK-8143141, makefile cleanup between jake and jdk9 Message-ID: <201511171538.tAHFcMEL016914@aojmv0008.oracle.com> Changeset: 48e940c6eece Author: erikj Date: 2015-11-17 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/48e940c6eece Jake part of JDK-8143141, makefile cleanup between jake and jdk9 ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/bin/compare.sh ! make/CompileJavaModules.gmk ! make/HotspotWrapper.gmk ! make/StripBinaries.gmk ! make/common/JavaCompilation.gmk From erik.joelsson at oracle.com Tue Nov 17 15:38:51 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:38:51 +0000 Subject: hg: jigsaw/jake/corba: Jake part of JDK-8143141, makefile cleanup between jake and jdk9 Message-ID: <201511171538.tAHFcp6o017026@aojmv0008.oracle.com> Changeset: 355803ae4e8a Author: erikj Date: 2015-11-17 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/355803ae4e8a Jake part of JDK-8143141, makefile cleanup between jake and jdk9 ! make/copy/Copy-java.corba.gmk From erik.joelsson at oracle.com Tue Nov 17 15:39:05 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:39:05 +0000 Subject: hg: jigsaw/jake/hotspot: Jake part of JDK-8143141, makefile cleanup between jake and jdk9 Message-ID: <201511171539.tAHFd5Df017076@aojmv0008.oracle.com> Changeset: 3cd01614795b Author: erikj Date: 2015-11-17 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3cd01614795b Jake part of JDK-8143141, makefile cleanup between jake and jdk9 ! make/gensrc/Gensrc-jdk.vm.ci.gmk From erik.joelsson at oracle.com Tue Nov 17 15:39:44 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:39:44 +0000 Subject: hg: jigsaw/jake/jdk: Jake part of JDK-8143141, makefile cleanup between jake and jdk9 Message-ID: <201511171539.tAHFdidf017325@aojmv0008.oracle.com> Changeset: 2376cb553336 Author: erikj Date: 2015-11-17 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2376cb553336 Jake part of JDK-8143141, makefile cleanup between jake and jdk9 ! make/copy/Copy-java.base.gmk ! make/copy/CopyCommon.gmk ! make/gensrc/Gensrc-java.management.gmk ! make/launcher/Launcher-java.base.gmk ! make/launcher/Launcher-java.corba.gmk ! make/launcher/Launcher-java.desktop.gmk ! make/launcher/Launcher-java.rmi.gmk ! make/launcher/Launcher-java.scripting.gmk ! make/launcher/Launcher-java.security.jgss.gmk ! make/launcher/Launcher-jdk.compiler.gmk ! make/launcher/Launcher-jdk.hotspot.agent.gmk ! make/launcher/Launcher-jdk.jartool.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jcmd.gmk ! make/launcher/Launcher-jdk.jconsole.gmk ! make/launcher/Launcher-jdk.jdeps.gmk ! make/launcher/Launcher-jdk.jdi.gmk ! make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.jshell.gmk ! make/launcher/Launcher-jdk.jvmstat.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/Launcher-jdk.policytool.gmk ! make/launcher/Launcher-jdk.rmic.gmk ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk ! make/launcher/Launcher-jdk.xml.bind.gmk ! make/launcher/Launcher-jdk.xml.ws.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-jdk.crypto.ucrypto.gmk ! make/lib/Lib-jdk.internal.le.gmk ! make/lib/SecurityLibraries.gmk From erik.joelsson at oracle.com Tue Nov 17 15:40:06 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Nov 2015 15:40:06 +0000 Subject: hg: jigsaw/jake/langtools: Jake part of JDK-8143141, makefile cleanup between jake and jdk9 Message-ID: <201511171540.tAHFe6dw017399@aojmv0008.oracle.com> Changeset: d63276f7f746 Author: erikj Date: 2015-11-17 16:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d63276f7f746 Jake part of JDK-8143141, makefile cleanup between jake and jdk9 ! make/gendata/Gendata-jdk.compiler.gmk From mandy.chung at oracle.com Tue Nov 17 16:58:04 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Nov 2015 08:58:04 -0800 Subject: RFR: 8143126 In-Reply-To: <94617ED1-75DB-4CAA-99AA-06A2A74AEC42@oracle.com> References: <94617ED1-75DB-4CAA-99AA-06A2A74AEC42@oracle.com> Message-ID: > On Nov 17, 2015, at 4:39 AM, Jean-Francois Denise wrote: > > Hi, > I removed a noisy call to System.out. > Webrev http://cr.openjdk.java.net/~jfdenise/8143126 +1 Mandy From mandy.chung at oracle.com Tue Nov 17 23:13:18 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 17 Nov 2015 23:13:18 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511172313.tAHNDJv8000592@aojmv0008.oracle.com> Changeset: e5fcea3aa679 Author: mchung Date: 2015-11-17 15:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e5fcea3aa679 Enable the test case to verify unnamed module fails to load properties bundle from named module ! test/java/util/logging/modules/pkgs/p3/test/ResourceBundleTest.java Changeset: 5aadb299a052 Author: mchung Date: 2015-11-17 15:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5aadb299a052 Merge From pbenedict at apache.org Wed Nov 18 01:18:43 2015 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 17 Nov 2015 19:18:43 -0600 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564A081E.3010809@oracle.com> References: <564A081E.3010809@oracle.com> Message-ID: I don't see how this approach could ever work in an EE container. An existing module can't guess who needs to reach inside to perform dependency injection, annotation or class scanning. Can't there be some concept of a "trusted" module (signed?) that gives it superuser access to any other module? Obviously an EE container would fit this description. Cheers, Paul On Mon, Nov 16, 2015 at 10:45 AM, Alan Bateman wrote: > > > On 16/11/2015 12:28, Stephen Colebourne wrote: > >> Access to private members of classes by reflection is indeed very, >> very common. I agree that JDK 9 needs to be cautious around this. >> >> >> I think this thread is just highlighting the obvious tension between > modules with encapsulation vs. serialization and other frameworks that need > to break encapsulation. At this time then explicit modules have to opt-in > to allow frameworks get access types in those packages. This can be done in > the module declaration or at run-time via the API. The alternative is of > course the all-powerful command line. > > As regards setAccessible(true) then it would be nice to have it eventually > go away in some future release. This would clearly require coming up with > solutions to some difficult problems and use-cases. > > -Alan > From peter.levart at gmail.com Wed Nov 18 08:03:32 2015 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 18 Nov 2015 09:03:32 +0100 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564A2732.4030307@oracle.com> References: <564A081E.3010809@oracle.com> <564A2732.4030307@oracle.com> Message-ID: <564C30D4.6080208@gmail.com> On 11/16/2015 07:57 PM, Alan Bateman wrote: > On 16/11/2015 17:48, Neil Bartlett wrote: >> Alan, >> >> In your consideration does the following declaration break >> encapsulation of a module, assuming that package ?org.example.impl? >> is not exported? >> >> module foo { >> provides org.example.api.ServiceInterface with >> org.example.impl.ServiceImpl; >> } >> >> This appears to allow the ServiceLoader to punch through >> encapsulation and obtain instances of a non-exported type. > Sure, but this just part of the support for services. In this example > then the service provider is fully encapsulated. The consumer of the > service can't access ServiceImpl, it instead accesses it via > ServiceInterface (assuming of course that the consumer reads the > module with ServiceInterface and org.example.api is exported to the > consumer). > >> How does this differ from a declaration that one might see in a >> Dependency Injection framework such as Spring? I.e. something like: >> >> ? >> > There isn't way to give Spring super powers so this needs foo to > export org.example.impl to Spring. > > -Alan. Hi, Just a thought (and I don't know yet if it is a good idea)... ServiceLoader currently has the following method: public static ServiceLoader load(Class service, ClassLoader loader) With the following overload: public static ServiceLoader load(Class service, ClassLoader loader, Function>, Stream>> streamManipulator) We (or Spring) could use it like: ServiceLoader loader = ServiceLoader.load( ServiceInterface.class, classLoader, stream -> stream.filter(implClass -> implClass.getName().equals("org.example.impl.ServiceImpl")) ); This could also be used to code various other strategies for service lookup, for example: public @interface Order { int value() default 100; } ServiceLoader loader = ServiceLoader.load( ServiceInterface.class, classLoader, stream -> stream.sorted( comparing(implClass -> implClass.getAnnotation(Order.class), comparing(Order::value)) ) ); This way the powers of instantiating the implementation classes are left to ServiceLoader, but client can decide what implementation classes are chosen. Regards, Peter From Alan.Bateman at oracle.com Wed Nov 18 09:17:36 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Nov 2015 09:17:36 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> Message-ID: <564C4230.1070802@oracle.com> On 18/11/2015 01:18, Paul Benedict wrote: > I don't see how this approach could ever work in an EE container. An > existing module can't guess who needs to reach inside to perform > dependency injection, annotation or class scanning. Can't there be > some concept of a "trusted" module (signed?) that gives it superuser > access to any other module? Obviously an EE container would fit this > description. > The EE container case might not be too bad as the EE container creates the configuration and so could arrange additional qualified exports when not using services. Details TBD, it might be that the container injects a helper into the application configuration, maybe it wraps the entry point so that code to export the otherwise internal packages to the framework/container. Modules are a fundamental change and it's important that we get it right. To that end, it's important to have a number of frameworks/containers working with us and helping to understand and work through the migration issues. -Alan From ali.ebrahimi1781 at gmail.com Wed Nov 18 10:04:53 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 18 Nov 2015 13:34:53 +0330 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564C4230.1070802@oracle.com> References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> Message-ID: Hi, Currently only code inside java.base module can add (qualified) exports programmatically. On Wed, Nov 18, 2015 at 12:47 PM, Alan Bateman wrote: > > On 18/11/2015 01:18, Paul Benedict wrote: > >> I don't see how this approach could ever work in an EE container. An >> existing module can't guess who needs to reach inside to perform dependency >> injection, annotation or class scanning. Can't there be some concept of a >> "trusted" module (signed?) that gives it superuser access to any other >> module? Obviously an EE container would fit this description. >> >> The EE container case might not be too bad as the EE container creates > the configuration and so could arrange additional qualified exports when > not using services. Details TBD, it might be that the container injects a > helper into the application configuration, maybe it wraps the entry point > so that code to export the otherwise internal packages to the > framework/container. Modules are a fundamental change and it's important > that we get it right. To that end, it's important to have a number of > frameworks/containers working with us and helping to understand and work > through the migration issues. > > -Alan > -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Wed Nov 18 10:23:08 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Nov 2015 10:23:08 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> Message-ID: <564C518C.3050807@oracle.com> On 18/11/2015 10:04, Ali Ebrahimi wrote: > Hi, > Currently only code inside java.base module can add (qualified) > exports programmatically. > Any module can export any of its packages to another module via the API. In the EE container case then there are a number of options to explore. It would clearly be desirable to aim for services in the medium term. Failing that then the EE containers will be creating dynamic configurations and so should be able to arrange for the equivalent of the -XaddExports command-line option that we have for the boot layer. -Alan From ali.ebrahimi1781 at gmail.com Wed Nov 18 10:55:23 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 18 Nov 2015 14:25:23 +0330 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564C518C.3050807@oracle.com> References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> <564C518C.3050807@oracle.com> Message-ID: Hi, On Wed, Nov 18, 2015 at 1:53 PM, Alan Bateman wrote: > > On 18/11/2015 10:04, Ali Ebrahimi wrote: > > Hi, > Currently only code inside java.base module can add (qualified) > exports programmatically. > > Any module can export any of its packages to another module via the API. > > In the EE container case then there are a number of options to explore. It > would clearly be desirable to aim for services in the medium term. Failing > that then the EE containers will be creating dynamic configurations and so > should be able to arrange for the equivalent of the -XaddExports > command-line option that we have for the boot layer. > > -Alan > For adding exports as I know there is two options: option 1: public Module.addExports @CallerSensitive public Module addExports(String pn, Module target) { if (pn == null) throw new IllegalArgumentException("package is null"); Objects.requireNonNull(target); if (isNamed()) { Module caller = Reflection.getCallerClass().getModule(); if (caller != this) { throw new IllegalStateException(caller + " != " + this); } implAddExports(pn, target, true); } return this; } option 2: internal for java.base jdk.internal.module.Modules.addExports(source, pn, target) As you can see option 1 is useless, why? because /** * If the caller's module is this module then update this module to export * package {@code pn} to the given {@code target} module. I think for all use cases we would have caller's module != this module So this don't work. Option 2 will fail since that is internal for java.base purpose only. Is there other options? (non-command-line options) -- Best Regards, Ali Ebrahimi From Alan.Bateman at oracle.com Wed Nov 18 11:08:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Nov 2015 11:08:19 +0000 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> <564C518C.3050807@oracle.com> Message-ID: <564C5C23.3050107@oracle.com> On 18/11/2015 10:55, Ali Ebrahimi wrote: > : > > Is there other options? (non-command-line options) > As I said in one of the previous mails, there are a number of things that can be explored. The EE container creating the configuration can control the exports, it can completely override module declarations if it really wants to. Another option might be wrapping the entry point so that the any additional exports are set when the container is launching the application. I think we should be confident that we can work through all these issues and come up with the right solutions. -Alan From erik.joelsson at oracle.com Wed Nov 18 11:21:56 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 11:21:56 +0000 Subject: hg: jigsaw/jake: Fixed compilation error when importing modules Message-ID: <201511181121.tAIBLugr024112@aojmv0008.oracle.com> Changeset: 677465fa89aa Author: erikj Date: 2015-11-18 12:21 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/677465fa89aa Fixed compilation error when importing modules ! make/CompileJavaModules.gmk From erik.joelsson at oracle.com Wed Nov 18 11:58:39 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 11:58:39 +0000 Subject: hg: jigsaw/jake: Reverting unneeded jigsaw specific changes Message-ID: <201511181158.tAIBwe4g005044@aojmv0008.oracle.com> Changeset: 903bd87f9402 Author: erikj Date: 2015-11-18 12:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/903bd87f9402 Reverting unneeded jigsaw specific changes ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! make/CompileJavaModules.gmk ! make/CreateBuildJdkCopy.gmk ! make/CreateJmods.gmk ! make/GensrcModuleInfo.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/ModuleWrapper.gmk ! make/StripBinaries.gmk ! make/ZipSource.gmk ! make/common/MakeBase.gmk From erik.joelsson at oracle.com Wed Nov 18 11:58:54 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 11:58:54 +0000 Subject: hg: jigsaw/jake/corba: Reverting unneeded jigsaw specific changes Message-ID: <201511181158.tAIBws8d005140@aojmv0008.oracle.com> Changeset: 2cc9f6df4e50 Author: erikj Date: 2015-11-18 12:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/2cc9f6df4e50 Reverting unneeded jigsaw specific changes ! make/copy/Copy-java.corba.gmk ! make/gensrc/Gensrc-java.corba.gmk From erik.joelsson at oracle.com Wed Nov 18 11:59:08 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 11:59:08 +0000 Subject: hg: jigsaw/jake/hotspot: Reverting unneeded jigsaw specific changes Message-ID: <201511181159.tAIBx8mo005259@aojmv0008.oracle.com> Changeset: 222c2519e1cb Author: erikj Date: 2015-11-18 12:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/222c2519e1cb Reverting unneeded jigsaw specific changes ! make/gensrc/Gensrc-jdk.vm.ci.gmk From erik.joelsson at oracle.com Wed Nov 18 11:59:46 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 11:59:46 +0000 Subject: hg: jigsaw/jake/jdk: Reverting unneeded jigsaw specific changes Message-ID: <201511181159.tAIBxkW6005763@aojmv0008.oracle.com> Changeset: fa885780a428 Author: erikj Date: 2015-11-18 12:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa885780a428 Reverting unneeded jigsaw specific changes ! make/Import.gmk ! make/copy/CopyCommon.gmk ! make/gendata/Gendata-java.base.gmk ! make/gendata/GendataBlacklistedCerts.gmk ! make/gendata/GendataFontConfig.gmk ! make/gendata/GendataPolicyJars.gmk ! make/gendata/GendataTZDB.gmk ! make/gensrc/Gensrc-jdk.charsets.gmk ! make/gensrc/Gensrc-jdk.jdi.gmk ! make/gensrc/GensrcBuffer.gmk ! make/gensrc/GensrcCLDR.gmk ! make/gensrc/GensrcCharacterData.gmk ! make/gensrc/GensrcCharsetCoder.gmk ! make/gensrc/GensrcCharsetMapping.gmk ! make/gensrc/GensrcExceptions.gmk ! make/gensrc/GensrcIcons.gmk ! make/gensrc/GensrcLocaleData.gmk ! make/gensrc/GensrcMisc.gmk ! make/gensrc/GensrcModuleLoaderMap.gmk ! make/gensrc/GensrcProperties.gmk ! make/gensrc/GensrcSwing.gmk ! make/gensrc/GensrcX11Wrappers.gmk ! make/launcher/Launcher-java.base.gmk ! make/launcher/Launcher-jdk.accessibility.gmk ! make/launcher/Launcher-jdk.pack200.gmk ! make/launcher/LauncherCommon.gmk ! make/lib/Awt2dLibraries.gmk ! make/lib/CoreLibraries.gmk ! make/lib/Lib-java.instrument.gmk ! make/lib/Lib-java.management.gmk ! make/lib/Lib-java.prefs.gmk ! make/lib/Lib-java.security.jgss.gmk ! make/lib/Lib-java.smartcardio.gmk ! make/lib/Lib-jdk.accessibility.gmk ! make/lib/Lib-jdk.attach.gmk ! make/lib/Lib-jdk.crypto.ec.gmk ! make/lib/Lib-jdk.crypto.mscapi.gmk ! make/lib/Lib-jdk.crypto.pkcs11.gmk ! make/lib/Lib-jdk.crypto.ucrypto.gmk ! make/lib/Lib-jdk.deploy.osx.gmk ! make/lib/Lib-jdk.internal.le.gmk ! make/lib/Lib-jdk.jdi.gmk ! make/lib/Lib-jdk.jdwp.agent.gmk ! make/lib/Lib-jdk.management.gmk ! make/lib/Lib-jdk.pack200.gmk ! make/lib/Lib-jdk.sctp.gmk ! make/lib/Lib-jdk.security.auth.gmk ! make/lib/LibCommon.gmk ! make/lib/NetworkingLibraries.gmk ! make/lib/NioLibraries.gmk ! make/lib/PlatformLibraries.gmk ! make/lib/SecurityLibraries.gmk ! make/lib/SoundLibraries.gmk From erik.joelsson at oracle.com Wed Nov 18 12:00:14 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 12:00:14 +0000 Subject: hg: jigsaw/jake/langtools: Reverting unneeded jigsaw specific changes Message-ID: <201511181200.tAIC0Ep5006077@aojmv0008.oracle.com> Changeset: 70ad7a14ed9b Author: erikj Date: 2015-11-18 12:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/70ad7a14ed9b Reverting unneeded jigsaw specific changes ! make/CompileInterim.gmk ! make/gendata/Gendata-jdk.compiler.gmk ! make/gensrc/GensrcCommon.gmk From forax at univ-mlv.fr Wed Nov 18 12:18:37 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 18 Nov 2015 13:18:37 +0100 (CET) Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> Message-ID: <395283695.1610546.1447849117169.JavaMail.zimbra@u-pem.fr> Hi Neil, If you already have an instance of a non exported type, then there is no issue because applications only access this instance through an interface which is itself exported. The main issue if how to create such instance, we need a factory which works in jigsaw mode. You can not use reflection to automatically implement such factory because trying to call a constructor of a non exported class will be rejected by jigsaw. Here, you have several solutions: - as Alan said, if you are a container you control the module configurations, so you control if package is exported or not but that's cheating, because the container changes the module configuration written by the user. - as you said you can use the mechanism of ServiceLoader or your favorite DI can use the ServiceLoader under the hood BTW, - you can re-implement a strawman version of the ServiceLoader by writing a code inside the implementation class that will add a factory (a lambda) inside a hashmap (a registry) which is globally accessible. Or you can consider that an implementation that is globally available should be in an exported package because the configuration code (yes code, no XML and no annotation) should access it. cheers, R?mi ----- Mail original ----- > De: "Neil Bartlett" > ?: "Alan Bateman" > Cc: "jigsaw-dev" > Envoy?: Lundi 16 Novembre 2015 18:48:54 > Objet: Re: A way to opt out of access restrictions on non-exported members. > > Alan, > > In your consideration does the following declaration break encapsulation of a > module, assuming that package ?org.example.impl? is not exported? > > module foo { > provides org.example.api.ServiceInterface with > org.example.impl.ServiceImpl; > } > > This appears to allow the ServiceLoader to punch through encapsulation and > obtain instances of a non-exported type. How does this differ from a > declaration that one might see in a Dependency Injection framework such as > Spring? I.e. something like: > > ? > > Regards, > Neil > > > > On 16 Nov 2015, at 16:45, Alan Bateman wrote: > > > > > > > > On 16/11/2015 12:28, Stephen Colebourne wrote: > >> Access to private members of classes by reflection is indeed very, > >> very common. I agree that JDK 9 needs to be cautious around this. > >> > >> > > I think this thread is just highlighting the obvious tension between > > modules with encapsulation vs. serialization and other frameworks that > > need to break encapsulation. At this time then explicit modules have to > > opt-in to allow frameworks get access types in those packages. This can be > > done in the module declaration or at run-time via the API. The alternative > > is of course the all-powerful command line. > > > > As regards setAccessible(true) then it would be nice to have it eventually > > go away in some future release. This would clearly require coming up with > > solutions to some difficult problems and use-cases. > > > > -Alan > > From ali.ebrahimi1781 at gmail.com Wed Nov 18 12:27:58 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 18 Nov 2015 15:57:58 +0330 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <564C5C23.3050107@oracle.com> References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> <564C518C.3050807@oracle.com> <564C5C23.3050107@oracle.com> Message-ID: Hi, On Wed, Nov 18, 2015 at 2:38 PM, Alan Bateman wrote: > > > On 18/11/2015 10:55, Ali Ebrahimi wrote: > > : > > Is there other options? (non-command-line options) > > As I said in one of the previous mails, there are a number of things that > can be explored. The EE container creating the configuration can control > the exports, it can completely override module declarations if it really > wants to. Another option might be wrapping the entry point so that the any > additional exports are set when the container is launching the application. > I think we should be confident that we can work through all these issues > and come up with the right solutions. > I think we need some friend (or privileged or trusted or bootstrapper) module concept that have full access for all modules in configuration that this module created. bootstrapper module == configuration creator module This can be used for all containers (EE or OSGI or Spring, ..., even my toy jakecontainer ). -- Best Regards, Ali Ebrahimi From erik.joelsson at oracle.com Wed Nov 18 12:56:21 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 12:56:21 +0000 Subject: hg: jigsaw/jake: Removed some more outdated jigsaw specifics parts from build files Message-ID: <201511181256.tAICuLw3026267@aojmv0008.oracle.com> Changeset: 7cf69b6b3538 Author: erikj Date: 2015-11-18 13:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7cf69b6b3538 Removed some more outdated jigsaw specifics parts from build files ! common/autoconf/configure.ac ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in From harold.seigel at oracle.com Wed Nov 18 15:00:47 2015 From: harold.seigel at oracle.com (harold.seigel at oracle.com) Date: Wed, 18 Nov 2015 15:00:47 +0000 Subject: hg: jigsaw/jake/hotspot: Add call to forName() so a class in package sun/invoke/util/ is referenced before requesting its location. Message-ID: <201511181500.tAIF0l78005997@aojmv0008.oracle.com> Changeset: 3f1ab53fc90d Author: hseigel Date: 2015-11-18 09:38 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3f1ab53fc90d Add call to forName() so a class in package sun/invoke/util/ is referenced before requesting its location. ! test/runtime/getSysPackage/GetSysPkgTest.java From erik.joelsson at oracle.com Wed Nov 18 16:15:50 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 18 Nov 2015 16:15:50 +0000 Subject: hg: jigsaw/jake: Refixed cross compilation Message-ID: <201511181615.tAIGFo81003115@aojmv0008.oracle.com> Changeset: a95a37aa12bf Author: erikj Date: 2015-11-18 17:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a95a37aa12bf Refixed cross compilation ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! make/HotspotWrapper.gmk From alan.bateman at oracle.com Wed Nov 18 16:49:29 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 18 Nov 2015 16:49:29 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511181649.tAIGnTJs016512@aojmv0008.oracle.com> Changeset: c1a46b310ca2 Author: alanb Date: 2015-11-18 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c1a46b310ca2 Using -limitmods so that it includes, but does not resolve, the modules specified to -m and -addmods ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkTask.java ! test/jdk/jigsaw/launcher/addmods/AddModsTest.java ! test/jdk/jigsaw/launcher/limitmods/LimitModsTest.java Changeset: 1d2dd559597e Author: alanb Date: 2015-11-18 16:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1d2dd559597e Part 1 of Class::getPackageName ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/sun/reflect/Reflection.java + test/java/lang/Class/getPackageName/Basic.java From markus.gronlund at oracle.com Wed Nov 18 17:45:23 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 18 Nov 2015 09:45:23 -0800 (PST) Subject: RFR(XS): 8143228: Update module exports for Java Flight Recorder Message-ID: Greetings, Looking for review of the following to update module exports for Java Flight Recorder: Bug: https://bugs.openjdk.java.net/browse/JDK-8143228 Change: Patch is attached and also unrolled here: # HG changeset patch # User mgronlun # Date 1447764614 -3600 # Tue Nov 17 13:50:14 2015 +0100 # Node ID e452cc5ea183f4db155514a5ae6201e83ef70c95 # Parent 93f2a16f683dd52cbe08ab3aa277535db13473ee [mq]: jdk_top_level diff --git a/common/bin/compare_exceptions.sh.incl b/common/bin/compare_exceptions.sh.incl --- a/common/bin/compare_exceptions.sh.incl +++ b/common/bin/compare_exceptions.sh.incl @@ -231,7 +231,6 @@ ./lib/amd64/libjava.so ./lib/amd64/libjawt.so ./lib/amd64/libjdwp.so -./lib/amd64/libjfr.so ./lib/amd64/libjpeg.so ./lib/amd64/libjsdt.so ./lib/amd64/libjsound.so @@ -364,7 +363,6 @@ ./lib/sparcv9/libjava.so ./lib/sparcv9/libjawt.so ./lib/sparcv9/libjdwp.so -./lib/sparcv9/libjfr.so ./lib/sparcv9/libjpeg.so ./lib/sparcv9/libjsdt.so ./lib/sparcv9/libjsound.so diff --git a/modules.xml b/modules.xml --- a/modules.xml +++ b/modules.xml @@ -236,6 +236,22 @@ jdk.scripting.nashorn + jdk.internal.org.xml.sax + jdk.jfr + + + jdk.internal.org.xml.sax.helpers + jdk.jfr + + + jdk.internal.util.xml + jdk.jfr + + + jdk.internal.util.xml.impl + jdk.jfr + + jdk.internal.org.objectweb.asm java.instrument jdk.jfr @@ -287,6 +303,7 @@ jdk.httpserver jdk.jartool jdk.jconsole + jdk.jfr jdk.jvmstat jdk.management.resource jdk.pack200 @@ -869,6 +886,7 @@ sun.management.spi jdk.management jdk.management.cmm + jdk.management.jfr
Thanks in advance Markus From Alan.Bateman at oracle.com Wed Nov 18 19:25:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 Nov 2015 19:25:05 +0000 Subject: RFR(XS): 8143228: Update module exports for Java Flight Recorder In-Reply-To: References: Message-ID: <564CD091.4080509@oracle.com> On 18/11/2015 17:45, Markus Gronlund wrote: > Greetings, > > > > Looking for review of the following to update module exports for Java Flight Recorder: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143228 > > > > Change: > > The changes to modules.xml look okay although I think we should figure out a way to drop these dependences at some point. -Alan From markus.gronlund at oracle.com Wed Nov 18 19:58:47 2015 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 18 Nov 2015 11:58:47 -0800 (PST) Subject: RFR(XS): 8143228: Update module exports for Java Flight Recorder In-Reply-To: <564CD091.4080509@oracle.com> References: <564CD091.4080509@oracle.com> Message-ID: <12c349e5-d9c2-4849-899a-2be37935c386@default> Thank you Alan. I agree on coming up with a evolution path here. Thanks for now. /Markus -----Original Message----- From: Alan Bateman Sent: den 18 november 2015 20:25 To: Markus Gronlund; jigsaw-dev at openjdk.java.net; serviceability-dev Subject: Re: RFR(XS): 8143228: Update module exports for Java Flight Recorder On 18/11/2015 17:45, Markus Gronlund wrote: > Greetings, > > > > Looking for review of the following to update module exports for Java Flight Recorder: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143228 > > > > Change: > > The changes to modules.xml look okay although I think we should figure out a way to drop these dependences at some point. -Alan From amy.lu at oracle.com Thu Nov 19 14:03:33 2015 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 19 Nov 2015 22:03:33 +0800 Subject: [jake] RFR JDK-8132672: DGCDeadLock test needs to be updated to wok with update setAccessible Message-ID: <564DD6B5.6090303@oracle.com> java/rmi/transport/dgcDeadLock/DGCDeadLock.java is a white-box test that needs to access internal objects by purpose. This patch is to add "-XaddExports" to the test. Please review. bug: https://bugs.openjdk.java.net/browse/JDK-8132672 webrev: http://cr.openjdk.java.net/~amlu/8132672/webrev.00 Thanks, Amy --- old/test/ProblemList.jake.txt 2015-11-19 17:52:25.000000000 +0800 +++ new/test/ProblemList.jake.txt 2015-11-19 17:52:25.000000000 +0800 @@ -66,9 +66,6 @@ # 8078484 sun/rmi/rmic/newrmic/equivalence/run.sh generic-all -# 8132672 -java/rmi/transport/dgcDeadLock/DGCDeadLock.java generic-all - ############################################################################ # jdk_other --- old/test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java 2015-11-19 17:52:26.000000000 +0800 +++ new/test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java 2015-11-19 17:52:26.000000000 +0800 @@ -74,6 +74,10 @@ try { String options = " -Djava.security.policy=" + TestParams.defaultPolicy + + " -XaddExports:java.rmi/sun.rmi.registry=ALL-UNNAMED," + + "java.rmi/sun.rmi.server=ALL-UNNAMED," + + "java.rmi/sun.rmi.transport=ALL-UNNAMED," + + "java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED" + " -Djava.rmi.dgc.leaseValue=500000" + " -Dsun.rmi.dgc.checkInterval=" + (HOLD_TARGET_TIME - 5000) + From Alan.Bateman at oracle.com Thu Nov 19 14:27:28 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Nov 2015 14:27:28 +0000 Subject: [jake] RFR JDK-8132672: DGCDeadLock test needs to be updated to wok with update setAccessible In-Reply-To: <564DD6B5.6090303@oracle.com> References: <564DD6B5.6090303@oracle.com> Message-ID: <564DDC50.1000106@oracle.com> On 19/11/2015 14:03, Amy Lu wrote: > java/rmi/transport/dgcDeadLock/DGCDeadLock.java is a white-box test > that needs to access internal objects by purpose. > > This patch is to add "-XaddExports" to the test. Please review. This looks okay to me, thanks for taking this one. -Alan. From alan.bateman at oracle.com Thu Nov 19 15:03:40 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 19 Nov 2015 15:03:40 +0000 Subject: hg: jigsaw/jake/jdk: 8132672: DGCDeadLock test needs to be updated to wok with modules Message-ID: <201511191503.tAJF3eOa029854@aojmv0008.oracle.com> Changeset: e8a58d7ea798 Author: amlu Date: 2015-11-19 15:03 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e8a58d7ea798 8132672: DGCDeadLock test needs to be updated to wok with modules ! test/ProblemList.jake.txt ! test/java/rmi/transport/dgcDeadLock/DGCDeadLock.java From alexandre.iline at oracle.com Thu Nov 19 16:40:17 2015 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 19 Nov 2015 08:40:17 -0800 Subject: RFR: 8139430 In-Reply-To: References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> <5649DC71.60106@oracle.com> Message-ID: <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com> Yes, sorry. Since the methods do not have any work to complete before interrupting and also methods are not used anywhere currently, I assume re-throwing the InterruptedException is a better choice. http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html Shura > On Nov 16, 2015, at 8:33 PM, Mandy Chung wrote: > > >> On Nov 16, 2015, at 5:38 AM, Alan Bateman wrote: >> >> >> >> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote: >>> V6: >>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/ >>> >>> >> This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting. > > +1 > > Mandy > From Alan.Bateman at oracle.com Thu Nov 19 17:49:38 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Nov 2015 17:49:38 +0000 Subject: RFR: 8139430 In-Reply-To: <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> <5649DC71.60106@oracle.com> <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com> Message-ID: <564E0BB2.9050103@oracle.com> On 19/11/2015 16:40, Alexandre (Shura) Iline wrote: > Yes, sorry. > > Since the methods do not have any work to complete before interrupting and also methods are not used anywhere currently, I assume re-throwing the InterruptedException is a better choice. > > http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html > > If handling InterruptedException isn't a burden in these tests then it should be okay. Also this is probably a better anyway if you want to give jtreg a chance to kill a test when it goes bad (say where the target thread is looping and the waitXXX methods will not otherwise complete). -Alan From mandy.chung at oracle.com Thu Nov 19 22:22:35 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 19 Nov 2015 22:22:35 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511192222.tAJMMZAF002055@aojmv0008.oracle.com> Changeset: e6921b23f45b Author: mchung Date: 2015-11-19 14:03 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e6921b23f45b ClassLoader::loadLocalClass should call findClass only if not loaded ! src/java.base/share/classes/java/lang/ClassLoader.java Changeset: f1fff0daf868 Author: mchung Date: 2015-11-19 14:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f1fff0daf868 Rename BootLoader::getPackage to getDefinedPackage ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/Package.java ! src/java.base/share/classes/jdk/internal/misc/BootLoader.java From szegedia at gmail.com Thu Nov 19 23:15:33 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 20 Nov 2015 00:15:33 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink Message-ID: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. The changes in this changeset fall into several categories: - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it - new tests I?m sending this webrev to several lists with the following rationales: - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. - jigsaw-dev because of modules.xml changes - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) - core-libs-dev since that?s the designated JEP 276 discussion list. Nashorn changes: top-level jdk9 changes: Thanks, Attila. From weijun.wang at oracle.com Fri Nov 20 00:40:59 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Nov 2015 08:40:59 +0800 Subject: About 8056174: New APIs for jar signing Message-ID: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com> I've just push the code change for this enhancement to jdk9/dev: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd http://hg.openjdk.java.net/jdk9/dev/rev/882c782d7d5a In order to work with jake, these changes are needed: diff --git a/src/jdk.jartool/share/classes/module-info.java b/src/jdk.jartool/share/classes/module-info.java --- a/src/jdk.jartool/share/classes/module-info.java +++ b/src/jdk.jartool/share/classes/module-info.java @@ -25,5 +25,6 @@ module jdk.jartool { exports com.sun.jarsigner; + exports jdk.security.jarsigner; } diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java --- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java +++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java @@ -1086,6 +1086,7 @@ try { // attempt to find signer Class signerClass = appClassLoader.loadClass(signerClassName); + JarSigner.class.getModule().addReads(signerClass.getModule()); Object signer = signerClass.newInstance(); return (ContentSigner) signer; } catch (ClassNotFoundException|InstantiationException| Thanks Max From mandy.chung at oracle.com Fri Nov 20 01:46:42 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Nov 2015 17:46:42 -0800 Subject: About 8056174: New APIs for jar signing In-Reply-To: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com> References: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com> Message-ID: <4E5C3DA9-D48B-4A8F-A35A-0FF1CCA1001A@oracle.com> This looks okay. We will push this fix once we pull down your changeset to jake. One question: is ?altsignerpath? and ?altsigner? properties are only for the existing jarsigner -altsigner option to work? Is it the plan to deprecate this -altsigner option? Mandy > On Nov 19, 2015, at 4:40 PM, Wang Weijun wrote: > > I've just push the code change for this enhancement to jdk9/dev: > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd > http://hg.openjdk.java.net/jdk9/dev/rev/882c782d7d5a > > In order to work with jake, these changes are needed: > > diff --git a/src/jdk.jartool/share/classes/module-info.java b/src/jdk.jartool/share/classes/module-info.java > --- a/src/jdk.jartool/share/classes/module-info.java > +++ b/src/jdk.jartool/share/classes/module-info.java > @@ -25,5 +25,6 @@ > > module jdk.jartool { > exports com.sun.jarsigner; > + exports jdk.security.jarsigner; > } > > diff --git a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > --- a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > +++ b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java > @@ -1086,6 +1086,7 @@ > try { > // attempt to find signer > Class signerClass = appClassLoader.loadClass(signerClassName); > + JarSigner.class.getModule().addReads(signerClass.getModule()); > Object signer = signerClass.newInstance(); > return (ContentSigner) signer; > } catch (ClassNotFoundException|InstantiationException| > > Thanks > Max From weijun.wang at oracle.com Fri Nov 20 01:51:40 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Nov 2015 09:51:40 +0800 Subject: About 8056174: New APIs for jar signing In-Reply-To: <4E5C3DA9-D48B-4A8F-A35A-0FF1CCA1001A@oracle.com> References: <252BB8E3-2C3B-453C-B6FA-479DA071B9AD@oracle.com> <4E5C3DA9-D48B-4A8F-A35A-0FF1CCA1001A@oracle.com> Message-ID: > On Nov 20, 2015, at 9:46 AM, Mandy Chung wrote: > > This looks okay. We will push this fix once we pull down your changeset to jake. > > One question: is ?altsignerpath? and ?altsigner? properties are only for the existing jarsigner -altsigner option to work? Yes, because jarsigner the tool now calls JarSigner the API. They are not described in the spec. > Is it the plan to deprecate this -altsigner option? Already deprecated (in the -help output), but not removed yet. Thanks Max > > Mandy From mandy.chung at oracle.com Fri Nov 20 03:00:06 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Nov 2015 19:00:06 -0800 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> Message-ID: <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> I reviewed the top repo change. modules.xml looks fine. jdk.dynalink should be in MAIN_MODULES since it has exported APIs. jdk.scripting.nashorn should be moved too. They are not sole service providers. Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well? Mandy > On Nov 19, 2015, at 3:15 PM, Attila Szegedi wrote: > > Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. > > The changes in this changeset fall into several categories: > - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages > - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it > - new tests > > I?m sending this webrev to several lists with the following rationales: > - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. > - jigsaw-dev because of modules.xml changes > - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) > - core-libs-dev since that?s the designated JEP 276 discussion list. > > Nashorn changes: > top-level jdk9 changes: > > Thanks, > Attila. > From sundararajan.athijegannathan at oracle.com Fri Nov 20 04:53:53 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 20 Nov 2015 05:53:53 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> Message-ID: <564EA761.8080602@oracle.com> +1 on all changes. -Sundar On 11/20/2015 12:15 AM, Attila Szegedi wrote: > Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. > > The changes in this changeset fall into several categories: > - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages > - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it > - new tests > > I?m sending this webrev to several lists with the following rationales: > - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. > - jigsaw-dev because of modules.xml changes > - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) > - core-libs-dev since that?s the designated JEP 276 discussion list. > > Nashorn changes: > top-level jdk9 changes: > > Thanks, > Attila. > From mandy.chung at oracle.com Fri Nov 20 05:10:35 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Nov 2015 21:10:35 -0800 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> Message-ID: jdk.scripting.nashorn is loaded by the extension class loader. Is jdk.dynalink expected to be loaded by the ext. class loader? You need to edit this file to include the new module: jdk/make/src/classes/build/tools/module/ext.modules This is an interim file to map modules to class loader and we will fix it when the changeset propagates to jake. Mandy > On Nov 19, 2015, at 7:00 PM, Mandy Chung wrote: > > I reviewed the top repo change. > > modules.xml looks fine. > > jdk.dynalink should be in MAIN_MODULES since it has exported APIs. jdk.scripting.nashorn should be moved too. They are not sole service providers. Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well? > > Mandy > >> On Nov 19, 2015, at 3:15 PM, Attila Szegedi wrote: >> >> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. >> >> The changes in this changeset fall into several categories: >> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages >> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it >> - new tests >> >> I?m sending this webrev to several lists with the following rationales: >> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. >> - jigsaw-dev because of modules.xml changes >> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) >> - core-libs-dev since that?s the designated JEP 276 discussion list. >> >> Nashorn changes: >> top-level jdk9 changes: >> >> Thanks, >> Attila. >> > From Alan.Bateman at oracle.com Fri Nov 20 15:10:01 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Nov 2015 15:10:01 +0000 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> Message-ID: <564F37C9.4000604@oracle.com> On 19/11/2015 23:15, Attila Szegedi wrote: > Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. > > The changes in this changeset fall into several categories: > - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages > - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it > - new tests > > I?m sending this webrev to several lists Probably build-dev instead of jdk9-dev. I'm curious if it's strictly necessary for module jdk.dynalink to be in the nashorn repo now, I assume not but it's probably convenient when working Nashorn. In any case, the module name and the changes to modules.xml look okay to me. As Mandy noted, this isn't a service provider API so in Images.gmk then you can add it to MAIN_MODULES rather than PROVIDER_MODULES. Your webrevs don't have the changes to the jdk repo but I assume that make/src/classes/build/tools/module/ext.modules has been updated to list jdk.dynalink. That is, I assume it needs to be defined to the ext loader because jdk.scripting.nashorn uses it. The ext.modules file is temporary and goes away when we bring in the module system. -Alan. From szegedia at gmail.com Fri Nov 20 15:41:19 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 20 Nov 2015 16:41:19 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> Message-ID: Thanks for pointing out these, Mandy; I will make the changes you suggested. Attila. > On Nov 20, 2015, at 6:10 AM, Mandy Chung wrote: > > jdk.scripting.nashorn is loaded by the extension class loader. Is jdk.dynalink expected to be loaded by the ext. class loader? > > You need to edit this file to include the new module: > jdk/make/src/classes/build/tools/module/ext.modules > > This is an interim file to map modules to class loader and we will fix it when the changeset propagates to jake. > Mandy > >> On Nov 19, 2015, at 7:00 PM, Mandy Chung wrote: >> >> I reviewed the top repo change. >> >> modules.xml looks fine. >> >> jdk.dynalink should be in MAIN_MODULES since it has exported APIs. jdk.scripting.nashorn should be moved too. They are not sole service providers. Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well? >> >> Mandy >> >>> On Nov 19, 2015, at 3:15 PM, Attila Szegedi wrote: >>> >>> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. >>> >>> The changes in this changeset fall into several categories: >>> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages >>> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it >>> - new tests >>> >>> I?m sending this webrev to several lists with the following rationales: >>> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. >>> - jigsaw-dev because of modules.xml changes >>> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) >>> - core-libs-dev since that?s the designated JEP 276 discussion list. >>> >>> Nashorn changes: >>> top-level jdk9 changes: >>> >>> Thanks, >>> Attila. >>> >> > From szegedia at gmail.com Fri Nov 20 15:42:34 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 20 Nov 2015 16:42:34 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <564F37C9.4000604@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <564F37C9.4000604@oracle.com> Message-ID: <1B8AC6F2-0704-415A-ADDE-978D42CC4AE0@gmail.com> On Nov 20, 2015, at 4:10 PM, Alan Bateman wrote: > > On 19/11/2015 23:15, Attila Szegedi wrote: >> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. >> >> The changes in this changeset fall into several categories: >> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages >> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it >> - new tests >> >> I?m sending this webrev to several lists > Probably build-dev instead of jdk9-dev. > > I'm curious if it's strictly necessary for module jdk.dynalink to be in the nashorn repo now, I assume not but it's probably convenient when working Nashorn. Exactly; it isn?t necessary, but it has been beneficial for now seeing how changes in Dynalink usually had changes in Nashorn to go with them, so having them in a single repo for atomic update is a nice property. I guess someone might eventually give a bit of a thought to the issue of how modularization relates to the JDK forest organization? > In any case, the module name and the changes to modules.xml look okay to me. As Mandy noted, this isn't a service provider API so in Images.gmk then you can add it to MAIN_MODULES rather than PROVIDER_MODULES. Yep, will do that as Mandy suggested. > Your webrevs don't have the changes to the jdk repo but I assume that make/src/classes/build/tools/module/ext.modules has been updated to list jdk.dynalink. Because I haven?t updated the webrevs since Mandy pointed out that this file also has to be changed :-). Will do it soon. > That is, I assume it needs to be defined to the ext loader because jdk.scripting.nashorn uses it. The ext.modules file is temporary and goes away when we bring in the module system. I too believe that having it in ext loader is correct. It will hopefully become moot once the module system is in. Thanks, Attila. > -Alan. From jonathan.gibbons at oracle.com Sat Nov 21 00:52:45 2015 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 21 Nov 2015 00:52:45 +0000 Subject: hg: jigsaw/jake/langtools: read target of symbolic links in JRT file system Message-ID: <201511210052.tAL0qji7003890@aojmv0008.oracle.com> Changeset: 2eea71812f91 Author: jjg Date: 2015-11-20 16:52 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2eea71812f91 read target of symbolic links in JRT file system ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java From sibabrata.sahoo at oracle.com Mon Nov 23 11:26:19 2015 From: sibabrata.sahoo at oracle.com (Siba Sahoo) Date: Mon, 23 Nov 2015 03:26:19 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Message-ID: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Hi, Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ Description Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total of 72 test cases with the following criteria: (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) Thanks, Siba From sibabrata.sahoo at oracle.com Mon Nov 23 13:14:47 2015 From: sibabrata.sahoo at oracle.com (Siba Sahoo) Date: Mon, 23 Nov 2015 05:14:47 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net From: Siba Sahoo Sent: Monday, November 23, 2015 4:56 PM To: jigsaw-dev at openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Hi, Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ Description Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total of 72 test cases with the following criteria: (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) Thanks, Siba From szegedia at gmail.com Mon Nov 23 15:27:06 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 23 Nov 2015 16:27:06 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> Message-ID: <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> Folks, I integrated the changes Mandy suggested; please review these (build related) changes: jdk9 top level: jdk9/jdk: For the sake of completeness, the jdk/nashorn changes are here: but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request. Sundar was kind enough to verify that JDK9 builds fine with these changes. Thanks, Attila. > On Nov 20, 2015, at 4:41 PM, Attila Szegedi wrote: > > Thanks for pointing out these, Mandy; I will make the changes you suggested. > > Attila. > >> On Nov 20, 2015, at 6:10 AM, Mandy Chung wrote: >> >> jdk.scripting.nashorn is loaded by the extension class loader. Is jdk.dynalink expected to be loaded by the ext. class loader? >> >> You need to edit this file to include the new module: >> jdk/make/src/classes/build/tools/module/ext.modules >> >> This is an interim file to map modules to class loader and we will fix it when the changeset propagates to jake. >> Mandy >> >>> On Nov 19, 2015, at 7:00 PM, Mandy Chung wrote: >>> >>> I reviewed the top repo change. >>> >>> modules.xml looks fine. >>> >>> jdk.dynalink should be in MAIN_MODULES since it has exported APIs. jdk.scripting.nashorn should be moved too. They are not sole service providers. Since you are on this file, can you move jdk.scripting.nashorn to MAIN_MODULES as well? >>> >>> Mandy >>> >>>> On Nov 19, 2015, at 3:15 PM, Attila Szegedi wrote: >>>> >>>> Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. >>>> >>>> The changes in this changeset fall into several categories: >>>> - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages >>>> - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it >>>> - new tests >>>> >>>> I?m sending this webrev to several lists with the following rationales: >>>> - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. >>>> - jigsaw-dev because of modules.xml changes >>>> - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) >>>> - core-libs-dev since that?s the designated JEP 276 discussion list. >>>> >>>> Nashorn changes: >>>> top-level jdk9 changes: >>>> >>>> Thanks, >>>> Attila. >>>> >>> >> > From Alan.Bateman at oracle.com Mon Nov 23 15:40:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Nov 2015 15:40:10 +0000 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> Message-ID: <5653335A.3070606@oracle.com> On 23/11/2015 15:27, Attila Szegedi wrote: > Folks, > > I integrated the changes Mandy suggested; please review these (build related) changes: > jdk9 top level: > jdk9/jdk: > > For the sake of completeness, the jdk/nashorn changes are here: but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request. > > Sundar was kind enough to verify that JDK9 builds fine with these changes. > The jdk repo looks okay (just had to change your link to find it :-) In the top-level repo then you've moved jdk.scripting.nashorn from PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in PROVIDER_MODULES is because we treat it as a service provider module (it provides an implementation of javax.script.ScriptEngineFactory). -Alan. From sundararajan.athijegannathan at oracle.com Mon Nov 23 15:42:17 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Nov 2015 21:12:17 +0530 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <5653335A.3070606@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> Message-ID: <565333D9.1080508@oracle.com> But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. -Sundar On 11/23/2015 9:10 PM, Alan Bateman wrote: > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build >> related) changes: >> jdk9 top level: >> >> jdk9/jdk: >> >> >> For the sake of completeness, the jdk/nashorn changes are here: >> but they >> have already been reviewed by Hannes and Sundar; only the above two >> (jdk9 and jdk9/jdk) have been modified compared to the original >> review request. >> >> Sundar was kind enough to verify that JDK9 builds fine with these >> changes. >> > The jdk repo looks okay (just had to change your link to find it :-) > > In the top-level repo then you've moved jdk.scripting.nashorn from > PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in > PROVIDER_MODULES is because we treat it as a service provider module > (it provides an implementation of javax.script.ScriptEngineFactory). > > -Alan. > From sundararajan.athijegannathan at oracle.com Mon Nov 23 15:43:20 2015 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 23 Nov 2015 21:13:20 +0530 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <5653335A.3070606@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> Message-ID: <56533418.1020002@oracle.com> But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. -Sundar On 11/23/2015 9:10 PM, Alan Bateman wrote: > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build >> related) changes: >> jdk9 top level: >> >> jdk9/jdk: >> >> >> For the sake of completeness, the jdk/nashorn changes are here: >> but they >> have already been reviewed by Hannes and Sundar; only the above two >> (jdk9 and jdk9/jdk) have been modified compared to the original >> review request. >> >> Sundar was kind enough to verify that JDK9 builds fine with these >> changes. >> > The jdk repo looks okay (just had to change your link to find it :-) > > In the top-level repo then you've moved jdk.scripting.nashorn from > PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in > PROVIDER_MODULES is because we treat it as a service provider module > (it provides an implementation of javax.script.ScriptEngineFactory). > > -Alan. > From mandy.chung at oracle.com Mon Nov 23 15:45:12 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Nov 2015 07:45:12 -0800 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <5653335A.3070606@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> Message-ID: <4CF6A889-AE24-4520-8884-319EA8EC18A4@oracle.com> > On Nov 23, 2015, at 7:40 AM, Alan Bateman wrote: > > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build related) changes: >> jdk9 top level: >> jdk9/jdk: >> >> For the sake of completeness, the jdk/nashorn changes are here: but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request. >> >> Sundar was kind enough to verify that JDK9 builds fine with these changes. >> > The jdk repo looks okay (just had to change your link to find it :-) > > In the top-level repo then you've moved jdk.scripting.nashorn from PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in PROVIDER_MODULES is because we treat it as a service provider module (it provides an implementation of javax.script.ScriptEngineFactory). jdk.scripting.nashorn now exports two API packages. It is no longer a sole service provider and so I asked Attila to move it MAIN_MODULE. Mandy From Alan.Bateman at oracle.com Mon Nov 23 15:46:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Nov 2015 15:46:49 +0000 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <56533418.1020002@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> <56533418.1020002@oracle.com> Message-ID: <565334E9.7050908@oracle.com> On 23/11/2015 15:43, Sundararajan Athijegannathan wrote: > But, in addition to providing service, jdk.scripting.nashorn module > also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. Sure, it could go in either but we mostly treat it as a service provider. -Alan. From szegedia at gmail.com Mon Nov 23 16:07:03 2015 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 23 Nov 2015 17:07:03 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <5653335A.3070606@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> Message-ID: <46DE1660-A471-4383-92F2-62369975C3D7@gmail.com> > On Nov 23, 2015, at 4:40 PM, Alan Bateman wrote: > > > > On 23/11/2015 15:27, Attila Szegedi wrote: >> Folks, >> >> I integrated the changes Mandy suggested; please review these (build related) changes: >> jdk9 top level: >> jdk9/jdk: >> >> For the sake of completeness, the jdk/nashorn changes are here: but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request. >> >> Sundar was kind enough to verify that JDK9 builds fine with these changes. >> > The jdk repo looks okay (just had to change your link to find it :-) D?oh. I was doublechecking those links few times and still managed to bungle it? thanks for figuring it out. > > In the top-level repo then you've moved jdk.scripting.nashorn from PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in PROVIDER_MODULES is because we treat it as a service provider module (it provides an implementation of javax.script.ScriptEngineFactory). Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively ?provider? seems like a weaker category (exposes a service provider but doesn?t have its own API), so (without knowing the particulars of the use of these *_MODULES variables) it seems to me Mandy?s suggestion is correct to reclassify Nashorn into a MAIN module. Attila. > > -Alan. > From hannes.wallnoefer at oracle.com Mon Nov 23 09:09:23 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 23 Nov 2015 10:09:23 +0100 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> Message-ID: <5652D7C3.5060002@oracle.com> +1 for the Nashorn/Dynalink changes. The top level changes look good to me but I'd prefer to leave reviews to those who are more familiar with the build/modules infrastructure. Hannes Am 2015-11-20 um 00:15 schrieb Attila Szegedi: > Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API that has CCC approval (request 8075866), and is also the implementation step of JEP 276 which is now targeted for 9 and thus can be integrated. > > The changes in this changeset fall into several categories: > - renaming of jdk.internal.dynalink.* package to jdk.dynalink.* package, with ripple effects in Nashorn classes that import from these packages > - changes to modules.xml and some build files to accommodate a new public module and a dependency of Nashorn on it > - new tests > > I?m sending this webrev to several lists with the following rationales: > - nashorn-dev as the primary users and expected reviewers (also, the Dynalink module code lives in jdk9/nashorn/src/jdk.dynalink). A lot of newly added test code was contributed by Sundar. > - jigsaw-dev because of modules.xml changes > - jdk9-dev for build changes (build file changes were graciously contributed by Erik Joelsson and Sundar) > - core-libs-dev since that?s the designated JEP 276 discussion list. > > Nashorn changes: > top-level jdk9 changes: > > Thanks, > Attila. > From Alan.Bateman at oracle.com Mon Nov 23 16:42:59 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Nov 2015 16:42:59 +0000 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <46DE1660-A471-4383-92F2-62369975C3D7@gmail.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> <46DE1660-A471-4383-92F2-62369975C3D7@gmail.com> Message-ID: <56534213.9070506@oracle.com> On 23/11/2015 16:07, Attila Szegedi wrote: > : > Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively ?provider? seems like a weaker category (exposes a service provider but doesn?t have its own API), so (without knowing the particulars of the use of these *_MODULES variables) it seems to me Mandy?s suggestion is correct to reclassify Nashorn into a MAIN module. > We need to do a bit of clean-up in Images.gmk to make things clearer as this MAIN vs. PROVIDER topic has caused confusion on a few cases. If we can keep the lists separate to the list of modules for the compact profile builds then there is no reason why they can't be combined as JRE_MODULES. In this case then jdk.scripting.nashorn.shell is already listed in MAIN_MODULES so this will ensure than Nashorn is linked into any run-time image that has the the jjs tool/shell. It doesn't matter if jdk.scripting.nashorn is listed or not. -Alan. From javalists at cbfiddle.com Mon Nov 23 17:58:12 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 23 Nov 2015 09:58:12 -0800 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> <564C518C.3050807@oracle.com> <564C5C23.3050107@oracle.com> Message-ID: <9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com> > There are rather a lot of libraries out there that access private > members via reflection. I posit that almost all such libraries break > without an easy way to fix the problem, if there is no way to use > reflection to access non-exported members. I agree with Reinier that there are situations where it makes sense to bypass module encapsulation and the existing access rules. Encapsulation is a good thing, but unless it is needed for security, Java should not be totally rigid about it. My use case is a platform specific Swing look and feel. To work, it needs access to platform specific features of the AWT. I?m trying not to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK will be motivated to create a public API for all of the platform specific features that I need, or if they do, that the API will be available in a timely manner. I understand that my library will have dependencies on specific JDK versions as it does on specific platform versions. I was unpleasantly surprised to learn (via the recent Java One talks) that the module encapsulation rules apply to reflection, as I had understood that they did not. Using command line arguments as an escape mechanism is not a good fit for this use. The main reason is that it places a burden on all users of the library, both direct and indirect. Every application in which this library is used must define the appropriate command line arguments. The other reason is that the command line argument solution is too broad. Using reflection, each specific need to penetrate encapsulation is identified. Using the command line argument, entire packages are opened up. Which brings me to a question... How is native code access to classes and methods via JNI affected by module encapsulation? Alan From mandy.chung at oracle.com Mon Nov 23 19:54:58 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Nov 2015 11:54:58 -0800 Subject: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink In-Reply-To: <56534213.9070506@oracle.com> References: <893527C1-D5F5-4A40-8400-D21DA824F72C@gmail.com> <19FE07FE-E742-4038-A604-789D114842FF@oracle.com> <108EDD96-1F91-4C06-8BA5-F9FE13493CAF@gmail.com> <5653335A.3070606@oracle.com> <46DE1660-A471-4383-92F2-62369975C3D7@gmail.com> <56534213.9070506@oracle.com> Message-ID: <0865324C-A221-493B-BC7A-2109380F66DC@oracle.com> > On Nov 23, 2015, at 8:42 AM, Alan Bateman wrote: > > We need to do a bit of clean-up in Images.gmk to make things clearer as this MAIN vs. PROVIDER topic has caused confusion on a few cases. If we can keep the lists separate to the list of modules for the compact profile builds then there is no reason why they can't be combined as JRE_MODULES. Agree and we should clean that up to remove the confusion. Mandy From mandy.chung at oracle.com Mon Nov 23 22:38:10 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 Nov 2015 14:38:10 -0800 Subject: RFR: 8139430 In-Reply-To: <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com> References: <8DA47C0A-87D3-4BAD-8504-E83E7F5026E4@oracle.com> <564256C7.60905@oracle.com> <14D01FF5-E613-48A4-901F-6E3D65174175@oracle.com> <5649DC71.60106@oracle.com> <083D7050-8850-4D0E-B97B-7523857ABECC@oracle.com> Message-ID: Hi Shura, I have pushed the changeset to jdk9/dev. Mandy > On Nov 19, 2015, at 8:40 AM, Alexandre (Shura) Iline wrote: > > Yes, sorry. > > Since the methods do not have any work to complete before interrupting and also methods are not used anywhere currently, I assume re-throwing the InterruptedException is a better choice. > > http://cr.openjdk.java.net/~shurailine/8139430/webrev.07/test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java.html > > Shura > >> On Nov 16, 2015, at 8:33 PM, Mandy Chung wrote: >> >> >>> On Nov 16, 2015, at 5:38 AM, Alan Bateman wrote: >>> >>> >>> >>> On 16/11/2015 13:01, Alexandre (Shura) Iline wrote: >>>> V6: >>>> http://cr.openjdk.java.net/~shurailine/8139430/webrev.06/ >>>> >>>> >>> This looks okay to me. For completeness then I assume the THreadMXBeanTool.waitUntilXXX methods should re-assert the interrupt status if interrupted when waiting. >> >> +1 >> >> Mandy >> > From alex.buckley at oracle.com Tue Nov 24 00:24:34 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 23 Nov 2015 16:24:34 -0800 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com> References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> <564C518C.3050807@oracle.com> <564C5C23.3050107@oracle.com> <9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com> Message-ID: <5653AE42.4030809@oracle.com> On 11/23/2015 9:58 AM, Alan Snyder wrote: > My use case is a platform specific Swing look and feel. To work, it > needs access to platform specific features of the AWT. I?m trying not > to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK > will be motivated to create a public API for all of the platform > specific features that I need, or if they do, that the API will be > available in a timely manner. I understand that my library will have > dependencies on specific JDK versions as it does on specific platform > versions. I know there is considerable effort going into replacement public APIs for JavaFX -- see http://openjdk.java.net/jeps/253 from May and the openjfx-dev thread "Understanding the com.sun.* APIs being (ab)used by the community" from June -- you could inquire about equivalents on swing-dev. Alex > I was unpleasantly surprised to learn (via the recent Java One talks) > that the module encapsulation rules apply to reflection, as I had > understood that they did not. > > Using command line arguments as an escape mechanism is not a good fit > for this use. The main reason is that it places a burden on all users > of the library, both direct and indirect. Every application in which > this library is used must define the appropriate command line > arguments. The other reason is that the command line argument > solution is too broad. Using reflection, each specific need to > penetrate encapsulation is identified. Using the command line > argument, entire packages are opened up. > > Which brings me to a question... How is native code access to classes > and methods via JNI affected by module encapsulation? > > Alan > From sergei.pikalev at oracle.com Tue Nov 24 00:37:26 2015 From: sergei.pikalev at oracle.com (Sergei Pikalev) Date: Tue, 24 Nov 2015 03:37:26 +0300 Subject: RFR 8135972: Implement new tests for native libjimage library In-Reply-To: <5645EFBE.1060903@oracle.com> References: <5645EA93.5040102@oracle.com> <5645EFBE.1060903@oracle.com> Message-ID: <5653B146.9030408@oracle.com> Hi All, http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html There are a minimal set of passing cleanly tests which does not explore bad values touching memory addresses. Please review. Thanks, Sergi On 13.11.2015 17:12, Alan Bateman wrote: > On 13/11/2015 13:50, Sergei Pikalev wrote: >> >> Hello, >> >> This is the code with new tests for libjimage native library. >> >> A webrev with the tests is here: >> >> http://cr.openjdk.java.net/~jlaskey/8135972/webrev.00/index.html > > Are there tests passing cleanly on all platforms? At least some of > them seems to be passing bad values to native methods that take memory > addresses. > > Are the tests tied to changes in jigsaw/jake or can these tests go > into jdk9/dev to follow the jimage changes that are also going in via > that route? > > -Alan From javalists at cbfiddle.com Tue Nov 24 00:50:04 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 23 Nov 2015 16:50:04 -0800 Subject: A way to opt out of access restrictions on non-exported members. In-Reply-To: <5653AE42.4030809@oracle.com> References: <564A081E.3010809@oracle.com> <564C4230.1070802@oracle.com> <564C518C.3050807@oracle.com> <564C5C23.3050107@oracle.com> <9A22B32F-0036-4EF1-91C2-B8FCF4B0CFA4@cbfiddle.com> <5653AE42.4030809@oracle.com> Message-ID: <1681644E-F46C-4050-87C3-0106A595B9CF@cbfiddle.com> > On Nov 23, 2015, at 4:24 PM, Alex Buckley wrote: > > I know there is considerable effort going into replacement public APIs for JavaFX -- see http://openjdk.java.net/jeps/253 from May and the openjfx-dev thread "Understanding the com.sun.* APIs being (ab)used by the community" from June -- you could inquire about equivalents on swing-dev. Yes, I have already proposed some and some are under development. I have not proposed low level ones yet. Alan From mandy.chung at oracle.com Tue Nov 24 03:22:32 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 24 Nov 2015 03:22:32 +0000 Subject: hg: jigsaw/jake/jdk: Throw IAE if the proxy module can't access interface Message-ID: <201511240322.tAO3MWYd019011@aojmv0008.oracle.com> Changeset: 89fb05b6e864 Author: mchung Date: 2015-11-23 19:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89fb05b6e864 Throw IAE if the proxy module can't access interface ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyModuleMapping.java + test/jdk/jigsaw/reflect/Proxy/q/NP.java From mandy.chung at oracle.com Tue Nov 24 06:02:40 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 24 Nov 2015 06:02:40 +0000 Subject: hg: jigsaw/jake/langtools: Fix langtools/tools/jdeps/APIDeps.java to reference internal type Message-ID: <201511240602.tAO62esK019732@aojmv0008.oracle.com> Changeset: f7876cd903aa Author: mchung Date: 2015-11-23 22:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f7876cd903aa Fix langtools/tools/jdeps/APIDeps.java to reference internal type ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/VerboseFormat/JdepsDependencyClosure.java ! test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass.java ! test/tools/jdeps/VerboseFormat/use/internal/UseJdkInternalClass2.java ! test/tools/jdeps/f/F.java From Alan.Bateman at oracle.com Tue Nov 24 08:29:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Nov 2015 08:29:50 +0000 Subject: RFR 8135972: Implement new tests for native libjimage library In-Reply-To: <5653B146.9030408@oracle.com> References: <5645EA93.5040102@oracle.com> <5645EFBE.1060903@oracle.com> <5653B146.9030408@oracle.com> Message-ID: <56541FFE.7020707@oracle.com> On 24/11/2015 00:37, Sergei Pikalev wrote: > > Hi All, > > http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html > > There are a minimal set of passing cleanly tests which does not explore > bad values touching memory addresses. > > Please review. I assume Jim or Jean-Francois will sponsor this for you. Is JImagePackageToModuleTest the only test that is unique to jake? I'm just wondering if we can get these tests into via jdk9/dev. One thing that isn't clear to me is the multipleOpenTest, I would have expected a second call to JIMAGE_Open to return a unique handle. A small comment on JImageOpenCloseTest - I assume this should create the 0-length or bad-magic jimage file rather than checking in binary files. -Alan From erik.joelsson at oracle.com Tue Nov 24 10:04:00 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 24 Nov 2015 10:04:00 +0000 Subject: hg: jigsaw/jake: Fixed images target to properly also build the exploded-image target Message-ID: <201511241004.tAOA416u017813@aojmv0008.oracle.com> Changeset: d18e85f68fe3 Author: erikj Date: 2015-11-24 11:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d18e85f68fe3 Fixed images target to properly also build the exploded-image target ! common/autoconf/generated-configure.sh ! make/Main.gmk From erik.joelsson at oracle.com Tue Nov 24 13:02:39 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 24 Nov 2015 13:02:39 +0000 Subject: hg: jigsaw/jake: More build unification with jdk9 Message-ID: <201511241302.tAOD2dZ3014512@aojmv0008.oracle.com> Changeset: 5165085d2c54 Author: erikj Date: 2015-11-24 14:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5165085d2c54 More build unification with jdk9 ! make/CompileJavaModules.gmk From erik.joelsson at oracle.com Tue Nov 24 13:03:44 2015 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 24 Nov 2015 13:03:44 +0000 Subject: hg: jigsaw/jake/jdk: More build unification with jdk9 Message-ID: <201511241303.tAOD3iuR014957@aojmv0008.oracle.com> Changeset: 33d87582d833 Author: erikj Date: 2015-11-24 14:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/33d87582d833 More build unification with jdk9 ! make/launcher/Launcher-jdk.jcmd.gmk ! make/launcher/LauncherCommon.gmk From lois.foltan at oracle.com Tue Nov 24 14:21:55 2015 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Tue, 24 Nov 2015 14:21:55 +0000 Subject: hg: jigsaw/jake/hotspot: JVM changes to record the j.l.r.Module for unnamed modules Message-ID: <201511241421.tAOELtfJ012414@aojmv0008.oracle.com> Changeset: f4f2580e950a Author: lfoltan Date: 2015-11-24 09:00 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f4f2580e950a JVM changes to record the j.l.r.Module for unnamed modules ! make/aix/makefiles/mapfile-vers-debug ! make/aix/makefiles/mapfile-vers-product ! make/bsd/makefiles/mapfile-vers-darwin-debug ! make/bsd/makefiles/mapfile-vers-darwin-product ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/share/makefiles/mapfile-vers ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/modules.hpp ! src/share/vm/classfile/packageEntry.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/globals.hpp ! test/runtime/modules/JVMDefineModule.java From lois.foltan at oracle.com Tue Nov 24 14:23:37 2015 From: lois.foltan at oracle.com (lois.foltan at oracle.com) Date: Tue, 24 Nov 2015 14:23:37 +0000 Subject: hg: jigsaw/jake/jdk: Changes to communicate the j.l.r.Module for the boot loader's unnamed module to the JVM Message-ID: <201511241423.tAOENbe9012739@aojmv0008.oracle.com> Changeset: fa97a65164bc Author: lfoltan Date: 2015-11-24 09:02 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa97a65164bc Changes to communicate the j.l.r.Module for the boot loader's unnamed module to the JVM ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/jdk/internal/misc/BootLoader.java ! src/java.base/share/native/include/jvm.h ! src/java.base/share/native/libjava/BootLoader.c ! src/java.base/share/native/libjava/Module.c From sundararajan.athijegannathan at oracle.com Tue Nov 24 14:46:18 2015 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 24 Nov 2015 14:46:18 +0000 Subject: hg: jigsaw/jake/jdk: 8142959: Remove dependency on sun.boot.class.path property Message-ID: <201511241446.tAOEkIBt017931@aojmv0008.oracle.com> Changeset: 5098cced084a Author: sundar Date: 2015-11-24 20:14 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5098cced084a 8142959: Remove dependency on sun.boot.class.path property Reviewed-by: alanb ! src/jdk.rmic/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/jdk.rmic/share/classes/sun/tools/java/ClassPath.java From mik3hall at gmail.com Wed Nov 25 00:11:57 2015 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 24 Nov 2015 18:11:57 -0600 Subject: OS X application won't launch with jigsaw Message-ID: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> Up to now I have been able to take java 9 builds and paste the appropriate contents into a OS X javapackager produced application and have it run with the embedded jdk. I just got a jigsaw build instead of the main 9 forest and it does not launch. I get? 11/24/15 5:54:16.326 PM com.apple.xpc.launchd[1]: (us.hall.hp.common.86368[4137]) Service exited with abnormal code: 1 What is different, and not quite so good, with the jake build? Previously I noticed the lib/modules directory contained individual modules like java.base. I notice the jake build now has only bootmodules.jimage. I assume this is the current correct container for all modules? This sort of rhetorical, if true. I watched some of the java9 videos off of the provided links. It was mentioned that the modules no longer use jar/zip. A more efficient way to package the modules has been developed. Is this file format available for use outside the jdk? Are there any tools that work with jimage now or in the works? Michael Hall From mandy.chung at oracle.com Wed Nov 25 00:58:50 2015 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 25 Nov 2015 00:58:50 +0000 Subject: hg: jigsaw/jake/jdk: 8139430: Refactor test library to decrease module dependencies of tests Message-ID: <201511250058.tAP0wo2s000607@aojmv0008.oracle.com> Changeset: 45cb94eef0ec Author: shurailine Date: 2015-11-23 11:49 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/45cb94eef0ec 8139430: Refactor test library to decrease module dependencies of tests Reviewed-by: mchung, alanb ! test/java/util/logging/TestLoggerWeakRefLeak.java - test/lib/testlibrary/jdk/testlibrary/InputArguments.java ! test/lib/testlibrary/jdk/testlibrary/JcmdBase.java ! test/lib/testlibrary/jdk/testlibrary/ProcessTools.java ! test/lib/testlibrary/jdk/testlibrary/TestThread.java + test/lib/testlibrary/jdk/testlibrary/management/InputArguments.java + test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java ! test/sun/tools/jcmd/TestJcmdSanity.java ! test/sun/tools/jinfo/JInfoHelper.java ! test/sun/tools/jmap/BasicJMapTest.java ! test/sun/tools/jps/JpsBase.java ! test/sun/tools/jstack/BasicJStackTest.java From mik3hall at gmail.com Wed Nov 25 00:59:26 2015 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 24 Nov 2015 18:59:26 -0600 Subject: OS X application won't launch with jigsaw In-Reply-To: References: Message-ID: > On Nov 24, 2015, at 6:11 PM, Michael Hall wrote: > > Up to now I have been able to take java 9 builds and paste the appropriate contents into a OS X javapackager produced application and have it run with the embedded jdk. Sorry, to reply to my own. But I notice the install layout is somewhat different. There is now a MacOS directory along with the Home directory with what looks like a symbolic link to libjli.dylib. (I tried copying that into my app framework, still no go). Would the javafx list be a more appropriate place to ask about this? Is javapackager supposed to currently be working or would that be pending jigsaw becoming more stable? Michael Hall From mik3hall at gmail.com Wed Nov 25 01:52:11 2015 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 24 Nov 2015 19:52:11 -0600 Subject: Apple internal api's Message-ID: I know these are being addressed as part of JEP 272 [1], but for now. I have a shell script that will launch my OS X app with most of it?s functionality. I think some appleevent related won?t work as less than a full app, but the app should run. It is completely unmodularized at this point though. I get? ./halfpipe9.sh Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eawt.Application (in module: java.desktop), com.apple.eawt is not exported to Unnamed Module I found documentation for the addExports ?get out of jail free? option at JEP 261. I tried... java -XaddExports:us.hall.osx/com.apple.eawt=ALL-UNNAMED getting? /halfpipe9.sh Error occurred during initialization of VM java.lang.RuntimeException: Unknown source module: us.hall.osx.OSXApplication This is not in a module yet. addExports is not available? [1] http://openjdk.java.net/jeps/272 [2] http://openjdk.java.net/jeps/261 Michael Hall From mandy.chung at oracle.com Wed Nov 25 03:18:32 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 24 Nov 2015 19:18:32 -0800 Subject: Apple internal api's In-Reply-To: References: Message-ID: <2A18D261-FB25-4AC4-85E5-ADE899E1819E@oracle.com> com.apple.eawt is in java.desktop module. Try this: java -XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED Mandy > On Nov 24, 2015, at 5:52 PM, Michael Hall wrote: > > I know these are being addressed as part of JEP 272 [1], but for now. > I have a shell script that will launch my OS X app with most of it?s functionality. I think some appleevent related won?t work as less than a full app, but the app should run. It is completely unmodularized at this point though. > I get? > ./halfpipe9.sh > Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eawt.Application (in module: java.desktop), com.apple.eawt is not exported to Unnamed Module > > I found documentation for the addExports ?get out of jail free? option at JEP 261. > I tried... > java -XaddExports:us.hall.osx/com.apple.eawt=ALL-UNNAMED > > getting? > /halfpipe9.sh > Error occurred during initialization of VM > java.lang.RuntimeException: Unknown source module: us.hall.osx.OSXApplication > > This is not in a module yet. addExports is not available? > > [1] http://openjdk.java.net/jeps/272 > [2] http://openjdk.java.net/jeps/261 > > Michael Hall > > > > From sundararajan.athijegannathan at oracle.com Wed Nov 25 04:52:25 2015 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 25 Nov 2015 04:52:25 +0000 Subject: hg: jigsaw/jake/nashorn: 8139106: ant build/test fails with jigsaw/jake/nashorn Message-ID: <201511250452.tAP4qPwT020288@aojmv0008.oracle.com> Changeset: e2e713228703 Author: sundar Date: 2015-11-25 10:21 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/e2e713228703 8139106: ant build/test fails with jigsaw/jake/nashorn ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java From sergei.pikalev at oracle.com Wed Nov 25 05:02:30 2015 From: sergei.pikalev at oracle.com (Sergei Pikalev) Date: Wed, 25 Nov 2015 08:02:30 +0300 Subject: RFR 8135972: Implement new tests for native libjimage library In-Reply-To: <56541FFE.7020707@oracle.com> References: <5645EA93.5040102@oracle.com> <5645EFBE.1060903@oracle.com> <5653B146.9030408@oracle.com> <56541FFE.7020707@oracle.com> Message-ID: <565540E6.4060808@oracle.com> Hi Alan, I've attached the diff with minor changes: * multipleOpenTest - check on second call of JIMAGE_Open * removed corrupted data files from patch and create them in @BeforeTest block Should I create new webrev or could I contact Jim or Jean-Francois directly? Answers on your question: Yes, the tests could be used in jdk9/dev as well with minor tuning. Thanks, Sergi On 24.11.2015 11:29, Alan Bateman wrote: > On 24/11/2015 00:37, Sergei Pikalev wrote: >> >> Hi All, >> >> http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html >> >> There are a minimal set of passing cleanly tests which does not explore >> bad values touching memory addresses. >> >> Please review. > I assume Jim or Jean-Francois will sponsor this for you. Is > JImagePackageToModuleTest the only test that is unique to jake? I'm > just wondering if we can get these tests into via jdk9/dev. > > One thing that isn't clear to me is the multipleOpenTest, I would have > expected a second call to JIMAGE_Open to return a unique handle. > > A small comment on JImageOpenCloseTest - I assume this should create > the 0-length or bad-magic jimage file rather than checking in binary > files. > > -Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: libjimage_min_tests.diff Type: text/x-patch Size: 22179 bytes Desc: not available URL: From Alan.Bateman at oracle.com Wed Nov 25 08:27:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Nov 2015 08:27:05 +0000 Subject: OS X application won't launch with jigsaw In-Reply-To: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> Message-ID: <565570D9.4070302@oracle.com> On 25/11/2015 00:11, Michael Hall wrote: > Up to now I have been able to take java 9 builds and paste the appropriate contents into a OS X javapackager produced application and have it run with the embedded jdk. > I just got a jigsaw build instead of the main 9 forest and it does not launch. > I get? > 11/24/15 5:54:16.326 PM com.apple.xpc.launchd[1]: (us.hall.hp.common.86368[4137]) Service exited with abnormal code: 1 > What is different, and not quite so good, with the jake build? > > Previously I noticed the lib/modules directory contained individual modules like java.base. I notice the jake build now has only bootmodules.jimage. > I assume this is the current correct container for all modules? This sort of rhetorical, if true. Yes, this is the container file. If you previously saw a directory named modules/java.base then I assume you must have been looking at an exploded build rather than an images build. I think we touched on this in your other thread where you used the build /jdk tree rather than /images/jdk. > > I watched some of the java9 videos off of the provided links. It was mentioned that the modules no longer use jar/zip. A more efficient way to package the modules has been developed. Is this file format available for use outside the jdk? Are there any tools that work with jimage now or in the works? > The jimage file that you see in the JDK image is internal to the run-time image. The format is not meant to be documented as it is likely to change frequently. Application and library modules can be packaged as modular JAR files, these are just regular JAR files but with a compiled module declaration (module-info.class) in the top-level directory of the JAR file. The jar tool is updated in the jake builds to support modular JARs. -Alan From mik3hall at gmail.com Wed Nov 25 09:17:27 2015 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Nov 2015 03:17:27 -0600 Subject: OS X application won't launch with jigsaw In-Reply-To: <565570D9.4070302@oracle.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> Message-ID: <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> > On Nov 25, 2015, at 2:27 AM, Alan Bateman wrote: > > I think we touched on this in your other thread where you used the build /jdk tree rather than /images/jdk. Sorry, you are correct on this. Once I had correctly built the images version the modules are no longer individual/exploded. I notice there are three images when built from source? appmodules.jimage bootmodules.jimage extmodules.jimage For the jake ea version I downloaded from the URL provided at the talks there is only bootmodules.jimage if that matters. Copying the other two images into the embedded application jdk still does not seem to launch. Although even command line showed that it should get the internals error. It might be the same problem for the app and I?m just not seeing the more meaningful error messages. Is there any way around the internals for a non-modularized application? A fair percentage of OS X applications might have these particular ?internals?. There is JEP 272 so if I just wait, and change some code, that should go away. But in general, if you have other applications looking to migrate to 9 that have any of these who want to start out by just getting their application up and running they are not going to work. They will be forced to either eliminate the internal use or go modular from the start? Then the addExports will work. If I?m understanding that error message correctly. Michael Hall From karlsanders75 at gmail.com Wed Nov 25 11:59:32 2015 From: karlsanders75 at gmail.com (Karl Sanders) Date: Wed, 25 Nov 2015 12:59:32 +0100 Subject: Current plans for a new Java access modifier Message-ID: Hi, after a quick search in the Jigsaw docs and mailing list archives I came to the conclusion that there won't be a new Java access modifier between public and Package-Access, to allow visibility and access from other packages but only if inside the same module. Is this correct? Regards, Karl From Alan.Bateman at oracle.com Wed Nov 25 15:56:52 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 Nov 2015 15:56:52 +0000 Subject: OS X application won't launch with jigsaw In-Reply-To: <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> Message-ID: <5655DA44.1050206@oracle.com> On 25/11/2015 09:17, Michael Hall wrote: > I notice there are three images when built from source? > appmodules.jimage > bootmodules.jimage > extmodules.jimage > > For the jake ea version I downloaded from the URL provided at the talks there is only bootmodules.jimage if that matters. > > Copying the other two images into the embedded application jdk still does not seem to launch. Although even command line showed that it should get the internals error. > It might be the same problem for the app and I?m just not seeing the more meaningful error messages. There are a lot of changes in the jake forest, one of which is storing the classes/resources for all modules in one jimage container. This should transparent to you, there is no need to every look in the lib/** tree. In particular, it will break things really badly if you copy or move jimage files between builds. > > Is there any way around the internals for a non-modularized application? A fair percentage of OS X applications might have these particular ?internals?. There is JEP 272 so if I just wait, and change some code, that should go away. > > But in general, if you have other applications looking to migrate to 9 that have any of these who want to start out by just getting their application up and running they are not going to work. They will be forced to either eliminate the internal use or go modular from the start? Then the addExports will work. If I?m understanding that error message correctly. > If you feel strongly that the com.apple.eawt APIs should be exported in JDK 9 then you need to read JEP 260 [1] and make a case for adding the Apple APIs to the list. -Alan. [1] http://openjdk.java.net/jeps/260 From kevin.rushforth at oracle.com Wed Nov 25 16:13:07 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Nov 2015 08:13:07 -0800 Subject: OS X application won't launch with jigsaw In-Reply-To: <5655DA44.1050206@oracle.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> <5655DA44.1050206@oracle.com> Message-ID: <5655DE13.2070102@oracle.com> The com.apple.eawt APIs are already being replaced by public API as part of JEP 272 (which Michael already noted). I think he's just wondering what to do in the mean time; "-XaddExports" should do the trick. -- Kevin Alan Bateman wrote: > > On 25/11/2015 09:17, Michael Hall wrote: >> I notice there are three images when built from source? >> appmodules.jimage >> bootmodules.jimage >> extmodules.jimage >> >> For the jake ea version I downloaded from the URL provided at the >> talks there is only bootmodules.jimage if that matters. >> >> Copying the other two images into the embedded application jdk still >> does not seem to launch. Although even command line showed that it >> should get the internals error. >> It might be the same problem for the app and I?m just not seeing the >> more meaningful error messages. > There are a lot of changes in the jake forest, one of which is storing > the classes/resources for all modules in one jimage container. This > should transparent to you, there is no need to every look in the > lib/** tree. In particular, it will break things really badly if you > copy or move jimage files between builds. > >> >> Is there any way around the internals for a non-modularized >> application? A fair percentage of OS X applications might have these >> particular ?internals?. There is JEP 272 so if I just wait, and >> change some code, that should go away. >> >> But in general, if you have other applications looking to migrate to >> 9 that have any of these who want to start out by just getting their >> application up and running they are not going to work. They will be >> forced to either eliminate the internal use or go modular from the >> start? Then the addExports will work. If I?m understanding that error >> message correctly. >> > If you feel strongly that the com.apple.eawt APIs should be exported > in JDK 9 then you need to read JEP 260 [1] and make a case for adding > the Apple APIs to the list. > > -Alan. > > [1] http://openjdk.java.net/jeps/260 From danno.ferrin at oracle.com Wed Nov 25 16:45:07 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 25 Nov 2015 09:45:07 -0700 Subject: OS X application won't launch with jigsaw In-Reply-To: <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> Message-ID: <13108C67-EF00-4B7E-86C4-97791489A425@oracle.com> JEP275 [1] is updating the javapackager to use and create modular runtimes. I have just posted a webrev with the last features to the openjfx list. A prior version is in the sandbox-9-jake repo [2] and the webrev will go there. Except for needing to specify where your jmods are stored, the API and CLI should be 100% compatible with the Java 8 version. And if it's not, post a bug, we should fix any incompatibilities that are not necessary for Jake integration. And if they are necessary we should be able to defend the decision in the bug post. However, we fully expect that the Java 8 packager will not be able to make bundles holding a Java 9 runtime, and I think this is what you are encountering. [1] http://openjdk.java.net/jeps/275 [2] http://hg.openjdk.java.net/openjfx/sandbox-9-jake/rt > On Nov 25, 2015, at 2:17 AM, Michael Hall wrote: > >> On Nov 25, 2015, at 2:27 AM, Alan Bateman wrote: >> >> I think we touched on this in your other thread where you used the build /jdk tree rather than /images/jdk. > > Sorry, you are correct on this. Once I had correctly built the images version the modules are no longer individual/exploded. > I notice there are three images when built from source? > appmodules.jimage > bootmodules.jimage > extmodules.jimage > > For the jake ea version I downloaded from the URL provided at the talks there is only bootmodules.jimage if that matters. > > Copying the other two images into the embedded application jdk still does not seem to launch. Although even command line showed that it should get the internals error. > It might be the same problem for the app and I?m just not seeing the more meaningful error messages. > > Is there any way around the internals for a non-modularized application? A fair percentage of OS X applications might have these particular ?internals?. There is JEP 272 so if I just wait, and change some code, that should go away. > > But in general, if you have other applications looking to migrate to 9 that have any of these who want to start out by just getting their application up and running they are not going to work. They will be forced to either eliminate the internal use or go modular from the start? Then the addExports will work. If I?m understanding that error message correctly. > > Michael Hall > > > > > From alex.buckley at oracle.com Wed Nov 25 18:58:06 2015 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 25 Nov 2015 10:58:06 -0800 Subject: Current plans for a new Java access modifier In-Reply-To: References: Message-ID: <565604BE.5080104@oracle.com> There is no new modifier for class/field/method declarations, but the effect of 'exports' in a module declaration is to limit the accessibility of 'public' class/field/method declarations. You also mentioned visibility, but that's a separate topic related to class loaders. Suggest you watch my "Project Jigsaw: Under the Hood" video linked from the Jigsaw project page. Alex On 11/25/2015 3:59 AM, Karl Sanders wrote: > Hi, > > after a quick search in the Jigsaw docs and mailing list archives I > came to the conclusion that there won't be a new Java access modifier > between public and Package-Access, to allow visibility and access from > other packages but only if inside the same module. > Is this correct? > > Regards, > Karl > From mik3hall at gmail.com Wed Nov 25 22:54:04 2015 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Nov 2015 16:54:04 -0600 Subject: OS X application won't launch with jigsaw In-Reply-To: <13108C67-EF00-4B7E-86C4-97791489A425@oracle.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> <13108C67-EF00-4B7E-86C4-97791489A425@oracle.com> Message-ID: Michael Hall > On Nov 25, 2015, at 10:45 AM, Danno Ferrin wrote: > > However, we fully expect that the Java 8 packager will not be able to make bundles holding a Java 9 runtime, and I think this is what you are encountering. > What I had done was use javapackager to generate an application bundle for 7 or 8. Not sure which anymore, I?ve been reusing the same one for a while. Then I take the output of jdk 9 builds and paste it into the plugins directory of that same application. This has been working fine until I tried a jigsaw specific ea. Now the application doesn?t launch. The launch errors output a single message to the console log that the application failed to launch. I have a shell script that launches the application that way. This fails indicating it is trying to access the apple legacy api?s. Which it should. Access them that is, not should fail. It does fail because these classes have been classified ?internal? and are inaccessible with the current jake builds. _________ Exception in thread "main" java.lang.IllegalAccessError: class us.hall.osx.OSXApplication (in module: Unnamed Module) cannot access class com.apple.eawt.Application (in module: java.desktop), com.apple.eawt is not exported to Unnamed Module ___________ My understanding is that JEP 272 out of the awt group is addressing these classes. Converting them to a Desktop api that will be supported going forward. It will I?m assuming require changes on the part of any current OS X applications using the apple api?s to instead use the new Desktop api?s. I am ok with this. As long as I know about it and the changes aren?t massive. However, for any OS X developers not actively following the java 9 project this may become a problem in migration. javapackager, or whatever tool the developers use to create their application bundles could work fine but due to use of these api?s their applications won?t launch. I?m sort of guessing javapackager might be the only tool at that point that will create valid application bundles. That or my way, guessing how a pasted in embedded jdk should work and just manually copying it in. As long as the changes don?t develop any other complications before the project completes so that by itself doesn?t work. Anyhow I don?t believe the issues are javapackager, they are making formerly public apple ?extra? api?s now ?internal? ones whose use causes the application to fail. From michael.rasmussen at zeroturnaround.com Wed Nov 25 22:56:20 2015 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 26 Nov 2015 00:56:20 +0200 Subject: Instrumentation best practices question, and more Message-ID: Hi Having recently started looking into the JDK9-jigsaw builds, and the numerous changes that it entails, to see what impact it has on our software, I have some initial questions that I haven't been able to find the answers to so far. 1) There have been some discussions on this mailing list already regarding escaping the encaptulation of the modules, but I haven't found anything regarding what the best/recommended practice is for something like profilers, trace advices, etc or anything else that instruments classes throughout the system, inserting calls to methods to perform various tasks. In JDK8, adding this using a javaagent, my classes were on the boot classpath, thus accessible to the entire system. But this is no longer the case in jigsaw -- so how am I supposed to do this in a module-aware system? Am I just supposed to hack into the module system, to add edges from every single module in the system to my agent? While that is doable, it doesn't sounds very nice, requiring poking a lot of holes using reflection to bypass the "in-same-module" checks etc. These kind of instrumentations are not that uncommon in the Java ecosystem, so I assume there must have been some considerations how this should be accompliced? Or is there no recommended way for doing this? 2) Why the backwards-incompatible change to getResourceAsStream family of methods? Sure, the methods are binary compatible, but behave very differently than previously! Object.class.getResourceAsStream("Object.class") now returns null, apparently just for the sake of it, as the InputStream can easily be obtained from the Module, without any in-same-module checks, via: Object.class.getModule().getResourceAsStream("java/lang/Object.class") But, accessing this through the Module requires the code to be compiled against JDK9, having to keep multiple different codepaths in the code depending on which JDK version I'm loading the resources on! 3) Why was the implementation of java.lang.Package changed, so it no longer returns the content of the Manifest file? Previously, doing MyClass.class.getPackage().getImplementationTitle() would return the "Implementation-Title" entry from the manifest file, but now it returns null instead. The documentation in JDK8 even mentions that this information is typically stored in the manifest, where as the JDK9 now states that these values are unspecified. Best regards Michael Rasmussen ZeroTurnaround From mik3hall at gmail.com Wed Nov 25 23:06:53 2015 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 25 Nov 2015 17:06:53 -0600 Subject: OS X application won't launch with jigsaw In-Reply-To: <5655DA44.1050206@oracle.com> References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> <5655DA44.1050206@oracle.com> Message-ID: > On Nov 25, 2015, at 9:56 AM, Alan Bateman wrote: > > If you feel strongly that the com.apple.eawt APIs should be exported in JDK 9 then you need to read JEP 260 [1] and make a case for adding the Apple APIs to the list. I understand that knowing what impact a change will have is difficult to determine. I don?t think I could argue reversing that change solely on the basis of my own application. I can?t say how many applications it will affect. Probably most that have attempted to do any OS X customization. I myself am OK with these becoming supported going forward as part of the awt Desktop api?s. The question would be how many developers aren?t going to even be aware this has been done? I don?t have any estimate for that. My questions mostly concerned my own application. I was trying to figure out if I could get addExports to work without any other changes to my current application. Not modularizing. My use of addExports may of been incorrect for this use case. Unmodularized application using ?internal? api?s and trying to addExports around it. Does this work? What would be an example of the addExports for this situation? I not only wanted a free get out of jail card, I wanted a free lunch. If this doesn?t work I will probably try to isolate out the startup code that use the apple api?s and just modularize that. Or if worse comes to worse I?ll just kill the functionality that uses the api?s in order to test with jake until JEP 272 is in fact ready and I can change api's. Michael Hall From Alan.Bateman at oracle.com Thu Nov 26 07:33:08 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Nov 2015 07:33:08 +0000 Subject: Instrumentation best practices question, and more In-Reply-To: References: Message-ID: <5656B5B4.3090504@oracle.com> On 25/11/2015 22:56, Michael Rasmussen wrote: > : > > 1) There have been some discussions on this mailing list already > regarding escaping the encaptulation of the modules, but I haven't > found anything regarding what the best/recommended practice is for > something like profilers, trace advices, etc or anything else that > instruments classes throughout the system, inserting calls to methods > to perform various tasks. > In JDK8, adding this using a javaagent, my classes were on the boot > classpath, thus accessible to the entire system. But this is no longer > the case in jigsaw -- so how am I supposed to do this in a module-aware > system? > Am I just supposed to hack into the module system, to add edges from > every single module in the system to my agent? While that is doable, > it doesn't sounds very nice, requiring poking a lot of holes using > reflection to bypass the "in-same-module" checks etc. > These kind of instrumentations are not that uncommon in the Java > ecosystem, so I assume there must have been some considerations how > this should be accompliced? > Or is there no recommended way for doing this? Not in the current EA builds but in time there will be support for "module aware" agents. In the mean-time then agents developed for JDK 8 and older should mostly just work. If you do load time or dynamic instrumentation via JVM TI or java.lang.instrument then you get some "readability for free", specifically there will be read edges automatically added so that when you instrument code in named module M then M will read the unnamed modules of the both the boot and application class loader. So if you instrument code in a named module to call your into your supporting classes on the boot class path or class path then it should continue to work. I don't think I understand your point about being on the boot class path and get access "to the entire system". Being on the boot class path will limit visibility but doesn't change accessibility. Perhaps you mean that you get all permissions when running with a security manager? > > 2) Why the backwards-incompatible change to getResourceAsStream > family of methods? Sure, the methods are binary compatible, but > behave very differently than previously! > Object.class.getResourceAsStream("Object.class") now returns null, > apparently just for the sake of it, as the InputStream can easily > be obtained from the Module, without any in-same-module checks, via: > Object.class.getModule().getResourceAsStream("java/lang/Object.class") > But, accessing this through the Module requires the code to be > compiled against JDK9, having to keep multiple different codepaths in > the code depending on which JDK version I'm loading the resources on! Mark has summarized the current state of affairs here: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000163.html > > 3) Why was the implementation of java.lang.Package changed, so it no > longer returns the content of the Manifest file? > Previously, doing MyClass.class.getPackage().getImplementationTitle() > would return the "Implementation-Title" entry from the manifest file, > but now it returns null instead. > The documentation in JDK8 even mentions that this information is > typically stored in the manifest, where as the JDK9 now states that > these values are unspecified. If MyClass is packaged as a JAR file with an Implementation-Title attribute then this should continue to work. I just checked and I don't see any issues but it's possible my test case doesn't match what you have. If you can create a short test case then that would be useful to help us see whether there is a bug here. -Alan From michael.rasmussen at zeroturnaround.com Thu Nov 26 10:13:13 2015 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 26 Nov 2015 12:13:13 +0200 Subject: Instrumentation best practices question, and more In-Reply-To: <5656B5B4.3090504@oracle.com> References: <5656B5B4.3090504@oracle.com> Message-ID: On 26 November 2015 at 09:33, Alan Bateman wrote: > On 25/11/2015 22:56, Michael Rasmussen wrote: >> >> >> 3) Why was the implementation of java.lang.Package changed, so it no >> longer returns the content of the Manifest file? >> Previously, doing MyClass.class.getPackage().getImplementationTitle() >> would return the "Implementation-Title" entry from the manifest file, >> but now it returns null instead. >> The documentation in JDK8 even mentions that this information is >> typically stored in the manifest, where as the JDK9 now states that >> these values are unspecified. > > If MyClass is packaged as a JAR file with an Implementation-Title attribute > then this should continue to work. I just checked and I don't see any issues > but it's possible my test case doesn't match what you have. If you can > create a short test case then that would be useful to help us see whether > there is a bug here. > Yeah, I should have been more specific -- the issue is when the package is loaded from the boot loader, for instance when you have an agent that has itself on the Boot-Class-Path in the manifest. Sample code: https://gist.github.com/anonymous/d4f591fc041e676eb8d9 Output: $ java -javaagent:target\test-1.0-SNAPSHOT.jar -version test null 1.0-SNAPSHOT test null 1.0-SNAPSHOT test java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) $ java -javaagent:target\test-1.0-SNAPSHOT.jar -version null null null null null null null java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-jigsaw-nightly-h3660-20151022-b86) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-jigsaw-nightly-h3660-20151022-b86, mixed mode) From Alan.Bateman at oracle.com Thu Nov 26 10:54:06 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 Nov 2015 10:54:06 +0000 Subject: Instrumentation best practices question, and more In-Reply-To: References: <5656B5B4.3090504@oracle.com> Message-ID: <5656E4CE.10402@oracle.com> On 26/11/2015 10:13, Michael Rasmussen wrote: > Yeah, I should have been more specific -- the issue is when the package > is loaded from the boot loader, for instance when you have an agent that > has itself on the Boot-Class-Path in the manifest. > > Thanks for clarifying. What you are seeing is specific to JAR files added to the (otherwise does not exist) boot class path via -Xbootclasspath/a or agent equivalent. It's not a general issue. We've ignored this case in the current EA builds on the assumption that it should be very rare, we will probably need to look at it again. -Alan. From alan.bateman at oracle.com Thu Nov 26 18:32:25 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Nov 2015 18:32:25 +0000 Subject: hg: jigsaw/jake/jdk: ProxyClassAccessTest.java failing in agentvm mode Message-ID: <201511261832.tAQIWPdG017018@aojmv0008.oracle.com> Changeset: 7ca5833e24a0 Author: alanb Date: 2015-11-26 18:31 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ca5833e24a0 ProxyClassAccessTest.java failing in agentvm mode ! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java From alan.bateman at oracle.com Thu Nov 26 18:40:37 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Nov 2015 18:40:37 +0000 Subject: hg: jigsaw/jake/jdk: 8143583: Several tests don't work with latest jtreg due to non-existing files in @build Message-ID: <201511261840.tAQIecQw018745@aojmv0008.oracle.com> Changeset: 8fde59315381 Author: amlu Date: 2015-11-23 16:14 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fde59315381 8143583: Several tests don't work with latest jtreg due to non-existing files in @build Reviewed-by: alanb, sla ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/SuspendNoFlagTest.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/sun/tools/jmap/BasicJMapTest.java From alan.bateman at oracle.com Thu Nov 26 19:33:55 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 Nov 2015 19:33:55 +0000 Subject: hg: jigsaw/jake/jdk: Remove invalid negative test Message-ID: <201511261933.tAQJXtTk028606@aojmv0008.oracle.com> Changeset: be2e47bf00ce Author: alanb Date: 2015-11-26 19:33 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/be2e47bf00ce Remove invalid negative test ! test/jdk/jigsaw/tools/jlink/JLinkNegativeTest.java From stef at epardaud.fr Fri Nov 27 13:51:05 2015 From: stef at epardaud.fr (Stephane Epardaud) Date: Fri, 27 Nov 2015 14:51:05 +0100 Subject: Questions about the Jigsaw EA builds Message-ID: <56585FC9.3070400@epardaud.fr> Hi, I work on Ceylon, a JVM language, using a fork of javac 7 with backports from javac 8, and currently trying to see how to make it work with Java 9, which is interesting in our case as Ceylon already has modularity and adopted the JDK modularisation (as it was planned in Jigsaw) since Java 7. I downloaded the EA builds from https://jdk9.java.net/ and it lists two: - https://jdk9.java.net/download/ (build 93) - https://jdk9.java.net/jigsaw/ (build 86) Leading me to believe that the first was more recent, but it does not appear to include the java.annotations.common module in its lib/modules jimages. The second one has it, but has other differences such as having a jmods/ folder with ZIP module files (the format seems to be straightforward, but is there a specification somewhere?), and having only a single .jimage in lib/modules (but with more modules there). Am I right that I should use the second one? How do the build numbers relate? Are they independent ? Is the lib/modules supposed to contain one or three .jimage files? How does that relate to the jmods/ folder? Will/should javac use the .jimage or the jmods files? They seem to offer the same contents. Is there any documentation as to the format of the "jrt:/" NIO FileSystem? I've figured some things out to extract class file data from there, but a specification (even WIP) would be useful to verify my observations. Thanks for you help, cheers. From Alan.Bateman at oracle.com Fri Nov 27 14:28:32 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Nov 2015 14:28:32 +0000 Subject: Questions about the Jigsaw EA builds In-Reply-To: <56585FC9.3070400@epardaud.fr> References: <56585FC9.3070400@epardaud.fr> Message-ID: <56586890.7010504@oracle.com> On 27/11/2015 13:51, Stephane Epardaud wrote: > Hi, > > I work on Ceylon, a JVM language, using a fork of javac 7 with backports > from javac 8, and currently trying to see how to make it work with Java > 9, which is interesting in our case as Ceylon already has modularity and > adopted the JDK modularisation (as it was planned in Jigsaw) since Java 7. > > I downloaded the EA builds from https://jdk9.java.net/ and it lists two: > > - https://jdk9.java.net/download/ (build 93) > - https://jdk9.java.net/jigsaw/ (build 86) > > Leading me to believe that the first was more recent, but it does not > appear to include the java.annotations.common module in its lib/modules > jimages. The second one has it, but has other differences such as having > a jmods/ folder with ZIP module files (the format seems to be > straightforward, but is there a specification somewhere?), and having > only a single .jimage in lib/modules (but with more modules there). > > Am I right that I should use the second one? > > How do the build numbers relate? Are they independent ? > > Is the lib/modules supposed to contain one or three .jimage files? > > How does that relate to the jmods/ folder? Will/should javac use the > .jimage or the jmods files? They seem to offer the same contents. > > Is there any documentation as to the format of the "jrt:/" NIO > FileSystem? I've figured some things out to extract class file data from > there, but a specification (even WIP) would be useful to verify my > observations. > The JDK 9 EA builds are built from the JDK 9 master forest and are published weekly. The module system is not in JDK 9 yet but there are a multitude of other features and bug fixes going into JDK 9 each week. The weekly builds are tagged with a build number, the current build that is on the java.net download site is build 93. The module system (as in the prototype for JSR 376 and the JDK-specific enhancements in JEP 261) is being developed here, in Project Jigsaw. The development is based on JDK 9. We periodically sync up the development forest with the changes from JDK 9, we also make EA builds available. At this time then the jigsaw/jake forest is JDK 9 build 92 + module system. The current EA download is a bit older, it is based on JDK 9 build 86. The module system changes a lot of things and it's often a lot a bit of work to sync up the jigsaw/jake forest (lots of merging and adjustments to get everything working after a big sync up). Once the design has settled then we will integrate the module system into JDK 9 so that should reduce the work (and the confusion with having different EA downloads). As regards the jrt file system then you need to start with JEP 220 [1]. I don't think there is other documentation at this time. The jrt file system provider is in JDK 9 since late 2014. There are several changes and bug fixes that are in the jigsaw/jake forest that are not in JDK 9 and might not be in JDK 9 until the module system goes in. The reason for this is that underlying jimage container is used differently in JDK 9 vs. jigsaw/jake. We have moved to a single jimage container file in jigsaw/jake where the classes/resources are addressed by module. javac and other tools are using the file system API and should not care how many container files are used in the run-time image. The jmod files that you seeing are just packaged modules. I don't expect you will need to be concerned with these at this point. There are many open questions about the JMOD format so no documents to point at just now. The linker tool consumes these packaged modules when creating run-time images. The reason for the jmods/ directory in the EA builds is to put everything in a single download rather than having separate downloads and risk getting out of sync. This does make the EA downloads bigger for the moment (much bigger because the packages modules have the debug symbols). -Alan. [1] http://openjdk.java.net/jeps/220 From stef at epardaud.fr Fri Nov 27 14:51:25 2015 From: stef at epardaud.fr (Stephane Epardaud) Date: Fri, 27 Nov 2015 15:51:25 +0100 Subject: Questions about the Jigsaw EA builds In-Reply-To: <56586890.7010504@oracle.com> References: <56585FC9.3070400@epardaud.fr> <56586890.7010504@oracle.com> Message-ID: <56586DED.6050203@epardaud.fr> OK thanks a lot for all these answers, it's much clearer for me now :) From alan.bateman at oracle.com Fri Nov 27 15:46:06 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 27 Nov 2015 15:46:06 +0000 Subject: hg: jigsaw/jake/hotspot: Change Configuration.resolve to take a parent Configuration rather than parent Layer Message-ID: <201511271546.tARFk6K7006746@aojmv0008.oracle.com> Changeset: 5d9fe269bb7a Author: alanb Date: 2015-11-27 15:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d9fe269bb7a Change Configuration.resolve to take a parent Configuration rather than parent Layer Change Configuration.reads to read a set of read dependences rather than descriptors ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualToM1.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodNpkg.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/NmodNpkg_CheckRead.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualToM1.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgNotExp.java ! test/runtime/modules/AccessCheck/NmodNpkg_UmodNpkg.java ! test/runtime/modules/AccessCheck/NmodNpkg_UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/UmodNpkg_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_PkgNotExp.java From alan.bateman at oracle.com Fri Nov 27 15:46:23 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 27 Nov 2015 15:46:23 +0000 Subject: hg: jigsaw/jake/langtools: Change Configuration.resolve to take a parent Configuration rather than parent Layer Message-ID: <201511271546.tARFkNRW006944@aojmv0008.oracle.com> Changeset: 39f04bde0b71 Author: alanb Date: 2015-11-27 15:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/39f04bde0b71 Change Configuration.resolve to take a parent Configuration rather than parent Layer Change Configuration.reads to read a set of read dependences rather than descriptors ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java From alan.bateman at oracle.com Fri Nov 27 15:46:50 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 27 Nov 2015 15:46:50 +0000 Subject: hg: jigsaw/jake/jdk: Change Configuration.resolve to take a parent Configuration rather than parent Layer Message-ID: <201511271546.tARFkoa3007069@aojmv0008.oracle.com> Changeset: 85e0957f1d06 Author: alanb Date: 2015-11-27 15:34 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/85e0957f1d06 Change Configuration.resolve to take a parent Configuration rather than parent Layer Change Configuration.reads to read a set of read dependences rather than descriptors ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/TaskHelper.java ! test/java/lang/Class/getResource/Main.java ! test/java/lang/ModuleClassLoader/Basic.java ! test/jdk/jigsaw/module/AutomaticModulesTest.java ! test/jdk/jigsaw/module/ConfigurationTest.java ! test/jdk/jigsaw/reflect/Layer/LayerTest.java ! test/jdk/jigsaw/reflect/Module/BasicModuleTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyClassAccessTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java ! test/jdk/jigsaw/scenarios/automaticmodules/src/basictest/test/Main.java ! test/jdk/jigsaw/scenarios/container/src/container/container/Main.java ! test/jdk/jigsaw/util/ServiceLoader/ServicesTest.java From alan.bateman at oracle.com Fri Nov 27 16:14:46 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 27 Nov 2015 16:14:46 +0000 Subject: hg: jigsaw/jake/jdk: Change IllegalAccessException messages to align with IllegalAccessError messages Message-ID: <201511271614.tARGEkGr017398@aojmv0008.oracle.com> Changeset: a92829ff8629 Author: alanb Date: 2015-11-27 16:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a92829ff8629 Change IllegalAccessException messages to align with IllegalAccessError messages ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/sun/reflect/Reflection.java From simon at ochsenreither.de Fri Nov 27 19:52:44 2015 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Fri, 27 Nov 2015 20:52:44 +0100 Subject: Creating modules with JDK8 Message-ID: <5658B48C.5040808@ochsenreither.de> Hi everyone, sorry if this has been asked already, I couldn't find it in the documentation. Will the code that creates *.jmod files from *.class files be runnable on earlier versions of the JDK, or available via Maven Central? Thanks, Simon From forax at univ-mlv.fr Sat Nov 28 13:46:27 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 28 Nov 2015 14:46:27 +0100 (CET) Subject: Creating modules with JDK8 In-Reply-To: <5658B48C.5040808@ochsenreither.de> References: <5658B48C.5040808@ochsenreither.de> Message-ID: <1266968111.403122.1448718387586.JavaMail.zimbra@u-pem.fr> Hi Simon, the jmod file format is special file format, compared to the jar file format, jmod allows to embed native code in the archive. Apart if you want to embed native code, a module is just a jar with a module-info.class at its root. regards, R?mi ----- Mail original ----- > De: "Simon Ochsenreither" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Vendredi 27 Novembre 2015 20:52:44 > Objet: Creating modules with JDK8 > > Hi everyone, > > sorry if this has been asked already, I couldn't find it in the > documentation. > > Will the code that creates *.jmod files from *.class files be runnable > on earlier versions of the JDK, or available via Maven Central? > > Thanks, > > Simon > From alan.bateman at oracle.com Sun Nov 29 07:58:52 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 29 Nov 2015 07:58:52 +0000 Subject: hg: jigsaw/jake/hotspot: ModuleReference does not need to be abstract class Message-ID: <201511290758.tAT7wqGN009776@aojmv0008.oracle.com> Changeset: 3263a98ebab2 Author: alanb Date: 2015-11-29 07:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3263a98ebab2 ModuleReference does not need to be abstract class ! test/runtime/modules/AccessCheck/ExportAllUnnamed.java ! test/runtime/modules/AccessCheck/ModuleLibrary.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_CheckRead.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpQualToM1.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodNpkg.java ! test/runtime/modules/AccessCheck/NmodNpkgDiffCL_UmodUpkg.java ! test/runtime/modules/AccessCheck/NmodNpkg_CheckRead.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpQualToM1.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/NmodNpkg_PkgNotExp.java ! test/runtime/modules/AccessCheck/NmodNpkg_UmodNpkg.java ! test/runtime/modules/AccessCheck/NmodNpkg_UmodUPkg.java ! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/UmodNpkgDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodNpkg_PkgExpUnqual.java ! test/runtime/modules/AccessCheck/UmodNpkg_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkgDiffCL_PkgNotExp.java ! test/runtime/modules/AccessCheck/UmodUpkg_PkgExpQualOther.java ! test/runtime/modules/AccessCheck/UmodUpkg_PkgNotExp.java From alan.bateman at oracle.com Sun Nov 29 07:59:27 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 29 Nov 2015 07:59:27 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511290759.tAT7xREI010077@aojmv0008.oracle.com> Changeset: 23fa3594a1d4 Author: alanb Date: 2015-11-27 16:27 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/23fa3594a1d4 Fix imports ! src/java.base/share/classes/java/lang/module/Resolver.java Changeset: a3683eec0092 Author: alanb Date: 2015-11-29 07:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3683eec0092 ModuleReference does not need to be abstract class ! src/java.base/share/classes/java/lang/module/InstalledModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! test/jdk/jigsaw/lib/ModuleUtils.java ! test/jdk/jigsaw/module/ModuleReferenceTest.java ! test/jdk/jigsaw/reflect/Proxy/ProxyLayerTest.java From Alan.Bateman at oracle.com Sun Nov 29 08:18:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 29 Nov 2015 08:18:24 +0000 Subject: Creating modules with JDK8 In-Reply-To: <5658B48C.5040808@ochsenreither.de> References: <5658B48C.5040808@ochsenreither.de> Message-ID: <565AB4D0.3040702@oracle.com> On 27/11/2015 19:52, Simon Ochsenreither wrote: > Hi everyone, > > sorry if this has been asked already, I couldn't find it in the > documentation. > > Will the code that creates *.jmod files from *.class files be runnable > on earlier versions of the JDK, or available via Maven Central? > I suspect there is a more general question here as to how you might release a library that works on JDK 8 but can also work as a module with JDK 9, is that right? If so then check out modular JARs (as R?mi suggested) as they are just regular JAR files with a compiled module declaration in the top-level directory of the JAR file. If the code that is packaged in the JAR file is compiled for JDK 8 then it creates the potential for the library to work as a regular JAR file on the class path with JDK 8 (or 9) or as a module on the module path with JDK 9+. There is clearly a lot of opportunity for tooling. I think most builds today compile with an older JDK whereas the transition to modules brings up the question as to whether to compile with JDK 9 and use the new javac -release option to compile the code JDK 8, and compile the module declaration for JDK 9. Also with multi-release JAR files coming in JDK 9 (JEP 238) then it's possible to have release specific code in the JAR file too. All told, it could complicates the build a bit and this is where good tooling could help a lot. As you bring up JMOD files then it's just an alternative packaging format. At this time then it's mostly for modules that are intended to be linked into a run-time image (meaning a JRE, JDK or custom run-time) - it isn't currently an execution format. I could imagine Maven plugins supporting it as a new artifact type in the future. -Alan From weijun.wang at oracle.com Sun Nov 29 09:23:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 29 Nov 2015 17:23:45 +0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: Some comments: 1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner? 2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security. Thanks Max > On Nov 23, 2015, at 9:14 PM, Siba Sahoo wrote: > > +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net > > > > From: Siba Sahoo > Sent: Monday, November 23, 2015 4:56 PM > To: jigsaw-dev at openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan > Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > > > Hi, > > > > Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, > > > > Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ > > > > Description > > Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total of 72 test cases with the following criteria: > > > > (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) > > > > Thanks, > > Siba > > From simon at ochsenreither.de Sun Nov 29 14:21:57 2015 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Sun, 29 Nov 2015 15:21:57 +0100 Subject: Creating modules with JDK8 In-Reply-To: <1266968111.403122.1448718387586.JavaMail.zimbra@u-pem.fr> References: <5658B48C.5040808@ochsenreither.de> <1266968111.403122.1448718387586.JavaMail.zimbra@u-pem.fr> Message-ID: <565B0A05.3050609@ochsenreither.de> Thanks for these details, they help a lot! From mik3hall at gmail.com Sun Nov 29 16:03:58 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 29 Nov 2015 10:03:58 -0600 Subject: jdeps command In-Reply-To: <5542B8F0.5080003@oracle.com> References: <71F0EB41-C2C4-40A2-A65D-196D09A8D309@gmail.com> <8707BB4D-EEEC-43D7-B294-6D2862450BFE@oracle.com> <1C429076-EAD9-4E9F-9F46-0CBEC5FCAF55@apple.com> <4003789C-4821-439B-9E57-88837D6B55B2@gmail.com> <5542AF10.2000500@oracle.com> <5542B8F0.5080003@oracle.com> Message-ID: <1647CC9C-AFA9-4BF4-BE2C-B7D81C8DF4B7@gmail.com> > On Apr 30, 2015, at 6:21 PM, Mandy Chung wrote: >> > > Right - things may change during JDK 9 development and should wait until GA. My main point is that the list of JDK tools could be different for any release. > > Mandy Just remembered this one. I?m not sure who maintains the production installers and links. But it seems to me the correct way to do this is sort of what I have been doing lately for java 9 early access. You need to know what version links are currently in place and run an uninstaller script that deletes those. You can get the correct list of commands by listing the prior jvm's bin directory. Then you run an installer script that sets up links to the new jvm?s bin directory, this time listing against that directory first to get the correct list of commands that need linking. Michael Hall From alan.bateman at oracle.com Sun Nov 29 19:44:09 2015 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 29 Nov 2015 19:44:09 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201511291944.tATJi9dI002947@aojmv0008.oracle.com> Changeset: ab5b6e7e9db6 Author: alanb Date: 2015-11-29 10:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab5b6e7e9db6 ModuleReference hashCode no longer cached ! src/java.base/share/classes/java/lang/module/ModuleReference.java Changeset: 5dbfdd461d03 Author: alanb Date: 2015-11-29 19:43 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5dbfdd461d03 Change -listmods to list observable modules ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/native/libjli/java.c ! test/jdk/jigsaw/launcher/listmods/ListModsTest.java + test/jdk/jigsaw/launcher/listmods/src/java.transaction/javax/transaction/Transaction.java + test/jdk/jigsaw/launcher/listmods/src/java.transaction/javax/transaction/atomic/Atomic.java + test/jdk/jigsaw/launcher/listmods/src/java.transaction/module-info.java + test/jdk/jigsaw/launcher/listmods/src/m1/module-info.java From simon at ochsenreither.de Sun Nov 29 20:26:53 2015 From: simon at ochsenreither.de (Simon Ochsenreither) Date: Sun, 29 Nov 2015 21:26:53 +0100 Subject: Creating modules with JDK8 In-Reply-To: <565AB4D0.3040702@oracle.com> References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com> Message-ID: <565B5F8D.1060606@ochsenreither.de> Hi, > All told, it could complicates the build a bit and this is > where good tooling could help a lot. is there anything planned in this direction yet? Because the rest of the JVM ecosystem seems to remain largely apathetic towards it. A small list of issues which remain to be tackled: - No usable separation between runtime of the build tool and runtime of the code to be compiled. (You can do it, but it's annoying and hard to setup.) - No support for runtime versioning in Maven/Ivy. (Currently people seem to use horrible hacks like using one major version for e.g. Java 6, and another major version with Java 8), meaning it is completely impossible to specify currently "I want to have versions of my dependencies that run on JDK X". - Versioning/artifact structure differences between major tools like Maven and Ivy cause a lot of unnecessary churn and complexity. - JDK artifacts are not available through dependency resolution tools, meaning installing the JVM/JDK is a separate step which needs to be handled outside of the usual build tools. (Which in turn makes reproducible builds across different machines annoying.) - No small enough _supported_ JVM runtime which could be bundled with build tools, meaning the setup is yet-another step beginners have to deal with. - The two things above combined mean that it's currently not possible to have a build tool which can bootstrap itself properly. While I understand that Oracle doesn't make money with developer happiness or ease-of-use it holds some of the important keys to improvements in its hand. > As you bring up JMOD files then it's just an alternative packaging > format. At this time then it's mostly for modules that are intended to > be linked into a run-time image (meaning a JRE, JDK or custom run-time) > - it isn't currently an execution format. I could imagine Maven plugins > supporting it as a new artifact type in the future. How would we read these files when running on earlier JDK versions? Thanks, Simon From mik3hall at gmail.com Sun Nov 29 20:28:35 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 29 Nov 2015 14:28:35 -0600 Subject: Apple internal api's In-Reply-To: <2A18D261-FB25-4AC4-85E5-ADE899E1819E@oracle.com> References: <2A18D261-FB25-4AC4-85E5-ADE899E1819E@oracle.com> Message-ID: <7A423D82-BF29-45ED-A908-45382CAEF368@gmail.com> > On Nov 24, 2015, at 9:18 PM, Mandy Chung wrote: > > com.apple.eawt is in java.desktop module. Try this: > > java -XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED This one I had almost missed. For me, more fully, this had to be? -XaddExports:java.desktop/com.apple.eawt=ALL-UNNAMED,java.desktop/com.apple.eio=ALL-UNNAMED It then works and launches the application with some exceptions I have to look at. For OS X customized apps just wanting to get up and running with java 9 this seems the way to go. If you start hearing from people that their OS X applications won?t launch you might suggest that to them. Michael Hall From mik3hall at gmail.com Sun Nov 29 21:20:10 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 29 Nov 2015 15:20:10 -0600 Subject: OS X application won't launch with jigsaw In-Reply-To: References: <260BCAF4-BF68-461C-B2A0-15AF759BDED7@gmail.com> <565570D9.4070302@oracle.com> <2B2A9FA3-4B1F-44F7-944B-3E35DF9754BD@gmail.com> <13108C67-EF00-4B7E-86C4-97791489A425@oracle.com> Message-ID: >> On Nov 25, 2015, at 10:45 AM, Danno Ferrin > wrote: >> >> However, we fully expect that the Java 8 packager will not be able to make bundles holding a Java 9 runtime, and I think this is what you are encountering. I got past the original, jigsaw problem with internal apple api?s, running with a command line launch from a shell script. when I tried applying the same change, addition of a new -X jvmoption to my application bundle by changing the Info.plist file with Xcode, I get this? 11/29/15 3:00:35.131 PM sandboxd[277]: ([6613]) mdworker(6613) deny file-read-data /Users/mjh/Library/Preferences/com.apple.security.plist (import fstype:hfs fsflag:480D000 flags:250000025E diag:0 isXCode:0 uti:com.apple.application-bundle plugin:/Library/Spotlight/Application.mdimporter - find suspect file using: sudo mdutil -t 12638960) 11/29/15 3:01:14.467 PM amfid[104]: /Users/mjh/HalfPipe/bundles/HalfPipe9/HalfPipe9.app/Contents/MacOS/HalfPipe9 signature not valid: 0xfffefa2a 11/29/15 3:01:14.000 PM kernel[0]: proc 6707: load code signature error 4 for file ?HalfPipe9" It might be that changing the application bundle doesn?t invalidate the signed application signature but changing the Info.plist does? I might try regenerating the application including the -X option. I assume from your message javapackager support for Java 9 isn?t considered complete yet? So I might have to try the same trick of generating a earlier version and then copying in the java 9 jvm. My use of javapackager is still rather limited as for this application reusing the same one has seemed to work best up to now. Michael Hall From mic at micdev.net Sun Nov 29 22:16:18 2015 From: mic at micdev.net (Michael Mayne (micdev)) Date: Sun, 29 Nov 2015 22:16:18 +0000 Subject: hg: jigsaw/jake/jdk: Change IllegalAccessException messages to align with IllegalAccessError messages In-Reply-To: <201511271614.tARGEkGr017398@aojmv0008.oracle.com> References: <201511271614.tARGEkGr017398@aojmv0008.oracle.com> Message-ID: unsubscribe On 27 November 2015 at 16:14, wrote: > Changeset: a92829ff8629 > Author: alanb > Date: 2015-11-27 16:14 +0000 > URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a92829ff8629 > > Change IllegalAccessException messages to align with IllegalAccessError > messages > > ! src/java.base/share/classes/java/lang/reflect/Module.java > ! src/java.base/share/classes/sun/reflect/Reflection.java > > From cedric.champeau at gmail.com Mon Nov 30 08:50:56 2015 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 30 Nov 2015 09:50:56 +0100 Subject: Creating modules with JDK8 In-Reply-To: <565B5F8D.1060606@ochsenreither.de> References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com> <565B5F8D.1060606@ochsenreither.de> Message-ID: 2015-11-29 21:26 GMT+01:00 Simon Ochsenreither : > Hi, > > > All told, it could complicates the build a bit and this is > > where good tooling could help a lot. > > is there anything planned in this direction yet? Because the rest of the > JVM ecosystem seems to remain largely apathetic towards it. > > Not all the JVM ecosystem is apathic about this. Gradle already demonstrated support for building for Jigsaw during JavaOne, with our software model. It's still under heavy development but we plan to have something testable for general public by early next year (it is already testable by "power users"). Basically you can already have build scripts that contain configuration like this: model { myLib(JvmLibrarySpec) { targetPlatform 'java8' targetPlatform 'java9' api { exports 'com.acme.mylib.util' exports 'com.acme.mylib.client' } } } And we're building the Java 8 and Java 9 versions separately for this specification. By separately, we mean that it's really 2 different jars. Also this modelling allows us to check *at compile time* today if a dependent component makes use of non-exported (internal) APIs, and this works for pre-Jigsaw platforms. We want to get away from the traditional "Maven" way of things which is not good enough for what we want to do, and doesn't scale to real industrial challenges. In particular, we want to express that the dependencies for a platform (Java 8) are different from the dependencies for a different platform (Java 9). As well, runtime dependencies are very different from compile time dependencies. Depending on your target deployment environment, you would want to express different dependencies (targetting WildFly is not the same as targetting Tomcat, but one model can describe both). This also means that while for us it is pretty easy to support "multi-version jars", this is definitely not something we will ever recommend to do, because it's a very weak model. It doesn't allow you to have different dependencies for the same library. We think that support for this problem of separating the runtime from the compile process is something that the build tools have to deal with, not the JVM. So because we're a generic build tool we will support multi-version jars, but not by default. Eventually, I would also not recommend to put a module-info class (jdk 9 format) into a jar built for java 8. Just because there are tons of changes that it will blow up at runtime for legacy applications that use classpath scanning, and will fail when they see an unrecognized class format. I won't want to dig more into the details here, but no, the JVM world is not apathic about this, it's not just Maven and Ivy. > A small list of issues which remain to be tackled: > > - No usable separation between runtime of the build tool and runtime of > the code to be compiled. (You can do it, but it's annoying and hard to > setup.) > - No support for runtime versioning in Maven/Ivy. (Currently people seem > to use horrible hacks like using one major version for e.g. Java 6, and > another major version with Java 8), meaning it is completely impossible > to specify currently "I want to have versions of my dependencies that > run on JDK X". > - Versioning/artifact structure differences between major tools like > Maven and Ivy cause a lot of unnecessary churn and complexity. > - JDK artifacts are not available through dependency resolution tools, > meaning installing the JVM/JDK is a separate step which needs to be > handled outside of the usual build tools. (Which in turn makes > reproducible builds across different machines annoying.) > - No small enough _supported_ JVM runtime which could be bundled with > build tools, meaning the setup is yet-another step beginners have to > deal with. > - The two things above combined mean that it's currently not possible to > have a build tool which can bootstrap itself properly. > > While I understand that Oracle doesn't make money with developer > happiness or ease-of-use it holds some of the important keys to > improvements in its hand. > > > As you bring up JMOD files then it's just an alternative packaging > > format. At this time then it's mostly for modules that are intended to > > be linked into a run-time image (meaning a JRE, JDK or custom run-time) > > - it isn't currently an execution format. I could imagine Maven plugins > > supporting it as a new artifact type in the future. > > How would we read these files when running on earlier JDK versions? > > Thanks, > > Simon > > From Alan.Bateman at oracle.com Mon Nov 30 09:30:14 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Nov 2015 09:30:14 +0000 Subject: Creating modules with JDK8 In-Reply-To: <565B5F8D.1060606@ochsenreither.de> References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com> <565B5F8D.1060606@ochsenreither.de> Message-ID: <565C1726.40303@oracle.com> On 29/11/2015 20:26, Simon Ochsenreither wrote: > : > How would we read these files when running on earlier JDK versions? > It depends on what the eventual format will be. In the current prototype then JMOD files are zip format so they can be easily opened with with the java.util.zip APIs and many tools. In the case of module-info.class then ASM makes it easy. That is what the jar and jmod tools use to read and re-write it with additional attributes. -Alan. From Alan.Bateman at oracle.com Mon Nov 30 09:43:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Nov 2015 09:43:19 +0000 Subject: Creating modules with JDK8 In-Reply-To: References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com> <565B5F8D.1060606@ochsenreither.de> Message-ID: <565C1A37.4060804@oracle.com> On 30/11/2015 08:50, C?dric Champeau wrote: > : > > Eventually, I would also not recommend to put a module-info class (jdk 9 > format) into a jar built for java 8. Just because there are tons of changes > that it will blow up > at runtime for legacy applications that use classpath scanning, and will > fail when they see an unrecognized class format. > > Out of curiosity, you have examples of this? The hyphen makes it an invalid identifier so I would expect it should be ignored. At this time then the class file version is still 52.0 but maybe you've seen examples where something scanning the class path barfs on the new access_flags? -Alan From cedric.champeau at gmail.com Mon Nov 30 10:34:10 2015 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 30 Nov 2015 11:34:10 +0100 Subject: Creating modules with JDK8 In-Reply-To: <565C1A37.4060804@oracle.com> References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com> <565B5F8D.1060606@ochsenreither.de> <565C1A37.4060804@oracle.com> Message-ID: Actually no, you made me realize that the module-info.class file uses the same class format as in Java 8, so it should be ok with existing tools I guess, as long as they don't rewrite classes. So it's unlikely to happen for classpath scanning, but at compile time more likely (think of ProGuard). 2015-11-30 10:43 GMT+01:00 Alan Bateman : > > On 30/11/2015 08:50, C?dric Champeau wrote: > >> : >> >> Eventually, I would also not recommend to put a module-info class (jdk 9 >> format) into a jar built for java 8. Just because there are tons of >> changes >> that it will blow up >> at runtime for legacy applications that use classpath scanning, and will >> fail when they see an unrecognized class format. >> >> >> Out of curiosity, you have examples of this? The hyphen makes it an > invalid identifier so I would expect it should be ignored. At this time > then the class file version is still 52.0 but maybe you've seen examples > where something scanning the class path barfs on the new access_flags? > > -Alan > From forax at univ-mlv.fr Mon Nov 30 10:39:58 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 Nov 2015 11:39:58 +0100 (CET) Subject: Creating modules with JDK8 In-Reply-To: <565C1A37.4060804@oracle.com> References: <5658B48C.5040808@ochsenreither.de> <565AB4D0.3040702@oracle.com> <565B5F8D.1060606@ochsenreither.de> <565C1A37.4060804@oracle.com> Message-ID: <630584809.173373.1448879998683.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "C?dric Champeau" > Cc: "jigsaw-dev" > Envoy?: Lundi 30 Novembre 2015 10:43:19 > Objet: Re: Creating modules with JDK8 > > > On 30/11/2015 08:50, C?dric Champeau wrote: > > : > > > > Eventually, I would also not recommend to put a module-info class (jdk 9 > > format) into a jar built for java 8. Just because there are tons of changes > > that it will blow up > > at runtime for legacy applications that use classpath scanning, and will > > fail when they see an unrecognized class format. > > > > > Out of curiosity, you have examples of this? The hyphen makes it an > invalid identifier so I would expect it should be ignored. At this time > then the class file version is still 52.0 but maybe you've seen examples > where something scanning the class path barfs on the new access_flags? Cedric as a point here, A hypen is valid in class name otherwise you will not decode package-info.class correctly. If the application uses ASM to parse the bytecode, ASM will blow up on the unrecognized class file version. > > -Alan > R?mi From sibabrata.sahoo at oracle.com Mon Nov 30 11:13:11 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 30 Nov 2015 03:13:11 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/web