From claes.redestad at oracle.com Sun May 1 02:02:06 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 1 May 2016 04:02:06 +0200 Subject: Speeding up jmod Message-ID: <5725639E.5020000@oracle.com> Hi, Alan asked me to take a look at jmod performance (also jlink, but saving that for another day), so I set up a naive benchmark[1] and started profiling. ... and saw nothing really suspicious except that time is split between doing I/O and executing native code in libz.so, which I guess isn't surprising. Oddly enough the only java methods that even show up in profiles are related to writing, so I figured taking a closer look at the code for writing output from jmod wouldn't hurt. Turns out I was wrong, since I soon found that the output stream used by JmodTask is unbuffered... Applied a trivial patch[2] and results of running the micro with -f 10 -i 1 -bm ss (which is more or less like running jmod standalone): Benchmark Mode Cnt Score Error Units JmodBenchmark.jmodJavaBase ss 10 1.966 ? 0.297 s/op # before JmodBenchmark.jmodJavaBase ss 10 1.196 ? 0.142 s/op # after Seems like a notable reduction right there. Timing runs of jmod standalone gives analogous results on real time, but user time is still almost as high. Poking around further and it's obvious JIT threads are eating a larger portion of my cycles now - likely C2 is ramping up but not having time to get much done in the short life-time of jmod, which is mostly spent in native code anyhow. Switching to running short-running apps with only C1 can be profitable, especially on machines with a lot of cores (like the 2x8x2 machine I'm running this on), so I ran the numbers: Again, with time: Benchmark Mode Cnt Score Error Units JmodBenchmark.jmodJavaBase ss 10 1.175 ? 0.147 s/op real 0m17.140s user 0m54.868s sys 0m4.172s -XX:TieredStopAtLevel=1 Benchmark Mode Cnt Score Error Units JmodBenchmark.jmodJavaBase thrpt 10 1.075 ? 0.194 ops/s real 0m14.810s user 0m15.556s sys 0m1.584s Yep, only running "C1" improves things a lot in this case and on my environment. I suggest accepting the patch[2] as well as switching the jmod runner to run with -XX:TieredStopAtLevel=1 or similar. Both are likely needed for most to see any effect on build times. A long term alternative to consider might be to implement a server-based jmod akin to the javac server. Thanks! /Claes [1] http://cr.openjdk.java.net/~redestad/scratch/JmodBenchmark.java - assumes the java.base directory of module compiled sources are available in the working directory, which I won't include here for obvious reasons. -XaddExports:jdk.jlink/jdk.tools.jmod=ALL-UNNAMED [2] http://cr.openjdk.java.net/~redestad/scratch/jmod_buff.01/ From Alan.Bateman at oracle.com Sun May 1 11:53:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 1 May 2016 12:53:24 +0100 Subject: Speeding up jmod In-Reply-To: <5725639E.5020000@oracle.com> References: <5725639E.5020000@oracle.com> Message-ID: <5725EE34.7090808@oracle.com> On 01/05/2016 03:02, Claes Redestad wrote: > Hi, > > Alan asked me to take a look at jmod performance (also jlink, but > saving that for another day), so I set > up a naive benchmark[1] and started profiling. > > ... and saw nothing really suspicious except that time is split > between doing I/O and executing native code in > libz.so, which I guess isn't surprising. Oddly enough the only java > methods that even show up in > profiles are related to writing, so I figured taking a closer look at > the code for writing output from jmod > wouldn't hurt. Turns out I was wrong, since I soon found that the > output stream used by JmodTask is > unbuffered... > > Applied a trivial patch[2] and results of running the micro with -f 10 > -i 1 -bm ss (which is more or less like > running jmod standalone): > > Benchmark Mode Cnt Score Error Units > JmodBenchmark.jmodJavaBase ss 10 1.966 ? 0.297 s/op # before > JmodBenchmark.jmodJavaBase ss 10 1.196 ? 0.142 s/op # after > > Seems like a notable reduction right there. Timing runs of jmod > standalone gives analogous results on > real time, but user time is still almost as high. > > Poking around further and it's obvious JIT threads are eating a larger > portion of my cycles now - likely C2 is > ramping up but not having time to get much done in the short life-time > of jmod, which is mostly spent in > native code anyhow. Switching to running short-running apps with only > C1 can be profitable, especially on > machines with a lot of cores (like the 2x8x2 machine I'm running this > on), so I ran the numbers: > > Again, with time: > > Benchmark Mode Cnt Score Error Units > JmodBenchmark.jmodJavaBase ss 10 1.175 ? 0.147 s/op > > real 0m17.140s > user 0m54.868s > sys 0m4.172s > > -XX:TieredStopAtLevel=1 > > Benchmark Mode Cnt Score Error Units > JmodBenchmark.jmodJavaBase thrpt 10 1.075 ? 0.194 ops/s > > real 0m14.810s > user 0m15.556s > sys 0m1.584s > > Yep, only running "C1" improves things a lot in this case and on my > environment. > > I suggest accepting the patch[2] as well as switching the jmod runner > to run with -XX:TieredStopAtLevel=1 > or similar. Both are likely needed for most to see any effect on build > times. > > A long term alternative to consider might be to implement a > server-based jmod akin to the javac server. Thanks Claes, this is good analysis! The create method should be using a BufferedOutputStream, I'm surprised that it isn't. 'll get that patch in the current refresh although it looks like this helps more with the benchmark that with the build. I changed make/CreateJmods.java to use -XX:TieredStopAtLevel=1 and make a bit difference in the build. The wall clock time to create the jmods on my local machine drops from 46s. to 22s. I also tried a remote Windows machine and the time to create the jmods also dropped by about 20s. I'm sure Erik will have advice on how to fit this in. As things stand, the VM options for the jmod command are configured in spec.gmk.in to to use $(JAVA_TOOL_FLAGS_SMALL). Maybe it's time to change JAVA_TOOL_FLAGS_SMALL as it it seems to be -XX:+UseSerialGC and some heap settings at this time. As regards changing the jmod launcher then one concern with that it the options might conflict with options specified via -J so would need to look at that more closely. -Alan From andrej.golovnin at gmail.com Sun May 1 13:50:13 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Sun, 1 May 2016 15:50:13 +0200 Subject: Speeding up jmod In-Reply-To: <5725EE34.7090808@oracle.com> References: <5725639E.5020000@oracle.com> <5725EE34.7090808@oracle.com> Message-ID: Hi Alan, If you would like to improve the performance a little bit more, you can make additional changes (see the patch) to JmodTask and maybe Claes can rerun his tests to see if it helps. The patch makes following changes: - reads module info in a little bit more efficient way. - avoids duplicate searching for module info when hashing of modules is required. - uses String#lastIndexOf(int) in toPackageName(ZipEntry) instead of String#lastIndexOf(String). - avoids checking for every directory entry in a JarFile if it ends with ?module-info.class?. Best regards, Andrej Golovnin -------------- next part -------------- diff -r 7210b5dbd92f src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java --- a/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Sat Apr 30 16:41:08 2016 -0700 +++ b/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Sun May 01 15:43:24 2016 +0200 @@ -373,7 +373,6 @@ final String osArch = options.osArch; final String osVersion = options.osVersion; final List excludes = options.excludes; - final Hasher hasher = hasher(); JmodFileWriter() { } @@ -400,31 +399,34 @@ * on the class path of directories and JAR files. */ Supplier newModuleInfoSupplier() throws IOException { - ByteArrayOutputStream baos = new ByteArrayOutputStream(); + byte[] bytes = null; for (Path e: classpath) { if (Files.isDirectory(e)) { Path mi = e.resolve(MODULE_INFO); if (Files.isRegularFile(mi)) { - Files.copy(mi, baos); + bytes = Files.readAllBytes(mi); break; } } else if (Files.isRegularFile(e) && e.toString().endsWith(".jar")) { try (JarFile jf = new JarFile(e.toFile())) { ZipEntry entry = jf.getEntry(MODULE_INFO); if (entry != null) { - jf.getInputStream(entry).transferTo(baos); - break; + byte[] tmp = new byte[(int) entry.getSize()]; + if (jf.getInputStream(entry).read(tmp) == tmp.length) { + bytes = tmp; + break; + } } } catch (ZipException x) { // Skip. Do nothing. No packages will be added. } } } - if (baos.size() == 0) { + if (bytes == null) { return null; } else { - byte[] bytes = baos.toByteArray(); - return () -> new ByteArrayInputStream(bytes); + byte[] tmp = bytes; + return () -> new ByteArrayInputStream(tmp); } } @@ -450,7 +452,6 @@ try (InputStream in = miSupplier.get()) { descriptor = ModuleDescriptor.read(in); } - // copy the module-info.class into the jmod with the additional // attributes for the version, main class and other meta data try (InputStream in = miSupplier.get()) { @@ -479,6 +480,7 @@ if (moduleVersion != null) extender.version(moduleVersion); + Hasher hasher = hasher(descriptor); if (hasher != null) { ModuleHashes moduleHashes = hasher.computeHashes(descriptor.name()); if (moduleHashes != null) { @@ -504,50 +506,36 @@ * The jmod file is being created and does not exist in the * given modulepath. */ - private Hasher hasher() { + private Hasher hasher(ModuleDescriptor descriptor) { if (options.modulesToHash == null) return null; - try { - Supplier miSupplier = newModuleInfoSupplier(); - if (miSupplier == null) { - throw new IOException(MODULE_INFO + " not found"); + URI uri = options.jmodFile.toUri(); + ModuleReference mref = new ModuleReference(descriptor, uri, new Supplier<>() { + @Override + public ModuleReader get() { + throw new UnsupportedOperationException(); } + }); - ModuleDescriptor descriptor; - try (InputStream in = miSupplier.get()) { - descriptor = ModuleDescriptor.read(in); - } + // compose a module finder with the module path and also + // a module finder that can find the jmod file being created + ModuleFinder finder = ModuleFinder.compose(options.moduleFinder, + new ModuleFinder() { + @Override + public Optional find(String name) { + if (descriptor.name().equals(name)) + return Optional.of(mref); + else return Optional.empty(); + } - URI uri = options.jmodFile.toUri(); - ModuleReference mref = new ModuleReference(descriptor, uri, new Supplier<>() { @Override - public ModuleReader get() { - throw new UnsupportedOperationException(); + public Set findAll() { + return Collections.singleton(mref); } }); - // compose a module finder with the module path and also - // a module finder that can find the jmod file being created - ModuleFinder finder = ModuleFinder.compose(options.moduleFinder, - new ModuleFinder() { - @Override - public Optional find(String name) { - if (descriptor.name().equals(name)) - return Optional.of(mref); - else return Optional.empty(); - } - - @Override - public Set findAll() { - return Collections.singleton(mref); - } - }); - - return new Hasher(finder); - } catch (IOException e) { - throw new UncheckedIOException(e); - } + return new Hasher(finder); } /** @@ -617,7 +605,7 @@ String toPackageName(ZipEntry entry) { String name = entry.getName(); assert name.endsWith(".class"); - int index = name.lastIndexOf("/"); + int index = name.lastIndexOf('/'); if (index != -1) return name.substring(0, index).replace('/', '.'); else @@ -714,7 +702,7 @@ public boolean test(JarEntry je) { String name = je.getName(); // ## no support for excludes. Is it really needed? - return !name.endsWith(MODULE_INFO) && !je.isDirectory(); + return !je.isDirectory() && !name.endsWith(MODULE_INFO); } } } From chris.hegarty at oracle.com Sun May 1 15:56:40 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 1 May 2016 16:56:40 +0100 Subject: Speeding up jmod In-Reply-To: <5725EE34.7090808@oracle.com> References: <5725639E.5020000@oracle.com> <5725EE34.7090808@oracle.com> Message-ID: > On 1 May 2016, at 12:53, Alan Bateman wrote: > > On 01/05/2016 03:02, Claes Redestad wrote: >> Hi, >> >> Alan asked me to take a look at jmod performance (also jlink, but saving that for another day), so I set >> up a naive benchmark[1] and started profiling. >> >> ... and saw nothing really suspicious except that time is split between doing I/O and executing native code in >> libz.so, which I guess isn't surprising. Oddly enough the only java methods that even show up in >> profiles are related to writing, so I figured taking a closer look at the code for writing output from jmod >> wouldn't hurt. Turns out I was wrong, since I soon found that the output stream used by JmodTask is >> unbuffered... >> >> Applied a trivial patch[2] and results of running the micro with -f 10 -i 1 -bm ss (which is more or less like >> running jmod standalone): >> >> Benchmark Mode Cnt Score Error Units >> JmodBenchmark.jmodJavaBase ss 10 1.966 ? 0.297 s/op # before >> JmodBenchmark.jmodJavaBase ss 10 1.196 ? 0.142 s/op # after >> >> Seems like a notable reduction right there. Timing runs of jmod standalone gives analogous results on >> real time, but user time is still almost as high. >> >> Poking around further and it's obvious JIT threads are eating a larger portion of my cycles now - likely C2 is >> ramping up but not having time to get much done in the short life-time of jmod, which is mostly spent in >> native code anyhow. Switching to running short-running apps with only C1 can be profitable, especially on >> machines with a lot of cores (like the 2x8x2 machine I'm running this on), so I ran the numbers: >> >> Again, with time: >> >> Benchmark Mode Cnt Score Error Units >> JmodBenchmark.jmodJavaBase ss 10 1.175 ? 0.147 s/op >> >> real 0m17.140s >> user 0m54.868s >> sys 0m4.172s >> >> -XX:TieredStopAtLevel=1 >> >> Benchmark Mode Cnt Score Error Units >> JmodBenchmark.jmodJavaBase thrpt 10 1.075 ? 0.194 ops/s >> >> real 0m14.810s >> user 0m15.556s >> sys 0m1.584s >> >> Yep, only running "C1" improves things a lot in this case and on my environment. >> >> I suggest accepting the patch[2] as well as switching the jmod runner to run with -XX:TieredStopAtLevel=1 >> or similar. Both are likely needed for most to see any effect on build times. >> >> A long term alternative to consider might be to implement a server-based jmod akin to the javac server. > Thanks Claes, this is good analysis! Yes, this is great work. Thanks Claes. > The create method should be using a BufferedOutputStream, This was an oversight in the original implementation. The output should be buffered. > I'm surprised that it isn't. 'll get that patch in the current refresh although it looks like this helps more with the benchmark that with the build. > > I changed make/CreateJmods.java to use -XX:TieredStopAtLevel=1 and make a bit difference in the build. The wall clock time to create the jmods on my local machine drops from 46s. to 22s. I also tried a remote Windows machine and the time to create the jmods also dropped by about 20s. Wow, this is a real win. Good find. > I'm sure Erik will have advice on how to fit this in. As things stand, the VM options for the jmod command are configured in spec.gmk.in to to use $(JAVA_TOOL_FLAGS_SMALL). Maybe it's time to change JAVA_TOOL_FLAGS_SMALL as it it seems to be -XX:+UseSerialGC and some heap settings at this time. I would expect that a number of other tools could benefit from this too. -Chris. From alan.bateman at oracle.com Sun May 1 15:57:14 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 01 May 2016 15:57:14 +0000 Subject: hg: jigsaw/jake/jdk: 2 new changesets Message-ID: <201605011557.u41FvEHR022256@aojmv0008.oracle.com> Changeset: 2beef7ebb9f2 Author: alanb Date: 2016-05-01 16:40 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2beef7ebb9f2 Creating JMOD should use buffered output Contributed-by: claes.redestad at oracle.com ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Changeset: f05d7fee4b7e Author: alanb Date: 2016-05-01 16:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f05d7fee4b7e More misc. cleanup ! src/java.base/share/classes/java/lang/reflect/Module.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/module/ModuleHashes.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java From chris.hegarty at oracle.com Sun May 1 16:02:11 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 1 May 2016 17:02:11 +0100 Subject: Speeding up jmod In-Reply-To: References: <5725639E.5020000@oracle.com> <5725EE34.7090808@oracle.com> Message-ID: On 1 May 2016, at 14:50, Andrej Golovnin wrote: > > Hi Alan, > > If you would like to improve the performance a little bit more, > you can make additional changes (see the patch) to JmodTask > and maybe Claes can rerun his tests to see if it helps. These look good too, even as general clean ups, but it would be good to get some numbers on them. > The patch makes following changes: > > - reads module info in a little bit more efficient way. > - avoids duplicate searching for module info > when hashing of modules is required. > - uses String#lastIndexOf(int) in toPackageName(ZipEntry) > instead of String#lastIndexOf(String). > - avoids checking for every directory entry in a JarFile if it ends > with ?module-info.class?. -Chris. From andrej.golovnin at gmail.com Sun May 1 17:28:34 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Sun, 1 May 2016 19:28:34 +0200 Subject: Speeding up jmod In-Reply-To: References: <5725639E.5020000@oracle.com> <5725EE34.7090808@oracle.com> Message-ID: Hi Chris, Alan, I have updated my patch. Additionally to the other changes it warps the InputStream returned by Files.newInputStream() in a BufferedInputStream in the method JmodFileWriter#processSection(ZipOutputStream, Section, Path) because Files.newInputStream() returns an unbuffered InputStream per specification. Best regards, Andrej Golovnin -------------- next part -------------- diff -r 7210b5dbd92f src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java --- a/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Sat Apr 30 16:41:08 2016 -0700 +++ b/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java Sun May 01 19:09:04 2016 +0200 @@ -373,7 +373,6 @@ final String osArch = options.osArch; final String osVersion = options.osVersion; final List excludes = options.excludes; - final Hasher hasher = hasher(); JmodFileWriter() { } @@ -400,31 +399,34 @@ * on the class path of directories and JAR files. */ Supplier newModuleInfoSupplier() throws IOException { - ByteArrayOutputStream baos = new ByteArrayOutputStream(); + byte[] bytes = null; for (Path e: classpath) { if (Files.isDirectory(e)) { Path mi = e.resolve(MODULE_INFO); if (Files.isRegularFile(mi)) { - Files.copy(mi, baos); + bytes = Files.readAllBytes(mi); break; } } else if (Files.isRegularFile(e) && e.toString().endsWith(".jar")) { try (JarFile jf = new JarFile(e.toFile())) { ZipEntry entry = jf.getEntry(MODULE_INFO); if (entry != null) { - jf.getInputStream(entry).transferTo(baos); - break; + byte[] tmp = new byte[(int) entry.getSize()]; + if (jf.getInputStream(entry).read(tmp) == tmp.length) { + bytes = tmp; + break; + } } } catch (ZipException x) { // Skip. Do nothing. No packages will be added. } } } - if (baos.size() == 0) { + if (bytes == null) { return null; } else { - byte[] bytes = baos.toByteArray(); - return () -> new ByteArrayInputStream(bytes); + byte[] tmp = bytes; + return () -> new ByteArrayInputStream(tmp); } } @@ -450,7 +452,6 @@ try (InputStream in = miSupplier.get()) { descriptor = ModuleDescriptor.read(in); } - // copy the module-info.class into the jmod with the additional // attributes for the version, main class and other meta data try (InputStream in = miSupplier.get()) { @@ -479,6 +480,7 @@ if (moduleVersion != null) extender.version(moduleVersion); + Hasher hasher = hasher(descriptor); if (hasher != null) { ModuleHashes moduleHashes = hasher.computeHashes(descriptor.name()); if (moduleHashes != null) { @@ -504,50 +506,36 @@ * The jmod file is being created and does not exist in the * given modulepath. */ - private Hasher hasher() { + private Hasher hasher(ModuleDescriptor descriptor) { if (options.modulesToHash == null) return null; - try { - Supplier miSupplier = newModuleInfoSupplier(); - if (miSupplier == null) { - throw new IOException(MODULE_INFO + " not found"); + URI uri = options.jmodFile.toUri(); + ModuleReference mref = new ModuleReference(descriptor, uri, new Supplier<>() { + @Override + public ModuleReader get() { + throw new UnsupportedOperationException(); } + }); - ModuleDescriptor descriptor; - try (InputStream in = miSupplier.get()) { - descriptor = ModuleDescriptor.read(in); - } + // compose a module finder with the module path and also + // a module finder that can find the jmod file being created + ModuleFinder finder = ModuleFinder.compose(options.moduleFinder, + new ModuleFinder() { + @Override + public Optional find(String name) { + if (descriptor.name().equals(name)) + return Optional.of(mref); + else return Optional.empty(); + } - URI uri = options.jmodFile.toUri(); - ModuleReference mref = new ModuleReference(descriptor, uri, new Supplier<>() { @Override - public ModuleReader get() { - throw new UnsupportedOperationException(); + public Set findAll() { + return Collections.singleton(mref); } }); - // compose a module finder with the module path and also - // a module finder that can find the jmod file being created - ModuleFinder finder = ModuleFinder.compose(options.moduleFinder, - new ModuleFinder() { - @Override - public Optional find(String name) { - if (descriptor.name().equals(name)) - return Optional.of(mref); - else return Optional.empty(); - } - - @Override - public Set findAll() { - return Collections.singleton(mref); - } - }); - - return new Hasher(finder); - } catch (IOException e) { - throw new UncheckedIOException(e); - } + return new Hasher(finder); } /** @@ -617,7 +605,7 @@ String toPackageName(ZipEntry entry) { String name = entry.getName(); assert name.endsWith(".class"); - int index = name.lastIndexOf("/"); + int index = name.lastIndexOf('/'); if (index != -1) return name.substring(0, index).replace('/', '.'); else @@ -665,7 +653,8 @@ Path relPath = top.relativize(file); if (!relPath.toString().equals(MODULE_INFO) && !matches(relPath, excludes)) { - try (InputStream in = Files.newInputStream(file)) { + try (InputStream in = new BufferedInputStream( + Files.newInputStream(file))) { writeZipEntry(zos, in, prefix, relPath.toString()); } } @@ -714,7 +703,7 @@ public boolean test(JarEntry je) { String name = je.getName(); // ## no support for excludes. Is it really needed? - return !name.endsWith(MODULE_INFO) && !je.isDirectory(); + return !je.isDirectory() && !name.endsWith(MODULE_INFO); } } } From peter.levart at gmail.com Sun May 1 22:27:35 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 2 May 2016 00:27:35 +0200 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: <572355B0.60303@oracle.com> References: <572355B0.60303@oracle.com> Message-ID: Hi, I have some mostly stylish changes (which you can use or not) regarding usage of Optional and Stream(s) in package java.lang.module: http://cr.openjdk.java.net/~plevart/jdk9-jake/ModuleSystem.referesh.201604/webrev.01/ ...with some optimizations/cleanups/fixes: ModuleFinder.compose: - the composed ModuleFinder.findAll() is more efficient this way as it doesn't need to call back to find(). ModulePath: - there's unneeded overhead to call distinct() for a Stream that is later collected into Collectors.toSet() as the collector already uniquifies the elements. - lines 432...437 (old) - you don't want to treat entries in SERVICES_PREFIX directory that end with ".class" as classFiles - so I changes the: .filter(e -> (e.endsWith(".class") || e.startsWith(SERVICES_PREFIX))) to: .filter(s -> (s.endsWith(".class") ^ s.startsWith(SERVICES_PREFIX))) ModuleReader: - the default method read(String name) should close the InputStream after reading from it, shouldn't it? ModuleReferences: - no need for 'closed' flag in SafeCloseModuleReader to be volatile as it is always accessed under lock (either read lock when reading or write lock when writing). Resolver: - Implemented caching of ResolvedModule(s) as they are entered into resolved graph so that there are no duplicates. - Simplified last stage of iterative algorithm to build resolved graph. There's no need to construct a map of changes and apply it afterwards to 'g1' as changes can be applied individually for each module 'm1' in the graph 'g1' as they are collected. Regards, Peter On 04/29/2016 02:38 PM, Alan Bateman wrote: > > There have several changes in jake that we need to bring into > jdk9/dev. The main changes are: > > 1. The policy described in JEP 261 for the root modules to resolve > when compiling code in the unnamed module or where the main class is > loaded from the class file. This is a disruptive change and we need to > get through the transition. > > Related is a new token `ALL-DEFAULT` that can be specified to > `-addmods` to resolve the same roots when the initial module is a > named module. This will eventually replace `ALL-SYSTEM` but we can't > remove that just yet. The launchers for javac, javadoc, jlink and a > few other tools that load arbitrary code in unnamed modules are now > compiled with this option. > > 2. The transition to the new form of -Xpatch. This is mostly changes > in hotspot but there are changes in other repos too to drop or replace > the old form of -Xpatch (boot cycle builds for example). > > 3. Removal of the old form of -XaddExports and -XaddReads. This has > build + test changes. > > 4. The second phase of integrity hashing. With this phase then the > build records in java.base the hashes of the non-upgradeable modules. > This prevents accidental linking of standard/JDK modules from > different JDK builds. The jar and jmod tools have updated options to > support this. > > 5. Peter Levart's patch to replace the internal WeakSet in jlr.Module > with a WeakKeyPair. > > 6. Updates to jlink option handling. The reason this went into > jdk9/dev is that it is disruptive to FX packager and it's hard to > coordinate with FX when it's a separate forest. The packager class > that Chris Bensen has added to jlink will allows us to iterate on > jlink with reduced risk of breaking FX. > > There are several small bug fixes and clean-ups in several areas, > we'll have a lot more of these for the next update. > > One other thing to mention is that we've bumped the required version > of jtreg as jtreg relies on-Xpatch to add test cases into modules and > so it needed to be updated too. > > The webrevs, all repos are here: > http://cr.openjdk.java.net/~alanb/8154956/1/ > > There are a couple of files in the webrevs that we probably won't > bring to JDK 9 in this update: > > i. We have a patch to IDL compiler in the corba repo that needs a more > extensive fix. > ii. The javadoc change in ModuleFinder as there are still details to > decide on how modular JARs work as multi-release JARs. > > One other point is that the webrevs are against jdk-9+116 for now. > I've done a test merge + build with the current jdk9/dev forest and > there are only a few conflicts to fix. I will re-merge + test with > jdk9/dev once we have agreed the changes for this update. > > Finally, just to say that we'll probably continue in jake for a while > after we get through this update. There are several design issues on > the JSR issues list that will likely require a few iterations and a > bit of bake time before we bring them to JDK 9. > > -Alan From peter.levart at gmail.com Sun May 1 22:54:09 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 2 May 2016 00:54:09 +0200 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: References: <572355B0.60303@oracle.com> Message-ID: <999b3af9-ce8a-06d5-adfe-35007a1bdce5@gmail.com> Hi, Last minute findings... In ModulePath, jarPackages() and jmodPackages() helper method both use toPackageName(ZipEntry entry) method which checks for "classes/" prefix and strips it away. But "classes" is a valid package name or prefix (in case it is found in a .jar file). So it's better to only strip it off for jmodPackages()... http://cr.openjdk.java.net/~plevart/jdk9-jake/ModuleSystem.referesh.201604/webrev.02/ Regards, Peter On 05/02/2016 12:27 AM, Peter Levart wrote: > Hi, > > I have some mostly stylish changes (which you can use or not) > regarding usage of Optional and Stream(s) in package java.lang.module: > > http://cr.openjdk.java.net/~plevart/jdk9-jake/ModuleSystem.referesh.201604/webrev.01/ > > ...with some optimizations/cleanups/fixes: > > ModuleFinder.compose: > - the composed ModuleFinder.findAll() is more efficient this way as it > doesn't need to call back to find(). > > ModulePath: > - there's unneeded overhead to call distinct() for a Stream that is > later collected into Collectors.toSet() as the collector already > uniquifies the elements. > - lines 432...437 (old) - you don't want to treat entries in > SERVICES_PREFIX directory that end with ".class" as classFiles - so I > changes the: > .filter(e -> (e.endsWith(".class") || > e.startsWith(SERVICES_PREFIX))) > to: > .filter(s -> (s.endsWith(".class") ^ > s.startsWith(SERVICES_PREFIX))) > > ModuleReader: > - the default method read(String name) should close the InputStream > after reading from it, shouldn't it? > > ModuleReferences: > - no need for 'closed' flag in SafeCloseModuleReader to be volatile as > it is always accessed under lock (either read lock when reading or > write lock when writing). > > Resolver: > - Implemented caching of ResolvedModule(s) as they are entered into > resolved graph so that there are no duplicates. > - Simplified last stage of iterative algorithm to build resolved > graph. There's no need to construct a map of changes and apply it > afterwards to 'g1' as changes can be applied individually for each > module 'm1' in the graph 'g1' as they are collected. > > > Regards, Peter > > On 04/29/2016 02:38 PM, Alan Bateman wrote: >> >> There have several changes in jake that we need to bring into >> jdk9/dev. The main changes are: >> >> 1. The policy described in JEP 261 for the root modules to resolve >> when compiling code in the unnamed module or where the main class is >> loaded from the class file. This is a disruptive change and we need >> to get through the transition. >> >> Related is a new token `ALL-DEFAULT` that can be specified to >> `-addmods` to resolve the same roots when the initial module is a >> named module. This will eventually replace `ALL-SYSTEM` but we can't >> remove that just yet. The launchers for javac, javadoc, jlink and a >> few other tools that load arbitrary code in unnamed modules are now >> compiled with this option. >> >> 2. The transition to the new form of -Xpatch. This is mostly changes >> in hotspot but there are changes in other repos too to drop or >> replace the old form of -Xpatch (boot cycle builds for example). >> >> 3. Removal of the old form of -XaddExports and -XaddReads. This has >> build + test changes. >> >> 4. The second phase of integrity hashing. With this phase then the >> build records in java.base the hashes of the non-upgradeable modules. >> This prevents accidental linking of standard/JDK modules from >> different JDK builds. The jar and jmod tools have updated options to >> support this. >> >> 5. Peter Levart's patch to replace the internal WeakSet in jlr.Module >> with a WeakKeyPair. >> >> 6. Updates to jlink option handling. The reason this went into >> jdk9/dev is that it is disruptive to FX packager and it's hard to >> coordinate with FX when it's a separate forest. The packager class >> that Chris Bensen has added to jlink will allows us to iterate on >> jlink with reduced risk of breaking FX. >> >> There are several small bug fixes and clean-ups in several areas, >> we'll have a lot more of these for the next update. >> >> One other thing to mention is that we've bumped the required version >> of jtreg as jtreg relies on-Xpatch to add test cases into modules and >> so it needed to be updated too. >> >> The webrevs, all repos are here: >> http://cr.openjdk.java.net/~alanb/8154956/1/ >> >> There are a couple of files in the webrevs that we probably won't >> bring to JDK 9 in this update: >> >> i. We have a patch to IDL compiler in the corba repo that needs a >> more extensive fix. >> ii. The javadoc change in ModuleFinder as there are still details to >> decide on how modular JARs work as multi-release JARs. >> >> One other point is that the webrevs are against jdk-9+116 for now. >> I've done a test merge + build with the current jdk9/dev forest and >> there are only a few conflicts to fix. I will re-merge + test with >> jdk9/dev once we have agreed the changes for this update. >> >> Finally, just to say that we'll probably continue in jake for a while >> after we get through this update. There are several design issues on >> the JSR issues list that will likely require a few iterations and a >> bit of bake time before we bring them to JDK 9. >> >> -Alan > From andrej.golovnin at gmail.com Mon May 2 05:52:15 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Mon, 2 May 2016 07:52:15 +0200 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: <999b3af9-ce8a-06d5-adfe-35007a1bdce5@gmail.com> References: <572355B0.60303@oracle.com> <999b3af9-ce8a-06d5-adfe-35007a1bdce5@gmail.com> Message-ID: Hi Peter, src/java.base/share/classes/java/lang/module/ModuleReader.java 146 if (oin.isPresent()) try (InputStream in = oin.get()) { 147 return Optional.of(ByteBuffer.wrap(in.readAllBytes())); 148 } else { 149 return Optional.empty(); 150 } I highly doubt that the line 146 is easy to read. Can you change it into: 146 if (oin.isPresent()) { 147 try (InputStream in = oin.get()) { 148 return Optional.of(ByteBuffer.wrap(in.readAllBytes())); 149 } 150 } 151 return Optional.empty(); And maybe you can add following changes to your patch too. http://cr.openjdk.java.net/~plevart/jdk9-jake/ModuleSystem.referesh.201604/webrev.02/src/java.base/share/classes/java/lang/module/ModulePath.java.html The following lines use the String-based version of the #lastIndexOf-method. 341 int index = cf.lastIndexOf("/") + 1; 391 int i = fn.lastIndexOf(File.separator); 568 int index = cn.lastIndexOf("/"); They should be changed to use the char-based version. I don't know how often the method #deriveModuleDescriptor(JarFile) is executed. But compiling regular expressions over and over doesn't really helps from the performance standpoint of view: 400 Matcher matcher = Pattern.compile("-(\\d+(\\.|$))").matcher(mn); 415 mn = mn.replaceAll("[^A-Za-z0-9]", ".") // replace non-alphanumeric 416 .replaceAll("(\\.)(\\1)+", ".") // collapse repeating dots 417 .replaceAll("^\\.", "") // drop leading dots 418 .replaceAll("\\.$", ""); // drop trailing dots Maybe the regular expressions in the above lines should be precompiled in static final fields (Pattern objects are immutable and thread safe) to improve the performance of the #deriveModuleDescriptor(JarFile)-method. Best regards, Andrej Golovnin From Alan.Bateman at oracle.com Mon May 2 06:24:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 07:24:56 +0100 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: References: <572355B0.60303@oracle.com> Message-ID: <5726F2B8.9090304@oracle.com> On 01/05/2016 23:27, Peter Levart wrote: > Hi, > > I have some mostly stylish changes (which you can use or not) > regarding usage of Optional and Stream(s) in package java.lang.module: > > http://cr.openjdk.java.net/~plevart/jdk9-jake/ModuleSystem.referesh.201604/webrev.01/ It's good to do cleanup although our main focus here is to get through the transition to the new policy on root modules and the new -Xpatch as both are disruptive. We will continue to work in jake for a while as there are still many areas that need iteration and we need to go through a few rounds of API clean-up too. > ...with some optimizations/cleanups/fixes: > > ModuleFinder.compose: > - the composed ModuleFinder.findAll() is more efficient this way as it > doesn't need to call back to find(). True although if you don't mind, I'd prefer to skip this for because this method is due to be changed in a round of API updates (see JDK-8152650). The implementation will be replaced then. > > ModulePath: > - there's unneeded overhead to call distinct() for a Stream that is > later collected into Collectors.toSet() as the collector already > uniquifies the elements. > - lines 432...437 (old) - you don't want to treat entries in > SERVICES_PREFIX directory that end with ".class" as classFiles - so I > changes the: > .filter(e -> (e.endsWith(".class") || > e.startsWith(SERVICES_PREFIX))) > to: > .filter(s -> (s.endsWith(".class") ^ > s.startsWith(SERVICES_PREFIX))) This looks good, I'll bring this in. > > ModuleReader: > - the default method read(String name) should close the InputStream > after reading from it, shouldn't it? Yes it should, just hasn't been noticed because each of the implementations implement this method. I don't know if you mean to put the try on the same line but I'll make that a bit more readable before pushing the patch. > > ModuleReferences: > - no need for 'closed' flag in SafeCloseModuleReader to be volatile as > it is always accessed under lock (either read lock when reading or > write lock when writing). You are right. There has been a few iterations on this code and I thin this was left over. > > Resolver: > - Implemented caching of ResolvedModule(s) as they are entered into > resolved graph so that there are no duplicates. > - Simplified last stage of iterative algorithm to build resolved > graph. There's no need to construct a map of changes and apply it > afterwards to 'g1' as changes can be applied individually for each > module 'm1' in the graph 'g1' as they are collected. I would prefer not to change makeGraph in this round. You are right that it could be more efficient, Claes pointed this out recently too and had caching too. So something for a future round where it might be completely replaced. -Alan From Alan.Bateman at oracle.com Mon May 2 07:06:29 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 08:06:29 +0100 Subject: Speeding up jmod In-Reply-To: References: <5725639E.5020000@oracle.com> <5725EE34.7090808@oracle.com> Message-ID: <5726FC75.3080002@oracle.com> On 01/05/2016 17:02, Chris Hegarty wrote: > On 1 May 2016, at 14:50, Andrej Golovnin wrote: >> Hi Alan, >> >> If you would like to improve the performance a little bit more, >> you can make additional changes (see the patch) to JmodTask >> and maybe Claes can rerun his tests to see if it helps. > These look good too, even as general clean ups, but it would > be good to get some numbers on them. > Andrej - aside from the micro benchmarks, the real test is `make jmods` where the tool runs N times (N = number of modules) to create the packaged modules. Short lived tools have always been the JDK's Achilles heel. It may be that we will eventually need a "jmod server", like the sjavac server in the build today. Alternative it could be wrapped in another tool that capable of creating several packaged modules. There is a balance here as we also don't want to over complicated things. -Alan From Alan.Bateman at oracle.com Mon May 2 07:31:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 08:31:53 +0100 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: References: <572355B0.60303@oracle.com> <999b3af9-ce8a-06d5-adfe-35007a1bdce5@gmail.com> Message-ID: <57270269.6060906@oracle.com> On 02/05/2016 06:52, Andrej Golovnin wrote: > : > > I don't know how often the method #deriveModuleDescriptor(JarFile) > is executed. But compiling regular expressions over and over doesn't really > helps from the performance standpoint of view: > > 400 Matcher matcher = Pattern.compile("-(\\d+(\\.|$))").matcher(mn); > > 415 mn = mn.replaceAll("[^A-Za-z0-9]", ".") // replace > non-alphanumeric > 416 .replaceAll("(\\.)(\\1)+", ".") // collapse > repeating dots > 417 .replaceAll("^\\.", "") // drop leading dots > 418 .replaceAll("\\.$", ""); // drop trailing dots > > Maybe the regular expressions in the above lines should be precompiled > in static final fields (Pattern objects are immutable and thread safe) > to improve > the performance of the #deriveModuleDescriptor(JarFile)-method. > This is the pattern matching to derive the module name for an automatic module. You are right that this is inefficient, we should only need to compile the pattern once. Probably not a static field though as it also has to be lazy. I think we have enough in this update so if you don't mind, I would prefer to leave this until another refresh. -Alan From alan.bateman at oracle.com Mon May 2 07:35:58 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 02 May 2016 07:35:58 +0000 Subject: hg: jigsaw/jake/jdk: More clean-up Message-ID: <201605020735.u427ZxbM022949@aojmv0008.oracle.com> Changeset: 294fcc1ae09f Author: alanb Date: 2016-05-02 08:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/294fcc1ae09f More clean-up Contributed-by: peter.levart at gmail.com ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java From peter.levart at gmail.com Mon May 2 07:51:57 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 2 May 2016 09:51:57 +0200 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: <5726F2B8.9090304@oracle.com> References: <572355B0.60303@oracle.com> <5726F2B8.9090304@oracle.com> Message-ID: <5611c157-61b5-0915-b4ad-68ead0af5b6f@gmail.com> On 05/02/2016 08:24 AM, Alan Bateman wrote: >> >> ModuleReader: >> - the default method read(String name) should close the InputStream >> after reading from it, shouldn't it? > Yes it should, just hasn't been noticed because each of the > implementations implement this method. I don't know if you mean to put > the try on the same line but I'll make that a bit more readable before > pushing the patch. Good, it's more readable this way. JmodModuleReader and JarModuleReader use this method, but this hasn't presented a problem since all those streams are closed when the JarFile is closed. But if there were any custom ModuleReaders (it's a public API) not overriding the default method, there would be a possible leak. Regards, Peter From chris.hegarty at oracle.com Mon May 2 08:39:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 2 May 2016 09:39:10 +0100 Subject: 8154956: Module system implementation refresh (4/2016) In-Reply-To: <572355B0.60303@oracle.com> References: <572355B0.60303@oracle.com> Message-ID: <6E4243C2-D72F-48A3-A0E9-51EF968C6764@oracle.com> > On 29 Apr 2016, at 13:38, Alan Bateman wrote: > > The webrevs, all repos are here: > http://cr.openjdk.java.net/~alanb/8154956/1/ The updated changes look good to me. -Chris. From rafael.wth at gmail.com Mon May 2 12:51:28 2016 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Mon, 2 May 2016 14:51:28 +0200 Subject: Accessing class files for named modules Message-ID: Hello everybody, after I gave feedback a while ago I recently revisited how to port code generation libraries to Java 9 and unfortunately, this still does not seem possible with the current implementation. I am speaking based on experience with Javassist and Byte Buddy which are both broadly used within the Java ecosystem (several million downloads a year). I think I am competent to speak on this topic as I wrote Byte Buddy and work as a consultant in the field of code generation what gives me insight into many open- and closed-source code bases that depend heavily on the API. Code instrumentation libraries are often used for creating Java agents. One challange with defining Java agents is the inavailability of "rich type descriptions" similar to the Java reflection API which could be used to gather information about the type that is supplied to a class file transformer. To overcome this, both Javassist and Byte Buddy offer means of investigating information about unloaded types and their referred types. For this purpose, type information is extracted manually from class files which are read from the class loader that is provided to the ClassFileTransformer as an argument. A class file is located by calling ClassLoader::getResource with an argument of "binaryTypeName.replace('.', '/') + ".class". This includes classes that are defined by the VM (which are now contained within runtime modules). In Java 9, the latter method is overloaded by another method that accepts a module name as a second parameter. The javadoc of the preexisting getResource(String) now says: "Resources in a named module are private to that module. This method does not find resources in named modules defined to this class loader." Of course, this includes resources that represent class file which are no longer returned for named modules. This is the API-change that I struggle with. To explain why, consider this scenario: I want to create a ClassFileTransformer to instrument any class that implements Interface A. Doing so, the ClassFileTransformer is notified of some type Z being loaded. In order to find out if Z implements A, I am looking at all the interface types that are stored in the class file that the ClassFileTransformer provides. If any of these interfaces represents A, I am done. Otherwise, as a next stept, I need to look into the interfaces that Z does implement, Let's say, Z implements B. I now parse the class files of B to see if this interface implements A. Before Java 9, I could call "getResource" on the class loader that the ClassFileTransformer provides. While I cannot generally assume that a class loader provides the raw class file, this tactic works surprisingly well as most implementors of custom class loaders are aware of this convention and stick to it. With Java 9, this is no longer possible as I cannot determine what module - if any - the above interface B is defined within. What I really require is the previous behavior: I just want to get the class file independently of a module similar to somebody wanting to load a class by name without knowing what module this class will be defined within. I am aware that the idea of project Jigsaw is encapsulation but for scenarios like the above, it is often required to break module bondaries. In general, I think that project Jigsaw solved this problem elegantly but changing this single method's contract broke all 26 projects that I looked into before giving this feedback. Note that I only changed runtime as this contract change also affects "old" code running on a Java 9 VM as the JVM classes are now contained in runtime modules where assert ClassLoader.getSystemClassLoader().getResourceAsAStram("java/lang/Object.class") != null fails on Java 9 (but not on Java 8) whereas the following behavior is as expected: assert Object.class.getModule().getResourceAsStream("java/lang/Object.class") != null; assert MyCustomClass.class.getModule().getResourceAsStream("java/lang/Object.class") == null This leads me to the suggestion I want to make. Did you consider to simply retain the ClassLoader's behavior to not respect module boundaries? In the end, a class loader exists on a level above modules. If I wanted to read a module-scoped resource I would expect a user to read a resource via a particular module or via a Class instance. It would be possible to introduce an interface like: interface ResourceAware { URL getResource(String name); InputStream getResourceAsStram(String name); } which could be implemented by the ClassLoader, Class and Module classes where a class loader represents a Module-agnostic view whereas Class and Module respect the new encapsulation rules. Doing so, the implementation of Class could rather delegate to its Module rather then to its ClassLoader such that assert Object.class.getResourceAsStream("Object.class") != null; holds again which currently fails on Java 9 but works on Java 8. I think this outcome is intuitive and it would not introduce a breaking change unless accessing a "foreign resource" via a class instance what is quite rare. Also, if the latter was a problem, at least there exists a simple migration path as a class loader is easily available from any Class instance. To implement this behavior, it would only be necessary to change the contract of the getResource(String) and getResourceAsStream(String) methods of ClassLoader back to the current Java-8 definition. Note that the requirement of reading class foreign files is not only a matter of convenience but is also required for low-level instrumentation when using for example ASM computing stack map frames at runtime where it is important to find two type's common super type. Typically, this is done by the same strategy as explained above. Thank you for your time and considering this problem. Best regards, Rafael From Alan.Bateman at oracle.com Mon May 2 13:04:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 2 May 2016 14:04:56 +0100 Subject: Accessing class files for named modules In-Reply-To: References: Message-ID: <57275078.60003@oracle.com> On 02/05/2016 13:51, Rafael Winterhalter wrote: > : > > I am aware that the idea of project Jigsaw is encapsulation but for > scenarios like the above, it is often required to break module bondaries. > In general, I think that project Jigsaw solved this problem elegantly but > changing this single method's contract broke all 26 projects that I looked > into before giving this feedback. Note that I only changed runtime as this > contract change also affects "old" code running on a Java 9 VM as the JVM > classes are now contained in runtime modules where > This is #ClassFilesAsResources [1], or more generally #ResourceEncapsulation [2], on the JSR issues list. In due course then I'm sure Mark will bring a proposal to the jpms-spec-experts list on these issues. We don't want to make any changes to the API or implementation in this area before then. -Alan. [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ClassFilesAsResources [2] http://openjdk.java.net/projects/jigsaw/spec/issues/#ResourceEncapsulation From jonathan.gibbons at oracle.com Mon May 2 14:37:12 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 02 May 2016 07:37:12 -0700 Subject: Speeding up jmod In-Reply-To: <5726FC75.3080002@oracle.com> References: <5725639E.5020000@oracle.com> <5725EE34.7090808@oracle.com> <5726FC75.3080002@oracle.com> Message-ID: <57276618.4090708@oracle.com> On 05/02/2016 12:06 AM, Alan Bateman wrote: > > On 01/05/2016 17:02, Chris Hegarty wrote: >> On 1 May 2016, at 14:50, Andrej Golovnin >> wrote: >>> Hi Alan, >>> >>> If you would like to improve the performance a little bit more, >>> you can make additional changes (see the patch) to JmodTask >>> and maybe Claes can rerun his tests to see if it helps. >> These look good too, even as general clean ups, but it would >> be good to get some numbers on them. >> > Andrej - aside from the micro benchmarks, the real test is `make > jmods` where the tool runs N times (N = number of modules) to create > the packaged modules. Short lived tools have always been the JDK's > Achilles heel. It may be that we will eventually need a "jmod server", > like the sjavac server in the build today. Alternative it could be > wrapped in another tool that capable of creating several packaged > modules. There is a balance here as we also don't want to over > complicated things. > > -Alan Rather than build "sjavac"-like server functionality into selected tools, maybe we could generalize the server part of sjavac to be a "tool server", capable of running any tool implementing a simple Tool interface. -- Jon From michael.rasmussen at zeroturnaround.com Mon May 2 14:45:15 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Mon, 2 May 2016 17:45:15 +0300 Subject: Accessing class files for named modules In-Reply-To: <57275078.60003@oracle.com> References: <57275078.60003@oracle.com> Message-ID: I can only agree with this. We rely heavily on both ASM and Javassist, and resource lookup/loading in general. While, as an agent, we can usually patch the bytecode to poke holes where needed, having a supported way to read resource bytes, similar to how getResourceAsStream works in jdk8, following the same logic as the JVM uses to locate classes, would be very welcome, so we wouldn't have to implement that kind of support for every single classloader implementation out there. Currently, we have some code in place, that enables us to get the bytes for classes without knowing beforehand which module they are defined in, by basically mapping packages to modules. At the moment, this only works for named modules in the boot-layer though. /Michael Rasmussen From jonathan.gibbons at oracle.com Mon May 2 18:43:11 2016 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 02 May 2016 18:43:11 +0000 Subject: hg: jigsaw/jake/langtools: tiny whitespace fix Message-ID: <201605021843.u42IhBk0013346@aojmv0008.oracle.com> Changeset: ad9a8e291a81 Author: jjg Date: 2016-05-02 11:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ad9a8e291a81 tiny whitespace fix ! make/tools/crules/MutableFieldsAnalyzer.java From alexandre.iline at oracle.com Mon May 2 20:03:03 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 2 May 2016 13:03:03 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences Message-ID: Hi, Can you please take a look on: http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ ? Thank you Shura From mandy.chung at oracle.com Mon May 2 21:31:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 2 May 2016 14:31:14 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: Message-ID: <6DA4027B-523F-416A-AD26-78A5B04DA870@oracle.com> > On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: > > Hi, > > Can you please take a look on: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > ? Looks okay to me. Mandy From chris.hegarty at oracle.com Tue May 3 10:07:34 2016 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 03 May 2016 10:07:34 +0000 Subject: hg: jigsaw/jake/jdk: Fix typo Message-ID: <201605031007.u43A7YmI017652@aojmv0008.oracle.com> Changeset: 42007c6589fc Author: chegar Date: 2016-05-03 11:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/42007c6589fc Fix typo ! src/java.base/share/classes/java/lang/reflect/Module.java From gunnar at hibernate.org Tue May 3 12:46:57 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 3 May 2016 14:46:57 +0200 Subject: Overriding requirements of 3rd party modules Message-ID: Hi, While looking into Jigsaw-enabling some existing code, I came across the following use case for which I'm seeking advice on how to deal with. Consider a 3rd party library that contains JPA entities. Application developers will include that library into their app and work with its entities as part of their model. The library author doesn't know which JPA provider will be used (Hibernate, EclipseLink etc.), so the library should work with any compatible provider. Now the different providers all have their own JPA API Jar. Thus in the module-info.java of the library, there'd be a "requires" clause to one of the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the library. But users of the lib might want to use *another* JPA provider and hence API Jar for their app. What's Jigsaw's approach for letting the user deal with that? I.e. how could the user override the requirement of the lib in order to work with the provider of their choice? I vaguely remember a concept of "module aliases" in earlier drafts which might have been used for that (for instance, all the different API Jars could act as "jpa-2.1"), but I cannot seem to find that in the current docs anymore. Thanks, --Gunnar From Alan.Bateman at oracle.com Tue May 3 13:45:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 3 May 2016 14:45:15 +0100 Subject: Overriding requirements of 3rd party modules In-Reply-To: References: Message-ID: <5728AB6B.5090108@oracle.com> On 03/05/2016 13:46, Gunnar Morling wrote: > Hi, > > While looking into Jigsaw-enabling some existing code, I came across the > following use case for which I'm seeking advice on how to deal with. > > Consider a 3rd party library that contains JPA entities. Application > developers will include that library into their app and work with its > entities as part of their model. The library author doesn't know which JPA > provider will be used (Hibernate, EclipseLink etc.), so the library should > work with any compatible provider. > > Now the different providers all have their own JPA API Jar. Thus in the > module-info.java of the library, there'd be a "requires" clause to one of > the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the > library. > > But users of the lib might want to use *another* JPA provider and hence > API Jar for their app. What's Jigsaw's approach for letting the user deal > with that? I.e. how could the user override the requirement of the lib in > order to work with the provider of their choice? > > I vaguely remember a concept of "module aliases" in earlier drafts which > might have been used for that (for instance, all the different API Jars > could act as "jpa-2.1"), but I cannot seem to find that in the current docs > anymore. > The early exploration phase did have some support for aliasing (`provides jpa` for example). This is not in the current design. An alternative is to use services of course, say where there is one API module and a service provider interface to allow the implementation be plugged in. The current design (with `uses` and `provides`) leads itself very well to this type of loose coupling. We have many examples in Java SE and the JDK. Sorry I don't know JPA too well to know whether this applies or not but I do see a javax.persistence.spi package that looks like it supporting plugging in alterative implementations. -Alan From steve.drach at oracle.com Mon May 2 21:48:29 2016 From: steve.drach at oracle.com (Steve Drach) Date: Mon, 2 May 2016 14:48:29 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: Message-ID: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> Looks fine to me, although I am not an official reviewer. Thanks for doing this. > On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: > > Hi, > > Can you please take a look on: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > ? > > Thank you > > Shura > From chris.hegarty at oracle.com Tue May 3 15:10:33 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 May 2016 16:10:33 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> Message-ID: <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> On 2 May 2016, at 22:48, Steve Drach wrote: > Looks fine to me, +1. -Chris. > although I am not an official reviewer. Thanks for doing this. > >> On May 2, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: >> >> Hi, >> >> Can you please take a look on: >> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ >> ? >> >> Thank you >> >> Shura >> > From alexandre.iline at oracle.com Tue May 3 19:43:02 2016 From: alexandre.iline at oracle.com (Alexandre Iline (Shura)) Date: Tue, 3 May 2016 12:43:02 -0700 Subject: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules In-Reply-To: <570FA8D9.4080807@oracle.com> References: <570FA8D9.4080807@oracle.com> Message-ID: > On Apr 14, 2016, at 7:27 AM, Alan Bateman wrote: > > On 13/04/2016 18:29, Alexandre (Shura) Iline wrote: >> Hi, >> >> Could you be so kind to take a look on this fix: >> http://cr.openjdk.java.net/~shurailine/8154182/webrev.00/ >> > What would you think of having this test run with `-addmods ALL-SYSTEM` instead? Your patch is okay but it will mean that the test won't exercise getDeclaredFields on the EE module, at least not when we bring the changes in jake to JDK 9. This option can be used with `-limitmods`. > > Another test like this is VerifyModuleDelegation. In both cases the tests have been changed to run with `-addmods ALL-SYSTEM` in jake. Alan, I am not sure what you are suggesting. Right now the test is failing without my changes, if ?-limitmods java.base? is supplied to the jtreg command line: $ jtreg -jdk:... -noreport "-javaoptions:-limitmods java.base" java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java with Test failed for the following classes: ? Right now the test has: * @run main/othervm -Djdk.launcher.addmods=ALL-SYSTEM FieldSetAccessibleTest UNSECURE Changing it to * @run main/othervm -addmods ALL-SYSTEM FieldSetAccessibleTest UNSECURE yields the same results. I was thinking that the Jake integration would change something, but I see the same behavior as before. Shura > > -Alan From naoto.sato at oracle.com Tue May 3 23:33:00 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 3 May 2016 16:33:00 -0700 Subject: RFR: JDK-8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved Message-ID: <5729352C.80203@oracle.com> Hi, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8155649 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8155649/webrev.00/ Naoto From emmanuel at hibernate.org Wed May 4 08:20:31 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 4 May 2016 10:20:31 +0200 Subject: Overriding requirements of 3rd party modules In-Reply-To: <5728AB6B.5090108@oracle.com> References: <5728AB6B.5090108@oracle.com> Message-ID: <20160504082031.GA938@hibernate.org> On Tue 2016-05-03 14:45, Alan Bateman wrote: > On 03/05/2016 13:46, Gunnar Morling wrote: > > Hi, > > > > While looking into Jigsaw-enabling some existing code, I came across the > > following use case for which I'm seeking advice on how to deal with. > > > > Consider a 3rd party library that contains JPA entities. Application > > developers will include that library into their app and work with its > > entities as part of their model. The library author doesn't know which JPA > > provider will be used (Hibernate, EclipseLink etc.), so the library should > > work with any compatible provider. > > > > Now the different providers all have their own JPA API Jar. Thus in the > > module-info.java of the library, there'd be a "requires" clause to one of > > the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the > > library. > > > > But users of the lib might want to use *another* JPA provider and hence > > API Jar for their app. What's Jigsaw's approach for letting the user deal > > with that? I.e. how could the user override the requirement of the lib in > > order to work with the provider of their choice? > > > > I vaguely remember a concept of "module aliases" in earlier drafts which > > might have been used for that (for instance, all the different API Jars > > could act as "jpa-2.1"), but I cannot seem to find that in the current docs > > anymore. > > > The early exploration phase did have some support for aliasing (`provides > jpa` for example). This is not in the current design. > > An alternative is to use services of course, say where there is one API > module and a service provider interface to allow the implementation be > plugged in. The current design (with `uses` and `provides`) leads itself > very well to this type of loose coupling. We have many examples in Java SE > and the JDK. Sorry I don't know JPA too well to know whether this applies or > not but I do see a javax.persistence.spi package that looks like it > supporting plugging in alterative implementations. JPA uses the service loader pattern to find the list of implementations. But what Gunnar is describing is a concern of the API module itself. For reasons related to history, license, copyright openness concerns and code maintenance, there are several alternative incarnations of JSR APIs floating around. They are all sig compliant as per the TCK but they have different Maven GAVs For JPA at the very least, there is the Oracle and Red Hat version. I'm pretty sure Apache has its own too. So if the third party module Gunnar mentions does use the hibernate version (which its own name), there is no way for the third party module user to override this decision and use the Oracle one. Hope that clarifies. emmanuel From chris.hegarty at oracle.com Wed May 4 08:40:07 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 09:40:07 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> Message-ID: On 3 May 2016, at 16:10, Chris Hegarty wrote: >>> >>> Can you please take a look on: >>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ Taking another look over this before sponsoring?. The test library dependency seems to be on java.compiler, and not jdk.compiler, right ? Also, I see no reason for the addition of jdk.zipfs. -Chris. From gunnar at hibernate.org Wed May 4 09:24:35 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 4 May 2016 11:24:35 +0200 Subject: Overriding requirements of 3rd party modules In-Reply-To: <20160504082031.GA938@hibernate.org> References: <5728AB6B.5090108@oracle.com> <20160504082031.GA938@hibernate.org> Message-ID: Note that this is not a requirement specific only to JPA. There are more cases where reusable components obtain a package from module A at their own build time (and thus would declare requirements in module-info.java accordingly) but need to work with the same package provided by another module B when being part of a downstream application. For instance there is the "stripped" javaee-api-7.0.jar which can be used for compiling a module against the complete Java EE API (and thus seems reasonable as requirement in module-info.java). But this JAR contains no actual method implementations at all, instead the same packages must be provided from other sources when executing a module compiled against it as part of a downstream application. Or consider the case of logging (abstractions). Suppose a library depends on Commons Logging (JCL). An application using the library might wish to work with slf4j though for a unified logging experience. For that purpose slf4j provides a JCL-over-slf4j bridge. This is a drop-in replacement for JCL, re-implementing the JCL packages but using slf4j and its configured backend underneath. In such scenario the application developer would need to override the requirement of the lib to JCL with the slf4j-based bridge. I agree that in theory it'd be nice if there was a canonical source for each package which then uses the service loader to bootstrap specific implementations. But in practice we are not there. There may be several providers of the same package (as in the case of JPA), or a package doesn't foresee different implementations and thus should be replaceable with a compatible alternative (the logging bridge example). Thus it's my believe that it is vital for the module system to provide application developers with means of overriding module requirements of their dependencies with (package-compatible) alternatives. 2016-05-04 10:20 GMT+02:00 Emmanuel Bernard : > On Tue 2016-05-03 14:45, Alan Bateman wrote: > > On 03/05/2016 13:46, Gunnar Morling wrote: > > > Hi, > > > > > > While looking into Jigsaw-enabling some existing code, I came across > the > > > following use case for which I'm seeking advice on how to deal with. > > > > > > Consider a 3rd party library that contains JPA entities. Application > > > developers will include that library into their app and work with its > > > entities as part of their model. The library author doesn't know which > JPA > > > provider will be used (Hibernate, EclipseLink etc.), so the library > should > > > work with any compatible provider. > > > > > > Now the different providers all have their own JPA API Jar. Thus in the > > > module-info.java of the library, there'd be a "requires" clause to one > of > > > the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing > the > > > library. > > > > > > But users of the lib might want to use *another* JPA provider and hence > > > API Jar for their app. What's Jigsaw's approach for letting the user > deal > > > with that? I.e. how could the user override the requirement of the lib > in > > > order to work with the provider of their choice? > > > > > > I vaguely remember a concept of "module aliases" in earlier drafts > which > > > might have been used for that (for instance, all the different API Jars > > > could act as "jpa-2.1"), but I cannot seem to find that in the current > docs > > > anymore. > > > > > The early exploration phase did have some support for aliasing (`provides > > jpa` for example). This is not in the current design. > > > > An alternative is to use services of course, say where there is one API > > module and a service provider interface to allow the implementation be > > plugged in. The current design (with `uses` and `provides`) leads itself > > very well to this type of loose coupling. We have many examples in Java > SE > > and the JDK. Sorry I don't know JPA too well to know whether this > applies or > > not but I do see a javax.persistence.spi package that looks like it > > supporting plugging in alterative implementations. > > JPA uses the service loader pattern to find the list of implementations. > But what Gunnar is describing is a concern of the API module itself. > > For reasons related to history, license, copyright openness concerns and > code maintenance, there are several alternative incarnations of JSR APIs > floating around. They are all sig compliant as per the TCK but they have > different Maven GAVs > > For JPA at the very least, there is the Oracle and Red Hat version. I'm > pretty sure Apache has its own too. So if the third party module Gunnar > mentions does use the hibernate version (which its own name), there is > no way for the third party module user to override this decision and use > the Oracle one. > > Hope that clarifies. > > emmanuel > From Alan.Bateman at oracle.com Wed May 4 09:54:58 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 10:54:58 +0100 Subject: Overriding requirements of 3rd party modules In-Reply-To: <20160504082031.GA938@hibernate.org> References: <5728AB6B.5090108@oracle.com> <20160504082031.GA938@hibernate.org> Message-ID: <5729C6F2.1040809@oracle.com> On 04/05/2016 09:20, Emmanuel Bernard wrote: > : > JPA uses the service loader pattern to find the list of implementations. > But what Gunnar is describing is a concern of the API module itself. > > For reasons related to history, license, copyright openness concerns and > code maintenance, there are several alternative incarnations of JSR APIs > floating around. They are all sig compliant as per the TCK but they have > different Maven GAVs > > For JPA at the very least, there is the Oracle and Red Hat version. I'm > pretty sure Apache has its own too. So if the third party module Gunnar > mentions does use the hibernate version (which its own name), there is > no way for the third party module user to override this decision and use > the Oracle one. > I don't know how/when Java EE will embrace modules but I would expect that module names will be chosen and that the module name, exports, etc. will become part of the TCK signature test. In the case of JPA then it might be "module java.persistence" where compliant implementations will have a declaration like this: module java.persistence { exports javax.persistence; exports javax.persistence.criteria; exports javax.persistence.metamodel; exports javax.persistence.spi uses javax.persistence.spi.PersistenceProvider; : } When you have an explicit module then it doesn't matter how the artifact is named, the group/artifact/version in Maven isn't relevant to the module system either. I realize that we are in somewhat of a void at the moment in that there aren't Java EE modules yet but cases like this, where they are several different copies of the API classes, then maybe the folks involved could come together with the spec lead for the API and agree the module name. -Alan From Alan.Bateman at oracle.com Wed May 4 10:03:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 11:03:25 +0100 Subject: RFR: JDK-8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved In-Reply-To: <5729352C.80203@oracle.com> References: <5729352C.80203@oracle.com> Message-ID: <5729C8ED.8060206@oracle.com> On 04/05/2016 00:33, Naoto Sato wrote: > Hi, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8155649 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8155649/webrev.00/ This looks okay. There is a corner case where it should be possible to --include-locales to specify en_US and it should always succeed but I don't think that is worth spending time on. -Alan From Alan.Bateman at oracle.com Wed May 4 10:07:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 11:07:13 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> Message-ID: <5729C9D1.5040506@oracle.com> On 04/05/2016 09:40, Chris Hegarty wrote: > On 3 May 2016, at 16:10, Chris Hegarty wrote: > >>>> Can you please take a look on: >>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ > Taking another look over this before sponsoring?. > > The test library dependency seems to be on java.compiler, and not jdk.compiler, > right ? Also, I see no reason for the addition of jdk.zipfs. > java.compiler is just the API module, the runtime image needs to have jdk.compiler linked in to be useful. So I think @modules jdk.compiler is right here as otherwise the test will be selected when testing a "JRE". java. javac needs the zipfs provider in order to compiler against libraries that are packaged as JAR/zip files so I assume this is why it listed here. -Alan. From chris.hegarty at oracle.com Wed May 4 10:24:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 11:24:06 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <5729C9D1.5040506@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> Message-ID: On 4 May 2016, at 11:07, Alan Bateman wrote: > On 04/05/2016 09:40, Chris Hegarty wrote: >> On 3 May 2016, at 16:10, Chris Hegarty wrote: >> >>>>> Can you please take a look on: >>>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/ >> Taking another look over this before sponsoring?. >> >> The test library dependency seems to be on java.compiler, and not jdk.compiler, >> right ? Also, I see no reason for the addition of jdk.zipfs. >> > java.compiler is just the API module, the runtime image needs to have jdk.compiler linked in to be useful. So the test depends on both the compiler API and impl, which is implicit with the 'requires public java.compiler? in the jdk.compiler module. That?s fine, and makes sense. > So I think @modules jdk.compiler is right here as otherwise the test will be selected when testing a "JRE". java. javac needs the zipfs provider in order to compiler against libraries that are packaged as JAR/zip files so I assume this is why it listed here. The tests cause compilation of test library classes, but only some tests actually use the methods that provoke compilation. Similar to above, tests that don?t actually compile anything could depend on just java.compiler. This is all to fragile and may cause problems with future refactoring. I think we should add the same set of @moduels to all these tests, rather than an individual set determined by intimate knowledge of the inner workings of the test. @modules java.compiler jdk.compiler jdk.zipfs jdk.jartool with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. -Chris From konstantin.barzilovich at oracle.com Wed May 4 13:18:36 2016 From: konstantin.barzilovich at oracle.com (Konstantin Barzilovich) Date: Wed, 04 May 2016 16:18:36 +0300 Subject: Modules with packages duplication Message-ID: Hello, I can see that RI checks if there are packages with the same names in different modules (named or unnamed). This check fails even if there is no clash (no module can read both packages). Will it be the same in final version of JDK9 or it can be changed soon? -- Thanks, Konstantin. From Alan.Bateman at oracle.com Wed May 4 13:32:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 14:32:14 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> Message-ID: <5729F9DE.4080909@oracle.com> On 04/05/2016 11:24, Chris Hegarty wrote: > : > The tests cause compilation of test library classes, but only some tests > actually use the methods that provoke compilation. Similar to above, tests > that don?t actually compile anything could depend on just java.compiler. > > This is all to fragile and may cause problems with future refactoring. I > think we should add the same set of @moduels to all these tests, rather > than an individual set determined by intimate knowledge of the inner > workings of the test. > > @modules java.compiler > jdk.compiler > jdk.zipfs > jdk.jartool > > with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. > or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. -Alan From Alan.Bateman at oracle.com Wed May 4 14:03:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 15:03:38 +0100 Subject: Modules with packages duplication In-Reply-To: References: Message-ID: <572A013A.7060806@oracle.com> On 04/05/2016 14:18, Konstantin Barzilovich wrote: > Hello, > > I can see that RI checks if there are packages with the same names in > different modules (named or unnamed). > This check fails even if there is no clash (no module can read both > packages). > Will it be the same in final version of JDK9 or it can be changed soon? > I think you are asking about modules on the application module path (`java -modulepath ...`) that are resolved at startup. These are defined to the application class loader so they cannot have overlapping packages. It's trivial to do things like map each module in its own class loader but that messes with visibility with lots of implications (particularly when running with both a class path and module path or where you bringing automatic modules into the picture). So what you are seeing is specific to the boot Layer and no specific short term plans to change this. -Alan From felix.yang at oracle.com Wed May 4 14:39:16 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 4 May 2016 22:39:16 +0800 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <57230C62.7010607@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> Message-ID: <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> Hi Alan, please review the updated webrev. Reverted changes for those tests with "-addmods". http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ Thanks, Felix On 2016/4/29 15:25, Alan Bateman wrote: > On 29/04/2016 03:16, Felix Yang wrote: >> Hi there, >> >> please review the changes to explicitly declare module >> dependencies for "java/sql/*" and "javax/*" tests; >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155088 >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.00/ > Felix - would it be disruptive to you if I asked to hold off on this > until we get the changes in jake pushed to jdk9/dev (next week). The > reason is that this we've changed most of these tests in jake to use > -addmods. We've also replaced the TEST.properties for the > javax.transaction tests so that they are run with a driver class > instead. This is also related to the policy for root modules which > impacts the tests that we have for the EE modules in the jdk repo. > > -Alan From Alan.Bateman at oracle.com Wed May 4 14:45:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 15:45:24 +0100 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> Message-ID: <572A0B04.5000502@oracle.com> On 04/05/2016 15:39, Felix Yang wrote: > Hi Alan, > > please review the updated webrev. Reverted changes for those tests > with "-addmods". > > http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ For the javax.transaction test then don't you also add "java.transaction" in the @modules value? The rest looks fine. -Alan From naoto.sato at oracle.com Wed May 4 15:12:20 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 4 May 2016 08:12:20 -0700 Subject: RFR: JDK-8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved In-Reply-To: <5729C8ED.8060206@oracle.com> References: <5729352C.80203@oracle.com> <5729C8ED.8060206@oracle.com> Message-ID: <32ba60e7-b0ad-32b2-09de-253aa8b1fa84@oracle.com> Thanks, Alan. I thought of the same for en_US w/o jdk.localedata case, and reached the same conclusion. I found one typo in my fix, where "-addmods" in plugins.properties should be "--addmods". I will correct it and push the changeset. Naoto On 5/4/16 3:03 AM, Alan Bateman wrote: > On 04/05/2016 00:33, Naoto Sato wrote: >> Hi, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8155649 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8155649/webrev.00/ > This looks okay. There is a corner case where it should be possible to > --include-locales to specify en_US and it should always succeed but I > don't think that is worth spending time on. > > -Alan > From mandy.chung at oracle.com Wed May 4 15:19:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 May 2016 08:19:16 -0700 Subject: RFR: JDK-8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved In-Reply-To: <5729C8ED.8060206@oracle.com> References: <5729352C.80203@oracle.com> <5729C8ED.8060206@oracle.com> Message-ID: <402BB375-1B90-4AF2-9844-CF0D928EDF38@oracle.com> > On May 4, 2016, at 3:03 AM, Alan Bateman wrote: > > On 04/05/2016 00:33, Naoto Sato wrote: >> Hi, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8155649 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8155649/webrev.00/ +1 > This looks okay. There is a corner case where it should be possible to --include-locales to specify en_US and it should always succeed but I don't think that is worth spending time on. I agree this not worth spending time on. The alternative is drop jdk.localedata from linking. Mandy From chris.hegarty at oracle.com Wed May 4 15:30:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 4 May 2016 16:30:38 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <5729F9DE.4080909@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> Message-ID: <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> On 4 May 2016, at 14:32, Alan Bateman wrote: > > On 04/05/2016 11:24, Chris Hegarty wrote: >> : >> The tests cause compilation of test library classes, but only some tests >> actually use the methods that provoke compilation. Similar to above, tests >> that don?t actually compile anything could depend on just java.compiler. >> >> This is all to fragile and may cause problems with future refactoring. I >> think we should add the same set of @moduels to all these tests, rather >> than an individual set determined by intimate knowledge of the inner >> workings of the test. >> >> @modules java.compiler >> jdk.compiler >> jdk.zipfs >> jdk.jartool >> >> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >> > or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. I think that would be better. -Chris. From felix.yang at oracle.com Wed May 4 15:44:01 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 4 May 2016 23:44:01 +0800 Subject: RFR 8155088, Fix module dependencies in java/sql/* and javax/* tests In-Reply-To: <572A0B04.5000502@oracle.com> References: <8a466652-c0da-1f0c-8272-d1b51bea6c73@oracle.com> <57230C62.7010607@oracle.com> <136f5ce3-e751-c062-f486-6cd18fb4809e@oracle.com> <572A0B04.5000502@oracle.com> Message-ID: <0ef38c22-33a8-8a2b-bc46-7cfaba1bb15e@oracle.com> Hi Alan, On 2016/5/4 22:45, Alan Bateman wrote: > > > On 04/05/2016 15:39, Felix Yang wrote: >> Hi Alan, >> >> please review the updated webrev. Reverted changes for those >> tests with "-addmods". >> >> http://cr.openjdk.java.net/~xiaofeya/8155088/webrev.01/ > For the javax.transaction test then don't you also add > "java.transaction" in the @modules value? The rest looks fine. I'm a bit confused here. There is "-addmods java.transaction" for @compile. Is it still necessary to declare in @modules? Actually, if add java.transaction in the @modules, the test will be skipped by jtreg. Filed https://bugs.openjdk.java.net/browse/CODETOOLS-7901671 for jtreg, because it looks to be not a good practice for either situation. -Felix > > -Alan From alexandre.iline at oracle.com Wed May 4 15:55:08 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 4 May 2016 08:55:08 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> Message-ID: <7EA704D5-9C0D-416C-89E8-FA31A4A13DD5@oracle.com> This makes sense - I will move the tests into a subduer, put the dependencies into a TEST.properties file. jdk.zipfs has the code needed for access jars - the tests are failing without that dependency. Shura > On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: > > On 4 May 2016, at 14:32, Alan Bateman wrote: >> >> On 04/05/2016 11:24, Chris Hegarty wrote: >>> : >>> The tests cause compilation of test library classes, but only some tests >>> actually use the methods that provoke compilation. Similar to above, tests >>> that don?t actually compile anything could depend on just java.compiler. >>> >>> This is all to fragile and may cause problems with future refactoring. I >>> think we should add the same set of @moduels to all these tests, rather >>> than an individual set determined by intimate knowledge of the inner >>> workings of the test. >>> >>> @modules java.compiler >>> jdk.compiler >>> jdk.zipfs >>> jdk.jartool >>> >>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>> >> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. > > I think that would be better. > > -Chris. From david.lloyd at redhat.com Wed May 4 18:33:06 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 4 May 2016 13:33:06 -0500 Subject: module-info.java just causes problems Message-ID: <572A4062.5080601@redhat.com> Tools like Maven and JUnit are yet still having a difficult time coping with the oddball module-info.java file. Can we just drop this thing and let the layer provide metadata for the module? This way of defining module metadata is clearly causing trouble. Reference: all previous arguments from non-Oracle people over the last 5 years or so. So far none of our software actually functions with Jigsaw, and the prospect is not improving. In the meantime the EG is alternately completely dead or in a state of we'll-register-your-issue-but-cannot-help-resolve-them mode. I'm highly concerned. -- - DML From pbenedict at apache.org Wed May 4 18:57:08 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 4 May 2016 13:57:08 -0500 Subject: module-info.java just causes problems In-Reply-To: <572A4062.5080601@redhat.com> References: <572A4062.5080601@redhat.com> Message-ID: It's tough to rehash issues. I don't want to re-open old discussions that go nowhere, yet, I still share David's concerns. Personally, I was very jealous :-) of the proprietary module.xml the initial jigsaw system had. I liked the XML way better and still do. Cheers, Paul On Wed, May 4, 2016 at 1:33 PM, David M. Lloyd wrote: > Tools like Maven and JUnit are yet still having a difficult time coping > with the oddball module-info.java file. Can we just drop this thing and > let the layer provide metadata for the module? This way of defining module > metadata is clearly causing trouble. Reference: all previous arguments > from non-Oracle people over the last 5 years or so. > > So far none of our software actually functions with Jigsaw, and the > prospect is not improving. In the meantime the EG is alternately > completely dead or in a state of > we'll-register-your-issue-but-cannot-help-resolve-them mode. I'm highly > concerned. > -- > - DML > From Alan.Bateman at oracle.com Wed May 4 19:46:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 20:46:53 +0100 Subject: none of our software actually functions In-Reply-To: <572A4062.5080601@redhat.com> References: <572A4062.5080601@redhat.com> Message-ID: <572A51AD.5080400@oracle.com> On 04/05/2016 19:33, David M. Lloyd wrote: > Tools like Maven and JUnit are yet still having a difficult time > coping with the oddball module-info.java file. Has been discussion on the JUnit tests about this? Aside from a few usability issues then I haven't seen any issues with JUnit, it seems to work just fine on class path or the module path as an automatic module. > : > > So far none of our software actually functions with Jigsaw, and the > prospect is not improving. Can you expand a bit on this? Is this code that runs on JDK 8 but doesn't run on JDK 9? Or maybe you mean that you or someone is migrating some libraries or a complete stack to modules? -Alan From Alan.Bateman at oracle.com Wed May 4 19:54:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 4 May 2016 20:54:24 +0100 Subject: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules In-Reply-To: References: <570FA8D9.4080807@oracle.com> Message-ID: <572A5370.8070301@oracle.com> On 03/05/2016 20:43, Alexandre (Shura) Iline wrote: > : > Alan, > > I am not sure what you are suggesting. > > Right now the test is failing without my changes, if ?-limitmods java.base? is supplied to the jtreg command line: > $ jtreg -jdk:... -noreport "-javaoptions:-limitmods java.base" java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java > with > Test failed for the following classes: ? > > Right now the test has: > * @run main/othervm -Djdk.launcher.addmods=ALL-SYSTEM FieldSetAccessibleTest UNSECURE > Changing it to > * @run main/othervm -addmods ALL-SYSTEM FieldSetAccessibleTest UNSECURE > yields the same results. > > I was thinking that the Jake integration would change something, but I see the same behavior as before. > You are right, running it with `-limitmods java.base` will limit the observability to just java.base and so`-addmods ALL-SYSTEM` is essentially a no-op because "all system" will be java.base in this case. I've looked at the changes in the webrev and they look fine, sorry for delaying you on this one. -Alan From mandy.chung at oracle.com Wed May 4 20:07:06 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 4 May 2016 13:07:06 -0700 Subject: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules In-Reply-To: References: Message-ID: <10A72473-B26C-4AFC-8C37-C041F8658367@oracle.com> > On Apr 13, 2016, at 10:29 AM, Alexandre (Shura) Iline wrote: > > Hi, > > Could you be so kind to take a look on this fix: > http://cr.openjdk.java.net/~shurailine/8154182/webrev.00/ Looks okay. Some suggestion: You only need to walk one root: root = fs.getPath("/modules?) and instead of caching the available modules, you could .filter(x -> Layer.boot().findModule(x.getName(1).toString())).isPresent() I can sponsor your patch - please send me the changeset. Mandy From david.lloyd at redhat.com Wed May 4 20:15:25 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 4 May 2016 15:15:25 -0500 Subject: none of our software actually functions In-Reply-To: <572A51AD.5080400@oracle.com> References: <572A4062.5080601@redhat.com> <572A51AD.5080400@oracle.com> Message-ID: <572A585D.8090206@redhat.com> On 05/04/2016 02:46 PM, Alan Bateman wrote: > > On 04/05/2016 19:33, David M. Lloyd wrote: >> Tools like Maven and JUnit are yet still having a difficult time >> coping with the oddball module-info.java file. > Has been discussion on the JUnit tests about this? Aside from a few > usability issues then I haven't seen any issues with JUnit, it seems to > work just fine on class path or the module path as an automatic module. Integration with Maven is the real problem in this case, I guess. >> So far none of our software actually functions with Jigsaw, and the >> prospect is not improving. > Can you expand a bit on this? Is this code that runs on JDK 8 but > doesn't run on JDK 9? Or maybe you mean that you or someone is migrating > some libraries or a complete stack to modules? Mainly I'm referring to the unresolved issues at http://openjdk.java.net/projects/jigsaw/spec/issues/. As yet I see no evidence of activity from Mark nor anyone in the Jigsaw development on any of these issues - no discussion, no response to discussion, nothing. Not even rejection, just radio silence. To be specific we need resolution to at least #ModuleNameCharacters, #CyclicDependences, #LazyConfigurationAndInstantiation, #MutableConfigurations, #ClassFilesAsResources, #VersionSyntax, and #NonHierarchicalLayers for sure, in order for our system to interoperate with Jigsaw (as opposed to trying to pretend it doesn't exist and won't come back and bite us for Java EE 9). I think I can squeak out some simple changes that disable version and module name syntax validation for the simpler two, maybe even moving the existing rules in to the system layer, but the rest require some real design thinking and discussion, and I don't think I will have access to the resources needed to contribute fixes to these without help from the Jigsaw team. With the various SE 9 deadlines looming large, how realistic is it to expect that even some of these issues will ultimately be resolved? -- - DML From Alan.Bateman at oracle.com Thu May 5 09:26:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 10:26:10 +0100 Subject: none of our software actually functions In-Reply-To: <572A585D.8090206@redhat.com> References: <572A4062.5080601@redhat.com> <572A51AD.5080400@oracle.com> <572A585D.8090206@redhat.com> Message-ID: <572B11B2.2070000@oracle.com> On 04/05/2016 21:15, David M. Lloyd wrote: > > Integration with Maven is the real problem in this case, I guess. Herv? Boutemy and Arnaud H?rtier gave an update at Devoxx FR a few weeks ago: https://speakerdeck.com/aheritier/fr-apache-maven-java-9-et-le-projet-jigsaw-at-devoxx-france-2016 There's a reference to a wiki page too: https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw As we've always said, retrofitting modules to the Java Language and platform is a huge undertaking and requires the tools and eco system to work with us to make this happen. Members of the Maven community have been engaged with JDK 9 for a long tie and we'll do what we can here to help with the effort to upgrade Maven and its plugins to support the development and testing of modules. > : > > To be specific we need resolution to at least #ModuleNameCharacters, > #CyclicDependences, #LazyConfigurationAndInstantiation, > #MutableConfigurations, #ClassFilesAsResources, #VersionSyntax, and > #NonHierarchicalLayers for sure, in order for our system to > interoperate with Jigsaw (as opposed to trying to pretend it doesn't > exist and won't come back and bite us for Java EE 9). I think I can > squeak out some simple changes that disable version and module name > syntax validation for the simpler two, maybe even moving the existing > rules in to the system layer, but the rest require some real design > thinking and discussion, and I don't think I will have access to the > resources needed to contribute fixes to these without help from the > Jigsaw team. I'm sure Mark will bring proposals or closure (with justification) to these issues in due course. > > With the various SE 9 deadlines looming large, how realistic is it to > expect that even some of these issues will ultimately be resolved? The date that is approaching is the JDK 9 Feature Complete (FC) date. We have "the feature" in JDK 9 since jdk-9+111 with a refresh in jdk9/dev for jdk-9+118. There will be further iteration, tinkering and updates. Some parts of the implementation have replacement/improvements coming, the API needs improvements in a few areas, and I'm sure there will be changes to support some of the issues on the JSR list. In past releases then features with a JSR continued to iterate a bit after FC, I expect the same here. Furthermore, with there will be feedback and usages with other features that will require re-work or changes after FC, that is normal and healthy. The next milestone is ramp down starting Sep 1. I expect we will be in significant better shape by then. -Alan From michael.rasmussen at zeroturnaround.com Thu May 5 14:56:10 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 5 May 2016 17:56:10 +0300 Subject: NPE in InstrumentationImpl.transform() Message-ID: Hi Loading classes from the unnamed boot module (for instance an agent) causes: *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at JPLISAgent.c line: 884 Due to trying to dereference the null-loader in sun.instrument.InstrumentationImpl:439 module = loader.getUnnamedModule(); simple example: package pkg; public class Agent { public static void premain(String args, Instrumentation ins) { new Object() {}; } } and then in manifest have: Premain-Class: pkg.Agent Boot-Class-Path: agent.jar Regards /Michael From Alan.Bateman at oracle.com Thu May 5 15:06:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 16:06:50 +0100 Subject: NPE in InstrumentationImpl.transform() In-Reply-To: References: Message-ID: <572B618A.7020207@oracle.com> On 05/05/2016 15:56, Michael Rasmussen wrote: > Hi > > Loading classes from the unnamed boot module (for instance an agent) causes: > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" > with message transform method call failed at JPLISAgent.c line: 884 > > Due to trying to dereference the null-loader in > sun.instrument.InstrumentationImpl:439 > module = loader.getUnnamedModule(); Thanks for the bug report, this is regression in JDK 9. I suspect we don't have tests that exercise this with classes added to the boot loader with -Xbootclasspath/a. I've created JDK-8156147 [1] to track it. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8156147 From adinn at redhat.com Thu May 5 15:19:59 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 5 May 2016 16:19:59 +0100 Subject: NPE in InstrumentationImpl.transform() In-Reply-To: <572B618A.7020207@oracle.com> References: <572B618A.7020207@oracle.com> Message-ID: <572B649F.1030909@redhat.com> On 05/05/16 16:06, Alan Bateman wrote: >> Loading classes from the unnamed boot module (for instance an agent) >> causes: >> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" >> with message transform method call failed at JPLISAgent.c line: 884 >> >> Due to trying to dereference the null-loader in >> sun.instrument.InstrumentationImpl:439 >> module = loader.getUnnamedModule(); > Thanks for the bug report, this is regression in JDK 9. I suspect we > don't have tests that exercise this with classes added to the boot > loader with -Xbootclasspath/a. I've created JDK-8156147 [1] to track it. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-8156147 Ah, pre-empted! I was just about to report that I see this with Byteman when I hoist the Byteman classes into the bootstrap and don't see it when I leave them in the system classpath. I will be happy to validate any fix. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From konstantin.barzilovich at oracle.com Thu May 5 15:21:20 2016 From: konstantin.barzilovich at oracle.com (Konstantin Barzilovich) Date: Thu, 05 May 2016 18:21:20 +0300 Subject: Modules with packages duplication In-Reply-To: <572A013A.7060806@oracle.com> References: <572A013A.7060806@oracle.com> Message-ID: Hello Alan, Thank you for the answer. I have one more question connected with duplication of packages. Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them. But in case of these two modules are readable by third module, in runtime it will result in error of boot Layer, as you said. Is it okey, that compiler allow us to compile code, that will cause runtime failure? Here is minimal test case: ------------------------------ module1/module-info.java module module1 { exports pack; } module1/pack/A.java: package pack; public class A{} module2/module-info.java module module2 { } module2/pack/A.java: package pack; public class A{} module3/module-info.java: module module3{ requires module1; requires module2; } Thanks, Konstantin. > > On 04/05/2016 14:18, Konstantin Barzilovich wrote: >> Hello, >> >> I can see that RI checks if there are packages with the same names in >> different modules (named or unnamed). >> This check fails even if there is no clash (no module can read both >> packages). >> Will it be the same in final version of JDK9 or it can be changed soon? >> > I think you are asking about modules on the application module path > (`java -modulepath ...`) that are resolved at startup. These are defined > to the application class loader so they cannot have overlapping > packages. It's trivial to do things like map each module in its own > class loader but that messes with visibility with lots of implications > (particularly when running with both a class path and module path or > where you bringing automatic modules into the picture). So what you are > seeing is specific to the boot Layer and no specific short term plans to > change this. > > -Alan From adinn at redhat.com Thu May 5 16:31:55 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 5 May 2016 17:31:55 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <5718D656.4010805@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> Message-ID: <572B757B.6070801@redhat.com> Hi Alan, I'm finally replying to your previous post and also reporting news of the solution I have currently investigated to retain existing Byteman agent capabilities (I have a working implementation and am interested to see how high it causes your eyebrows to rise :-). > If the instrumentation is just injecting code to call into Byteman then > I assume it just works now. That is, it doesn't appear that Byteman has > embraced modules yet and so I assume it must be an agent specified via > -javaagent with perhaps supporting code in other JAR files. In that > case, the Byteman code is the unnamed module of the app class loader and > the VM will automatically add a read edge when the transformer touches > code in any named module. This is the compatibility support that I > mentioned in another mail. All the Byteman code which matters is in a single jar loaded using -javaagent (or the VM_Attach API for dynamic load). The Main class (implementing premain/agentmain) is completely isolated from the rest of the code (i.e. no link references -- it loads by name and executes by reflection). That isolation is necessary in order to be able to inject into JDK runtime classes. Main is loaded by the system classloader. However, Main.premain/agentmain will 'hoist' the jar into the bootstrap path on request, ensuring that the rest of the agent jar contents are loaded by the bootstrap loader. In particular this means JDK classes can reference the 3 Byteman exception types and 1 static method that appear in injected code. n.b. I have zero desire to make Byteman (Jigsaw-)modular. That would definitely require a dual source implementation (since I need to keep it working on JDK6+). > If you right this it should be simple as you say. On the other hand, > some of the mails mention accessing non-public members, setAccessible, > and even (it would appear) adjusting class loader delegation on the fly > to facilitate the patches. Byteman is mostly used for i) unit, integration and system tests ii) monitoring/debugging apps -- normally (but not always :-) in a sandbox In the former case, breaking the app (injection of code which generates a fault scenario) or validating execution (injecting code which asserts invariants) is often only only feasible if injected code can access non-public APIs and/or data. In any significant size app the stuff you need to check/call at test time is almost always stuff you also want to hide behind an encapsulation barrier at runtime. In the latter case identifying what is broken when trouble-shooting a problem generally requires the same license. If you are lucky your error might affect public code/data but you'd be very lucky. So, if Jigsaw were able to remove the existing opportunity for an agent to access non-public code/data then that would seriously limit the usefulness of Byteman -- almost to the point of making it useless. Test code can often get by in cases where there is public access to data (modulo getting a handle on the relevant objects). It's precisely the private stuff that cannot easily be tested. The reason I use setAccessible in the current implementation is that it is the only way for injected code to access private data, methods and constructors. Field, Method and Constructor instances are used by the interpreter (which executes reflectively) and also as a backdoor to perform such accesses when Byteman translates injected code to bytecode. I am not (yet) interested in the issue of injecting into non-public app classes/methods embedded in Modules nor am I (yet) interested in allowing injected code to access non-public data/methods of such app classes. That's not really an important problem for me (yet) because no such code exists. When I need to address this issue I hope to resolve any problems by extending the existing module IMPORT syntax which is used to notify Byteman that injected code needs access to classes (& their methods/data) deployed in JBoss Modules. My current concern is for injected code to retain the ability to access non-public fields of classes residing in JDK modules, in particular java.base but also the other modules into which the JDK code base has been partitioned. This currently works on JDK8- and a lot of projects are relying on it continuing to work in order to be able to test their code. Luckily, java.base exports to any module and also exports many of the packages which users tend to inject into (e.g. java.lang.Thread, java.io.FileInputStream, etc). So ,the checks performed by method AccessibleObject.checkCanSetAccessible(Class,Class()) tend to vote yes for most attempts to execute setAccessible i.e. the legacy problem is not as pressing as it appears at first glance. However, there will still be cases where existing Byteman usage will fail on JDK9. I looked at several ways of making this work and decided the best thing was to have the agent redefine AccessibleObject.checkCanSetAccessible so that it grants Byteman code (specifically one Byteman class called Rule) free reign when it calls this method. This still retains security manager checks made around this call. Choosing this method targets the code which does module access checks. Basically I transformed this method so that it looks like this public boolean checkCanSetAccessible(Class caller, Class declaringClass) { // injected code if ("org.jboss.byteman.rule.Rule".equals(caller.getName()) { if (caller.getClassLoader == Classloader.getSystemCalssLoader()) return true } } // original code Module callerModule = caller.getModule(); Module declaringModule = declaringClass.getModule(); . . . n.b. when the agent code is loaded in the bootstrap the 2nd if compares against null rather than the system loader. Either way the name+loader check ensures that it is not possible to spoof calls from any old app class called Rule. When this code is injected the oonly caller class which will pass this initial test is Byteman's Rule class. So, with that in place whenever the agent needs to grant access to a Field/Method I ensure it calls calls method Rule.grantAccess(AccessibleObject) which is only accessible from code provided by the agent. The resulting accessible is private to agent Rule instances and can only be accessed by the interpreter or by generated bytecode when executing injected code. So, there is no danger of leaking these access objects. The nice thing is that I can do all this using only JDK6 compatible code with no need for it to know about anything Jigsaw-related other than whether class java.lang.reflect Module exists (thanks, Peter :-). Now, I know setting an arbitrary Member accessible looks a tad dangerous from the point of view that it might foil expectations of the JDK runtime or JVM (from the point of view of app this is the users responsibilty -- they ask for it they get it). However, I looked at the rest of the code in method checkCanSetAccessible and noted that any caller in the java.base module is allowed to set any Member to be accessible. So, I adopted the working hypothesis that for now, at least, making this method say 'yes' is not going to break anything that could not already potentially be broken -- in particular it's not going to foil the expectations of the JIT (yet? :-). So, I'd be very interested to know how horrified you are to hear about what I am doing and whether you have any caveats to throw my way :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From michael.rasmussen at zeroturnaround.com Thu May 5 17:38:39 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 5 May 2016 20:38:39 +0300 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572B757B.6070801@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> Message-ID: While waiting for some proper way of doing this, in my current prototype for supporting jigsaw I'm simply injecting a class into the java.lang.reflect package that can call setAccessible0, in order to circumvent these checks. Probably not what was envisioned either :) /Michael From michael.rasmussen at zeroturnaround.com Thu May 5 17:44:37 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 5 May 2016 20:44:37 +0300 Subject: Modules with packages duplication In-Reply-To: <572A013A.7060806@oracle.com> References: <572A013A.7060806@oracle.com> Message-ID: If the no split package rule is only applicable to boot layer, how will the instrumentation API provide the correct module for other layers, as currently that is implemented by mapping package to module ? /Michael From alexandre.iline at oracle.com Thu May 5 18:42:26 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 5 May 2016 11:42:26 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> Message-ID: <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Chris, could you please take another look: http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/ What I have discovered is that jdk.zipfs was used to access jars on the classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the class path through the environment removed dependency on the zipfs. Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. Thank you. Shura > On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: > > On 4 May 2016, at 14:32, Alan Bateman wrote: >> >> On 04/05/2016 11:24, Chris Hegarty wrote: >>> : >>> The tests cause compilation of test library classes, but only some tests >>> actually use the methods that provoke compilation. Similar to above, tests >>> that don?t actually compile anything could depend on just java.compiler. >>> >>> This is all to fragile and may cause problems with future refactoring. I >>> think we should add the same set of @moduels to all these tests, rather >>> than an individual set determined by intimate knowledge of the inner >>> workings of the test. >>> >>> @modules java.compiler >>> jdk.compiler >>> jdk.zipfs >>> jdk.jartool >>> >>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>> >> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. > > I think that would be better. > > -Chris. From alexandre.iline at oracle.com Thu May 5 19:01:57 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 5 May 2016 12:01:57 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Message-ID: > On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline wrote: > Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. I take this ^^^^^^ back, as the error was there all along: "java.nio.file.ProviderNotFoundException: no provider found for .jar files? The fix is valid, then, is and waiting for a review. Shura > > Thank you. > > Shura > >> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: >> >> On 4 May 2016, at 14:32, Alan Bateman wrote: >>> >>> On 04/05/2016 11:24, Chris Hegarty wrote: >>>> : >>>> The tests cause compilation of test library classes, but only some tests >>>> actually use the methods that provoke compilation. Similar to above, tests >>>> that don?t actually compile anything could depend on just java.compiler. >>>> >>>> This is all to fragile and may cause problems with future refactoring. I >>>> think we should add the same set of @moduels to all these tests, rather >>>> than an individual set determined by intimate knowledge of the inner >>>> workings of the test. >>>> >>>> @modules java.compiler >>>> jdk.compiler >>>> jdk.zipfs >>>> jdk.jartool >>>> >>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>>> >>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. >> >> I think that would be better. >> >> -Chris. > From jonathan.gibbons at oracle.com Thu May 5 19:12:52 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 05 May 2016 12:12:52 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Message-ID: <572B9B34.8070406@oracle.com> There is potentially a separate discussion here, as to whether javac should "force" the provision of a jar-fs provider. Strictly speaking, javac does not inherently require it. You can use javac just fine, with files in the system image, and source and class files in the default file system. But I suspect most folk would be suprised if they ca across an image for which javac could not read jar files. -- Jon On 05/05/2016 12:01 PM, Alexandre (Shura) Iline wrote: >> On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline wrote: >> Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. > I take this ^^^^^^ back, as the error was there all along: "java.nio.file.ProviderNotFoundException: no provider found for .jar files? > > The fix is valid, then, is and waiting for a review. > > Shura > >> Thank you. >> >> Shura >> >>> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: >>> >>> On 4 May 2016, at 14:32, Alan Bateman wrote: >>>> On 04/05/2016 11:24, Chris Hegarty wrote: >>>>> : >>>>> The tests cause compilation of test library classes, but only some tests >>>>> actually use the methods that provoke compilation. Similar to above, tests >>>>> that don?t actually compile anything could depend on just java.compiler. >>>>> >>>>> This is all to fragile and may cause problems with future refactoring. I >>>>> think we should add the same set of @moduels to all these tests, rather >>>>> than an individual set determined by intimate knowledge of the inner >>>>> workings of the test. >>>>> >>>>> @modules java.compiler >>>>> jdk.compiler >>>>> jdk.zipfs >>>>> jdk.jartool >>>>> >>>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>>>> >>>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. >>> I think that would be better. >>> >>> -Chris. From Alan.Bateman at oracle.com Thu May 5 19:50:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 20:50:47 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572B757B.6070801@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> Message-ID: <572BA417.3060700@oracle.com> On 05/05/2016 17:31, Andrew Dinn wrote: > : > > I looked at several ways of making this work and decided the best thing > was to have the agent redefine AccessibleObject.checkCanSetAccessible so > that it grants Byteman code (specifically one Byteman class called Rule) > free reign when it calls this method. This still retains security > manager checks made around this call. Choosing this method targets the > code which does module access checks. > This is very fragile because checkCanSetAccessible is not part of the API and may go away or change at any time. Have you looked at injecting code in the victim module that invokes Module addExports to export the packages to the Byteman modules (modules plural because it sounds like the code is split between the unnamed module of the app class loader and the unnamed modulie of the boot loader). -Alan From alexandre.iline at oracle.com Thu May 5 20:09:34 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Thu, 5 May 2016 13:09:34 -0700 Subject: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules In-Reply-To: <10A72473-B26C-4AFC-8C37-C041F8658367@oracle.com> References: <10A72473-B26C-4AFC-8C37-C041F8658367@oracle.com> Message-ID: <2281C3AE-1ED9-4448-8400-ECF16888B36D@oracle.com> http://cr.openjdk.java.net/~shurailine/8154182/webrev.01/ I was storing the module list in a collection before to get the things more ?effective?. It did not make it more effective, you are right about that. Thanks for the tip on ?/modules?. Please take a look. Shura > On May 4, 2016, at 1:07 PM, Mandy Chung wrote: > > >> On Apr 13, 2016, at 10:29 AM, Alexandre (Shura) Iline wrote: >> >> Hi, >> >> Could you be so kind to take a look on this fix: >> http://cr.openjdk.java.net/~shurailine/8154182/webrev.00/ > > Looks okay. Some suggestion: > > You only need to walk one root: > root = fs.getPath("/modules?) > > and instead of caching the available modules, you could > .filter(x -> Layer.boot().findModule(x.getName(1).toString())).isPresent() > > I can sponsor your patch - please send me the changeset. > > Mandy From Alan.Bateman at oracle.com Thu May 5 20:16:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 5 May 2016 21:16:36 +0100 Subject: Modules with packages duplication In-Reply-To: References: <572A013A.7060806@oracle.com> Message-ID: <572BAA24.9010405@oracle.com> On 05/05/2016 18:44, Michael Rasmussen wrote: > > If the no split package rule is only applicable to boot layer, how > will the instrumentation API provide the correct module for other > layers, as currently that is implemented by mapping package to module ? > I'm not sure that I get the question. I think you might be asking about classes loaded into modules that are in Layers but I don't know if the context is java.lang.instrument or JVM TI. If this is java.lang.instrument then ClassFileTransformer transform method is called with the Module. The underlying mapping is loader + package => module, not package => module. We need more tests in this area but I don't expect any issues. If this is JVM TI then the CFLH doesn't have the Module, we're still mulling over whether to expose a JVM TI function (see JDK-8155207). We have the underlying support in place, it's just not exposed in JVM TI. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8155207 From mandy.chung at oracle.com Thu May 5 20:45:38 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 13:45:38 -0700 Subject: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules In-Reply-To: <2281C3AE-1ED9-4448-8400-ECF16888B36D@oracle.com> References: <10A72473-B26C-4AFC-8C37-C041F8658367@oracle.com> <2281C3AE-1ED9-4448-8400-ECF16888B36D@oracle.com> Message-ID: Looks fine. Mandy > On May 5, 2016, at 1:09 PM, Alexandre (Shura) Iline wrote: > > http://cr.openjdk.java.net/~shurailine/8154182/webrev.01/ > > I was storing the module list in a collection before to get the things more ?effective?. It did not make it more effective, you are right about that. > > Thanks for the tip on ?/modules?. > > Please take a look. > > Shura > >> On May 4, 2016, at 1:07 PM, Mandy Chung wrote: >> >> >>> On Apr 13, 2016, at 10:29 AM, Alexandre (Shura) Iline wrote: >>> >>> Hi, >>> >>> Could you be so kind to take a look on this fix: >>> http://cr.openjdk.java.net/~shurailine/8154182/webrev.00/ >> >> Looks okay. Some suggestion: >> >> You only need to walk one root: >> root = fs.getPath("/modules?) >> >> and instead of caching the available modules, you could >> .filter(x -> Layer.boot().findModule(x.getName(1).toString())).isPresent() >> >> I can sponsor your patch - please send me the changeset. >> >> Mandy > From michael.rasmussen at zeroturnaround.com Thu May 5 20:49:29 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Thu, 5 May 2016 23:49:29 +0300 Subject: Modules with packages duplication In-Reply-To: <572BAA24.9010405@oracle.com> References: <572A013A.7060806@oracle.com> <572BAA24.9010405@oracle.com> Message-ID: > I'm not sure that I get the question. I think you might be asking about > classes loaded into modules that are in Layers but I don't know if the > context is java.lang.instrument or JVM TI. Sorry, I could have been more specific, and I might have misunderstood what you were saying. I was referring to your: "So what you are seeing is specific to the boot Layer and no specific short term plans to change this." Am I understanding it correctly, that only the boot layer has the limitation that packages cannot be split between multiple modules? If that is the case, what if in another layer, comprised of a single classloader, I have a package split between multiple modules, how will the current Instrumentation implementation work, since as you mention, it maps loader+package to Module, which in that case won't be a 1-to-1 mapping (as implemented in JVM_GetModuleByPackageName from JDK-8147465) > If this is JVM TI then the CFLH doesn't have the Module, we're still mulling > over whether to expose a JVM TI function (see JDK-8155207). We have the > underlying support in place, it's just not exposed in JVM TI. Yeah, that would be greatly appreciated -- at the moment I'm calling JVM_GetModuleByPackageName in my CFLH function, but would prefer a more supported way. /Michael From mandy.chung at oracle.com Thu May 5 21:21:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 5 May 2016 14:21:42 -0700 Subject: RFR 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules In-Reply-To: <2281C3AE-1ED9-4448-8400-ECF16888B36D@oracle.com> References: <10A72473-B26C-4AFC-8C37-C041F8658367@oracle.com> <2281C3AE-1ED9-4448-8400-ECF16888B36D@oracle.com> Message-ID: <7642F899-AEFA-48DD-9A5D-106D26356F59@oracle.com> > On May 5, 2016, at 1:09 PM, Alexandre (Shura) Iline wrote: > > http://cr.openjdk.java.net/~shurailine/8154182/webrev.01/ Pushed. I took the liberty to take out the extra-whitespace and rename the variable from x to p. Mandy From peter.levart at gmail.com Thu May 5 22:26:56 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 6 May 2016 00:26:56 +0200 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572BA417.3060700@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> Message-ID: <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> On 05/05/2016 09:50 PM, Alan Bateman wrote: > > On 05/05/2016 17:31, Andrew Dinn wrote: >> : >> >> I looked at several ways of making this work and decided the best thing >> was to have the agent redefine AccessibleObject.checkCanSetAccessible so >> that it grants Byteman code (specifically one Byteman class called Rule) >> free reign when it calls this method. This still retains security >> manager checks made around this call. Choosing this method targets the >> code which does module access checks. >> > This is very fragile because checkCanSetAccessible is not part of the > API and may go away or change at any time. > > Have you looked at injecting code in the victim module that invokes > Module addExports to export the packages to the Byteman modules > (modules plural because it sounds like the code is split between the > unnamed module of the app class loader and the unnamed modulie of the > boot loader). > > -Alan What about adding an all-powers addModuleExports(module, pn, other) method to java.lang.instrument.Instrumentation (like it was done with addModuleReads) to simplify the agent's task? An agent could be considered trusted code, couldn't it? Regards, Peter From Alan.Bateman at oracle.com Fri May 6 06:29:10 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 07:29:10 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> Message-ID: <572C39B6.7000409@oracle.com> On 05/05/2016 23:26, Peter Levart wrote: > > What about adding an all-powers addModuleExports(module, pn, other) > method to java.lang.instrument.Instrumentation (like it was done with > addModuleReads) to simplify the agent's task? An agent could be > considered trusted code, couldn't it? It was looked into but has the potential to break encapsulation in arbitrary ways. I think we have to see how far we can get with injecting code into the target module to export the packages to the agent or other module that the agent is arranging to access the internals. -Alan From Alan.Bateman at oracle.com Fri May 6 06:31:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 07:31:46 +0100 Subject: Modules with packages duplication In-Reply-To: References: <572A013A.7060806@oracle.com> <572BAA24.9010405@oracle.com> Message-ID: <572C3A52.6020902@oracle.com> On 05/05/2016 21:49, Michael Rasmussen wrote: >> : >> >> If that is the case, what if in another layer, comprised of a single >> classloader, I have a package split between multiple modules, how will >> the current Instrumentation implementation work, since as you mention, >> it maps loader+package to Module, which in that case won't be a 1-to-1 >> mapping (as implemented in JVM_GetModuleByPackageName from >> JDK-8147465) >> If all modules in the layer are defined to the same class loader then there can't be any overlapping packages. So I don't think there is an issue here. -Alan From peter.levart at gmail.com Fri May 6 07:32:21 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 6 May 2016 09:32:21 +0200 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C39B6.7000409@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> Message-ID: <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> On 05/06/2016 08:29 AM, Alan Bateman wrote: > On 05/05/2016 23:26, Peter Levart wrote: >> >> What about adding an all-powers addModuleExports(module, pn, other) >> method to java.lang.instrument.Instrumentation (like it was done with >> addModuleReads) to simplify the agent's task? An agent could be >> considered trusted code, couldn't it? > It was looked into but has the potential to break encapsulation in > arbitrary ways. I think we have to see how far we can get with > injecting code into the target module to export the packages to the > agent or other module that the agent is arranging to access the internals. > > -Alan The easiest thing for agent to do then is to observe class loading and when 1st class of a particular module located in an exported package is about to be loaded, instruments it and adds a static method to it - a trampoline that invokes Module.addExports(pn, other). The added method can then be invoked via reflection. But what if agent needs to augment exports of some module before the 1st exported class of the module comes around? Suppose that classes in concealed packages are loaded 1st and that they already start executing code in them before the 1st exported class is loaded. Agent would have to piggy-back the exports augmentation code on the instrumented methods themselves to ensure exports are added soon enough. What if instrumentation has the goal to introduce as little overhead as possible? Adding redundant Module.addExports() invocations all over the place on hot paths would not help to achieve that goal. I think that not giving the agent such API just makes life for agent writers harder but does not prevent them to break encapsulation in arbitrary ways anyway. Regards, Peter From adinn at redhat.com Fri May 6 07:46:51 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 08:46:51 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> Message-ID: <572C4BEB.5060907@redhat.com> On 05/05/16 18:38, Michael Rasmussen wrote: > While waiting for some proper way of doing this, in my current prototype > for supporting jigsaw I'm simply injecting a class into the > java.lang.reflect package that can call setAccessible0, in order to > circumvent these checks. > Probably not what was envisioned either :) Hmm, I considered that but had not investigated modules in enough detail to determine how to do it. So, I took the easy route and knobbled the access check code. Is your code open source? More importantly, is its license compatible with the LGPL license used by Byteman? If so then can I take a peek? (and maybe steal it :-) regards, Andrew Dinn ----------- From adinn at redhat.com Fri May 6 07:57:06 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 08:57:06 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> Message-ID: <572C4E52.7000906@redhat.com> On 05/05/16 23:26, Peter Levart wrote: > What about adding an all-powers addModuleExports(module, pn, other) > method to java.lang.instrument.Instrumentation (like it was done with > addModuleReads) to simplify the agent's task? An agent could be > considered trusted code, couldn't it? Well, that was actually something I also thought of and it is a /very/ neat solution. Indeed the thought behind your rhetorical question is what motivated me to raise #ReflectiveAccessByInstrumentationAgents as a missing requirement. An agent really should be considered trusted code, shouldn't it. Much as I think this would be the best general solution it doesn't quite work for me, for practical rather than technical reasons. The downside of using an API extension is that it requires compiling the agent as JDK9 code. I need my agent to run on 1.6+ and currently build it using target 1.6. I could finesse this issue by releasing both a JDK8- agent and a JDK9+ agent. That path is unattractive because it requires me to maintain dual source & product. That requires users to reconfigure their build and runtime paths when they switch between JDK8 and JDK9. This doesn't sound like much but you would be astonished how many users fail at configuring this sort of thing (no, /really/). Anyway, if it came to a beauty contest I'd definitely vote for extending Instrumentation with yet another God-like power i.e. its own setAccessible API without any module checks. Of course, I'd prefer that we adopt this on its merits rather than by resort to mob rule^H^H^H^H democracy. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri May 6 07:59:59 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 08:59:59 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> Message-ID: <572C4EFF.9070405@oracle.com> On 06/05/2016 08:32, Peter Levart wrote: > : > > The easiest thing for agent to do then is to observe class loading and > when 1st class of a particular module located in an exported package > is about to be loaded, instruments it and adds a static method to it - > a trampoline that invokes Module.addExports(pn, other). The added > method can then be invoked via reflection. > > But what if agent needs to augment exports of some module before the > 1st exported class of the module comes around? Suppose that classes in > concealed packages are loaded 1st and that they already start > executing code in them before the 1st exported class is loaded. Agent > would have to piggy-back the exports augmentation code on the > instrumented methods themselves to ensure exports are added soon > enough. What if instrumentation has the goal to introduce as little > overhead as possible? Adding redundant Module.addExports() invocations > all over the place on hot paths would not help to achieve that goal. > > I think that not giving the agent such API just makes life for agent > writers harder but does not prevent them to break encapsulation in > arbitrary ways anyway. We've been over this a few times, it's on the issues list, but we want to see how far we can get without adding this method. On injecting helpers then if the agent can inject an initializer + helper method into any public class in the module then it has full control. It doesn't matter if it's a concealed package because the initializer (which the agent can trigger to execute without access) just needs to export the package to the agent. -Alan From adinn at redhat.com Fri May 6 08:07:21 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 09:07:21 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572BA417.3060700@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> Message-ID: <572C50B9.9010806@redhat.com> On 05/05/16 20:50, Alan Bateman wrote: > > On 05/05/2016 17:31, Andrew Dinn wrote: >> : >> >> I looked at several ways of making this work and decided the best thing >> was to have the agent redefine AccessibleObject.checkCanSetAccessible so >> that it grants Byteman code (specifically one Byteman class called Rule) >> free reign when it calls this method. This still retains security >> manager checks made around this call. Choosing this method targets the >> code which does module access checks. >> > This is very fragile because checkCanSetAccessible is not part of the > API and may go away or change at any time. Yes, that is true. I was assuming that once baked into JDK9 this was very unlikely to change if it did I could upgrade Byteman to implement another such hack However, I think you are right that what I need to do is implement something that depends on a guaranteed property e.g. inject a class which makes the call into the module of java.lang.Object (java .base). I'll still need to make sure it can only be called from my Rule class so I can guarantee that it does not leak access. > Have you looked at injecting code in the victim module that invokes > Module addExports to export the packages to the Byteman modules (modules > plural because it sounds like the code is split between the unnamed > module of the app class loader and the unnamed modulie of the boot loader). Not yet but I will do. n.b. for all practical purposes there is only one Byteman module although which one it is depends upon whether the agent jar is hoisted into the bootstrap or remains in the system loader. In the former case the code is split but only in that the Main class gets left in the system loader while all others sit in bootstrap. Since Main merely acts as a trampoline it does not require any special module linkage. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri May 6 08:10:52 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 09:10:52 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C39B6.7000409@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> Message-ID: <572C518C.6090800@redhat.com> On 06/05/16 07:29, Alan Bateman wrote: > On 05/05/2016 23:26, Peter Levart wrote: >> What about adding an all-powers addModuleExports(module, pn, other) >> method to java.lang.instrument.Instrumentation (like it was done with >> addModuleReads) to simplify the agent's task? An agent could be >> considered trusted code, couldn't it? > It was looked into but has the potential to break encapsulation in > arbitrary ways. I think we have to see how far we can get with injecting > code into the target module to export the packages to the agent or other > module that the agent is arranging to access the internals. Well, actually, I am deliberately trying to break encapsulation in arbitrary ways :-) although it is not really quite that arbitrary. I am only doing so for very strictly limited purposes (testing, monitoring/debugging) and only so as to grant access to 'trusted' code. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri May 6 08:16:33 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 09:16:33 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C4EFF.9070405@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> <572C4EFF.9070405@oracle.com> Message-ID: <572C52E1.4070203@redhat.com> On 06/05/16 08:59, Alan Bateman wrote: > On 06/05/2016 08:32, Peter Levart wrote: >> I think that not giving the agent such API just makes life for agent >> writers harder but does not prevent them to break encapsulation in >> arbitrary ways anyway. > > We've been over this a few times, it's on the issues list, but we want > to see how far we can get without adding this method. Ok, I'll be that guinea pig. > On injecting helpers then if the agent can inject an initializer + > helper method into any public class in the module then it has full > control. It doesn't matter if it's a concealed package because the > initializer (which the agent can trigger to execute without access) just > needs to export the package to the agent. Yes, that's probably the best way to restrict access if you assume the agent is itself in a Jigsaw module. But I doubt all (or even most?) agents will want to use Jigsaw. They certainly won't if they want to implement functionality that is useful to pre- and post-JDK9 runtimes since that will force the devs down the path of dual-source and dual-produuct. That is a very unattractive proposition since it complicates both development and deployment. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From michael.rasmussen at zeroturnaround.com Fri May 6 08:18:45 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Fri, 6 May 2016 11:18:45 +0300 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C4BEB.5060907@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572C4BEB.5060907@redhat.com> Message-ID: > Is your code open source? More importantly, is its license compatible > with the LGPL license used by Byteman? If so then can I take a peek? > (and maybe steal it :-) Nothing fancy about it, just a simple class generated via ASM and then defined using unsafe Here's a simple main class with it (changed to access override field instead, to be compatible with JDK8 as well) https://gist.github.com/anonymous/7dacfe87fa9517c7c82d4e910d6f7300 Feel free to use it as you see fit, consider the above MIT, BSD, public domain, or what ever you feel comfortable with :) /Michael From adinn at redhat.com Fri May 6 08:23:48 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 09:23:48 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572C4BEB.5060907@redhat.com> Message-ID: <572C5494.1090506@redhat.com> On 06/05/16 09:18, Michael Rasmussen wrote: >> Is your code open source? More importantly, is its license compatible >> with the LGPL license used by Byteman? If so then can I take a peek? >> (and maybe steal it :-) > > Nothing fancy about it, just a simple class generated via ASM and then > defined using unsafe > > Here's a simple main class with it (changed to access override field > instead, to be compatible with JDK8 as well) > https://gist.github.com/anonymous/7dacfe87fa9517c7c82d4e910d6f7300 > > Feel free to use it as you see fit, consider the above MIT, BSD, > public domain, or what ever you feel comfortable with :) Thanks very much for offering me this code but before I can look at it I actually need explicit confirmation that I am able to release it under LGPL (sorry to be fussy but I don't want any legal issues to cause my employer a problem). If you could acknowledge that permission then I'll be able to click on the link. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From michael.rasmussen at zeroturnaround.com Fri May 6 08:28:27 2016 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Fri, 6 May 2016 11:28:27 +0300 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C5494.1090506@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572C4BEB.5060907@redhat.com> <572C5494.1090506@redhat.com> Message-ID: > Thanks very much for offering me this code but before I can look at it I > actually need explicit confirmation that I am able to release it under > LGPL (sorry to be fussy but I don't want any legal issues to cause my > employer a problem). If you could acknowledge that permission then I'll > be able to click on the link. Permission granted. /Michael From Alan.Bateman at oracle.com Fri May 6 08:37:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 09:37:53 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C52E1.4070203@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> <572C4EFF.9070405@oracle.com> <572C52E1.4070203@redhat.com> Message-ID: <572C57E1.1080302@oracle.com> On 06/05/2016 09:16, Andrew Dinn wrote: > : > Yes, that's probably the best way to restrict access if you assume the > agent is itself in a Jigsaw module. Your agent may not be in a named module but it will be in an unnamed module. Once you catch up on the concepts then I think it should be much clearer. -Alan. From alan.bateman at oracle.com Fri May 6 08:39:59 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:39:59 +0000 Subject: hg: jigsaw/jake/jaxp: 5 new changesets Message-ID: <201605060839.u468dx2H029963@aojmv0008.oracle.com> Changeset: af1875980cbf Author: joehw Date: 2016-04-28 09:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/af1875980cbf 8154220: Semi-colon delimited list of catalog files in System property is throwing IllegalArgumentException Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java + test/javax/xml/jaxp/unittest/catalog/first_cat.xml + test/javax/xml/jaxp/unittest/catalog/next_cat.xml + test/javax/xml/jaxp/unittest/catalog/second_cat.xml Changeset: 4b13796fa518 Author: lana Date: 2016-04-28 09:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4b13796fa518 Merge Changeset: 46b57560cd06 Author: fyuan Date: 2016-04-28 19:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/46b57560cd06 8155514: jaxp.library.TestPolicy should extend the default security policy Reviewed-by: mchung, joehw Contributed-by: Frank Yuan ! test/javax/xml/jaxp/libs/jaxp/library/TestPolicy.java Changeset: 6513699ddc34 Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6513699ddc34 Added tag jdk-9+117 for changeset 46b57560cd06 ! .hgtags Changeset: 987a44004fe3 Author: alanb Date: 2016-05-06 08:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/987a44004fe3 Merge From alan.bateman at oracle.com Fri May 6 08:39:58 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:39:58 +0000 Subject: hg: jigsaw/jake: 13 new changesets Message-ID: <201605060839.u468dwrG029906@aojmv0008.oracle.com> Changeset: c3efe6acb2ae Author: erikj Date: 2016-04-27 14:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c3efe6acb2ae 8154841: Let different Jib profiles have different default make targets Reviewed-by: dholmes, tbell ! common/conf/jib-profiles.js ! make/Init.gmk ! make/Jprt.gmk ! make/Main.gmk Changeset: d8b1e1832b0e Author: chegar Date: 2016-04-27 20:35 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d8b1e1832b0e 8044773: Refactor jdk.net API so that it can be moved out of the base module Reviewed-by: alanb, erikj, mchung Contributed-by: Chris Hegarty , Erik Joelsson ! make/GensrcModuleInfo.gmk ! make/Javadoc.gmk ! make/common/Modules.gmk Changeset: 2bc539c6b48a Author: erikj Date: 2016-04-28 16:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2bc539c6b48a 8155641: Correct merge typo in compare script Reviewed-by: chegar ! common/autoconf/compare.sh.in Changeset: 5a2fe64cd60c Author: erikj Date: 2016-04-28 17:14 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5a2fe64cd60c 8155629: MODULES_FILTER should apply to imported modules Reviewed-by: dholmes, tbell, mchung ! make/common/Modules.gmk Changeset: 2ebe9495d8a5 Author: erikj Date: 2016-04-28 17:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2ebe9495d8a5 8155632: Remove debuginfo from jmod files Reviewed-by: tbell, mchung, alanb ! make/CreateJmods.gmk ! make/Images.gmk Changeset: 7c0463107cf6 Author: lana Date: 2016-04-28 09:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7c0463107cf6 Merge Changeset: 1d683c899373 Author: dholmes Date: 2016-04-29 01:45 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1d683c899373 8155689: Build failing for install on jdk9/dev when using -testset hotspot Summary: add installer target that aliases the expected target Reviewed-by: jmasa, tbell ! make/Main.gmk Changeset: 29effd8b21b5 Author: prr Date: 2016-04-25 15:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/29effd8b21b5 8154213: clean up uses of boxed primitive constructors in the java.desktop module Reviewed-by: serb, psadhukhan ! make/CompileJavaModules.gmk Changeset: 5f943da92463 Author: prr Date: 2016-04-29 11:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5f943da92463 Merge Changeset: 5abfe7826b95 Author: erikj Date: 2016-05-02 15:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/5abfe7826b95 8155821: Typo for s390x for HOTSPOT__CPU_DEFINE Reviewed-by: erikj Contributed-by: Matthias Klose ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: e882bcdbdac4 Author: redestad Date: 2016-05-02 17:54 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e882bcdbdac4 8155824: JDK build should tune down small apps more aggressively Reviewed-by: erikj ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-configure.sh Changeset: b17bdc69a754 Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b17bdc69a754 Added tag jdk-9+117 for changeset e882bcdbdac4 ! .hgtags Changeset: 443835b49c41 Author: alanb Date: 2016-05-06 09:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/443835b49c41 Merge ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/conf/jib-profiles.js ! make/CompileJavaModules.gmk ! make/CreateJmods.gmk ! make/GensrcModuleInfo.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Jprt.gmk ! make/Main.gmk ! make/common/Modules.gmk From alan.bateman at oracle.com Fri May 6 08:39:58 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:39:58 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201605060839.u468dwM2029903@aojmv0008.oracle.com> Changeset: 18695748cc41 Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/18695748cc41 Added tag jdk-9+117 for changeset 7a1b36bf2fe5 ! .hgtags Changeset: 285b3e979423 Author: alanb Date: 2016-05-06 08:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/285b3e979423 Merge From alan.bateman at oracle.com Fri May 6 08:40:00 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:40:00 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201605060840.u468e1t9000055@aojmv0008.oracle.com> Changeset: 2d52e0610b05 Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/2d52e0610b05 Added tag jdk-9+117 for changeset 58265b39fc74 ! .hgtags Changeset: 1d96ce2eaed2 Author: alanb Date: 2016-05-06 08:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/1d96ce2eaed2 Merge From alan.bateman at oracle.com Fri May 6 08:40:02 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:40:02 +0000 Subject: hg: jigsaw/jake/langtools: 18 new changesets Message-ID: <201605060840.u468e2Uu000093@aojmv0008.oracle.com> Changeset: 2aa0433e0add Author: jlahoda Date: 2016-04-15 11:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2aa0433e0add 8154283: Check for clash between package and class not working when package in a different module Summary: Looking for any visible package when checking for package-class clash Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! test/tools/javac/modules/EdgeCases.java Changeset: 8102be8ddff2 Author: rfield Date: 2016-04-27 18:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8102be8ddff2 8150382: JShell API: Allow setting remote JVM arguments 8151754: jshell tool: add command line options for setting feedback mode Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ArgTokenizer.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java ! test/jdk/jshell/StartOptionTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 77864d84ccb5 Author: rfield Date: 2016-04-27 19:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/77864d84ccb5 8155580: jshell tool: push for -R missed added file MessageHandler.java Reviewed-by: jlahoda + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/MessageHandler.java Changeset: 53d10f55a055 Author: bpatel Date: 2016-04-28 05:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/53d10f55a055 8154119: Module summary page should display module description Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SectionName.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml + test/jdk/javadoc/doclet/testModules/TestModules.java + test/jdk/javadoc/doclet/testModules/module1/module-info.java + test/jdk/javadoc/doclet/testModules/module1/testpkgmdl1/TestClassInModule1.java + test/jdk/javadoc/doclet/testModules/module2/module-info.java + test/jdk/javadoc/doclet/testModules/module2/testpkgmdl2/TestClassInModule2.java Changeset: 8d8d8069aaef Author: lana Date: 2016-04-28 09:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8d8d8069aaef Merge Changeset: 778c7b2dad22 Author: jjg Date: 2016-04-29 14:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/778c7b2dad22 8154270: javac wrongly rejects some class literals as annotation element values Reviewed-by: mcimadamore Contributed-by: cushon at google.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java + test/tools/javac/annotations/T8154270/EraseClassInfoAnnotationValueTest.java + test/tools/javac/annotations/T8154270/Other.java Changeset: 93bec8d431c5 Author: ksrini Date: 2016-04-29 15:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/93bec8d431c5 8154482: javadoc tool must support legacy doclet and taglet Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Main.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Messager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/jdk/javadoc/tool/EnsureNewOldDoclet.java + test/tools/lib/toolbox/TestRunner.java Changeset: 2dc339da8a93 Author: rfield Date: 2016-04-29 19:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2dc339da8a93 8139837: JShell API: make a common JShellException Reviewed-by: jlahoda ! 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/JShellException.java ! src/jdk.jshell/share/classes/jdk/jshell/SnippetEvent.java ! src/jdk.jshell/share/classes/jdk/jshell/Unit.java ! src/jdk.jshell/share/classes/jdk/jshell/UnresolvedReferenceException.java Changeset: 341333db5536 Author: ksrini Date: 2016-04-29 16:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/341333db5536 8155061: javadoc incorrectly sorted items in All Classes list and Index files Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/jdk/javadoc/doclet/testOrdering/TestOrdering.java Changeset: 411703ce5b42 Author: sadayapalam Date: 2016-05-02 10:11 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/411703ce5b42 8155028: javac crashes in silly do-while loop Summary: Compiler should short circuit code generation for unreachable code. Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/UnreachableLoopCond.java Changeset: 09e7096943d4 Author: jlahoda Date: 2016-05-02 06:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/09e7096943d4 8050993: There is no record for condition in ternary operator in LineNumberTable. Summary: Make sure there is an entry in the LineNumberTable for the condition of the ternary operator Reviewed-by: jjg Contributed-by: andrey.x.nazarov at oracle.com, jan.lahoda at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! test/tools/javac/classfiles/attributes/LineNumberTable/LineNumberTestBase.java + test/tools/javac/classfiles/attributes/LineNumberTable/T8050993.java Changeset: b82035aa5622 Author: jlahoda Date: 2016-05-02 12:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b82035aa5622 8155816: langtools/tools/javac/classfiles/attributes/LineNumberTable/T8050993.java test broken Summary: Correcting expected line numbers Reviewed-by: alundblad ! test/tools/javac/classfiles/attributes/LineNumberTable/T8050993.java Changeset: ceb435d36186 Author: rfield Date: 2016-05-02 08:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ceb435d36186 8139832: JShell API: Diag constructor should not be exposed and fix typo Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/Diag.java Changeset: a3e5875a0b7e Author: ksrini Date: 2016-05-02 15:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a3e5875a0b7e 8154578: Drop residual use of addReads from javadoc Reviewed-by: alanb, jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: e79cb3adffa7 Author: jjg Date: 2016-05-02 16:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e79cb3adffa7 8155774: move code from ModuleTestBase to toolbox Reviewed-by: ksrini, jlahoda ! test/tools/javac/modules/AbstractOrInnerClassServiceImplTest.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AnnotationProcessing.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/DoclintOtherModules.java ! test/tools/javac/modules/DuplicateClassTest.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/HelloWorldTest.java ! test/tools/javac/modules/MOptionTest.java ! test/tools/javac/modules/ModuleFinderTest.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/ModuleInfoTreeAccess.java ! test/tools/javac/modules/ModulePathTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/ModuleTestBase.java ! test/tools/javac/modules/ModulesAndClassPathTest.java ! test/tools/javac/modules/MultiModuleModeTest.java ! test/tools/javac/modules/NPECompilingModuleInfoTest.java ! test/tools/javac/modules/NPEEmptyFileTest.java ! test/tools/javac/modules/OutputDirTest.java ! test/tools/javac/modules/PackageConflictTest.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/PluginsInModulesTest.java ! test/tools/javac/modules/ProvidesTest.java ! test/tools/javac/modules/QueryBeforeEnter.java ! test/tools/javac/modules/RepeatedUsesAndProvidesTest.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java ! test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/ResolveTest.java ! test/tools/javac/modules/ServiceInStaticClassErrorTest.java ! test/tools/javac/modules/ServiceProvidedButNotExportedOrUsedTest.java ! test/tools/javac/modules/SingleModuleModeTest.java ! test/tools/javac/modules/SubpackageTest.java ! test/tools/javac/modules/UpgradeModulePathTest.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/modules/XModuleTest.java ! test/tools/lib/toolbox/JavacTask.java + test/tools/lib/toolbox/ModuleBuilder.java ! test/tools/lib/toolbox/TestRunner.java ! test/tools/lib/toolbox/ToolBox.java Changeset: 59adcdd0cd3b Author: darcy Date: 2016-05-02 18:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/59adcdd0cd3b 8155516: Suppress warnings from uses of deprecated Class.newInstance langtools Reviewed-by: jjg ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/options/Option.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: 3e122561e8a7 Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3e122561e8a7 Added tag jdk-9+117 for changeset 59adcdd0cd3b ! .hgtags Changeset: 25fc0ee0bc7c Author: alanb Date: 2016-05-06 09:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/25fc0ee0bc7c Merge ! .hgtags ! src/java.compiler/share/classes/javax/tools/ToolProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlConstants.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ModuleSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ModuleSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclet.xml ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/DocEnv.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.java ! test/tools/javac/modules/AbstractOrInnerClassServiceImplTest.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/AddReadsTest.java ! test/tools/javac/modules/AnnotationProcessing.java ! test/tools/javac/modules/AnnotationProcessorsInModulesTest.java ! test/tools/javac/modules/AutomaticModules.java ! test/tools/javac/modules/DoclintOtherModules.java ! test/tools/javac/modules/DuplicateClassTest.java ! test/tools/javac/modules/EdgeCases.java ! test/tools/javac/modules/GraphsTest.java ! test/tools/javac/modules/HelloWorldTest.java ! test/tools/javac/modules/MOptionTest.java ! test/tools/javac/modules/ModuleFinderTest.java ! test/tools/javac/modules/ModuleInfoTest.java ! test/tools/javac/modules/ModulePathTest.java ! test/tools/javac/modules/ModuleSourcePathTest.java ! test/tools/javac/modules/ModuleTestBase.java ! test/tools/javac/modules/ModulesAndClassPathTest.java ! test/tools/javac/modules/MultiModuleModeTest.java ! test/tools/javac/modules/NPEEmptyFileTest.java ! test/tools/javac/modules/OutputDirTest.java ! test/tools/javac/modules/PackageConflictTest.java ! test/tools/javac/modules/PackageMultipleModules.java ! test/tools/javac/modules/PluginsInModulesTest.java ! test/tools/javac/modules/ProvidesTest.java ! test/tools/javac/modules/QueryBeforeEnter.java ! test/tools/javac/modules/RepeatedUsesAndProvidesTest.java ! test/tools/javac/modules/ReportNonExistentPackageTest.java ! test/tools/javac/modules/RequiresPublicTest.java ! test/tools/javac/modules/ResolveTest.java ! test/tools/javac/modules/ServiceInStaticClassErrorTest.java ! test/tools/javac/modules/ServiceProvidedButNotExportedOrUsedTest.java ! test/tools/javac/modules/SingleModuleModeTest.java ! test/tools/javac/modules/SubpackageTest.java ! test/tools/javac/modules/UpgradeModulePathTest.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/modules/XModuleTest.java From alan.bateman at oracle.com Fri May 6 08:40:05 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:40:05 +0000 Subject: hg: jigsaw/jake/nashorn: 5 new changesets Message-ID: <201605060840.u468e5S4000110@aojmv0008.oracle.com> Changeset: bafd733be429 Author: hannesw Date: 2016-04-27 15:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bafd733be429 8134503: support ES6 parsing in Nashorn Reviewed-by: jlaskey, sundar, mhaupt Contributed-by: andreas.woess at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/SplitIntoFunctions.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ClassNode.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ExpressionList.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/ForNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/IndexNode.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Module.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContext.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextFunctionNode.java + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextModuleNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/TokenType.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java + test/script/basic/es6/parser-es6.js - test/script/basic/yield.js ! test/script/error/NASHORN-154/function_mult_params_in_strict.js.EXPECTED ! test/script/nosecurity/parserapi.js.EXPECTED ! test/script/nosecurity/parserapi_strict.js.EXPECTED ! test/script/nosecurity/treeapi/array_literal.js.EXPECTED ! test/script/nosecurity/treeapi/objectLiteral.js.EXPECTED ! test/script/nosecurity/treeapi/property.js.EXPECTED ! test/script/nosecurity/treeapi/throw.js.EXPECTED ! test/script/nosecurity/treeapi/with.js.EXPECTED ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java Changeset: fd2296436748 Author: hannesw Date: 2016-04-28 10:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fd2296436748 8155025: 0.001.toFixed(2) should return "0.00" not "0" Reviewed-by: jlaskey, hannesw Contributed-by: andreas.woess at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/doubleconv/DtoaBuffer.java + test/script/basic/JDK-8155025.js + test/script/basic/JDK-8155025.js.EXPECTED Changeset: 5267e9181161 Author: lana Date: 2016-04-28 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/5267e9181161 Merge - test/script/basic/yield.js Changeset: b0c9a78aee9d Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b0c9a78aee9d Added tag jdk-9+117 for changeset 5267e9181161 ! .hgtags Changeset: 878f812e33db Author: alanb Date: 2016-05-06 08:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/878f812e33db Merge ! .hgtags ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java - test/script/basic/yield.js ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java From alan.bateman at oracle.com Fri May 6 08:40:04 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:40:04 +0000 Subject: hg: jigsaw/jake/hotspot: 2 new changesets Message-ID: <201605060840.u468e4OK000107@aojmv0008.oracle.com> Changeset: 4443f69bba5a Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4443f69bba5a Added tag jdk-9+117 for changeset 88170d364290 ! .hgtags Changeset: 07536fe9b503 Author: alanb Date: 2016-05-06 09:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/07536fe9b503 Merge ! .hgtags From alan.bateman at oracle.com Fri May 6 08:40:19 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 06 May 2016 08:40:19 +0000 Subject: hg: jigsaw/jake/jdk: 67 new changesets Message-ID: <201605060840.u468eMWc000297@aojmv0008.oracle.com> Changeset: 41f95dde9770 Author: mrkam Date: 2016-04-25 16:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/41f95dde9770 8154594: JFrame.setDefaultCloseOperation is prohibited in jtreg: Missing part of the fix Reviewed-by: alexsch, prr ! test/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/button/ButtonDemo.java ! test/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tabbedpane/TabbedPaneDemo.java ! test/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/window/WindowDemo.java Changeset: d24c177b70ac Author: mrkam Date: 2016-04-25 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d24c177b70ac 8154706: Sanity tests prepareBundle task doesn't produce working bundle Reviewed-by: alexsch, prr ! test/sanity/client/TEST.ROOT.template Changeset: 5e70a502b37c Author: jlaskey Date: 2016-04-26 11:55 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5e70a502b37c 8132994: /modules and /packages should not be parsed by the jimage parser Reviewed-by: sundar ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java Changeset: ae10dd067bcd Author: rriggs Date: 2016-04-26 17:35 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ae10dd067bcd 8066750: Remove HTTP proxy implementation and tests from RMI Reviewed-by: smarks ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java + src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPDirectSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! test/ProblemList.txt - test/java/rmi/transport/httpSocket/HttpSocketTest.java - test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java - test/java/rmi/transport/httpSocket/security.policy - test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java - test/sun/rmi/transport/proxy/EagerHttpFallback.java - test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java - test/sun/rmi/transport/tcp/blockAccept/TestIface.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java - test/sun/rmi/transport/tcp/blockAccept/security.policy Changeset: 3243b2b2a365 Author: rriggs Date: 2016-04-26 21:25 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3243b2b2a365 8155182: fix to JDK-8066750 broke jdk9 builds Summary: Restore RMI Http Proxy support for now Reviewed-by: darcy, lancea, smarks ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java < src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPDirectSocketFactory.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java + src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! test/ProblemList.txt + test/java/rmi/transport/httpSocket/HttpSocketTest.java + test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java + test/java/rmi/transport/httpSocket/security.policy + test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java + test/sun/rmi/transport/proxy/EagerHttpFallback.java + test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java + test/sun/rmi/transport/tcp/blockAccept/TestIface.java + test/sun/rmi/transport/tcp/blockAccept/TestImpl.java + test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java + test/sun/rmi/transport/tcp/blockAccept/security.policy Changeset: ee25fcbc9b8c Author: psandoz Date: 2016-04-26 18:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee25fcbc9b8c 8154556: Use java.nio.ByteOrder instead of boolean value Reviewed-by: alanb ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template Changeset: 248dd87f816f Author: psandoz Date: 2016-04-26 18:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/248dd87f816f 8154447: Exempt classes under java.util.concurrent from MH.Lookup restrictions Reviewed-by: mchung, martin ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/JavaUtilConcurrentLookupTest.java + test/java/lang/invoke/java.base/java/util/concurrent/LookupTester.java Changeset: 5a6df35b0f97 Author: simonis Date: 2016-04-27 09:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a6df35b0f97 8155156: Remove remaining sun.misc.* imports from the jdk repo Reviewed-by: chegar ! src/java.base/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java Changeset: 5a48729a7eb6 Author: mhaupt Date: 2016-04-27 15:01 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a48729a7eb6 8155214: java/lang/invoke/PermuteArgsTest.java fails due to exhausted code cache Reviewed-by: sundar ! test/java/lang/invoke/PermuteArgsTest.java Changeset: 9e370f96dcf2 Author: dfuchs Date: 2016-04-27 18:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e370f96dcf2 8148568: LoggerFinder.getLogger and LoggerFinder.getLocalizedLogger should take a Module argument instead of a Class. Summary: Changes System.LoggerFinder methods to take a Module argument instead of a Class. Reviewed-by: mchung ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/jdk/internal/logger/DefaultLoggerFinder.java ! src/java.base/share/classes/jdk/internal/logger/LazyLoggers.java ! src/java.base/share/classes/sun/util/logging/PlatformLogger.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.logging/share/classes/sun/util/logging/internal/LoggingProviderImpl.java ! test/java/lang/System/Logger/custom/CustomLoggerTest.java ! test/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinder.java ! test/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java ! test/java/lang/System/LoggerFinder/BaseLoggerFinderTest/TestLoggerFinder.java ! test/java/lang/System/LoggerFinder/DefaultLoggerFinderTest/DefaultLoggerFinderTest.java ! test/java/lang/System/LoggerFinder/internal/BaseDefaultLoggerFinderTest/BaseDefaultLoggerFinderTest.java ! test/java/lang/System/LoggerFinder/internal/BaseLoggerBridgeTest/BaseLoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/BasePlatformLoggerTest/BasePlatformLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerAPIsTest.java ! test/java/lang/System/LoggerFinder/internal/BootstrapLogger/BootstrapLoggerTest.java ! test/java/lang/System/LoggerFinder/internal/LoggerBridgeTest/LoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java ! test/java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest/PlatformLoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/internal/api/LoggerFinderAPITest.java ! test/java/lang/System/LoggerFinder/internal/backend/LoggerFinderBackendTest.java ! test/java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java ! test/java/lang/System/LoggerFinder/jdk/DefaultPlatformLoggerTest/DefaultPlatformLoggerTest.java ! test/sun/util/logging/PlatformLoggerTest.java Changeset: 35e3f6bdf42b Author: simonis Date: 2016-04-27 18:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/35e3f6bdf42b 8155236: AIX: fix dectection of Xrender extension Reviewed-by: prr ! src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRBackendNative.c Changeset: c0e1a94f27f5 Author: mhaupt Date: 2016-04-27 20:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c0e1a94f27f5 8155106: MHs.Lookup.findConstructor returns handles for array classes Reviewed-by: shade, sundar ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/ArrayConstructorTest.java Changeset: 679e4061b6a0 Author: mchung Date: 2016-04-27 12:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/679e4061b6a0 8154905: Rename jdk.jvmstat.rmi to jdk.jstatd Reviewed-by: alanb, sundar + make/launcher/Launcher-jdk.jstatd.gmk - make/launcher/Launcher-jdk.jvmstat.rmi.gmk + src/jdk.jstatd/share/classes/module-info.java + src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java + src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java + src/jdk.jstatd/share/classes/sun/jvmstat/monitor/remote/package.html + src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java + src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java + src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java + src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java + src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java + src/jdk.jstatd/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html + src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java + src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java + src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteVmImpl.java - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java ! src/jdk.jvmstat/share/classes/module-info.java Changeset: 46dfc09b2c76 Author: chegar Date: 2016-04-27 20:36 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/46dfc09b2c76 8044773: Refactor jdk.net API so that it can be moved out of the base module Reviewed-by: alanb, erikj, mchung + make/lib/Lib-jdk.net.gmk + make/mapfiles/libextnet/mapfile-vers ! make/mapfiles/libnet/mapfile-vers ! make/src/classes/build/tools/module/GenModuleInfoSource.java - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java ! src/java.base/share/classes/module-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java + src/java.base/share/classes/sun/net/ext/ExtendedSocketOptions.java ! src/java.base/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/Net.java ! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/java.base/unix/classes/java/net/PlainDatagramSocketImpl.java ! src/java.base/unix/classes/java/net/PlainSocketImpl.java - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c ! src/java.base/unix/native/libnet/net_util_md.h - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c + src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java + src/jdk.net/share/classes/jdk/net/NetworkPermission.java + src/jdk.net/share/classes/jdk/net/SocketFlow.java + src/jdk.net/share/classes/jdk/net/Sockets.java + src/jdk.net/share/classes/jdk/net/package-info.java + src/jdk.net/share/classes/module-info.java + src/jdk.net/solaris/classes/jdk/net/SolarisSocketOptions.java + src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c + src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.h ! src/jdk.policytool/share/classes/module-info.java ! test/java/net/SocketOption/OptionsTest.java ! test/java/net/SocketOption/UnsupportedOptionsTest.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java + test/jdk/net/SocketFlow/SocketFlowBasic.java ! test/jdk/net/Sockets/Test.java Changeset: 566a5f5a9a5a Author: mrkam Date: 2016-04-27 17:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/566a5f5a9a5a 8154381: SwingSet tests are not auto closed in jtreg Reviewed-by: alexsch ! make/netbeans/client_sanity/nbproject/genfiles.properties ! make/netbeans/client_sanity/nbproject/project.properties ! make/netbeans/client_sanity/nbproject/project.xml ! test/sanity/client/SwingSet/src/ButtonDemoScreenshotTest.java ! test/sanity/client/SwingSet/src/ButtonDemoTest.java ! test/sanity/client/SwingSet/src/ComboBoxDemoTest.java ! test/sanity/client/SwingSet/src/ListDemoTest.java ! test/sanity/client/SwingSet/src/OptionPaneDemoTest.java ! test/sanity/client/SwingSet/src/ProgressBarDemoTest.java ! test/sanity/client/SwingSet/src/ScrollPaneDemoTest.java ! test/sanity/client/SwingSet/src/SpinnerDemoTest.java ! test/sanity/client/SwingSet/src/SplitPaneDemoTest.java ! test/sanity/client/SwingSet/src/TabbedPaneDemoTest.java ! test/sanity/client/SwingSet/src/TextFieldDemoTest.java ! test/sanity/client/SwingSet/src/ToggleButtonDemoTest.java ! test/sanity/client/SwingSet/src/TreeDemoTest.java ! test/sanity/client/SwingSet/src/WindowDemoTest.java + test/sanity/client/lib/Extensions/src/org/jemmy2ext/JemmyExt.java + test/sanity/client/lib/Extensions/src/org/jtregext/GuiTestListener.java - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java ! test/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/tabbedpane/TabbedPaneDemo.java Changeset: 69f430549260 Author: amlu Date: 2016-04-28 12:38 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/69f430549260 8154733: Fix module dependencies missed in java.rmi tests Reviewed-by: alanb, amlu Contributed-by: felix.yang at oracle.com + test/java/rmi/TEST.properties ! test/java/rmi/reliability/benchmark/bench/serial/Main.java + test/sun/rmi/TEST.properties Changeset: 88dbf3f5bb92 Author: chegar Date: 2016-04-28 09:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/88dbf3f5bb92 8155578: OpenJDK build failed after JDK-8044773 Reviewed-by: alanb ! src/java.base/share/classes/module-info.java Changeset: 8c23079bd4a6 Author: cbensen Date: 2016-04-28 08:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c23079bd4a6 8150990: Add helper class in jdk.jlink for packager use to avoid coordination with FX and JDK builds Reviewed-by: alanb, mchung, kcr, sundar + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java Changeset: 3a56dfbc0748 Author: lana Date: 2016-04-28 09:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3a56dfbc0748 Merge - make/launcher/Launcher-jdk.jvmstat.rmi.gmk - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c ! src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java ! src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java ! test/java/rmi/transport/httpSocket/HttpSocketTest.java ! test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java ! test/java/rmi/transport/httpSocket/security.policy - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java ! test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java ! test/sun/rmi/transport/proxy/EagerHttpFallback.java ! test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java ! test/sun/rmi/transport/tcp/blockAccept/TestIface.java ! test/sun/rmi/transport/tcp/blockAccept/TestImpl.java ! test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java Changeset: dc7a55eff236 Author: smarks Date: 2016-04-28 14:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dc7a55eff236 8154801: deprecate Observer and Observable Reviewed-by: darcy ! src/java.base/share/classes/java/util/Observable.java ! src/java.base/share/classes/java/util/Observer.java Changeset: cb9c35a20ea5 Author: redestad Date: 2016-04-29 11:56 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb9c35a20ea5 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction Reviewed-by: mullan, mchung, chegar - src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java Changeset: 709929854709 Author: shade Date: 2016-04-29 13:24 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/709929854709 8155090: String concatenation fails with a custom SecurityManager that uses concatenation Reviewed-by: redestad, chegar ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java + test/java/lang/String/concat/WithSecurityManager.java Changeset: 531822c47693 Author: tvaleev Date: 2016-04-29 16:52 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/531822c47693 8155600: Performance optimization of Arrays.asList().iterator() Reviewed-by: redestad, shade, plevart, attila ! src/java.base/share/classes/java/util/Arrays.java + test/java/util/Arrays/AsList.java Changeset: 4667ba19132d Author: psadhukhan Date: 2016-04-13 17:04 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4667ba19132d 8147841: [macosx] Updating TrayIcons popup menu does not work on Mac OS X Reviewed-by: serb, ssadetsky ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java + test/java/awt/TrayIcon/UpdatePopupMenu/UpdatePopupMenu.java Changeset: 161066523d96 Author: aivanov Date: 2016-04-14 13:07 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/161066523d96 8146035: Windows - With LCD antialiasing, some glyphs are not rendered correctly Reviewed-by: serb, prr Contributed-by: Dmitry Batrak ! src/java.desktop/windows/native/libfontmanager/lcdglyph.c Changeset: 12b94dc0e106 Author: ssadetsky Date: 2016-04-14 20:32 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/12b94dc0e106 8153351: GTK Menu's have no border Reviewed-by: alexsch, serb ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java Changeset: a8df904d5a45 Author: prr Date: 2016-04-14 12:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a8df904d5a45 8134986: Incorrect use of ConcurrentHashMap.contains in SunFontManager.java Reviewed-by: serb, jgodinez ! src/java.desktop/share/classes/sun/font/SunFontManager.java Changeset: a4a0eb3aa93e Author: psadhukhan Date: 2016-04-15 11:45 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a4a0eb3aa93e 6921664: The number of copies and the job name are not passed to a 3rd party PrintService Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java + test/java/awt/print/PrinterJob/DummyPrintTest.java Changeset: 936d82ddf9a2 Author: psadhukhan Date: 2016-04-15 11:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/936d82ddf9a2 6801613: Cross-platform pageDialog and printDialog top margin entry broken Reviewed-by: prr, jdv ! src/java.desktop/share/classes/sun/print/ServiceDialog.java + test/java/awt/print/PrinterJob/PageDialogMarginTest.java Changeset: c9965520ec63 Author: psadhukhan Date: 2016-04-15 11:52 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c9965520ec63 8154057: [macosx] getPrintJob doesn't throw NPE if Frame is null AND type is COMMON Reviewed-by: prr, jdv ! src/java.desktop/macosx/classes/sun/lwawt/LWToolkit.java + test/java/awt/PrintJob/NullFrameTest.java Changeset: 30c72e951070 Author: psadhukhan Date: 2016-04-15 12:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/30c72e951070 8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108 Reviewed-by: serb, psadhukhan Contributed-by: abdul.kolarkunnu at oracle.com + test/javax/swing/JEditorPane/5076514/bug5076514.java Changeset: 6cc7fef92fcf Author: ssadetsky Date: 2016-04-15 09:46 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6cc7fef92fcf 8080395: consider making sun.awt.CausedFocusEvent functionality public Reviewed-by: alexsch, prr ! src/java.desktop/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/PlatformWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.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/DefaultKeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/java/awt/event/FocusEvent.java ! src/java.desktop/share/classes/java/awt/peer/ComponentPeer.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/sun/awt/AWTAccessor.java ! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java ! src/java.desktop/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/java.desktop/share/classes/sun/awt/NullComponentPeer.java ! src/java.desktop/share/classes/sun/awt/RequestFocusController.java ! src/java.desktop/unix/classes/sun/awt/X11/XComponentPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WKeyboardFocusManagerPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java + test/java/awt/Focus/Cause/FocusCauseTest.java Changeset: d71511d28c7b Author: ssadetsky Date: 2016-04-15 09:54 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d71511d28c7b 8153276: [TEST_BUG] javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java Reviewed-by: alexsch, yan ! test/javax/swing/JFileChooser/ShellFolderQueries/ShellFolderQueriesTest.java Changeset: b0407f2af374 Author: ssadetsky Date: 2016-04-15 09:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b0407f2af374 8145787: [TEST_BUG][PIT] javax/swing/undo/UndoManager/AbstractDocumentUndoConcurrentTest.java fails with CannotUndoException Reviewed-by: alexsch, serb ! test/javax/swing/undo/UndoManager/AbstractDocumentUndoConcurrentTest.java Changeset: 735a130dc8db Author: aghaisas Date: 2016-04-15 15:50 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/735a130dc8db 8049069: JButton incorrect behaviour on button release Reviewed-by: serb, alexsch ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java + test/javax/swing/JButton/PressedButtonRightClickTest.java Changeset: 9d1077f29022 Author: alexsch Date: 2016-04-15 19:15 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9d1077f29022 8132791: No access to SynthContext.getContext() Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthArrowButton.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthBorder.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthContext.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneDivider.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 902e7cbe0acd Author: prr Date: 2016-04-15 10:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/902e7cbe0acd 8154269: Remove unused or unnecessary Xm/Xt files and header includes Reviewed-by: serb, ssadetsky ! src/java.desktop/unix/native/common/awt/awt.h ! src/java.desktop/unix/native/common/awt/awt_p.h - src/java.desktop/unix/native/common/awt/extutil.h ! src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.c ! src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h ! src/java.desktop/unix/native/include/jawt_md.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.c - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingAreaP.h ! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c ! src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c ! src/java.desktop/unix/native/libawt_xawt/awt/awt_util.c ! src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c Changeset: 7f390c98c765 Author: serb Date: 2016-04-16 23:29 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f390c98c765 8154016: [macosx] Some HiDPI code can be removed Reviewed-by: alexsch, prr ! src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/java.desktop/macosx/classes/sun/lwawt/PlatformWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java Changeset: 732f9c63e037 Author: serb Date: 2016-04-16 23:36 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/732f9c63e037 8141544: The interface sun.swing.UIClientPropertyKey can be made public Reviewed-by: alexsch ! src/java.desktop/share/classes/com/sun/java/swing/plaf/windows/AnimationController.java ! src/java.desktop/share/classes/javax/swing/JComponent.java + src/java.desktop/share/classes/javax/swing/UIClientPropertyKey.java ! src/java.desktop/share/classes/sun/swing/StringUIClientPropertyKey.java - src/java.desktop/share/classes/sun/swing/UIClientPropertyKey.java + test/javax/swing/ClientProperty/UIClientPropertyKeyTest/UIClientPropertyKeyTest.java Changeset: f92ee6e0d1f2 Author: serb Date: 2016-04-16 23:39 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f92ee6e0d1f2 7102282: TEST_BUG: sun/java2d/OpenGL/GradientPaints.java should be modified Reviewed-by: yan, psadhukhan ! test/sun/java2d/OpenGL/GradientPaints.java Changeset: 82ca44ca8285 Author: pkbalakr Date: 2016-04-18 15:39 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/82ca44ca8285 8153056: 8152647(duplicate of 6439354) Manual Test always passes Reviewed-by: alexsch, psadhukhan ! test/javax/swing/LookAndFeel/6439354/TitledBorderTest.java Changeset: 6e22aca29b0d Author: aghaisas Date: 2016-04-19 13:00 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e22aca29b0d 8031423: Test java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails by Timeout on Windows Reviewed-by: yan, arapte ! test/java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java Changeset: 079b369ab849 Author: ddehaven Date: 2016-04-19 11:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/079b369ab849 Merge - src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileAttributes.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/JrtExplodedFileAttributes.java - src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java - src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedPath.java - src/java.base/share/classes/jdk/internal/jrtfs/SystemImages.java - src/java.base/share/classes/sun/reflect/AccessorGenerator.java - src/java.base/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/ByteVector.java - src/java.base/share/classes/sun/reflect/ByteVectorFactory.java - src/java.base/share/classes/sun/reflect/ByteVectorImpl.java - src/java.base/share/classes/sun/reflect/CallerSensitive.java - src/java.base/share/classes/sun/reflect/ClassDefiner.java - src/java.base/share/classes/sun/reflect/ClassFileAssembler.java - src/java.base/share/classes/sun/reflect/ClassFileConstants.java - src/java.base/share/classes/sun/reflect/ConstantPool.java - src/java.base/share/classes/sun/reflect/ConstructorAccessor.java - src/java.base/share/classes/sun/reflect/ConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/DelegatingConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/DelegatingMethodAccessorImpl.java - src/java.base/share/classes/sun/reflect/FieldAccessor.java - src/java.base/share/classes/sun/reflect/FieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/FieldInfo.java - src/java.base/share/classes/sun/reflect/InstantiationExceptionConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/Label.java - src/java.base/share/classes/sun/reflect/LangReflectAccess.java - src/java.base/share/classes/sun/reflect/MagicAccessorImpl.java - src/java.base/share/classes/sun/reflect/MethodAccessor.java - src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java - src/java.base/share/classes/sun/reflect/MethodAccessorImpl.java - src/java.base/share/classes/sun/reflect/NativeConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/NativeMethodAccessorImpl.java - src/java.base/share/classes/sun/reflect/Reflection.java - src/java.base/share/classes/sun/reflect/ReflectionFactory.java - src/java.base/share/classes/sun/reflect/SerializationConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/SignatureIterator.java - src/java.base/share/classes/sun/reflect/UTF8.java - src/java.base/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java - src/java.base/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java - src/jdk.rmic/share/classes/jdk/rmi/rmic/Main.java - test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java - test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java - test/sun/reflect/CallerSensitive/MissingCallerSensitive.java - test/sun/reflect/Reflection/GetCallerClass.java - test/sun/reflect/Reflection/GetCallerClassTest.java - test/sun/reflect/Reflection/GetCallerClassTest.sh - test/sun/reflect/constantPool/ConstantPoolTest.java - test/sun/reflect/constantPool/ConstantPoolTestDummy.jasm Changeset: ea55f52c0ada Author: psadhukhan Date: 2016-04-20 10:59 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ea55f52c0ada 6197099: PrinterJob.getUserName() throws a security exception when user.name permission is not given Reviewed-by: prr, jdv ! src/java.desktop/share/classes/java/awt/print/PrinterJob.java + test/java/awt/print/PrinterJob/GetUserNameTest.java + test/java/awt/print/PrinterJob/GetUserNameTest.policy Changeset: d5322b45852d Author: ptbrunet Date: 2016-04-20 12:23 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d5322b45852d 8076554: [macosx] Custom Swing text components need to allow standard accessibility Summary: Remove JTextComponent listeners; use property change listeners for caret/text Reviewed-by: prr, alexsch Contributed-by: peter.brunet at oracle.com + src/java.desktop/macosx/classes/sun/lwawt/macosx/AccessibilityEventMonitor.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java Changeset: b4f8c8c4c129 Author: avstepan Date: 2016-04-21 20:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b4f8c8c4c129 8154762: [TEST] add some tests according to JDK-8132138 Reviewed-by: ssadetsky, serb + test/java/beans/Introspector/BeanPropertyTest.java Changeset: 0c5d27b173f7 Author: prr Date: 2016-04-21 10:30 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c5d27b173f7 Merge - test/java/util/ServiceLoader/modules/BasicTest.java Changeset: 9339eb17a38d Author: serb Date: 2016-04-22 01:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9339eb17a38d 8154088: [macosx] SWT does not work on JDK 9 since b65 Reviewed-by: prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java Changeset: 6d60dfa5e3f8 Author: ssadetsky Date: 2016-04-25 15:37 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6d60dfa5e3f8 8145547: [AWT/Swing] Conditional support for GTK 3 on Linux Reviewed-by: prr, alexsch ! make/mapfiles/libawt_xawt/mapfile-vers ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/java.desktop/unix/classes/sun/awt/UNIXToolkit.java ! src/java.desktop/unix/classes/sun/awt/X11/XDesktopPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTaskbarPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c ! src/java.desktop/unix/native/libawt_xawt/awt/awt_UNIXToolkit.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h + src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c + src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.h + src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c + src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.h ! src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c ! src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c ! src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKStyle.c ! src/java.desktop/unix/native/libawt_xawt/xawt/awt_Desktop.c ! src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c ! src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.h ! src/java.desktop/unix/native/libawt_xawt/xawt/gnome_interface.h Changeset: f60e53156db3 Author: avstepan Date: 2016-04-25 18:07 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f60e53156db3 8154962: [TEST] @BeanProperty: add some tests for anonimous classes Reviewed-by: serb + test/java/beans/Introspector/AnonymousClassBeanPropertyTest.java ! test/java/beans/Introspector/BeanPropertyTest.java Changeset: fe8df8e55825 Author: prr Date: 2016-04-25 09:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe8df8e55825 Merge - src/jdk.jlink/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.unsupported/share/classes/sun/misc/ManagedLocalsThread.java Changeset: 0d0cbb576c3c Author: prr Date: 2016-04-25 15:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0d0cbb576c3c 8154213: clean up uses of boxed primitive constructors in the java.desktop module Reviewed-by: serb, psadhukhan ! make/src/classes/build/tools/generatenimbus/UIProperty.java ! src/java.desktop/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxPopup.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java ! src/java.desktop/macosx/classes/com/apple/laf/ScreenPopupFactory.java ! src/java.desktop/macosx/classes/sun/font/CStrike.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/java.desktop/share/classes/java/awt/font/TextAttribute.java ! src/java.desktop/share/classes/java/awt/font/TextMeasurer.java ! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java ! src/java.desktop/share/classes/javax/swing/JLayeredPane.java ! src/java.desktop/share/classes/javax/swing/JProgressBar.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/SpinnerNumberModel.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/OceanTheme.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/NumberFormatter.java ! src/java.desktop/share/classes/javax/swing/text/StyleConstants.java ! src/java.desktop/share/classes/javax/swing/text/html/CSS.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java Changeset: bee22cd1ab09 Author: ssadetsky Date: 2016-04-29 09:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bee22cd1ab09 8155606: [PIT] Robot's createScreenCapture() broken on Linux Reviewed-by: prr ! src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c Changeset: 844fe87d784d Author: ssadetsky Date: 2016-04-29 09:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/844fe87d784d 8155613: [PIT] crash in AWT_Desktop/Automated/Exceptions/BasicTest Reviewed-by: prr ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: c6ee961ab61f Author: prr Date: 2016-04-29 09:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c6ee961ab61f Merge - make/launcher/Launcher-jdk.jvmstat.rmi.gmk - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java - src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java Changeset: daefa1109859 Author: shade Date: 2016-04-29 23:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/daefa1109859 8155215: java.lang.String concatenation spec is unnecessarily strong Reviewed-by: abuckley, sherman, chegar ! src/java.base/share/classes/java/lang/String.java Changeset: 6929d396c267 Author: psandoz Date: 2016-04-29 13:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6929d396c267 8154755: Add a VarHandle weakCompareAndSet with volatile semantics Reviewed-by: shade, vlivanov ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template Changeset: c15926d86fb1 Author: michaelm Date: 2016-04-30 00:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c15926d86fb1 8087124: HTTP/2 implementation Reviewed-by: chegar + src/java.httpclient/share/classes/java/net/http/AsyncConnection.java ! src/java.httpclient/share/classes/java/net/http/AsyncEvent.java + src/java.httpclient/share/classes/java/net/http/AsyncSSLConnection.java + src/java.httpclient/share/classes/java/net/http/AsyncSSLDelegate.java ! src/java.httpclient/share/classes/java/net/http/AuthenticationFilter.java ! src/java.httpclient/share/classes/java/net/http/BufferHandler.java + src/java.httpclient/share/classes/java/net/http/ByteBufferConsumer.java + src/java.httpclient/share/classes/java/net/http/ByteBufferGenerator.java + src/java.httpclient/share/classes/java/net/http/CharsetToolkit.java ! src/java.httpclient/share/classes/java/net/http/ConnectionPool.java + src/java.httpclient/share/classes/java/net/http/ContinuationFrame.java ! src/java.httpclient/share/classes/java/net/http/CookieFilter.java + src/java.httpclient/share/classes/java/net/http/DataFrame.java + src/java.httpclient/share/classes/java/net/http/ErrorFrame.java ! src/java.httpclient/share/classes/java/net/http/Exchange.java + src/java.httpclient/share/classes/java/net/http/FrameReader.java + src/java.httpclient/share/classes/java/net/http/GoAwayFrame.java + src/java.httpclient/share/classes/java/net/http/HeaderFrame.java + src/java.httpclient/share/classes/java/net/http/HeadersFrame.java ! src/java.httpclient/share/classes/java/net/http/Http1Exchange.java ! src/java.httpclient/share/classes/java/net/http/Http1Request.java ! src/java.httpclient/share/classes/java/net/http/Http1Response.java ! src/java.httpclient/share/classes/java/net/http/Http2ClientImpl.java ! src/java.httpclient/share/classes/java/net/http/Http2Connection.java + src/java.httpclient/share/classes/java/net/http/Http2Frame.java ! src/java.httpclient/share/classes/java/net/http/HttpClientImpl.java ! src/java.httpclient/share/classes/java/net/http/HttpConnection.java ! src/java.httpclient/share/classes/java/net/http/HttpHeadersImpl.java ! src/java.httpclient/share/classes/java/net/http/HttpRequestBuilderImpl.java ! src/java.httpclient/share/classes/java/net/http/HttpRequestImpl.java ! src/java.httpclient/share/classes/java/net/http/HttpResponse.java ! src/java.httpclient/share/classes/java/net/http/HttpResponseImpl.java + src/java.httpclient/share/classes/java/net/http/ImmutableHeaders.java ! src/java.httpclient/share/classes/java/net/http/Log.java ! src/java.httpclient/share/classes/java/net/http/MultiExchange.java + src/java.httpclient/share/classes/java/net/http/OutgoingHeaders.java ! src/java.httpclient/share/classes/java/net/http/Pair.java + src/java.httpclient/share/classes/java/net/http/PingFrame.java ! src/java.httpclient/share/classes/java/net/http/PlainHttpConnection.java ! src/java.httpclient/share/classes/java/net/http/PlainTunnelingConnection.java + src/java.httpclient/share/classes/java/net/http/PriorityFrame.java + src/java.httpclient/share/classes/java/net/http/PushPromiseFrame.java + src/java.httpclient/share/classes/java/net/http/Queue.java ! src/java.httpclient/share/classes/java/net/http/RawChannel.java ! src/java.httpclient/share/classes/java/net/http/RedirectFilter.java + src/java.httpclient/share/classes/java/net/http/ResetFrame.java ! src/java.httpclient/share/classes/java/net/http/ResponseHeaders.java ! src/java.httpclient/share/classes/java/net/http/SSLConnection.java ! src/java.httpclient/share/classes/java/net/http/SSLDelegate.java ! src/java.httpclient/share/classes/java/net/http/SSLTunnelConnection.java + src/java.httpclient/share/classes/java/net/http/SettingsFrame.java ! src/java.httpclient/share/classes/java/net/http/Stream.java ! src/java.httpclient/share/classes/java/net/http/Utils.java + src/java.httpclient/share/classes/java/net/http/WindowUpdateFrame.java ! src/java.httpclient/share/classes/java/net/http/package-info.java ! test/java/net/httpclient/APIErrors.java + test/java/net/httpclient/EchoHandler.java ! test/java/net/httpclient/LightWeightHttpServer.java ! test/java/net/httpclient/ManyRequests.java ! test/java/net/httpclient/RequestBodyTest.java ! test/java/net/httpclient/SmokeTest.java + test/java/net/httpclient/TestKit.java + test/java/net/httpclient/TestKitTest.java + test/java/net/httpclient/http2/BasicTest.java + test/java/net/httpclient/http2/ServerPush.java + test/java/net/httpclient/http2/TEST.properties + test/java/net/httpclient/http2/java.httpclient/java/net/http/BodyInputStream.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/BodyOutputStream.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/EchoHandler.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2Handler.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestExchange.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestServer.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestServerConnection.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/OutgoingPushPromise.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/PushHandler.java + test/java/net/httpclient/http2/java.httpclient/java/net/http/TestUtil.java ! test/java/net/httpclient/security/15.policy Changeset: 5c547db04adf Author: tvaleev Date: 2016-04-29 16:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c547db04adf 8153293: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/DoublePipeline.java ! src/java.base/share/classes/java/util/stream/IntPipeline.java ! src/java.base/share/classes/java/util/stream/LongPipeline.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java Changeset: b5eeb531268e Author: tvaleev Date: 2016-04-29 16:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b5eeb531268e 8154387: Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less Reviewed-by: psandoz ! src/java.base/share/classes/java/util/stream/StreamSpliterators.java Changeset: 2bf84670f079 Author: darcy Date: 2016-04-30 16:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2bf84670f079 8155792: Add @jls citations to java.lang.String Reviewed-by: alanb ! src/java.base/share/classes/java/lang/String.java Changeset: 7b4201143608 Author: prr Date: 2016-05-02 12:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7b4201143608 8155784: Build failure on Linux arm64 Reviewed-by: flar, serb ! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: eba31e937bfd Author: asmotrak Date: 2016-05-02 13:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eba31e937bfd 8155859: Problem list tools/pack200/Pack200Props.java Reviewed-by: rriggs ! test/ProblemList.txt Changeset: 8fc301b7b8f8 Author: ascarpino Date: 2016-05-02 16:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fc301b7b8f8 8140422: Add mechanism to allow non default root CAs to be not subject to algorithm restrictions Reviewed-by: mullan, xuelei ! make/gendata/Gendata-java.base.gmk ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIXMasterCertPathValidator.java ! src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java + src/java.base/share/classes/sun/security/util/AnchorCertificates.java + src/java.base/share/classes/sun/security/util/CertConstraintParameters.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/LegacyAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java ! src/java.base/share/conf/security/java.security ! test/sun/security/tools/jarsigner/Warning.java Changeset: 4da0f73ce03a Author: alanb Date: 2016-05-03 07:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4da0f73ce03a 8153925: (fs) WatchService hangs on GetOverlappedResult and locks directory (win) Reviewed-by: alanb Contributed-by: akashche at redhat.com, tmader at redhat.com ! src/java.base/windows/classes/sun/nio/fs/WindowsWatchService.java + test/java/nio/file/WatchService/DeleteInterference.java Changeset: f38c0650a60f Author: lana Date: 2016-05-05 17:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f38c0650a60f Added tag jdk-9+117 for changeset 4da0f73ce03a ! .hgtags Changeset: 1efd0e2eede6 Author: alanb Date: 2016-05-06 09:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1efd0e2eede6 Merge ! .hgtags ! make/gendata/Gendata-java.base.gmk + make/launcher/Launcher-jdk.jstatd.gmk - make/launcher/Launcher-jdk.jvmstat.rmi.gmk ! make/src/classes/build/tools/module/GenModuleInfoSource.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java ! src/java.base/share/classes/module-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java - src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java ! src/java.base/share/conf/security/java.security - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/beans/decoder/NewElementHandler.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Window.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/UIDefaults.java ! src/java.desktop/share/classes/javax/swing/text/NumberFormatter.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java - src/java.desktop/share/classes/sun/swing/UIClientPropertyKey.java - src/java.desktop/unix/native/common/awt/extutil.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.c - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingAreaP.h ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java ! src/jdk.jvmstat/share/classes/module-info.java ! src/jdk.policytool/share/classes/module-info.java ! test/ProblemList.txt - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java From adinn at redhat.com Fri May 6 08:47:23 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 6 May 2016 09:47:23 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C57E1.1080302@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> <572C4EFF.9070405@oracle.com> <572C52E1.4070203@redhat.com> <572C57E1.1080302@oracle.com> Message-ID: <572C5A1B.6030103@redhat.com> On 06/05/16 09:37, Alan Bateman wrote: > On 06/05/2016 09:16, Andrew Dinn wrote: >> : >> Yes, that's probably the best way to restrict access if you assume the >> agent is itself in a Jigsaw module. > Your agent may not be in a named module but it will be in an unnamed > module. Once you catch up on the concepts then I think it should be much > clearer. Oh, no, I grokked that. The way I intend to use it (i.e. compatibly with what happens in earlier JDKs) my agent it will be loaded by either the bootstrap or system loader and hence will be in their respective unnamed module. What I don't want to do is export the API provided by a concealed class/package that exposes a module check -free setAccessible to anything other than the Byteman class which uses it. If I follow your suggestion then I would potentially expose setAccessible to any class in the system classpath. So, rather than use module import/export checks I think I need to employ a caller class check. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Fri May 6 10:51:08 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 6 May 2016 11:51:08 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C5A1B.6030103@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C39B6.7000409@oracle.com> <446f2dfc-cfa8-bdb5-2e65-197241545723@gmail.com> <572C4EFF.9070405@oracle.com> <572C52E1.4070203@redhat.com> <572C57E1.1080302@oracle.com> <572C5A1B.6030103@redhat.com> Message-ID: <572C771C.7060207@oracle.com> On 06/05/2016 09:47, Andrew Dinn wrote: > What I don't want to do is export the API provided by a concealed > class/package that exposes a module check -free setAccessible to > anything other than the Byteman class which uses it. If I follow your > suggestion then I would potentially expose setAccessible to any class in > the system classpath. So, rather than use module import/export checks I > think I need to employ a caller class check. > A caller check seems overkill here but to your point, yes, if you coerce the target module to export packages to the unnamed module of the app class loader then it means that anything on the class path can access public types in those packages or they can use setAccessible(true) to hack into non-public types and members. From your earlier mails then it might be that you only need to export to the unnamed module of the boot loader so maybe this is not a concern. There are other more sophisticated approaches but I'm not sure if it's worth going into them now. For example deploying java agents as explicit modules (open question on whether this is needed in the short term) or using dynamic modules. I think that is a topic for another thread and another day. -Alan From peter.levart at gmail.com Fri May 6 14:34:49 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 6 May 2016 16:34:49 +0200 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C50B9.9010806@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <572C50B9.9010806@redhat.com> Message-ID: Hi, On 05/06/2016 10:07 AM, Andrew Dinn wrote: >> >Have you looked at injecting code in the victim module that invokes >> >Module addExports to export the packages to the Byteman modules (modules >> >plural because it sounds like the code is split between the unnamed >> >module of the app class loader and the unnamed modulie of the boot loader). > Not yet but I will do. n.b. for all practical purposes there is only one > Byteman module although which one it is depends upon whether the agent > jar is hoisted into the bootstrap or remains in the system loader. In > the former case the code is split but only in that the Main class gets > left in the system loader while all others sit in bootstrap. Since Main > merely acts as a trampoline it does not require any special module linkage. > regards, > > > Andrew Dinn So if Main agent class is always loaded by bootstrap loader / unnamed module, what about an API point in Instrumentation like: void addModuleExportsToBootstrapUnnamed(Module module, String pn); This would only allow adding exports from arbitrary module / package to bootstrap unnamed module, which would contain (part of) agent. This part of agent could also contain trampolines with regulated access from instrumented / tested classes. Every call to such exposed code would have to be done by invocation through Byteman layer then which could regulate access by any means including but not limited to exporting the Byteman code package to selected set of modules. Such limited addExports API would not allow to break encapsulation in arbitrary ways. Regards, Peter From tomas.zezula at oracle.com Fri May 6 14:38:35 2016 From: tomas.zezula at oracle.com (Tomas Zezula) Date: Fri, 6 May 2016 16:38:35 +0200 Subject: Ant JunitTask update to support JDK9 modules In-Reply-To: <57212E7A.9030003@oracle.com> References: <191E8BDB-8FCF-4549-9424-037A6A588BE0@oracle.com> <5721134E.7000402@oracle.com> <572123E0.90903@oracle.com> <57212E7A.9030003@oracle.com> Message-ID: > On 27 Apr 2016, at 23:26, Alex Buckley wrote: > > On 4/27/2016 1:41 PM, Jan Lahoda wrote: >> On 27.4.2016 21:30, Alex Buckley wrote: >>> Your changes skyrocket in complexity because your Ant setup involves >>> both ant-junit.jar and ant-junit4.jar. The JUnit task documentation >>> (https://ant.apache.org/manual/Tasks/junit.html) doesn't suggest this is >>> necessary or desirable. It's either pointless or dangerous to have both >>> JARs on the classpath, which is why the module system rejects them as >> >> I think it would be useful if you could elaborate on why using both >> ant-junit.jar and ant-junit4.jar is pointless or dangerous. What I see >> in the jars, the org.apache.tools.ant.taskdefs.optional.junit package is >> perfectly partitioned between the jars (there is no class that would be >> in both jars). It seems ant-junit4.jar cannot work by itself, without >> ant-junit.jar. I am not 100% sure what ant-junit4.jar does, but it seems >> it aids in running single test method in a JUnit 4 way. There appears to >> be some fallback to JUnit 3 style if the JUnit 4 style is not available, >> but it is hard to say if that is sufficient. So dropping (the content >> of) ant-junit4.jar would mean at least careful testing, but more >> probably a loss of a significant feature. > > Perfect partitioning of a split package is uncommon. The common case is some overlap of types, leading to obscure mix-and-match problems, so the module system rejects a split package unconditionally. Ant's redistribution of JUnit JARs (or perhaps its JUnit's own scheme for v3-to-v4 migration) is architected in a way that's at odds with the module system. > > It might be possible to make a case for relaxing the anti-split-package provision for automatic modules, since they're coming from the classpath world where every artifact is "open" to combination with artifacts elsewhere on the path. But that would reduce reliability, since generally it's a _feature_ that the module system warns: > > java.lang.module.ResolutionException: Modules ant.junit4 and ant.junit export package org.apache.tools.ant.taskdefs.optional.junit > to module hamcrest.core It?s exactly as Jan described. The ant-junit.jar and ant-junit4.jar are perfectly partitioned. Neither the ant-junit.jar nor the ant-junit4.jar is a redistribution of junit. The ant-junit.jar contains an implementation of Ant specific junit runner, the Ant does not use org.junit.runner.JUnitCore runner. The ant-junit4.jar contains just an adapter of Junit 4 API to JUnit 3.8 API for execution of tests and listening of events. These two jars were always an Ant implementation detail, there were put on classpath of the tested application automatically by an Ant. No change in this. The junit library needs to be either on classpath or newly on modulepath. I?ve described both these scenarios in the junit.html of the Ant manual. I personally prefer to put the test framework on classpath (unnamed module) with -XaddReads:${module.name}=ALL-UNNAMED -XaddExports:${module.name}/my.test=ALL-UNNAMED especially in case of generic generated build scripts. It?s very easy for an user to add another test framework just by adding it on classpath. There is no need to modify jvm options as the unnamed module is already covered. ? Tomas > > Alex From pbenedict at apache.org Fri May 6 14:43:15 2016 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 6 May 2016 09:43:15 -0500 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <572C50B9.9010806@redhat.com> Message-ID: I prefer the originally-proposed addExports() but allowing the layer to authorize it -- with a security check or other custom constraint the implementer chooses to code. Cheers, Paul On Fri, May 6, 2016 at 9:34 AM, Peter Levart wrote: > Hi, > > > On 05/06/2016 10:07 AM, Andrew Dinn wrote: > >> >Have you looked at injecting code in the victim module that invokes >>> >Module addExports to export the packages to the Byteman modules (modules >>> >plural because it sounds like the code is split between the unnamed >>> >module of the app class loader and the unnamed modulie of the boot >>> loader). >>> >> Not yet but I will do. n.b. for all practical purposes there is only one >> Byteman module although which one it is depends upon whether the agent >> jar is hoisted into the bootstrap or remains in the system loader. In >> the former case the code is split but only in that the Main class gets >> left in the system loader while all others sit in bootstrap. Since Main >> merely acts as a trampoline it does not require any special module >> linkage. >> regards, >> >> >> Andrew Dinn >> > > So if Main agent class is always loaded by bootstrap loader / unnamed > module, what about an API point in Instrumentation like: > > void addModuleExportsToBootstrapUnnamed(Module module, String pn); > > This would only allow adding exports from arbitrary module / package to > bootstrap unnamed module, which would contain (part of) agent. This part of > agent could also contain trampolines with regulated access from > instrumented / tested classes. Every call to such exposed code would have > to be done by invocation through Byteman layer then which could regulate > access by any means including but not limited to exporting the Byteman code > package to selected set of modules. > > Such limited addExports API would not allow to break encapsulation in > arbitrary ways. > > Regards, Peter > > From tomas.zezula at oracle.com Fri May 6 16:00:38 2016 From: tomas.zezula at oracle.com (Tomas Zezula) Date: Fri, 6 May 2016 18:00:38 +0200 Subject: Ant JunitTask update to support JDK9 modules In-Reply-To: <5721F26F.3060803@oracle.com> References: <191E8BDB-8FCF-4549-9424-037A6A588BE0@oracle.com> <5721F26F.3060803@oracle.com> Message-ID: Hi Alan, > On 28 Apr 2016, at 13:22, Alan Bateman wrote: > > On 27/04/2016 17:17, Tomas Zezula wrote: >> As seen in the modulepath and classpath mixture thread there are many possibilities how to execute unit tests. >> I've sumarised them on the ant-dev mailing list in the context of Apache Ant in http://mail-archives.apache.org/mod_mbox/ant-dev/201604.mbox/%3CAFE6C849-0622-44D1-9FF7-3A6CA4832F82 at oracle.com%3E >> As a result of the discussion I've created a pull request for Apache Ant JUnitTask to support JDK9 modules: >> https://github.com/apache/ant/pull/18 > On the qualified export approach then one thing you say is that it requires compiling with a "single multi-module compilation". You are right that compiling MyLibrary with a qualified export to MyLibraryTests will require MyLibraryTests to be on the module source path but you should be able to compile them separately if you want, this should do it: > > javac -modulesourcepath src -d mods $(find src/MyLibrary -name "*.java") > javac -modulepath mods -d mods/MyLibraryTests $(find src/MyLibraryTests -name "*.java?) Yes, this works. The MyLibrary is compiled with -modulesourcepath src to make MyLibraryTests module resolvable from MyLibrary?s module-info. > > > > On the split package issue then ant-junit and ant-junit4.jar does seem unusual. Do you know if they are in the same package because one needs package private access to something in the other? I believe that they do not have package private dependencies. And the packaging comes historically from the source layout. The sources are in the same package and then packed into ant-junit (the optional JUnitTask and Ant?s test runner) ant-junit4 (containing just the Adapter from JUnit 4 API to Ant 3.8 API). > I have no interest in making the options more complicated but if you really want to then -Xpatch can patch automatic modules and so `-Xpatch:ant.junit=ant-junit4.jar` will eventually overlay the contents of ant-junit4.jar over module ant.junit. Thanks Alan, it?s good to know this. These two jars are Ant implementation details, they were always put on classpath by Ant. I will try to keep them in the UNNAMED-MODULE. There is no need to make them automatic modules because no one depends on them, they are only a test launcher. ? Tomas > > -Alan From Alan.Bateman at oracle.com Sat May 7 08:08:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 7 May 2016 09:08:40 +0100 Subject: NPE in InstrumentationImpl.transform() In-Reply-To: References: Message-ID: <572DA288.6080203@oracle.com> On 05/05/2016 15:56, Michael Rasmussen wrote: > Hi > > Loading classes from the unnamed boot module (for instance an agent) causes: > *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" > with message transform method call failed at JPLISAgent.c line: 884 > > This is fixed in jdk9/dev so I expect it will be next week's build (jdk-9+118). -Alan From adinn at redhat.com Mon May 9 07:39:54 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 9 May 2016 08:39:54 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <572C50B9.9010806@redhat.com> Message-ID: <57303ECA.5090803@redhat.com> Hi Peter, On 06/05/16 15:34, Peter Levart wrote: > On 05/06/2016 10:07 AM, Andrew Dinn wrote: >> Not yet but I will do. n.b. for all practical purposes there is only one >> Byteman module although which one it is depends upon whether the agent >> jar is hoisted into the bootstrap or remains in the system loader. In >> the former case the code is split but only in that the Main class gets >> left in the system loader while all others sit in bootstrap. Since Main >> merely acts as a trampoline it does not require any special module linkage. > . . . > So if Main agent class is always loaded by bootstrap loader / unnamed I am afraid you have that the wrong way around. An agent's Main class is always loaded by the /system/ loader. If requested, my agent's Main class will use method appendToBootstrapClassLoaderSearch to place the agent jar file into the bootstrap path, ensuring that /everything else/ is loaded by the bootstrap loader. However, absent such a request it will retain the status quo leaving /everything/ to be loaded by the system loader. If I were able to split the agent code into two jars with a core jar hoisted into the bootstrap and the rest of the code retained in the system path then as you point out that would allow the core jar to include classes which do stuff that is normally restricted. This might also allow me to ensure that the API classes were in the right place while leaving the rest of the agent in the system path. I'm not sure if I can achieve this sort of split (using some combination of dynamic loading and interfaces) but I think it would probably require some significant changes to achieve it. My main problem with that is not the refactoring it would require but the fact that Byteman would need to know where the core jar is located in order to hoist it -- the Instrument API to extend the bootstrap path takes a path to the jar in the file system. So, users would have to configure this as an agent option on the -javaagent command line or as an argument to the utility that loads the agent dynamically. This extra configuration is already required when users want the current agent jar to be hoisted -- but it's actually turned out to be a noticeable barrier to uptake (many users don't really understand what the difference between the boot and sys loaders is, never mind how link requirements constrain adding jars to one or other). Requiring them to configure a different jar in the default case risks making normal use problematic for many users. One possibility I am still considering is to synthesize the class I require to do the restricted accesses and write it to a jar file in a tmp dir. I could then access it via the bootstrap loader and create an instance which I could then use to obtain the desired access. That might be a better option although I am still thinking about the security implications. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From chris.hegarty at oracle.com Mon May 9 13:05:15 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 May 2016 14:05:15 +0100 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> Message-ID: <57308B0B.9040202@oracle.com> On 05/05/16 19:42, Alexandre (Shura) Iline wrote: > Chris, could you please take another look: > http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/ This looks ok to me Shura, maybe just 'mrjar' for the directory name? Since there are file moves can you please prepare the changeset, and I will push it for you. -Chris. > What I have discovered is that jdk.zipfs was used to access jars on the classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the class path through the environment removed dependency on the zipfs. > > Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. > > Thank you. > > Shura > >> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: >> >> On 4 May 2016, at 14:32, Alan Bateman wrote: >>> >>> On 04/05/2016 11:24, Chris Hegarty wrote: >>>> : >>>> The tests cause compilation of test library classes, but only some tests >>>> actually use the methods that provoke compilation. Similar to above, tests >>>> that don?t actually compile anything could depend on just java.compiler. >>>> >>>> This is all to fragile and may cause problems with future refactoring. I >>>> think we should add the same set of @moduels to all these tests, rather >>>> than an individual set determined by intimate knowledge of the inner >>>> workings of the test. >>>> >>>> @modules java.compiler >>>> jdk.compiler >>>> jdk.zipfs >>>> jdk.jartool >>>> >>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>>> >>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. >> >> I think that would be better. >> >> -Chris. > From james.laskey at oracle.com Mon May 9 13:08:37 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 9 May 2016 10:08:37 -0300 Subject: Having problem building jdk9-dev Message-ID: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> Generating blacklisted certs java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:366) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:184) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) at java.lang.Class.forName0(java.base at 9-ea/Native Method) at java.lang.Class.forName(java.base at 9-ea/Class.java:294) at build.tools.generatebreakiteratordata.GenerateBreakIteratorData.generateFiles(GenerateBreakIteratorData.java:94) at build.tools.generatebreakiteratordata.GenerateBreakIteratorData.main(GenerateBreakIteratorData.java:66) From james.laskey at oracle.com Mon May 9 14:07:15 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 9 May 2016 11:07:15 -0300 Subject: Having problem building jdk9-dev In-Reply-To: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> References: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> Message-ID: Mac OS X - reproducible with a clean repo. > On May 9, 2016, at 10:08 AM, Jim Laskey (Oracle) wrote: > > > > > Generating blacklisted certs > java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules > at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:366) > at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:184) > at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) > at java.lang.Class.forName0(java.base at 9-ea/Native Method) > at java.lang.Class.forName(java.base at 9-ea/Class.java:294) > at build.tools.generatebreakiteratordata.GenerateBreakIteratorData.generateFiles(GenerateBreakIteratorData.java:94) > at build.tools.generatebreakiteratordata.GenerateBreakIteratorData.main(GenerateBreakIteratorData.java:66) > From james.laskey at oracle.com Mon May 9 17:41:18 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 9 May 2016 14:41:18 -0300 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input Message-ID: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8155237 From alexandre.iline at oracle.com Mon May 9 19:47:26 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 9 May 2016 12:47:26 -0700 Subject: RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences In-Reply-To: <572B9B34.8070406@oracle.com> References: <9891E5D7-3459-40DF-B76B-784F1F9628AF@oracle.com> <37188D23-E80B-427F-9859-68A3A66C8E02@oracle.com> <5729C9D1.5040506@oracle.com> <5729F9DE.4080909@oracle.com> <907375E5-2BB6-42FF-9259-3CE8A2D06665@oracle.com> <82FE24B5-351E-4962-9014-5AFB66FA9412@oracle.com> <572B9B34.8070406@oracle.com> Message-ID: <08E9DC80-CCF2-45EF-9F36-F8269E16A9E3@oracle.com> > On May 5, 2016, at 12:12 PM, Jonathan Gibbons wrote: > > There is potentially a separate discussion here, as to whether javac should "force" the provision of a jar-fs provider. > > Strictly speaking, javac does not inherently require it. You can use javac just fine, with files in the system image, and source and class files in the default file system. But I suspect most folk would be suprised if they ca across an image for which javac could not read jar files. What would definitely help is a error message which specifies the jar name. At least in my case that would, as I would not miss the message. Shura > > -- Jon > > On 05/05/2016 12:01 PM, Alexandre (Shura) Iline wrote: >>> On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline wrote: >>> Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl. >> I take this ^^^^^^ back, as the error was there all along: "java.nio.file.ProviderNotFoundException: no provider found for .jar files? >> >> The fix is valid, then, is and waiting for a review. >> >> Shura >> >>> Thank you. >>> >>> Shura >>> >>>> On May 4, 2016, at 8:30 AM, Chris Hegarty wrote: >>>> >>>> On 4 May 2016, at 14:32, Alan Bateman wrote: >>>>> On 04/05/2016 11:24, Chris Hegarty wrote: >>>>>> : >>>>>> The tests cause compilation of test library classes, but only some tests >>>>>> actually use the methods that provoke compilation. Similar to above, tests >>>>>> that don?t actually compile anything could depend on just java.compiler. >>>>>> >>>>>> This is all to fragile and may cause problems with future refactoring. I >>>>>> think we should add the same set of @moduels to all these tests, rather >>>>>> than an individual set determined by intimate knowledge of the inner >>>>>> workings of the test. >>>>>> >>>>>> @modules java.compiler >>>>>> jdk.compiler >>>>>> jdk.zipfs >>>>>> jdk.jartool >>>>>> >>>>>> with the addition of jdk.httpserver for MultiReleaseJarHttpProperties. >>>>>> >>>>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server. >>>> I think that would be better. >>>> >>>> -Chris. > From chris.hegarty at oracle.com Tue May 10 08:50:42 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 10 May 2016 09:50:42 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> <5028AF86-C8DD-431E-8499-0022B8D90C85@oracle.com> <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> Message-ID: On 9 May 2016, at 20:43, Richard Opalka wrote: > Fixed in JBoss Marshalling upstream. Thanks for fixing this, and getting back to us on the list. I assume then that, at least, this part of JBoss is working on JDK 9 b115, right? -Chris. > Thanks, > > Rio > > On 04/27/2016 11:54 PM, Chris Hegarty wrote: >> Hi Rio, >> >> >>> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner class >>> >>> in jdk.unsupported module: >>> >>> java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory$GetReflectionFactoryAction >>> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:366) >>> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:184) >>> at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) >>> at org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47) >> GetReflectionFactoryAction is a convenience class for acquiring >> the capability to instantiate reflective objects. >> >> As part of JEP 260, we retained the single getReflectionFactory >> accessor. You can replace your usage with the following: >> >> PrivilegedAction pa = new PrivilegedAction() { >> @Override >> public ReflectionFactory run() { >> return ReflectionFactory.getReflectionFactory(); >> } >> }; >> >> -Chris. >> > From claes.redestad at oracle.com Tue May 10 09:48:16 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 10 May 2016 11:48:16 +0200 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> Message-ID: <5731AE60.6000106@oracle.com> Hi, this looks good. Testing cold[1] startup on my machine I see an improvement ranging from around 30-40ms on a minimal test to around 60-80ms on a larger app. Warm startup and footprint measures seem largely unaffected, as would be expected. I also did an experiment with allowing secondary ordering in the plugin so that java.base could be ordered directly after the classlist-ordered resources but impact got lost in the noise, so it doesn't seem worthwhile to complicate things further. Thanks! /Claes [1] simulated by calling echo 3 > /proc/sys/vm/drop_caches between runs On 2016-05-09 19:41, Jim Laskey (Oracle) wrote: > Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. > > http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8155237 > From Alan.Bateman at oracle.com Tue May 10 09:59:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 May 2016 10:59:20 +0100 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> Message-ID: <5731B0F8.7060904@oracle.com> On 09/05/2016 18:41, Jim Laskey (Oracle) wrote: > Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. > > http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8155237 > I also see improvements with cold start so I think this is good and we should update the jlink usage in /make/Images.gmk to specify --order-resources. One thing about this is that the argument to the plugin is ambiguous, it would be better if there were some way to make it clear whether the value is a file or class names/pattern. I just wonder if the file name should use @file instead. Related is that value of order-resources.description should probably be updated to document the file name approach too. Style wise then you've mixed old and new I/O which seems unnecessary. There are a few other cleanups that could be done in this plugin but maybe for a cleanup round at some point. -Alan From alexandre.iline at oracle.com Tue May 10 19:00:19 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 10 May 2016 12:00:19 -0700 Subject: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl Message-ID: Hi. Please review the fix: http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/ In the failing tests I have replaced java.management with jdk.management in @modules. Besides the failed tests I have scanned all the tests which call ManagementFactory.getPlatformMBeanServer(?). Those which were not failing were already declaring dependency on jdk.management, sometimes together with java.management. Declaring java.management in such case is not needed, because java.management is a dependency of jdk.management. Shura From mandy.chung at oracle.com Tue May 10 19:49:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 12:49:16 -0700 Subject: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl In-Reply-To: References: Message-ID: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> > On May 10, 2016, at 12:00 PM, Alexandre (Shura) Iline wrote: > > Hi. > > Please review the fix: > http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/ > > In the failing tests I have replaced java.management with jdk.management in @modules. > > Besides the failed tests I have scanned all the tests which call ManagementFactory.getPlatformMBeanServer(?). Those which were not failing were already declaring dependency on jdk.management, sometimes together with java.management. Declaring java.management in such case is not needed, because java.management is a dependency of jdk.management. In fact JDK-8155993 reveals a potential bug in the VM support for java.lang.management when jdk.management module is not present. I have no objection to change these tests to run with jdk.management and this patch looks fine. But we should keep JDK-8155993 open and provide a small test to reproduce NCDFE when running with an image with only java.management but no jdk.management module. Mandy From alexandre.iline at oracle.com Tue May 10 20:03:15 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 10 May 2016 13:03:15 -0700 Subject: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl In-Reply-To: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> References: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> Message-ID: <0F8E9182-C44F-4831-8F8E-7FA055CFE1C0@oracle.com> OK, I will do that, Mandy. Should I create a separate bug (subtask) for this test fixes? Shura > On May 10, 2016, at 12:49 PM, Mandy Chung wrote: > > >> On May 10, 2016, at 12:00 PM, Alexandre (Shura) Iline wrote: >> >> Hi. >> >> Please review the fix: >> http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/ >> >> In the failing tests I have replaced java.management with jdk.management in @modules. >> >> Besides the failed tests I have scanned all the tests which call ManagementFactory.getPlatformMBeanServer(?). Those which were not failing were already declaring dependency on jdk.management, sometimes together with java.management. Declaring java.management in such case is not needed, because java.management is a dependency of jdk.management. > > In fact JDK-8155993 reveals a potential bug in the VM support for java.lang.management when jdk.management module is not present. > > I have no objection to change these tests to run with jdk.management and this patch looks fine. But we should keep JDK-8155993 open and provide a small test to reproduce NCDFE when running with an image with only java.management but no jdk.management module. > > Mandy > From mandy.chung at oracle.com Tue May 10 20:56:32 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 10 May 2016 13:56:32 -0700 Subject: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl In-Reply-To: <0F8E9182-C44F-4831-8F8E-7FA055CFE1C0@oracle.com> References: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> <0F8E9182-C44F-4831-8F8E-7FA055CFE1C0@oracle.com> Message-ID: <1940EC3A-2E61-41E1-9E85-9765ED7F8D3C@oracle.com> > On May 10, 2016, at 1:03 PM, Alexandre (Shura) Iline wrote: > > OK, I will do that, Mandy. > > Should I create a separate bug (subtask) for this test fixes? Create a new bug is good. Send me a committed changeset and I can push it for you. Mandy From ropalka at redhat.com Wed May 11 06:40:47 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 11 May 2016 08:40:47 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> <5028AF86-C8DD-431E-8499-0022B8D90C85@oracle.com> <1d3d6b24-5168-cc5c-942b-2bbda7f2d257@redhat.com> Message-ID: <857c3a19-1969-b96d-63dc-bfb24d70cba6@redhat.com> On 05/10/2016 10:50 AM, Chris Hegarty wrote: > On 9 May 2016, at 20:43, Richard Opalka wrote: > >> Fixed in JBoss Marshalling upstream. > Thanks for fixing this, and getting back to us on the list. > > I assume then that, at least, this part of JBoss is working on JDK 9 b115, right? Yes. Rio > > -Chris. > >> Thanks, >> >> Rio >> >> On 04/27/2016 11:54 PM, Chris Hegarty wrote: >>> Hi Rio, >>> >>> >>>> We are missing sun/reflect/ReflectionFactory$GetReflectionFactoryAction inner class >>>> >>>> in jdk.unsupported module: >>>> >>>> java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory$GetReflectionFactoryAction >>>> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-internal/BuiltinClassLoader.java:366) >>>> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-internal/ClassLoaders.java:184) >>>> at java.lang.ClassLoader.loadClass(java.base at 9-internal/ClassLoader.java:419) >>>> at org.jboss.marshalling.reflect.SerializableClass.(SerializableClass.java:47) >>> GetReflectionFactoryAction is a convenience class for acquiring >>> the capability to instantiate reflective objects. >>> >>> As part of JEP 260, we retained the single getReflectionFactory >>> accessor. You can replace your usage with the following: >>> >>> PrivilegedAction pa = new PrivilegedAction() { >>> @Override >>> public ReflectionFactory run() { >>> return ReflectionFactory.getReflectionFactory(); >>> } >>> }; >>> >>> -Chris. >>> From gunnar at hibernate.org Wed May 11 07:45:13 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 11 May 2016 09:45:13 +0200 Subject: module-info.java just causes problems In-Reply-To: <572A4062.5080601@redhat.com> References: <572A4062.5080601@redhat.com> Message-ID: This also ties in with the question of overriding required modules dependencies I raised recently [1]. Assuming a developer needs to change the module requirements of one of the modules they use, this means - as far as I understand the current design - they need to get the source of the module's module-info.java, adapt it as needed and re-compile it. Given how often I find myself re-working transitive dependency sets of Maven artifacts I depend on (e.g. to exclude things not needed for my case, or to only have a single source of the javax.transaction packages), I hope there'll be a way for controlling these things which doesn't include reworking module-info.java as described above. --Gunnar [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007617.html 2016-05-04 20:33 GMT+02:00 David M. Lloyd : > Tools like Maven and JUnit are yet still having a difficult time coping > with the oddball module-info.java file. Can we just drop this thing and > let the layer provide metadata for the module? This way of defining module > metadata is clearly causing trouble. Reference: all previous arguments > from non-Oracle people over the last 5 years or so. > > So far none of our software actually functions with Jigsaw, and the > prospect is not improving. In the meantime the EG is alternately > completely dead or in a state of > we'll-register-your-issue-but-cannot-help-resolve-them mode. I'm highly > concerned. > -- > - DML > From aleksey.shipilev at oracle.com Wed May 11 11:14:29 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 11 May 2016 14:14:29 +0300 Subject: Having problem building jdk9-dev In-Reply-To: References: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> Message-ID: <57331415.3010506@oracle.com> Got the same today, and figured it only fails with JDK 9 as the boot JDK. Builds fine with JDK 8 as boot JDK. Filed: https://bugs.openjdk.java.net/browse/JDK-8156740 Thanks, -Aleksey On 05/09/2016 05:07 PM, Jim Laskey (Oracle) wrote: > Mac OS X - reproducible with a clean repo. > > >> On May 9, 2016, at 10:08 AM, Jim Laskey (Oracle) wrote: >> >> >> >> >> Generating blacklisted certs >> java.lang.ClassNotFoundException: sun.text.resources.BreakIteratorRules >> at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:366) >> at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:184) >> at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) >> at java.lang.Class.forName0(java.base at 9-ea/Native Method) >> at java.lang.Class.forName(java.base at 9-ea/Class.java:294) >> at build.tools.generatebreakiteratordata.GenerateBreakIteratorData.generateFiles(GenerateBreakIteratorData.java:94) >> at build.tools.generatebreakiteratordata.GenerateBreakIteratorData.main(GenerateBreakIteratorData.java:66) >> > From Alan.Bateman at oracle.com Wed May 11 11:28:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 12:28:17 +0100 Subject: Having problem building jdk9-dev In-Reply-To: <57331415.3010506@oracle.com> References: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> <57331415.3010506@oracle.com> Message-ID: <57331751.1040709@oracle.com> On 11/05/2016 12:14, Aleksey Shipilev wrote: > Got the same today, and figured it only fails with JDK 9 as the boot > JDK. Builds fine with JDK 8 as boot JDK. Filed: > https://bugs.openjdk.java.net/browse/JDK-8156740 > You can never guarantee that the JDK N in development will build with a older build of JDK N, there is just too much churn. Boot cycles builds should be fine of course, meaning a JDK build should be able to build itself (make bootcycle-images). -Alan. From aleksey.shipilev at oracle.com Wed May 11 11:35:05 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 11 May 2016 14:35:05 +0300 Subject: Having problem building jdk9-dev In-Reply-To: <57331751.1040709@oracle.com> References: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> <57331415.3010506@oracle.com> <57331751.1040709@oracle.com> Message-ID: <573318E9.2030804@oracle.com> On 05/11/2016 02:28 PM, Alan Bateman wrote: > On 11/05/2016 12:14, Aleksey Shipilev wrote: >> Got the same today, and figured it only fails with JDK 9 as the boot >> JDK. Builds fine with JDK 8 as boot JDK. Filed: >> https://bugs.openjdk.java.net/browse/JDK-8156740 >> > You can never guarantee that the JDK N in development will build with a > older build of JDK N, there is just too much churn. Boot cycles builds > should be fine of course, meaning a JDK build should be able to build > itself (make bootcycle-images). No problem with that. Let's close the bug with WNF and this description then, so the next person facing this particular issue knows the corrective action immediately. Thanks, -Aleksey From james.laskey at oracle.com Wed May 11 11:48:37 2016 From: james.laskey at oracle.com (James Laskey) Date: Wed, 11 May 2016 08:48:37 -0300 Subject: Having problem building jdk9-dev In-Reply-To: <573318E9.2030804@oracle.com> References: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> <57331415.3010506@oracle.com> <57331751.1040709@oracle.com> <573318E9.2030804@oracle.com> Message-ID: <6135110E-E907-4536-8B2C-4222AF073143@oracle.com> Wonder if we should have a configuration warning when an inappropriate version is used. Sent from my iPhone > On May 11, 2016, at 8:35 AM, Aleksey Shipilev wrote: > >> On 05/11/2016 02:28 PM, Alan Bateman wrote: >>> On 11/05/2016 12:14, Aleksey Shipilev wrote: >>> Got the same today, and figured it only fails with JDK 9 as the boot >>> JDK. Builds fine with JDK 8 as boot JDK. Filed: >>> https://bugs.openjdk.java.net/browse/JDK-8156740 >> You can never guarantee that the JDK N in development will build with a >> older build of JDK N, there is just too much churn. Boot cycles builds >> should be fine of course, meaning a JDK build should be able to build >> itself (make bootcycle-images). > > No problem with that. Let's close the bug with WNF and this description > then, so the next person facing this particular issue knows the > corrective action immediately. > > Thanks, > -Aleksey > > From claes.redestad at oracle.com Wed May 11 12:30:16 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 11 May 2016 14:30:16 +0200 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> Message-ID: <573325D8.30407@oracle.com> Updated changes look good, too. I will file a new RFE to deal with the top level changes to actually enable the use of this functionality. Thanks! /Claes On 2016-05-09 19:41, Jim Laskey (Oracle) wrote: > Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. > > http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8155237 > From Alan.Bateman at oracle.com Wed May 11 12:35:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 13:35:19 +0100 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <573325D8.30407@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> <573325D8.30407@oracle.com> Message-ID: <57332707.8090009@oracle.com> On 11/05/2016 13:30, Claes Redestad wrote: > Updated changes look good, too. > > I will file a new RFE to deal with the top level changes to actually > enable the use of this functionality. Is there any reason not to update the jlink usage in Images.gmk as part of this? -Alan From Alan.Bateman at oracle.com Wed May 11 12:39:53 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 13:39:53 +0100 Subject: module-info.java just causes problems In-Reply-To: References: <572A4062.5080601@redhat.com> Message-ID: <57332819.8060409@oracle.com> On 11/05/2016 08:45, Gunnar Morling wrote: > : > > Assuming a developer needs to change the module requirements of one of the > modules they use, this means - as far as I understand the current design - > they need to get the source of the module's module-info.java, adapt it as > needed and re-compile it. Assuming there are actually good reasons for changing it then I would hope you would recompile the module completely, not just module declaration as otherwise it may not be in sync with the code in the module. -Alan From forax at univ-mlv.fr Wed May 11 12:50:20 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 11 May 2016 14:50:20 +0200 (CEST) Subject: module-info.java just causes problems In-Reply-To: <57332819.8060409@oracle.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> Message-ID: <1994747081.1333182.1462971020761.JavaMail.zimbra@u-pem.fr> Like Alan, i hope you will re-compile the module, it's more safe. Otherwise, you can use javap to dump the actual module-info.java from the module-info.class, patch it, recompile it with javac and then do a jar --update to replace the module-info.class in the jar cheers, R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "Gunnar Morling" > Cc: "jigsaw-dev" > Envoy?: Mercredi 11 Mai 2016 14:39:53 > Objet: Re: module-info.java just causes problems > > On 11/05/2016 08:45, Gunnar Morling wrote: > > : > > > > Assuming a developer needs to change the module requirements of one of the > > modules they use, this means - as far as I understand the current design - > > they need to get the source of the module's module-info.java, adapt it as > > needed and re-compile it. > Assuming there are actually good reasons for changing it then I would > hope you would recompile the module completely, not just module > declaration as otherwise it may not be in sync with the code in the module. > > -Alan > From james.laskey at oracle.com Wed May 11 12:50:56 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 11 May 2016 09:50:56 -0300 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <57332707.8090009@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> <573325D8.30407@oracle.com> <57332707.8090009@oracle.com> Message-ID: Only that experimentation is still ongoing. I have an agreement with Claes that he will make that change when he is satisfied with an improvement. > On May 11, 2016, at 9:35 AM, Alan Bateman wrote: > > > > On 11/05/2016 13:30, Claes Redestad wrote: >> Updated changes look good, too. >> >> I will file a new RFE to deal with the top level changes to actually enable the use of this functionality. > Is there any reason not to update the jlink usage in Images.gmk as part of this? > > -Alan From david.lloyd at redhat.com Wed May 11 12:52:39 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 11 May 2016 07:52:39 -0500 Subject: module-info.java just causes problems In-Reply-To: <57332819.8060409@oracle.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> Message-ID: <57332B17.1040708@redhat.com> On 05/11/2016 07:39 AM, Alan Bateman wrote: > On 11/05/2016 08:45, Gunnar Morling wrote: >> : >> >> Assuming a developer needs to change the module requirements of one of >> the >> modules they use, this means - as far as I understand the current >> design - >> they need to get the source of the module's module-info.java, adapt it as >> needed and re-compile it. > Assuming there are actually good reasons for changing it then I would > hope you would recompile the module completely, not just module > declaration as otherwise it may not be in sync with the code in the module. In practice this happens a lot. A module's dependency graph depends just as much on the environment as it depends on the classes in the module (if not more so). Modules are merged and split, replaced with compatibility stubs, renamed, etc. If you have to recompile every module for every environment, a lot of the benefit of modularity and compatibility-by-ABI is lost; changes to a module in an environment would lead to a massive cascade of recompilation. -- - DML From Alan.Bateman at oracle.com Wed May 11 12:56:50 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 13:56:50 +0100 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> <573325D8.30407@oracle.com> <57332707.8090009@oracle.com> Message-ID: <57332C12.1070502@oracle.com> On 11/05/2016 13:50, Jim Laskey (Oracle) wrote: > Only that experimentation is still ongoing. I have an agreement with Claes that he will make that change when he is satisfied with an improvement. No problem splitting this up as I had assumed we were already seen improvements with cold start. -Alan. From Alan.Bateman at oracle.com Wed May 11 13:15:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 14:15:07 +0100 Subject: module-info.java just causes problems In-Reply-To: <57332B17.1040708@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> Message-ID: <5733305B.2070408@oracle.com> On 11/05/2016 13:52, David M. Lloyd wrote: > > In practice this happens a lot. A module's dependency graph depends > just as much on the environment as it depends on the classes in the > module (if not more so). Modules are merged and split, replaced with > compatibility stubs, renamed, etc. If you have to recompile every > module for every environment, a lot of the benefit of modularity and > compatibility-by-ABI is lost; changes to a module in an environment > would lead to a massive cascade of recompilation. The module system can support many refactoring scenarios, including merging and splitting. I can see myself refactoring modules that I maintain, I'm less sure that I want to refactor modules coming from other projects. If I found myself refactoring modules from elsewhere then I would expect to have to build and test those modules, it would be strange not to do and I don't understand how you can get away with this when changing code in those modules. It might be useful if you could lay out a specific scenario as it may be that we are talking completely different things. -Alan. From david.lloyd at redhat.com Wed May 11 14:14:27 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 11 May 2016 09:14:27 -0500 Subject: module-info.java just causes problems In-Reply-To: <5733305B.2070408@oracle.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> Message-ID: <57333E43.7080200@redhat.com> On 05/11/2016 08:15 AM, Alan Bateman wrote: > > On 11/05/2016 13:52, David M. Lloyd wrote: >> >> In practice this happens a lot. A module's dependency graph depends >> just as much on the environment as it depends on the classes in the >> module (if not more so). Modules are merged and split, replaced with >> compatibility stubs, renamed, etc. If you have to recompile every >> module for every environment, a lot of the benefit of modularity and >> compatibility-by-ABI is lost; changes to a module in an environment >> would lead to a massive cascade of recompilation. > The module system can support many refactoring scenarios, including > merging and splitting. I can see myself refactoring modules that I > maintain, I'm less sure that I want to refactor modules coming from > other projects. If I found myself refactoring modules from elsewhere > then I would expect to have to build and test those modules, it would be > strange not to do and I don't understand how you can get away with this > when changing code in those modules. It might be useful if you could lay > out a specific scenario as it may be that we are talking completely > different things. We package several hundred JARs in our modular environment today, only some of which originate in-house. The dependency information for these modules is established not by the author of these JARs, but by us. The Maven artifact for such a JAR might stipulate certain things, like Log4j or a certain version of ASM. When we distribute that JAR though, we don't package the exact artifacts and versions of the dependencies that were stipulated in the Maven POM; instead we package single consistent versions which are ABI-compatible with all of its dependents, or maybe even a completely different artifact that meets the same ABI but performs its functions in a different manner. Over time the environment we distribute evolves, and we split or join modules, or we rename old modules to introduce a new major version of the same module in parallel, or we replace one implementation with another. When we do this we may chose to deprecate or eliminate a module from our environment. Thus we update all the module descriptors that reference the deprecated module, and set new dependencies on them, and after a certain amount of time, we delete the old module name. None of the artifacts that we package are impacted by this process, and generally no recompilation is necessary: after all, many of these artifacts come directly from Maven or are otherwise built independently at an earlier time outside of the context of our target environment. It's the ABI that matters; as long as that doesn't change (in an incompatible way), recompilation should never be necessary. I think "recompile just to be safe" puts us squarely into "turn it off and on again" territory, logically speaking. -- - DML From stef at epardaud.fr Wed May 11 14:21:21 2016 From: stef at epardaud.fr (Stephane Epardaud) Date: Wed, 11 May 2016 16:21:21 +0200 Subject: module-info.java just causes problems In-Reply-To: <57333E43.7080200@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> Message-ID: <57333FE1.4060903@epardaud.fr> I don't understand the problem with the module-info.java class. We also repackage jars to add module descriptors (for OSGi, Maven and JBoss Modules) and for Jigsaw we generate the `module-info.class` file when we need to repackage them. Between this binary format and XML or MANIFEST.MF, I don't see why it makes a big difference? I wouldn't recompile the module, though, just as I don't recompile them when we change the other manifests. From david.lloyd at redhat.com Wed May 11 14:44:58 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 11 May 2016 09:44:58 -0500 Subject: module-info.java just causes problems In-Reply-To: <57333FE1.4060903@epardaud.fr> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57333FE1.4060903@epardaud.fr> Message-ID: <5733456A.7090501@redhat.com> On 05/11/2016 09:21 AM, Stephane Epardaud wrote: > I don't understand the problem with the module-info.java class. We also > repackage jars to add module descriptors (for OSGi, Maven and JBoss > Modules) and for Jigsaw we generate the `module-info.class` file when we > need to repackage them. Between this binary format and XML or > MANIFEST.MF, I don't see why it makes a big difference? > > I wouldn't recompile the module, though, just as I don't recompile them > when we change the other manifests. If you have a .class file, you have to generate it with something. I think Alan is arguing that it should be done with javac, but we'd likely end up using something else. In our case, just editing an XML file and doing "git commit" is easier than running a tool to read and update a binary descriptor inside an artifact though, particularly as we don't package the actual artifacts. Thus we'd have to package a textual descriptor of some sort, to which we'd then have to apply a tool in order to update our final packaged artifacts, making it that much more difficult to use artifacts that already exist (e.g. from Maven). In addition it is common for our users to examine or modify module descriptors; having them be external is very useful for this purpose. We also allow features like specification of properties for modules which can be read, specification of module permission sets, and filtering of artifact resources and module dependencies in various ways. -- - DML From stef at epardaud.fr Wed May 11 14:55:39 2016 From: stef at epardaud.fr (Stephane Epardaud) Date: Wed, 11 May 2016 16:55:39 +0200 Subject: module-info.java just causes problems In-Reply-To: <5733456A.7090501@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57333FE1.4060903@epardaud.fr> <5733456A.7090501@redhat.com> Message-ID: <573347EB.9030804@epardaud.fr> I expect such a tool to generate module-info.class to materialise. I personally use ClassWriter from the JDK tools for that. Anyone with a JDK has that module and can write that tool trivially. The JBoss Modules use-case (and the Ceylon distrib one) is rather uncommon, though, IMO. Most people deal with modules as Maven modules and they can't really rewrite the descriptors as in most cases they're not in the jar and Maven will only use descriptors from the repos and not in any flat folder where you have Maven jars (I think). In Maven-land you deal with this via external (to the modules being overridden) overrides, which Java Modules don't support ATM. OSGi is already a pain to override because you have to extract the manifest, edit it and put it back. Here a tool would help. Overriding Ceylon modules is done via external overrides too, otherwise you'd have to extract the manifest (which is also a .class), edit it and put it back, for which we'd have generated tooling if there was ever demand for that (but there hasn't been yet). All that to say, in general after-packaging editing of module descriptors is already either rare or hard. I don't think module-info.class changes that much. On 11/05/16 16:44, David M. Lloyd wrote: > On 05/11/2016 09:21 AM, Stephane Epardaud wrote: >> I don't understand the problem with the module-info.java class. We also >> repackage jars to add module descriptors (for OSGi, Maven and JBoss >> Modules) and for Jigsaw we generate the `module-info.class` file when we >> need to repackage them. Between this binary format and XML or >> MANIFEST.MF, I don't see why it makes a big difference? >> >> I wouldn't recompile the module, though, just as I don't recompile them >> when we change the other manifests. > > If you have a .class file, you have to generate it with something. I > think Alan is arguing that it should be done with javac, but we'd > likely end up using something else. In our case, just editing an XML > file and doing "git commit" is easier than running a tool to read and > update a binary descriptor inside an artifact though, particularly as > we don't package the actual artifacts. Thus we'd have to package a > textual descriptor of some sort, to which we'd then have to apply a > tool in order to update our final packaged artifacts, making it that > much more difficult to use artifacts that already exist (e.g. from > Maven). > > In addition it is common for our users to examine or modify module > descriptors; having them be external is very useful for this purpose. > > We also allow features like specification of properties for modules > which can be read, specification of module permission sets, and > filtering of artifact resources and module dependencies in various ways. From gunnar at hibernate.org Wed May 11 14:57:55 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 11 May 2016 16:57:55 +0200 Subject: module-info.java just causes problems In-Reply-To: <57333E43.7080200@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> Message-ID: Recompiling entire modules might not be an option in cases where you don't have the sources of your dependencies. It might even be that you are not allowed to javap a module's module-info.java, depending on its licensing terms. But also leaving such cases aside, having to re-compile module-info descriptors for the sake of overriding required modules seems very tedious. E.g. imagine you hadn't the means of dependency exclusions in Maven (in your application's pom.xml) but were required to patch the pom.xml files of your dependencies in order to converge to a consistent set of logging dependencies. Having an (external) mechanism allowing to override module requirements appears very desirable to me. 2016-05-11 16:14 GMT+02:00 David M. Lloyd : > On 05/11/2016 08:15 AM, Alan Bateman wrote: > >> >> On 11/05/2016 13:52, David M. Lloyd wrote: >> >>> >>> In practice this happens a lot. A module's dependency graph depends >>> just as much on the environment as it depends on the classes in the >>> module (if not more so). Modules are merged and split, replaced with >>> compatibility stubs, renamed, etc. If you have to recompile every >>> module for every environment, a lot of the benefit of modularity and >>> compatibility-by-ABI is lost; changes to a module in an environment >>> would lead to a massive cascade of recompilation. >>> >> The module system can support many refactoring scenarios, including >> merging and splitting. I can see myself refactoring modules that I >> maintain, I'm less sure that I want to refactor modules coming from >> other projects. If I found myself refactoring modules from elsewhere >> then I would expect to have to build and test those modules, it would be >> strange not to do and I don't understand how you can get away with this >> when changing code in those modules. It might be useful if you could lay >> out a specific scenario as it may be that we are talking completely >> different things. >> > > We package several hundred JARs in our modular environment today, only > some of which originate in-house. The dependency information for these > modules is established not by the author of these JARs, but by us. The > Maven artifact for such a JAR might stipulate certain things, like Log4j or > a certain version of ASM. When we distribute that JAR though, we don't > package the exact artifacts and versions of the dependencies that were > stipulated in the Maven POM; instead we package single consistent versions > which are ABI-compatible with all of its dependents, or maybe even a > completely different artifact that meets the same ABI but performs its > functions in a different manner. > > Over time the environment we distribute evolves, and we split or join > modules, or we rename old modules to introduce a new major version of the > same module in parallel, or we replace one implementation with another. > When we do this we may chose to deprecate or eliminate a module from our > environment. Thus we update all the module descriptors that reference the > deprecated module, and set new dependencies on them, and after a certain > amount of time, we delete the old module name. > > None of the artifacts that we package are impacted by this process, and > generally no recompilation is necessary: after all, many of these artifacts > come directly from Maven or are otherwise built independently at an earlier > time outside of the context of our target environment. It's the ABI that > matters; as long as that doesn't change (in an incompatible way), > recompilation should never be necessary. I think "recompile just to be > safe" puts us squarely into "turn it off and on again" territory, logically > speaking. > > -- > - DML > From stef at epardaud.fr Wed May 11 15:05:07 2016 From: stef at epardaud.fr (Stephane Epardaud) Date: Wed, 11 May 2016 17:05:07 +0200 Subject: module-info.java just causes problems In-Reply-To: References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> Message-ID: <57334A23.6000203@epardaud.fr> Agreed, and this is the conclusion we came to in Ceylon wrt modules too. But that's orthogonal to the format of the module descriptor. I think the Java Modules already have a lot of overriding capabilities in the form of command-line flags (-addExports and friends), but ultimately an external overrides descriptor to encompass all those options will help. Of course, tools could define that and generate the options based on it, but then you will end up with different forms for different build tools which is less than ideal. On 11/05/16 16:57, Gunnar Morling wrote: > Having an (external) mechanism allowing to override module requirements > appears very desirable to me. > From david.lloyd at redhat.com Wed May 11 15:29:50 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 11 May 2016 10:29:50 -0500 Subject: module-info.java just causes problems In-Reply-To: <573347EB.9030804@epardaud.fr> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57333FE1.4060903@epardaud.fr> <5733456A.7090501@redhat.com> <573347EB.9030804@epardaud.fr> Message-ID: <57334FEE.4060100@redhat.com> I'm generally pretty skeptical that the entire greater Java ecosystem will converge in one single, mutually cohesive module environment, at least on the Java side of the fence (the Ceylon story is probably different since its ecosystem is cultivated by a much more unified will, at least at this moment). The evidence suggests that we're a long way away from such a place, if it is even possible at this point with all the legacy code in existence. This is why I originally pushed not for a new, ivory-tower module system design, but for a series of enhancements to the existing modularity capabilities in the JDK to enable the additional use cases that are stipulated in the requirements, which would have resulted not only in a *dramatically* smaller patch to the JDK but also a much simpler forwards- and backwards-compatibility story. But, whatever; at this stage I'd settle for whatever small improvements I can squeeze out of this stone. As for manipulating module descriptors, I'm certain all kinds of tools will turn up. But these kinds tools would exist to work around the conceptual problems of Jigsaw; why not just solve the problems instead? It's pretty common in our case for us and for users to want to manipulate external descriptors for various purposes, but we're an application environment, essentially; a curated distribution of modules which is maintained and tested over time. I think that there is a limit to how complex a Java application can get before it will become impractical to develop further without such an environment, either internally or externally maintained. Many users can build on such an environment as-is, but I think there will continue to be a sizable contingent that will need to manipulate these things, and I don't see why it has to be made more difficult than it already is. At the very least, with the JSR issues raised (including making some of the overarching module rules be Layer concerns, and allowing the Layer the ability to lazy-load modules), I am hoping that we can work around some of the limitations and continue doing what we're doing with external descriptors while still being able to present some of the useful additional capabilities of JDK modules to users (which, for us at this point, are amounting more or less to having module names and versions appear in stack traces, and being able to upgrade bits of the JDK somewhat more easily). But it's unfortunate (and a little bizarre) that this is the place we're in, when the requirements seemed so straightforward. On 05/11/2016 09:55 AM, Stephane Epardaud wrote: > I expect such a tool to generate module-info.class to materialise. I > personally use ClassWriter from the JDK tools for that. Anyone with a > JDK has that module and can write that tool trivially. > > The JBoss Modules use-case (and the Ceylon distrib one) is rather > uncommon, though, IMO. Most people deal with modules as Maven modules > and they can't really rewrite the descriptors as in most cases they're > not in the jar and Maven will only use descriptors from the repos and > not in any flat folder where you have Maven jars (I think). In > Maven-land you deal with this via external (to the modules being > overridden) overrides, which Java Modules don't support ATM. > > OSGi is already a pain to override because you have to extract the > manifest, edit it and put it back. Here a tool would help. Overriding > Ceylon modules is done via external overrides too, otherwise you'd have > to extract the manifest (which is also a .class), edit it and put it > back, for which we'd have generated tooling if there was ever demand for > that (but there hasn't been yet). > > All that to say, in general after-packaging editing of module > descriptors is already either rare or hard. I don't think > module-info.class changes that much. > > On 11/05/16 16:44, David M. Lloyd wrote: >> On 05/11/2016 09:21 AM, Stephane Epardaud wrote: >>> I don't understand the problem with the module-info.java class. We also >>> repackage jars to add module descriptors (for OSGi, Maven and JBoss >>> Modules) and for Jigsaw we generate the `module-info.class` file when we >>> need to repackage them. Between this binary format and XML or >>> MANIFEST.MF, I don't see why it makes a big difference? >>> >>> I wouldn't recompile the module, though, just as I don't recompile them >>> when we change the other manifests. >> >> If you have a .class file, you have to generate it with something. I >> think Alan is arguing that it should be done with javac, but we'd >> likely end up using something else. In our case, just editing an XML >> file and doing "git commit" is easier than running a tool to read and >> update a binary descriptor inside an artifact though, particularly as >> we don't package the actual artifacts. Thus we'd have to package a >> textual descriptor of some sort, to which we'd then have to apply a >> tool in order to update our final packaged artifacts, making it that >> much more difficult to use artifacts that already exist (e.g. from >> Maven). >> >> In addition it is common for our users to examine or modify module >> descriptors; having them be external is very useful for this purpose. >> >> We also allow features like specification of properties for modules >> which can be read, specification of module permission sets, and >> filtering of artifact resources and module dependencies in various ways. > -- - DML From forax at univ-mlv.fr Wed May 11 15:37:50 2016 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 11 May 2016 15:37:50 +0000 Subject: module-info.java just causes problems In-Reply-To: <57334A23.6000203@epardaud.fr> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57334A23.6000203@epardaud.fr> Message-ID: Le 11 mai 2016 17:05:07 CEST, Stephane Epardaud a ?crit : >Agreed, and this is the conclusion we came to in Ceylon wrt modules >too. >But that's orthogonal to the format of the module descriptor. > >I think the Java Modules already have a lot of overriding capabilities >in the form of command-line flags (-addExports and friends), but >ultimately an external overrides descriptor to encompass all those >options will help. Will this descriptor different from module-info.java in the end ? Note that i will update ASM soon to be able to read/write a module-info, so at least there will be a way to update a module-info.class without elying on javac. > Of course, tools could define that and generate the >options based on it, but then you will end up with different forms for >different build tools which is less than ideal. > Maven is the dominant player here, if it comes with a tool, every body will use it. R?mi >On 11/05/16 16:57, Gunnar Morling wrote: >> Having an (external) mechanism allowing to override module >requirements >> appears very desirable to me. >> From Alan.Bateman at oracle.com Wed May 11 16:56:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 11 May 2016 17:56:19 +0100 Subject: module-info.java just causes problems In-Reply-To: References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57334A23.6000203@epardaud.fr> Message-ID: <57336433.8030705@oracle.com> On 11/05/2016 16:37, R?mi Forax wrote: > : > > Note that i will update ASM soon to be able to read/write a module-info, so at least there will be a way to update a module-info.class without elying on javac. Good to hear. As you probably know, we have asm.Attribute implementation of the Module and other attributes and these are already used by the `jar` and `jmod` tools when they read or add attributes to module-info.class. All very straight-forward. -Alan. From mandy.chung at oracle.com Wed May 11 17:03:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 May 2016 10:03:35 -0700 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> Message-ID: <798777B1-1A70-4471-BD44-F80EBE7D393C@oracle.com> > On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) wrote: > > Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. > > http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8155237 This looks good and also cleaned up the original code. I saw that it?s pushed which is fine. A small comment: this plugin should throw error if @file not exists. Does jimage list command show the jimage entries in alphabetically order? It would be useful to provide an option to list the entries as layout in the jimage file (a RFE). Mandy From james.laskey at oracle.com Wed May 11 17:17:14 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 11 May 2016 14:17:14 -0300 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <798777B1-1A70-4471-BD44-F80EBE7D393C@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> <798777B1-1A70-4471-BD44-F80EBE7D393C@oracle.com> Message-ID: > On May 11, 2016, at 2:03 PM, Mandy Chung wrote: > > >> On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) wrote: >> >> Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. >> >> http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8155237 > > This looks good and also cleaned up the original code. I saw that it?s pushed which is fine. > > A small comment: this plugin should throw error if @file not exists. This is deliberate, since the classlist may not be there during one phase of the build. We could issue a warning. > Does jimage list command show the jimage entries in alphabetically order? It would be useful to provide an option to list the entries as layout in the jimage file (a RFE). Yes to alphabetically. Please post an RFE for file order. ? Jim From mandy.chung at oracle.com Wed May 11 17:21:57 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 May 2016 10:21:57 -0700 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> <798777B1-1A70-4471-BD44-F80EBE7D393C@oracle.com> Message-ID: <742D4DB6-77E7-4A6A-8A6A-62F0EDD661D6@oracle.com> > On May 11, 2016, at 10:17 AM, Jim Laskey (Oracle) wrote: > > >> On May 11, 2016, at 2:03 PM, Mandy Chung wrote: >> >> >>> On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) wrote: >>> >>> Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. >>> >>> http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html >>> https://bugs.openjdk.java.net/browse/JDK-8155237 >> >> This looks good and also cleaned up the original code. I saw that it?s pushed which is fine. >> >> A small comment: this plugin should throw error if @file not exists. > > This is deliberate, since the classlist may not be there during one phase of the build. We could issue a warning. > At build time, it should know the image is created using classlist or not and so the ?-order-resources option can only be specified when it?s present. This would help catching issue at link time in case if anything goes wrong. > >> Does jimage list command show the jimage entries in alphabetically order? It would be useful to provide an option to list the entries as layout in the jimage file (a RFE). > > Yes to alphabetically. Please post an RFE for file order. > OK. Mandy From james.laskey at oracle.com Wed May 11 17:24:55 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 11 May 2016 14:24:55 -0300 Subject: RFR: JDK-8155237 - jlink plugin to order resources should take a class list as input In-Reply-To: <742D4DB6-77E7-4A6A-8A6A-62F0EDD661D6@oracle.com> References: <5C2CE83C-2FE0-4DCA-9CC7-ED40F6A8A652@oracle.com> <798777B1-1A70-4471-BD44-F80EBE7D393C@oracle.com> <742D4DB6-77E7-4A6A-8A6A-62F0EDD661D6@oracle.com> Message-ID: <558B126E-E7EB-48DC-9555-59B0E1304434@oracle.com> > On May 11, 2016, at 2:21 PM, Mandy Chung wrote: > >> >> On May 11, 2016, at 10:17 AM, Jim Laskey (Oracle) wrote: >> >> >>> On May 11, 2016, at 2:03 PM, Mandy Chung wrote: >>> >>> >>>> On May 9, 2016, at 10:41 AM, Jim Laskey (Oracle) wrote: >>>> >>>> Modifies the jlink sort-plugin to accept a classlist to order files in the jimage. >>>> >>>> http://cr.openjdk.java.net/~jlaskey/8155237/webrev/index.html >>>> https://bugs.openjdk.java.net/browse/JDK-8155237 >>> >>> This looks good and also cleaned up the original code. I saw that it?s pushed which is fine. >>> >>> A small comment: this plugin should throw error if @file not exists. >> >> This is deliberate, since the classlist may not be there during one phase of the build. We could issue a warning. >> > > At build time, it should know the image is created using classlist or not and so the ?-order-resources option can only be specified when it?s present. This would help catching issue at link time in case if anything goes wrong. Erik, comments? > >> >>> Does jimage list command show the jimage entries in alphabetically order? It would be useful to provide an option to list the entries as layout in the jimage file (a RFE). >> >> Yes to alphabetically. Please post an RFE for file order. >> > > OK. > > Mandy From mandy.chung at oracle.com Wed May 11 17:57:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 May 2016 10:57:37 -0700 Subject: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl In-Reply-To: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> References: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> Message-ID: <3F5C7C42-F157-44D1-AB82-1D8178EEB73E@oracle.com> > On May 10, 2016, at 12:49 PM, Mandy Chung wrote: > > >> On May 10, 2016, at 12:00 PM, Alexandre (Shura) Iline wrote: >> >> Hi. >> >> Please review the fix: >> http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/ >> Pushed. > > In fact JDK-8155993 reveals a potential bug in the VM support for java.lang.management when jdk.management module is not present. I see another open issue for this VM issue (sorry for not seeing it earlier) https://bugs.openjdk.java.net/browse/JDK-8151099 I closed JDK-8155993 as a dup of JDK-8151099. Mandy From alexandre.iline at oracle.com Wed May 11 18:00:30 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Wed, 11 May 2016 11:00:30 -0700 Subject: RFR: 8155993: Some tests in java/lang/management fail with NCDFE: com/sun/management/internal/GarbageCollectorExtImpl In-Reply-To: <3F5C7C42-F157-44D1-AB82-1D8178EEB73E@oracle.com> References: <691BA9C8-F2D6-4F4F-8CE3-182A210FD0D9@oracle.com> <3F5C7C42-F157-44D1-AB82-1D8178EEB73E@oracle.com> Message-ID: <695F1914-5418-416E-A1EE-D96A0962DEB5@oracle.com> > On May 11, 2016, at 10:57 AM, Mandy Chung wrote: > > >> On May 10, 2016, at 12:49 PM, Mandy Chung wrote: >> >> >>> On May 10, 2016, at 12:00 PM, Alexandre (Shura) Iline wrote: >>> >>> Hi. >>> >>> Please review the fix: >>> http://cr.openjdk.java.net/~shurailine/8155993/webrev.00/ >>> > > Pushed. Thank you. > >> >> In fact JDK-8155993 reveals a potential bug in the VM support for java.lang.management when jdk.management module is not present. > > > I see another open issue for this VM issue (sorry for not seeing it earlier) > https://bugs.openjdk.java.net/browse/JDK-8151099 And both reported by me. I did forget about the old one. Shura > > I closed JDK-8155993 as a dup of JDK-8151099. > > Mandy From james.laskey at oracle.com Wed May 11 18:00:47 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 11 May 2016 15:00:47 -0300 Subject: RFR: JDK-8156781 - change to jlink has result in test failure Message-ID: http://cr.openjdk.java.net/~jlaskey/8156781/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8156781 From mandy.chung at oracle.com Wed May 11 18:32:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 11 May 2016 11:32:07 -0700 Subject: RFR: JDK-8156781 - change to jlink has result in test failure In-Reply-To: References: Message-ID: > On May 11, 2016, at 11:00 AM, Jim Laskey (Oracle) wrote: > > http://cr.openjdk.java.net/~jlaskey/8156781/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8156781 Looks okay. Since the plugin is renamed to OrderResourcesPlugin, maybe good to rename it to OrderResourcesPluginTest. Mandy From forax at univ-mlv.fr Wed May 11 18:53:13 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 11 May 2016 20:53:13 +0200 (CEST) Subject: module-info.java just causes problems In-Reply-To: <57336433.8030705@oracle.com> References: <572A4062.5080601@redhat.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57334A23.6000203@epardaud.fr> <57336433.8030705@oracle.com> Message-ID: <1325040585.1476794.1462992793299.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alan Bateman" > ?: "R?mi Forax" , jigsaw-dev at openjdk.java.net > Envoy?: Mercredi 11 Mai 2016 18:56:19 > Objet: Re: module-info.java just causes problems > On 11/05/2016 16:37, R?mi Forax wrote: > > : > > > Note that i will update ASM soon to be able to read/write a module-info, so > > at least there will be a way to update a module-info.class without elying > > on > > javac. > > Good to hear. As you probably know, we have asm.Attribute implementation of > the Module and other attributes and these are already used by the `jar` and > `jmod` tools when they read or add attributes to module-info.class. All very > straight-forward. yes, you means the attributes defined in jdk.internal.module.ClassFileAttributes. I want to add a visitor API (to allow incremental changes) and re-work the Remapper, the tool that help to rename a class or a package, because the module-info also need to be updated (exports, uses/provides, conceal attribute, etc). I also want to gather experience on the bytecode representation, BTW, the current format has a bug, encoding the name of a module as a part of the class name fell like a hack. It is a bad idea because the JVM Spec doesn't allow some characters in a class name, i think it should be encoded as a Utf8 (at the starts of the Module attribute), it's also weird because the name of the module-info.class is not "module-info" unlike any other classes, this will require to change more code than necessary in a lot of bytecode tools i know. > -Alan. R?mi From jonathan.gibbons at oracle.com Wed May 11 20:03:09 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 May 2016 13:03:09 -0700 Subject: module-info.java just causes problems In-Reply-To: <1325040585.1476794.1462992793299.JavaMail.zimbra@u-pem.fr> References: <572A4062.5080601@redhat.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <57334A23.6000203@epardaud.fr> <57336433.8030705@oracle.com> <1325040585.1476794.1462992793299.JavaMail.zimbra@u-pem.fr> Message-ID: <57338FFD.8020607@oracle.com> On 05/11/2016 11:53 AM, forax at univ-mlv.fr wrote: > I also want to gather experience on the bytecode representation, > BTW, the current format has a bug, encoding the name of a module as a part of the class name fell like a hack. It is a bad idea because the JVM Spec doesn't allow some characters in a class name, i think it should be encoded as a Utf8 (at the starts of the Module attribute), > it's also weird because the name of the module-info.class is not "module-info" unlike any other classes, this will require to change more code than necessary in a lot of bytecode tools i know. package-info.class is a precedent. -- Jon From sundararajan.athijegannathan at oracle.com Thu May 12 04:40:14 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 12 May 2016 10:10:14 +0530 Subject: RFR: JDK-8156781 - change to jlink has result in test failure In-Reply-To: References: Message-ID: Fix looks good. +1 on test renaming. -Sundar On 5/12/2016 12:02 AM, Mandy Chung wrote: >> On May 11, 2016, at 11:00 AM, Jim Laskey (Oracle) wrote: >> >> http://cr.openjdk.java.net/~jlaskey/8156781/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8156781 > Looks okay. Since the plugin is renamed to OrderResourcesPlugin, maybe good to rename it to OrderResourcesPluginTest. > > Mandy From sander.mak at luminis.eu Thu May 12 07:00:36 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Thu, 12 May 2016 07:00:36 +0000 Subject: j.l.r.Module: addUses but no addProvides Message-ID: <2B9794AB-6EC5-4664-8915-6AE6A74E4D90@luminis.eu> Hi, I noticed that it is possible to reflectively add uses for a service in a module, but not to provide a service implementation. I'm curious what the reason is for this asymmetry. I would imagine that calling ServiceLoader.load() from another module could just return the new service implementation (in addition to existing ones) after a hypothetical j.l.r.Module.addProvides was called. Sander From javadevlist at javasoft.de Thu May 12 07:15:40 2016 From: javadevlist at javasoft.de (wzberger) Date: Thu, 12 May 2016 09:15:40 +0200 Subject: How to embedd access to internal API in a library via XaddExports Message-ID: some of our libraries (third party vendor) require access to some internal API methods. Is it possible to add XaddExports to a library in a way that it is transparent for the user of the lib - means the related package must not be specified by the user via XaddExports? Thanks, Wolfgang From Alan.Bateman at oracle.com Thu May 12 07:16:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 08:16:15 +0100 Subject: j.l.r.Module: addUses but no addProvides In-Reply-To: <2B9794AB-6EC5-4664-8915-6AE6A74E4D90@luminis.eu> References: <2B9794AB-6EC5-4664-8915-6AE6A74E4D90@luminis.eu> Message-ID: <57342DBF.8070908@oracle.com> On 12/05/2016 08:00, Sander Mak wrote: > Hi, > > I noticed that it is possible to reflectively add uses for a service in a module, but not to provide a service implementation. I'm curious what the reason is for this asymmetry. I would imagine that calling ServiceLoader.load() from another module could just return the new service implementation (in addition to existing ones) after a hypothetical j.l.r.Module.addProvides was called. > So far then we've had (to my knowledge anyway) only one case where this looked like it might be needed on the command line but we found another solution to that specific issue. So no plan at the moment to add this, we want to see if there are compelling cases where service providers are created dynamically in (existing) modules before deciding whether to define this method or not. To be honest, I don't particularly like addUses but there are a few cases where libraries/frameworks need to locate service providers on behalf of consumers and so don't have any upfront knowledge about the service type. -Alan. From Alan.Bateman at oracle.com Thu May 12 07:24:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 08:24:48 +0100 Subject: How to embedd access to internal API in a library via XaddExports In-Reply-To: References: Message-ID: <57342FC0.2060302@oracle.com> On 12/05/2016 08:15, wzberger wrote: > some of our libraries (third party vendor) require access to some > internal API methods. Is it possible to add XaddExports to a library > in a way that it is transparent for the user of the lib - means the > related package must not be specified by the user via XaddExports? No, as that would that make it too easy for every library to break into JDK internals. I don't know what 3rd party libraries you have but best to get bugs submitted to the maintainers to look at these issues. -Alan. From Alan.Bateman at oracle.com Thu May 12 07:28:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 08:28:41 +0100 Subject: module-info.java just causes problems In-Reply-To: <57333E43.7080200@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> Message-ID: <573430A9.8010601@oracle.com> On 11/05/2016 15:14, David M. Lloyd wrote: > > We package several hundred JARs in our modular environment today, only > some of which originate in-house. The dependency information for > these modules is established not by the author of these JARs, but by > us. The Maven artifact for such a JAR might stipulate certain things, > like Log4j or a certain version of ASM. When we distribute that JAR > though, we don't package the exact artifacts and versions of the > dependencies that were stipulated in the Maven POM; instead we package > single consistent versions which are ABI-compatible with all of its > dependents, or maybe even a completely different artifact that meets > the same ABI but performs its functions in a different manner. > > Over time the environment we distribute evolves, and we split or join > modules, or we rename old modules to introduce a new major version of > the same module in parallel, or we replace one implementation with > another. When we do this we may chose to deprecate or eliminate a > module from our environment. Thus we update all the module > descriptors that reference the deprecated module, and set new > dependencies on them, and after a certain amount of time, we delete > the old module name. > > None of the artifacts that we package are impacted by this process, > and generally no recompilation is necessary: after all, many of these > artifacts come directly from Maven or are otherwise built > independently at an earlier time outside of the context of our target > environment. It's the ABI that matters; as long as that doesn't change > (in an incompatible way), recompilation should never be necessary. I > think "recompile just to be safe" puts us squarely into "turn it off > and on again" territory, logically speaking. > Thanks for the context. So I'm curious what will happen when you download JAR that is a modular JAR where the author have put in the effort to declare their dependences and exports, maybe services too. Are you going to override that too? -Alan From javadevlist at javasoft.de Thu May 12 07:47:08 2016 From: javadevlist at javasoft.de (wzberger) Date: Thu, 12 May 2016 09:47:08 +0200 Subject: How to embedd access to internal API in a library via XaddExports In-Reply-To: <57342FC0.2060302@oracle.com> References: <57342FC0.2060302@oracle.com> Message-ID: <57b0007f-bbd3-bf21-e17b-8a3b637e2e1a@javasoft.de> just to clarify things - we are the vendor of the libraries and looking for a simple way to keep all provided features for a Java 9 compatible release. Otherwise our lib users have to specify XaddExports which is pretty annoying. Additionally it would simplify providing workarounds for JDK issues as we often did in the past until things get fixed (if they get fixed). -Wolfgang Am 12.05.2016 um 09:24 schrieb Alan Bateman: > On 12/05/2016 08:15, wzberger wrote: >> some of our libraries (third party vendor) require access to some >> internal API methods. Is it possible to add XaddExports to a library >> in a way that it is transparent for the user of the lib - means the >> related package must not be specified by the user via XaddExports? > No, as that would that make it too easy for every library to break > into JDK internals. I don't know what 3rd party libraries you have but > best to get bugs submitted to the maintainers to look at these issues. > > -Alan. > > From Alan.Bateman at oracle.com Thu May 12 08:30:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 09:30:32 +0100 Subject: How to embedd access to internal API in a library via XaddExports In-Reply-To: <57b0007f-bbd3-bf21-e17b-8a3b637e2e1a@javasoft.de> References: <57342FC0.2060302@oracle.com> <57b0007f-bbd3-bf21-e17b-8a3b637e2e1a@javasoft.de> Message-ID: <57343F28.5090604@oracle.com> On 12/05/2016 08:47, wzberger wrote: > just to clarify things - we are the vendor of the libraries and > looking for a simple way to keep all provided features for a Java 9 > compatible release. Otherwise our lib users have to specify > XaddExports which is pretty annoying. Additionally it would simplify > providing workarounds for JDK issues as we often did in the past until > things get fixed (if they get fixed). I have sympathy for your users but I don't see a solution that allows these libraries to break encapsulation without the application owner needing configuration to allow this. So what JDK bugs are you working around? Are there JIRA issues tracking these. -Alan From sander.mak at luminis.eu Thu May 12 08:34:24 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Thu, 12 May 2016 08:34:24 +0000 Subject: j.l.r.Module: addUses but no addProvides In-Reply-To: <57342DBF.8070908@oracle.com> References: <2B9794AB-6EC5-4664-8915-6AE6A74E4D90@luminis.eu> <57342DBF.8070908@oracle.com> Message-ID: > On 12 May 2016, at 09:16, Alan Bateman wrote: > > So no plan at the moment to add this, we want to see if there are compelling cases where service providers are created dynamically in (existing) modules before deciding whether to define this method or not. Fair enough. I was just wondering whether there was a technical limitation that I overlooked. Sander From javadevlist at javasoft.de Thu May 12 08:49:40 2016 From: javadevlist at javasoft.de (wzberger) Date: Thu, 12 May 2016 10:49:40 +0200 Subject: How to embedd access to internal API in a library via XaddExports In-Reply-To: <57343F28.5090604@oracle.com> References: <57342FC0.2060302@oracle.com> <57b0007f-bbd3-bf21-e17b-8a3b637e2e1a@javasoft.de> <57343F28.5090604@oracle.com> Message-ID: > > On 12/05/2016 08:47, wzberger wrote: >> just to clarify things - we are the vendor of the libraries and >> looking for a simple way to keep all provided features for a Java 9 >> compatible release. Otherwise our lib users have to specify >> XaddExports which is pretty annoying. Additionally it would simplify >> providing workarounds for JDK issues as we often did in the past >> until things get fixed (if they get fixed). > I have sympathy for your users but I don't see a solution that allows > these libraries to break encapsulation without the application owner > needing configuration to allow this. > > So what JDK bugs are you working around? Are there JIRA issues > tracking these. > > -Alan > > We provide libs for Swing and JavaFX. For most of the issues bug reports have been filed. But it's not only about known bugs we also have to handle unknown bugs - the release cycles until things get fixed are way too long while customers need solutions. So will it be possible to fork specific JDK modules and deploy such modified modules to users in a simple manner - webstart included? -Wolfgang From forax at univ-mlv.fr Thu May 12 10:04:07 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 12 May 2016 12:04:07 +0200 (CEST) Subject: Name of the module -info in the classfile format Was: module-info.java just causes problems In-Reply-To: <57338FFD.8020607@oracle.com> References: <572A4062.5080601@redhat.com> <57333E43.7080200@redhat.com> <57334A23.6000203@epardaud.fr> <57336433.8030705@oracle.com> <1325040585.1476794.1462992793299.JavaMail.zimbra@u-pem.fr> <57338FFD.8020607@oracle.com> Message-ID: <672083245.1670057.1463047447719.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Jonathan Gibbons" > ?: forax at univ-mlv.fr, "jigsaw-dev" > Envoy?: Mercredi 11 Mai 2016 22:03:09 > Objet: Re: module-info.java just causes problems Hi Jon, > > > > On 05/11/2016 11:53 AM, forax at univ-mlv.fr wrote: > > I also want to gather experience on the bytecode representation, > > BTW, the current format has a bug, encoding the name of a module as a part > > of the class name fell like a hack. It is a bad idea because the JVM Spec > > doesn't allow some characters in a class name, i think it should be > > encoded as a Utf8 (at the starts of the Module attribute), > > it's also weird because the name of the module-info.class is not > > "module-info" unlike any other classes, this will require to change more > > code than necessary in a lot of bytecode tools i know. > > package-info.class is a precedent. No, package-info.java is not stored at the root of a module but in the directory containing the class of the package, so if the source file is java/util/package-info.java, the class file is java/util/package-info.class and the name of the class inside the class file is java/util/package-info. for the module-info, the source file is module-info.java, the class file is module-info.class and the class inside the class file is whatever/is/the/name/of/my/module/module-info. > > -- Jon > R?mi From david.lloyd at redhat.com Thu May 12 11:46:53 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 May 2016 06:46:53 -0500 Subject: module-info.java just causes problems In-Reply-To: <573430A9.8010601@oracle.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <573430A9.8010601@oracle.com> Message-ID: <57346D2D.201@redhat.com> On 05/12/2016 02:28 AM, Alan Bateman wrote: > On 11/05/2016 15:14, David M. Lloyd wrote: >> >> We package several hundred JARs in our modular environment today, only >> some of which originate in-house. The dependency information for >> these modules is established not by the author of these JARs, but by >> us. The Maven artifact for such a JAR might stipulate certain things, >> like Log4j or a certain version of ASM. When we distribute that JAR >> though, we don't package the exact artifacts and versions of the >> dependencies that were stipulated in the Maven POM; instead we package >> single consistent versions which are ABI-compatible with all of its >> dependents, or maybe even a completely different artifact that meets >> the same ABI but performs its functions in a different manner. >> >> Over time the environment we distribute evolves, and we split or join >> modules, or we rename old modules to introduce a new major version of >> the same module in parallel, or we replace one implementation with >> another. When we do this we may chose to deprecate or eliminate a >> module from our environment. Thus we update all the module >> descriptors that reference the deprecated module, and set new >> dependencies on them, and after a certain amount of time, we delete >> the old module name. >> >> None of the artifacts that we package are impacted by this process, >> and generally no recompilation is necessary: after all, many of these >> artifacts come directly from Maven or are otherwise built >> independently at an earlier time outside of the context of our target >> environment. It's the ABI that matters; as long as that doesn't change >> (in an incompatible way), recompilation should never be necessary. I >> think "recompile just to be safe" puts us squarely into "turn it off >> and on again" territory, logically speaking. >> > Thanks for the context. So I'm curious what will happen when you > download JAR that is a modular JAR where the author have put in the > effort to declare their dependences and exports, maybe services too. Are > you going to override that too? Almost certainly. At the very least we're going to review it to see if the module names match with our environment. If we retain our current modularity system then we'd likely have to externalize the descriptor as well, probably manually, and the internal one would be stripped out or ignored. But, that is as yet undecided and may depend on whether and how many of our issues get resolved in Jigsaw. -- - DML From Alan.Bateman at oracle.com Thu May 12 13:17:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 14:17:35 +0100 Subject: How to embedd access to internal API in a library via XaddExports In-Reply-To: References: <57342FC0.2060302@oracle.com> <57b0007f-bbd3-bf21-e17b-8a3b637e2e1a@javasoft.de> <57343F28.5090604@oracle.com> Message-ID: <5734826F.4050608@oracle.com> On 12/05/2016 09:49, wzberger wrote: > > We provide libs for Swing and JavaFX. For most of the issues bug > reports have been filed. But it's not only about known bugs we also > have to handle unknown bugs - the release cycles until things get > fixed are way too long while customers need solutions. So will it be > possible to fork specific JDK modules and deploy such modified modules > to users in a simple manner - webstart included? With OpenJDK then you can of course do your own builds. The java.desktop module is not an upgradeable module (not like the EE modules) so you can't deploy an upgraded version of java.desktop on the upgrade module path, at least not with Oracle JDK builds. You can patch it via -Xpatch for testing or debugging purposes but I assume you don't want your users doing that. This reminds to ask - when you patch the code today then you are using -Xbootclasspath/p or does patching mean using core reflection to access/change private fields. Java Web Start is not in OpenJDK so I can't comment on patching that (or maybe you mean having web start download patches?). Finally, and I understand it can frustrating to hit a bug that isn't fixed in a timely manner, but have you considered contributing fixes for the bugs that you are running into? -Alan From pbenedict at apache.org Thu May 12 16:19:23 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 12 May 2016 11:19:23 -0500 Subject: module-info.java just causes problems In-Reply-To: <57346D2D.201@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <573430A9.8010601@oracle.com> <57346D2D.201@redhat.com> Message-ID: Why can't the layer assist specifying the Module Configuration to each module in the Module system? By that I mean that the module-info.class shouldn't be read and accepted without mediation. The Layer should get the chance to augment (add, change, remove) anything it wants. Now perhaps the default behavior is to blindly accept module-info.class, but in an EE world, I say this is insufficient. The container should be able to do whatever it wants to the module information before it gets applied by the JDK. Cheers, Paul On Thu, May 12, 2016 at 6:46 AM, David M. Lloyd wrote: > On 05/12/2016 02:28 AM, Alan Bateman wrote: > >> On 11/05/2016 15:14, David M. Lloyd wrote: >> >>> >>> We package several hundred JARs in our modular environment today, only >>> some of which originate in-house. The dependency information for >>> these modules is established not by the author of these JARs, but by >>> us. The Maven artifact for such a JAR might stipulate certain things, >>> like Log4j or a certain version of ASM. When we distribute that JAR >>> though, we don't package the exact artifacts and versions of the >>> dependencies that were stipulated in the Maven POM; instead we package >>> single consistent versions which are ABI-compatible with all of its >>> dependents, or maybe even a completely different artifact that meets >>> the same ABI but performs its functions in a different manner. >>> >>> Over time the environment we distribute evolves, and we split or join >>> modules, or we rename old modules to introduce a new major version of >>> the same module in parallel, or we replace one implementation with >>> another. When we do this we may chose to deprecate or eliminate a >>> module from our environment. Thus we update all the module >>> descriptors that reference the deprecated module, and set new >>> dependencies on them, and after a certain amount of time, we delete >>> the old module name. >>> >>> None of the artifacts that we package are impacted by this process, >>> and generally no recompilation is necessary: after all, many of these >>> artifacts come directly from Maven or are otherwise built >>> independently at an earlier time outside of the context of our target >>> environment. It's the ABI that matters; as long as that doesn't change >>> (in an incompatible way), recompilation should never be necessary. I >>> think "recompile just to be safe" puts us squarely into "turn it off >>> and on again" territory, logically speaking. >>> >>> Thanks for the context. So I'm curious what will happen when you >> download JAR that is a modular JAR where the author have put in the >> effort to declare their dependences and exports, maybe services too. Are >> you going to override that too? >> > > Almost certainly. At the very least we're going to review it to see if > the module names match with our environment. If we retain our current > modularity system then we'd likely have to externalize the descriptor as > well, probably manually, and the internal one would be stripped out or > ignored. But, that is as yet undecided and may depend on whether and how > many of our issues get resolved in Jigsaw. > > -- > - DML > From david.lloyd at redhat.com Thu May 12 16:37:34 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 12 May 2016 11:37:34 -0500 Subject: module-info.java just causes problems In-Reply-To: References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <573430A9.8010601@oracle.com> <57346D2D.201@redhat.com> Message-ID: <5734B14E.9080306@redhat.com> This is along the lines of what I've requested. Still waiting for any kind of feedback though. On 05/12/2016 11:19 AM, Paul Benedict wrote: > Why can't the layer assist specifying the Module Configuration to each > module in the Module system? By that I mean that the module-info.class > shouldn't be read and accepted without mediation. The Layer should get > the chance to augment (add, change, remove) anything it wants. Now > perhaps the default behavior is to blindly accept module-info.class, but > in an EE world, I say this is insufficient. The container should be able > to do whatever it wants to the module information before it gets applied > by the JDK. > > Cheers, > Paul > > On Thu, May 12, 2016 at 6:46 AM, David M. Lloyd > wrote: > > On 05/12/2016 02:28 AM, Alan Bateman wrote: > > On 11/05/2016 15:14, David M. Lloyd wrote: > > > We package several hundred JARs in our modular environment > today, only > some of which originate in-house. The dependency > information for > these modules is established not by the author of these > JARs, but by > us. The Maven artifact for such a JAR might stipulate > certain things, > like Log4j or a certain version of ASM. When we distribute > that JAR > though, we don't package the exact artifacts and versions of the > dependencies that were stipulated in the Maven POM; instead > we package > single consistent versions which are ABI-compatible with all > of its > dependents, or maybe even a completely different artifact > that meets > the same ABI but performs its functions in a different manner. > > Over time the environment we distribute evolves, and we > split or join > modules, or we rename old modules to introduce a new major > version of > the same module in parallel, or we replace one > implementation with > another. When we do this we may chose to deprecate or > eliminate a > module from our environment. Thus we update all the module > descriptors that reference the deprecated module, and set new > dependencies on them, and after a certain amount of time, we > delete > the old module name. > > None of the artifacts that we package are impacted by this > process, > and generally no recompilation is necessary: after all, many > of these > artifacts come directly from Maven or are otherwise built > independently at an earlier time outside of the context of > our target > environment. It's the ABI that matters; as long as that > doesn't change > (in an incompatible way), recompilation should never be > necessary. I > think "recompile just to be safe" puts us squarely into > "turn it off > and on again" territory, logically speaking. > > Thanks for the context. So I'm curious what will happen when you > download JAR that is a modular JAR where the author have put in the > effort to declare their dependences and exports, maybe services > too. Are > you going to override that too? > > > Almost certainly. At the very least we're going to review it to see > if the module names match with our environment. If we retain our > current modularity system then we'd likely have to externalize the > descriptor as well, probably manually, and the internal one would be > stripped out or ignored. But, that is as yet undecided and may > depend on whether and how many of our issues get resolved in Jigsaw. > > -- > - DML > > -- - DML From pbenedict at apache.org Thu May 12 16:47:56 2016 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 12 May 2016 11:47:56 -0500 Subject: module-info.java just causes problems In-Reply-To: <5734B14E.9080306@redhat.com> References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <573430A9.8010601@oracle.com> <57346D2D.201@redhat.com> <5734B14E.9080306@redhat.com> Message-ID: I think the interception would also solve the use case of Redhat's Byteman. If the Layer can be given access to the Module Configuration and before any classes in the Module are loaded (chicken-and-egg for module-info.class?), then class transformation can be accomplished at the same time. Cheers, Paul On Thu, May 12, 2016 at 11:37 AM, David M. Lloyd wrote: > This is along the lines of what I've requested. Still waiting for any > kind of feedback though. > > On 05/12/2016 11:19 AM, Paul Benedict wrote: > >> Why can't the layer assist specifying the Module Configuration to each >> module in the Module system? By that I mean that the module-info.class >> shouldn't be read and accepted without mediation. The Layer should get >> the chance to augment (add, change, remove) anything it wants. Now >> perhaps the default behavior is to blindly accept module-info.class, but >> in an EE world, I say this is insufficient. The container should be able >> to do whatever it wants to the module information before it gets applied >> by the JDK. >> >> Cheers, >> Paul >> >> On Thu, May 12, 2016 at 6:46 AM, David M. Lloyd > > wrote: >> >> On 05/12/2016 02:28 AM, Alan Bateman wrote: >> >> On 11/05/2016 15:14, David M. Lloyd wrote: >> >> >> We package several hundred JARs in our modular environment >> today, only >> some of which originate in-house. The dependency >> information for >> these modules is established not by the author of these >> JARs, but by >> us. The Maven artifact for such a JAR might stipulate >> certain things, >> like Log4j or a certain version of ASM. When we distribute >> that JAR >> though, we don't package the exact artifacts and versions of >> the >> dependencies that were stipulated in the Maven POM; instead >> we package >> single consistent versions which are ABI-compatible with all >> of its >> dependents, or maybe even a completely different artifact >> that meets >> the same ABI but performs its functions in a different manner. >> >> Over time the environment we distribute evolves, and we >> split or join >> modules, or we rename old modules to introduce a new major >> version of >> the same module in parallel, or we replace one >> implementation with >> another. When we do this we may chose to deprecate or >> eliminate a >> module from our environment. Thus we update all the module >> descriptors that reference the deprecated module, and set new >> dependencies on them, and after a certain amount of time, we >> delete >> the old module name. >> >> None of the artifacts that we package are impacted by this >> process, >> and generally no recompilation is necessary: after all, many >> of these >> artifacts come directly from Maven or are otherwise built >> independently at an earlier time outside of the context of >> our target >> environment. It's the ABI that matters; as long as that >> doesn't change >> (in an incompatible way), recompilation should never be >> necessary. I >> think "recompile just to be safe" puts us squarely into >> "turn it off >> and on again" territory, logically speaking. >> >> Thanks for the context. So I'm curious what will happen when you >> download JAR that is a modular JAR where the author have put in >> the >> effort to declare their dependences and exports, maybe services >> too. Are >> you going to override that too? >> >> >> Almost certainly. At the very least we're going to review it to see >> if the module names match with our environment. If we retain our >> current modularity system then we'd likely have to externalize the >> descriptor as well, probably manually, and the internal one would be >> stripped out or ignored. But, that is as yet undecided and may >> depend on whether and how many of our issues get resolved in Jigsaw. >> >> -- >> - DML >> >> >> > -- > - DML > From javadevlist at javasoft.de Thu May 12 17:07:22 2016 From: javadevlist at javasoft.de (wzberger) Date: Thu, 12 May 2016 19:07:22 +0200 Subject: How to embedd access to internal API in a library via XaddExports In-Reply-To: <5734826F.4050608@oracle.com> References: <57342FC0.2060302@oracle.com> <57b0007f-bbd3-bf21-e17b-8a3b637e2e1a@javasoft.de> <57343F28.5090604@oracle.com> <5734826F.4050608@oracle.com> Message-ID: <26fd8c0e-02a6-40cd-cf2d-9db8423ffaff@javasoft.de> Am 12.05.2016 um 15:17 schrieb Alan Bateman: > > On 12/05/2016 09:49, wzberger wrote: >> >> We provide libs for Swing and JavaFX. For most of the issues bug >> reports have been filed. But it's not only about known bugs we also >> have to handle unknown bugs - the release cycles until things get >> fixed are way too long while customers need solutions. So will it be >> possible to fork specific JDK modules and deploy such modified >> modules to users in a simple manner - webstart included? > With OpenJDK then you can of course do your own builds. The > java.desktop module is not an upgradeable module (not like the EE > modules) so you can't deploy an upgraded version of java.desktop on > the upgrade module path, at least not with Oracle JDK builds. You can > patch it via -Xpatch for testing or debugging purposes but I assume > you don't want your users doing that. This reminds to ask - when you > patch the code today then you are using -Xbootclasspath/p or does > patching mean using core reflection to access/change private fields. > > Java Web Start is not in OpenJDK so I can't comment on patching that > (or maybe you mean having web start download patches?). > > Finally, and I understand it can frustrating to hit a bug that isn't > fixed in a timely manner, but have you considered contributing fixes > for the bugs that you are running into? > > -Alan > > Workarounds are mostly implemented via reflection - some features are provided by extending internal classes. A widely spread example is customization of a JTable header renderer by extending sun.swing.table.DefaultTableCellHeaderRenderer - it's a pretty common approach which is often used in the wild. We also extend sun.swing.DefaultLookup and require access to sun.swing.plaf.synth.DefaultSynthStyle - of course this is more specific. So what's the recommendation, should we file a bug report to provide a public API for these kind of classes and if so will these classes find their way into the public API? Because of contributing fixes, if things are simple and clear enough we propose fixes. More complex fixes or extensions would require extra resources which is currently not an option. - Wolfgang From Alan.Bateman at oracle.com Thu May 12 17:13:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 May 2016 18:13:22 +0100 Subject: module-info.java just causes problems In-Reply-To: References: <572A4062.5080601@redhat.com> <57332819.8060409@oracle.com> <57332B17.1040708@redhat.com> <5733305B.2070408@oracle.com> <57333E43.7080200@redhat.com> <573430A9.8010601@oracle.com> <57346D2D.201@redhat.com> <5734B14E.9080306@redhat.com> Message-ID: <5734B9B2.40606@oracle.com> On 12/05/2016 17:47, Paul Benedict wrote: > I think the interception would also solve the use case of Redhat's > Byteman. If the Layer can be given access to the Module Configuration > and before any classes in the Module are loaded (chicken-and-egg for > module-info.class?), then class transformation can be accomplished at > the same time. > Layer isn't the place for this. If you want to intercept or have the module declaration be in another format or have the module be packaged in other ways then you implement an appropriate ModuleFinder and specify it when creating the Configuration. -Alan. From alan.bateman at oracle.com Thu May 12 19:12:12 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:12 +0000 Subject: hg: jigsaw/jake: 10 new changesets Message-ID: <201605121912.u4CJCCPi019678@aojmv0008.oracle.com> Changeset: a36a877e7624 Author: alanb Date: 2016-05-03 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a36a877e7624 8154956: Module system implementation refresh (4/2016) Reviewed-by: alanb, mchung, chegar, redestad Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com, erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/conf/jib-profiles.js ! make/CreateBuildJdkCopy.gmk ! make/CreateJmods.gmk ! make/Main.gmk ! make/common/Modules.gmk Changeset: 2ceb4236f9bd Author: alanb Date: 2016-05-03 11:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2ceb4236f9bd Merge ! common/autoconf/generated-configure.sh ! common/conf/jib-profiles.js ! make/CreateJmods.gmk ! make/Main.gmk ! make/common/Modules.gmk Changeset: a73fa239a38e Author: darcy Date: 2016-05-03 09:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a73fa239a38e 8155872: Temporarily disable deprecation checking on the java.desktop module Reviewed-by: erikj ! make/CompileJavaModules.gmk Changeset: dd5bcb4b0693 Author: lana Date: 2016-05-05 19:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/dd5bcb4b0693 Merge Changeset: 3a35d575147a Author: mchung Date: 2016-05-05 16:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3a35d575147a 8154190: Deprivilege java.compiler module Reviewed-by: alanb, chegar, jjg ! make/common/Modules.gmk Changeset: c861a5be9c88 Author: mchung Date: 2016-05-05 22:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c861a5be9c88 8155513: Deprivilege jdk.charsets Reviewed-by: alanb, chegar ! make/common/Modules.gmk Changeset: f70030d86af1 Author: redestad Date: 2016-05-07 01:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f70030d86af1 8150044: Generate classlists at build-time Reviewed-by: alanb, mchung, iklam Contributed-by: claes.redestad at oracle.com, erik.joelsson at oracle.com ! common/autoconf/boot-jdk.m4 ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/CreateBuildJdkCopy.gmk ! make/CreateJmods.gmk ! make/Images.gmk + make/InterimImage.gmk ! make/Main.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk Changeset: 047f95de8f91 Author: erikj Date: 2016-05-09 17:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/047f95de8f91 8153685: Parfait integration missing in the new tools (jmod and jlink) Reviewed-by: alanb, mchung ! common/autoconf/boot-jdk.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! make/common/JavaCompilation.gmk Changeset: e68942b0ba37 Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e68942b0ba37 Added tag jdk-9+118 for changeset 047f95de8f91 ! .hgtags Changeset: bac1ee642a63 Author: alanb Date: 2016-05-12 19:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/bac1ee642a63 Merge ! common/autoconf/boot-jdk.m4 ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/conf/jib-profiles.js ! make/CompileJavaModules.gmk ! make/CreateBuildJdkCopy.gmk ! make/CreateJmods.gmk ! make/Images.gmk ! make/Main.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk From alan.bateman at oracle.com Thu May 12 19:12:10 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:10 +0000 Subject: hg: jigsaw/jake/corba: 5 new changesets Message-ID: <201605121912.u4CJCAgU019598@aojmv0008.oracle.com> Changeset: 425ca13f66db Author: alanb Date: 2016-05-03 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/425ca13f66db 8154956: Module system implementation refresh (4/2016) Reviewed-by: mchung, chegar, redestad ! src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/cff/FileLocator.java ! src/java.corba/share/classes/module-info.java Changeset: d5bbdec1fa7c Author: aefimov Date: 2016-05-05 18:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d5bbdec1fa7c 8152927: Incorrect GPL header in StubFactoryDynamicBase.java reported Reviewed-by: alanb ! src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java Changeset: 8c2c2d17f7ce Author: lana Date: 2016-05-05 19:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/8c2c2d17f7ce Merge Changeset: daf533920b12 Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/daf533920b12 Added tag jdk-9+118 for changeset 8c2c2d17f7ce ! .hgtags Changeset: 7d0c67c60d0d Author: alanb Date: 2016-05-12 19:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/7d0c67c60d0d Merge ! src/java.corba/share/classes/module-info.java From alan.bateman at oracle.com Thu May 12 19:12:12 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:12 +0000 Subject: hg: jigsaw/jake/jaxp: 6 new changesets Message-ID: <201605121912.u4CJCCCs019682@aojmv0008.oracle.com> Changeset: 7b995f6bcad4 Author: alanb Date: 2016-05-03 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/7b995f6bcad4 8154956: Module system implementation refresh (4/2016) Reviewed-by: mchung, chegar, redestad ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 4ddaf6f4cd7c Author: alanb Date: 2016-05-03 10:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/4ddaf6f4cd7c Merge Changeset: cdd9753dccad Author: lana Date: 2016-05-05 19:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/cdd9753dccad Merge Changeset: a8aa25fc6c5f Author: fyuan Date: 2016-05-05 20:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a8aa25fc6c5f 8156007: Refix: TestPolicy should extend the default security policy Reviewed-by: mchung, joehw Contributed-by: Frank Yuan ! test/javax/xml/jaxp/libs/jaxp/library/TestPolicy.java Changeset: def96e89f9f0 Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/def96e89f9f0 Added tag jdk-9+118 for changeset a8aa25fc6c5f ! .hgtags Changeset: 740a2c8c12a9 Author: alanb Date: 2016-05-12 19:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/740a2c8c12a9 Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java From alan.bateman at oracle.com Thu May 12 19:12:12 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:12 +0000 Subject: hg: jigsaw/jake/jaxws: 4 new changesets Message-ID: <201605121912.u4CJCCmZ019707@aojmv0008.oracle.com> Changeset: 8a7d05e55608 Author: alanb Date: 2016-05-03 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/8a7d05e55608 8154956: Module system implementation refresh (4/2016) Reviewed-by: mchung, chegar, redestad ! src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/SchemaGenerator.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsgenTool.java ! src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wscompile/WsimportTool.java Changeset: 6ba73d04589c Author: lana Date: 2016-05-05 19:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/6ba73d04589c Merge Changeset: 331a825f849a Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/331a825f849a Added tag jdk-9+118 for changeset 6ba73d04589c ! .hgtags Changeset: 8ca712aed1cd Author: alanb Date: 2016-05-12 19:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/8ca712aed1cd Merge From alan.bateman at oracle.com Thu May 12 19:12:12 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:12 +0000 Subject: hg: jigsaw/jake/langtools: 11 new changesets Message-ID: <201605121912.u4CJCDje019715@aojmv0008.oracle.com> Changeset: 4c740bddc648 Author: alanb Date: 2016-05-03 09:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4c740bddc648 8154956: Module system implementation refresh (4/2016) Reviewed-by: jjg, mchung, alanb Contributed-by: jonathan.gibbons at oracle.com, jan.lahoda at oracle.com ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! make/tools/crules/MutableFieldsAnalyzer.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.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/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! test/TEST.ROOT ! test/tools/all/RunCodingRules.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6406771.java ! test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/processing/loader/testClose/TestClose.java ! test/tools/javac/processing/loader/testClose/TestClose2.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javac/util/T6597678.java ! test/tools/jdeps/APIDeps.java Changeset: d5ca3c84a004 Author: alanb Date: 2016-05-03 11:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d5ca3c84a004 Merge ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/tools/javac/modules/AddLimitMods.java Changeset: d8e10040f5bd Author: jlahoda Date: 2016-05-04 17:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d8e10040f5bd 8156000: tools/all/RunCodingRules.java fails if build dir exists, but generated sources do not Summary: RunCodingRules test compiles and runs PropertiesParser to get the generated CompilerProperties.java Reviewed-by: mcimadamore, jjg ! make/tools/propertiesparser/PropertiesParser.java ! test/tools/all/RunCodingRules.java Changeset: 55d555868636 Author: mcimadamore Date: 2016-05-05 11:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/55d555868636 8155959: Langtools ant build should support new Xpatch option format Summary: Switch ant build and IntelliJ project to use the new Xpatch syntax flavor Reviewed-by: jlahoda, jjg ! make/build.xml ! make/intellij/workspace.xml ! make/launcher.sh-template Changeset: db00338f8e33 Author: lana Date: 2016-05-05 19:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/db00338f8e33 Merge Changeset: eddb2c2a831d Author: mchung Date: 2016-05-05 16:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/eddb2c2a831d 8154190: Deprivilege java.compiler module Reviewed-by: alanb, chegar, jjg ! src/java.compiler/share/classes/javax/tools/ToolProvider.java + test/tools/javac/api/ToolProvider/ToolProviderTest.java ! test/tools/javac/api/ToolProvider/ToolProviderTest1.java Changeset: 4ccabc2f6346 Author: vromero Date: 2016-05-06 16:06 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/4ccabc2f6346 8153268: javac accepts enums being referenced by 'uses' statement Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/modules/UsesTest.java Changeset: e043221cf018 Author: mli Date: 2016-05-09 12:30 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e043221cf018 8156189: Problem list tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java until JDK-8153481 is resolved Reviewed-by: mchung ! test/ProblemList.txt Changeset: 59a16fa5dede Author: darcy Date: 2016-05-09 11:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/59a16fa5dede 8156158: Mark ToolLocaleMessageTest.java as intermittently failing, demote to tier 2 Reviewed-by: jlahoda ! test/TEST.groups ! test/jdk/jshell/ToolLocaleMessageTest.java Changeset: 53ac6d02071d Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/53ac6d02071d Added tag jdk-9+118 for changeset 59a16fa5dede ! .hgtags Changeset: c310c87aa5e1 Author: alanb Date: 2016-05-12 19:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c310c87aa5e1 Merge ! .hgtags ! make/build.xml ! make/launcher.sh-template ! make/tools/crules/CodingRulesAnalyzerPlugin.java ! make/tools/crules/MutableFieldsAnalyzer.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/java.compiler/share/classes/javax/tools/ToolProvider.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/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.compiler/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc.properties ! test/ProblemList.txt ! test/TEST.ROOT ! test/tools/all/RunCodingRules.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6406771.java ! test/tools/javac/T8010737/ParameterNamesAreNotCopiedToAnonymousInitTest.java ! test/tools/javac/api/TestJavacTaskScanner.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/file/T7018098.java ! test/tools/javac/modules/AddLimitMods.java ! test/tools/javac/modules/UsesTest.java ! test/tools/javac/processing/loader/testClose/TestClose.java ! test/tools/javac/processing/loader/testClose/TestClose2.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javac/util/T6597678.java ! test/tools/jdeps/APIDeps.java From alan.bateman at oracle.com Thu May 12 19:12:14 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:14 +0000 Subject: hg: jigsaw/jake/nashorn: 11 new changesets Message-ID: <201605121912.u4CJCEXl019719@aojmv0008.oracle.com> Changeset: b7643d5bbe19 Author: alanb Date: 2016-05-03 09:11 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b7643d5bbe19 8154956: Module system implementation refresh (4/2016) Reviewed-by: alanb, mchung, chegar, redestad Contributed-by: alan.bateman at oracle.com, erik.joelsson at oracle.com ! make/BuildNashorn.gmk ! test/TEST.ROOT Changeset: 2b82d45d1ab8 Author: alanb Date: 2016-05-03 10:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2b82d45d1ab8 Merge Changeset: 51865518fa99 Author: sundar Date: 2016-05-03 21:27 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/51865518fa99 8155944: ant build/test of nashorn is broken with the latest jdk9-dev build Reviewed-by: jlaskey ! buildtools/nasgen/build.xml ! buildtools/nasgen/project.properties ! make/build-nasgen.xml ! make/build.xml ! make/project.properties Changeset: 9ecc29462c48 Author: hannesw Date: 2016-05-04 13:39 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9ecc29462c48 8144711: (x) => x + 1 causes Assertion failure instead of SyntaxError Reviewed-by: mhaupt, sundar + test/script/basic/JDK-8144711.js Changeset: b96917819cf6 Author: darcy Date: 2016-05-04 10:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b96917819cf6 8156040: Nashorn tests still failing after latest Jigsaw merge Reviewed-by: sundar ! test/TEST.ROOT Changeset: 4a9fca4fd993 Author: lana Date: 2016-05-05 19:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4a9fca4fd993 Merge Changeset: 58cac5dc254d Author: sundar Date: 2016-05-06 20:27 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/58cac5dc254d 8150731: Nashorn JSObject linker should be exposed as a service provider Reviewed-by: jlaskey, hannesw + src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/linker/NashornLinkerExporter.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/JSObjectLinker.java ! src/jdk.scripting.nashorn/share/classes/module-info.java ! test/src/jdk/dynalink/test/DynamicLinkerFactoryTest.java Changeset: f62f25cbd211 Author: sundar Date: 2016-05-07 20:13 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f62f25cbd211 8156489: jjs tab-completion crashes with stack overflow error Reviewed-by: jlaskey ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java Changeset: 05679aac2f7e Author: sundar Date: 2016-05-09 10:48 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/05679aac2f7e 8156492: ClassFormatError thrown when arrow function is used Reviewed-by: jlaskey ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java + test/script/basic/es6/JDK-8156492.js Changeset: 2fc3dc388f4d Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2fc3dc388f4d Added tag jdk-9+118 for changeset 05679aac2f7e ! .hgtags Changeset: b5d6e96e57f9 Author: alanb Date: 2016-05-12 19:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b5d6e96e57f9 Merge ! .hgtags ! buildtools/nasgen/build.xml ! buildtools/nasgen/project.properties ! make/BuildNashorn.gmk ! make/build-nasgen.xml ! make/build.xml ! make/project.properties ! src/jdk.scripting.nashorn/share/classes/module-info.java ! test/src/jdk/dynalink/test/DynamicLinkerFactoryTest.java From alan.bateman at oracle.com Thu May 12 19:12:18 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:18 +0000 Subject: hg: jigsaw/jake/hotspot: 6 new changesets Message-ID: <201605121912.u4CJCIvu019758@aojmv0008.oracle.com> Changeset: 9123de996cb5 Author: alanb Date: 2016-05-03 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9123de996cb5 8154956: Module system implementation refresh (4/2016) Reviewed-by: acorn, jiangli, ccheung, hseigel Contributed-by: alan.bateman at oracle.com, lois.foltan at oracle.com, harold.seigel at oracle.com ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/init.cpp ! test/TEST.ROOT ! test/compiler/intrinsics/bmi/verifycode/AndnTestI.java ! test/compiler/intrinsics/bmi/verifycode/AndnTestL.java ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jsr292/InvokerGC.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/compiler/jsr292/VMAnonymousClasses.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableMemoryBarrier.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/stable/TestStableUByte.java ! test/compiler/stable/TestStableUShort.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/runtime/BadObjectClass/BootstrapRedefine.java ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/Visibility/XpatchVisibility.java + test/runtime/modules/Xpatch/BasicJarBuilder.java ! test/runtime/modules/Xpatch/Xpatch2Dirs.java + test/runtime/modules/Xpatch/XpatchDupJavaBase.java + test/runtime/modules/Xpatch/XpatchDupModule.java + test/runtime/modules/Xpatch/XpatchJavaBase.java ! test/runtime/modules/Xpatch/XpatchTest.java + test/runtime/modules/Xpatch/XpatchTestJar.java + test/runtime/modules/Xpatch/XpatchTestJarDir.java ! test/runtime/modules/Xpatch/XpatchTraceCL.java ! test/runtime/modules/XpatchCDS.java Changeset: 3b56bf6b0bcb Author: psandoz Date: 2016-05-05 11:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/3b56bf6b0bcb 8155258: VarHandle implementation improvements Summary: Relax return type check for call to linked method handle invocation Reviewed-by: shade, vlivanov ! src/share/vm/opto/doCall.cpp Changeset: 7e27d7c1c58a Author: lana Date: 2016-05-05 19:10 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7e27d7c1c58a Merge Changeset: 9b1075cac08d Author: redestad Date: 2016-05-07 00:43 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9b1075cac08d 8150044: Generate classlists at build-time Reviewed-by: alanb, mchung, iklam Contributed-by: claes.redestad at oracle.com, erik.joelsson at oracle.com ! src/share/vm/memory/metaspaceShared.hpp ! test/runtime/SharedArchiveFile/MaxMetaspaceSize.java Changeset: e3ca323dfe1b Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e3ca323dfe1b Added tag jdk-9+118 for changeset 9b1075cac08d ! .hgtags Changeset: e049c36463d4 Author: alanb Date: 2016-05-12 19:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e049c36463d4 Merge ! .hgtags ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/modules.cpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/init.cpp ! test/TEST.ROOT ! test/compiler/jsr292/CallSiteDepContextTest.java ! test/compiler/jsr292/NonInlinedCall/GCTest.java ! test/compiler/jsr292/NonInlinedCall/InvokeTest.java ! test/compiler/jsr292/NonInlinedCall/RedefineTest.java ! test/compiler/jsr292/VMAnonymousClasses.java ! test/compiler/stable/TestStableBoolean.java ! test/compiler/stable/TestStableByte.java ! test/compiler/stable/TestStableChar.java ! test/compiler/stable/TestStableDouble.java ! test/compiler/stable/TestStableFloat.java ! test/compiler/stable/TestStableInt.java ! test/compiler/stable/TestStableLong.java ! test/compiler/stable/TestStableMemoryBarrier.java ! test/compiler/stable/TestStableObject.java ! test/compiler/stable/TestStableShort.java ! test/compiler/unsafe/UnsafeGetConstantField.java ! test/runtime/BadObjectClass/BootstrapRedefine.java ! test/runtime/getSysPackage/GetSysPkgTest.java ! test/runtime/modules/AccessCheck/DiffCL_Umod.java ! test/runtime/modules/AccessCheck/Umod.java ! test/runtime/modules/JVMAddReadsModule.java ! test/runtime/modules/Visibility/XpatchVisibility.java ! test/runtime/modules/Xpatch/Xpatch2Dirs.java ! test/runtime/modules/Xpatch/XpatchTest.java ! test/runtime/modules/Xpatch/XpatchTraceCL.java ! test/runtime/modules/XpatchCDS.java From alan.bateman at oracle.com Thu May 12 19:12:30 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 12 May 2016 19:12:30 +0000 Subject: hg: jigsaw/jake/jdk: 43 new changesets Message-ID: <201605121912.u4CJCXPI019819@aojmv0008.oracle.com> Changeset: 5c412978857d Author: alanb Date: 2016-05-03 09:09 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c412978857d 8154956: Module system implementation refresh (4/2016) Reviewed-by: alanb, mchung, chegar, redestad Contributed-by: alan.bateman at oracle.com, mandy.chung at oracle.com, erik.joelsson at oracle.com, chris.hegarty at oracle.com, peter.levart at gmail.com, sundararajan.athijegannathan at oracle.com ! make/Tools.gmk ! make/gendata/GendataBreakIterator.gmk ! make/launcher/Launcher-java.desktop.gmk ! make/launcher/Launcher-java.scripting.gmk ! make/launcher/Launcher-jdk.compiler.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.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/lang/reflect/WeakPairMap.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java - src/java.base/share/classes/jdk/internal/module/Hasher.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java + src/java.base/share/classes/jdk/internal/module/ModuleHashes.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OptimizationPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! test/TEST.ROOT ! test/com/sun/corba/5036554/TestCorbaBug.sh ! test/com/sun/corba/7130985/CorbaExceptionsCompileTest.java ! test/com/sun/corba/se/impl/io/HookPutFieldsTest.java ! test/com/sun/corba/se/impl/orb/SetDefaultORBTest.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/java/lang/invoke/VarargsArrayTest.java ! test/java/lang/module/ModuleFinderTest.java + test/java/lang/reflect/WeakPairMap/Driver.java + test/java/lang/reflect/WeakPairMap/java.base/java/lang/reflect/WeakPairMapTest.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/javax/crypto/Cipher/CipherStreamClose.java ! test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java ! test/javax/smartcardio/CommandAPDUTest.java ! test/javax/smartcardio/HistoricalBytes.java ! test/javax/smartcardio/ResponseAPDUTest.java ! test/javax/smartcardio/Serialize.java ! test/javax/smartcardio/TerminalFactorySpiTest.java ! test/javax/smartcardio/TestCardPermission.java ! test/javax/smartcardio/TestCommandAPDU.java + test/javax/transaction/testng/Driver.java - test/javax/transaction/testng/TEST.properties ! test/javax/xml/bind/xjc/8032884/XjcOptionalPropertyTest.java ! test/javax/xml/jaxp/common/8035437/run.sh ! test/javax/xml/soap/XmlTest.java ! test/javax/xml/soap/spi/SAAJFactoryTest.java ! test/javax/xml/ws/8043129/MailTest.java ! test/javax/xml/ws/clientjar/TestWsImport.java ! test/javax/xml/ws/publish/WSTest.java ! test/javax/xml/ws/xsanymixed/Test.java ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java ! test/sun/security/provider/PolicyFile/Modules.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLink2Test.java ! test/tools/jlink/JLinkTest.java - test/tools/jlink/hashes/HashesTest.java - test/tools/jlink/hashes/newsrc/m2/module-info.java - test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/tools/jlink/hashes/src/m1/module-info.java - test/tools/jlink/hashes/src/m1/org/m1/Main.java - test/tools/jlink/hashes/src/m2/module-info.java - test/tools/jlink/hashes/src/m2/org/m2/Util.java - test/tools/jlink/hashes/src/not_matched/module-info.java - test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java ! test/tools/jlink/plugins/FileCopierPluginTest.java ! test/tools/jmod/JmodNegativeTest.java + test/tools/jmod/hashes/HashesTest.java + test/tools/jmod/hashes/src/m1/module-info.java + test/tools/jmod/hashes/src/m1/org/m1/Main.java + test/tools/jmod/hashes/src/m2/module-info.java + test/tools/jmod/hashes/src/m2/org/m2/Util.java + test/tools/jmod/hashes/src/m3/module-info.java + test/tools/jmod/hashes/src/m3/org/m3/Name.java + test/tools/jmod/hashes/src/org.bar/module-info.java + test/tools/jmod/hashes/src/org.foo/module-info.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/modules/addmods/AddModsTest.java - test/tools/launcher/modules/addmods/src/app/Main.java - test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java - test/tools/launcher/modules/addmods/src/lib/module-info.java + test/tools/launcher/modules/addmods/src/logger/logger/Logger.java + test/tools/launcher/modules/addmods/src/logger/module-info.java + test/tools/launcher/modules/addmods/src/test/module-info.java + test/tools/launcher/modules/addmods/src/test/test/Main.java ! test/tools/launcher/modules/addreads/AddReadsTest.java ! test/tools/launcher/modules/patch/PatchTest.java ! test/tools/lib/tests/JImageGenerator.java Changeset: a8818f3e8c52 Author: alanb Date: 2016-05-03 11:45 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a8818f3e8c52 Merge ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java - src/java.base/share/classes/jdk/internal/module/Hasher.java ! src/java.base/share/classes/module-info.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java - test/javax/transaction/testng/TEST.properties - test/tools/jlink/hashes/HashesTest.java - test/tools/jlink/hashes/newsrc/m2/module-info.java - test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/tools/jlink/hashes/src/m1/module-info.java - test/tools/jlink/hashes/src/m1/org/m1/Main.java - test/tools/jlink/hashes/src/m2/module-info.java - test/tools/jlink/hashes/src/m2/org/m2/Util.java - test/tools/jlink/hashes/src/not_matched/module-info.java - test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java - test/tools/launcher/modules/addmods/src/app/Main.java - test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java - test/tools/launcher/modules/addmods/src/lib/module-info.java Changeset: 930d3aef37ee Author: redestad Date: 2016-05-03 15:50 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/930d3aef37ee 8155775: Re-examine naming of privileged methods to access System properties Reviewed-by: mullan ! src/java.base/linux/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/java.base/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystem.java ! src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystemProvider.java ! src/java.base/share/classes/java/io/File.java ! src/java.base/share/classes/java/lang/ProcessBuilder.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/SocksSocketImpl.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLConnection.java ! src/java.base/share/classes/java/net/URLEncoder.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/nio/file/TempFileHelper.java ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/java/util/PropertyResourceBundle.java ! src/java.base/share/classes/java/util/TimeZone.java ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/jar/Pack200.java ! src/java.base/share/classes/java/util/regex/PatternSyntaxException.java ! src/java.base/share/classes/java/util/zip/ZipOutputStream.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/java.base/share/classes/jdk/Version.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/java.base/share/classes/sun/net/ResourceManager.java ! src/java.base/share/classes/sun/net/sdp/SdpSupport.java ! src/java.base/share/classes/sun/net/smtp/SmtpClient.java ! src/java.base/share/classes/sun/net/www/MimeLauncher.java ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java ! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/classes/sun/net/www/protocol/netdoc/Handler.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/nio/ch/Net.java ! src/java.base/share/classes/sun/nio/ch/Util.java ! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template ! src/java.base/share/classes/sun/nio/fs/Util.java ! src/java.base/share/classes/sun/security/action/GetIntegerAction.java ! src/java.base/share/classes/sun/security/action/GetPropertyAction.java ! src/java.base/share/classes/sun/security/provider/DSAKeyFactory.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java ! src/java.base/share/classes/sun/security/ssl/ClientKeyExchangeService.java ! src/java.base/share/classes/sun/security/ssl/Debug.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java ! src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/java.base/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/java.base/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/java.base/unix/classes/java/io/UnixFileSystem.java ! src/java.base/unix/classes/java/lang/ProcessImpl.java ! src/java.base/unix/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/java.base/unix/classes/sun/net/NetHooks.java ! src/java.base/unix/classes/sun/net/sdp/SdpProvider.java ! src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/java.base/unix/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/java.base/unix/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java ! src/java.base/windows/classes/java/io/WinNTFileSystem.java ! src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java Changeset: 03453120a011 Author: darcy Date: 2016-05-03 10:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/03453120a011 6850612: Deprecate Class.newInstance since it violates the checked exception language contract Reviewed-by: lancea, mullan, dfuchs ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/ProxySelector.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/net/URLConnection.java ! src/java.base/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/java.base/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/java.base/share/classes/java/security/Policy.java ! src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/jar/Pack200.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/java.base/share/classes/javax/security/auth/login/Configuration.java ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java ! src/java.base/share/classes/sun/net/ftp/FtpClientProvider.java ! src/java.base/share/classes/sun/nio/ch/ThreadPool.java ! src/java.base/share/classes/sun/nio/cs/FastCharsetProvider.java ! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java ! src/java.base/share/classes/sun/security/pkcs/PKCS8Key.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java ! src/java.base/share/classes/sun/security/x509/X509Key.java ! src/java.base/share/classes/sun/util/calendar/CalendarSystem.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/java.base/unix/classes/java/net/DefaultDatagramSocketImplFactory.java ! src/java.base/unix/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/java.base/unix/classes/sun/nio/fs/DefaultFileSystemProvider.java ! src/java.httpclient/share/classes/java/net/http/FilterFactory.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/MemoryHandler.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.naming/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/java.naming/share/classes/com/sun/naming/internal/ResourceManager.java ! src/java.naming/share/classes/javax/naming/ldap/StartTlsRequest.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.prefs/share/classes/java/util/prefs/Preferences.java ! src/java.rmi/share/classes/java/rmi/activation/ActivationID.java ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/sun/rmi/server/Activation.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/Translator.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11Util.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/jdk.internal.le/share/classes/jdk/internal/jline/TerminalFactory.java ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/internal/ConsoleRunner.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.localedata/share/classes/sun/util/resources/provider/LocaleDataProvider.java Changeset: ddf9b6697e60 Author: darcy Date: 2016-05-03 12:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ddf9b6697e60 8155963: Fix deprecation warning in windows java.net implementation Reviewed-by: prr ! src/java.base/windows/classes/java/net/DefaultDatagramSocketImplFactory.java Changeset: 1db91f64f71b Author: darcy Date: 2016-05-03 16:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1db91f64f71b 4943627: Deprecate rounding mode integer constants in BigDecimal and their uses Reviewed-by: bpb ! src/java.base/share/classes/java/math/BigDecimal.java ! src/java.base/share/classes/java/math/RoundingMode.java Changeset: c49b0409a802 Author: sdrach Date: 2016-05-02 09:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c49b0409a802 8151542: URL resources for multi-release jar files have a #runtime fragment appended to them Reviewed-by: alanb, chegar, psandoz, sherman Contributed-by: steve.drach at oracle.com ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilJarAccess.java ! test/java/util/jar/JarFile/MultiReleaseJarHttpProperties.java + test/lib/testlibrary/java/util/jar/SimpleHttpServer.java ! test/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java Changeset: e10915345b2a Author: amlu Date: 2016-05-04 10:56 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e10915345b2a 8154911: Move GCDuringIteration.java back to tier1 Reviewed-by: darcy, martin ! test/TEST.groups Changeset: 909c7db6c47d Author: ant Date: 2016-05-04 16:41 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/909c7db6c47d 8145984: [macosx] sun.lwawt.macosx.CAccessible leaks Reviewed-by: serb, ptbrunet ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibleText.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityUtilities.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaTextAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.h ! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m Changeset: 40832198b160 Author: redestad Date: 2016-05-04 16:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/40832198b160 8155939: sun.launcher.LauncherHelper INSTANCE is unused Reviewed-by: rriggs, ksrini ! src/java.base/share/classes/sun/launcher/LauncherHelper.java Changeset: 5dd02e390cf8 Author: bpb Date: 2016-05-04 08:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5dd02e390cf8 8153192: (se) Selector.select(long) uses wrong timeout after EINTR (lnx) Summary: Pass what remains of the initial timeout to epoll_wait(2) (Linux) and ioctl(7d) (Solaris) instead of the original un-decremented timeout value. Reviewed-by: alanb, rriggs ! src/java.base/linux/native/libnio/ch/EPollArrayWrapper.c ! src/java.base/solaris/native/libnio/ch/DevPollArrayWrapper.c Changeset: 832e924b2ff8 Author: naoto Date: 2016-05-04 08:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/832e924b2ff8 8155649: IncludeLocalesPlugin throws NPE when jdk.localedata not resolved Reviewed-by: alanb, mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java Changeset: 455228b64de4 Author: michaelm Date: 2016-05-05 11:37 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/455228b64de4 8155928: Remove hardcoded port numbers from httpclient/Security.java test Reviewed-by: chegar, rriggs ! src/java.httpclient/share/classes/java/net/http/Utils.java ! test/java/net/httpclient/security/0.policy ! test/java/net/httpclient/security/1.policy ! test/java/net/httpclient/security/10.policy ! test/java/net/httpclient/security/11.policy ! test/java/net/httpclient/security/12.policy + test/java/net/httpclient/security/14.policy ! test/java/net/httpclient/security/15.policy ! test/java/net/httpclient/security/2.policy ! test/java/net/httpclient/security/3.policy ! test/java/net/httpclient/security/4.policy ! test/java/net/httpclient/security/5.policy ! test/java/net/httpclient/security/6.policy ! test/java/net/httpclient/security/7.policy ! test/java/net/httpclient/security/8.policy ! test/java/net/httpclient/security/9.policy + test/java/net/httpclient/security/Driver.java ! test/java/net/httpclient/security/Security.java Changeset: ee18c1df243b Author: psandoz Date: 2016-05-05 11:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee18c1df243b 8155258: VarHandle implementation improvements Reviewed-by: shade, vlivanov ! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/VarForm.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/VarHandleGuards.java ! src/java.base/share/classes/java/lang/invoke/VarHandles.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template Changeset: b77d076941f2 Author: lana Date: 2016-05-05 19:11 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b77d076941f2 Merge - src/java.base/share/classes/jdk/internal/module/Hasher.java - test/javax/transaction/testng/TEST.properties - test/tools/jlink/hashes/HashesTest.java - test/tools/jlink/hashes/newsrc/m2/module-info.java - test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/tools/jlink/hashes/src/m1/module-info.java - test/tools/jlink/hashes/src/m1/org/m1/Main.java - test/tools/jlink/hashes/src/m2/module-info.java - test/tools/jlink/hashes/src/m2/org/m2/Util.java - test/tools/jlink/hashes/src/not_matched/module-info.java - test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java - test/tools/launcher/modules/addmods/src/app/Main.java - test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java - test/tools/launcher/modules/addmods/src/lib/module-info.java Changeset: ed8ca9167d66 Author: shurailine Date: 2016-05-05 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ed8ca9167d66 8154182: Fix java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java to only use available modules Reviewed-by: alanb, mchung ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java Changeset: 59248872ead8 Author: mchung Date: 2016-05-05 16:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/59248872ead8 8154190: Deprivilege java.compiler module Reviewed-by: alanb, chegar, jjg ! src/java.base/share/conf/security/java.policy Changeset: 2d42c4cfd5ac Author: weijun Date: 2016-05-06 11:38 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2d42c4cfd5ac 8051408: NIST SP 800-90A SecureRandom implementations Reviewed-by: wetmore, xuelei, coffeys ! src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java + src/java.base/share/classes/java/security/DrbgParameters.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/security/SecureRandom.java + src/java.base/share/classes/java/security/SecureRandomParameters.java ! src/java.base/share/classes/java/security/SecureRandomSpi.java + src/java.base/share/classes/sun/security/provider/AbstractDrbg.java + src/java.base/share/classes/sun/security/provider/AbstractHashDrbg.java + src/java.base/share/classes/sun/security/provider/CtrDrbg.java + src/java.base/share/classes/sun/security/provider/DRBG.java + src/java.base/share/classes/sun/security/provider/EntropySource.java + src/java.base/share/classes/sun/security/provider/HashDrbg.java + src/java.base/share/classes/sun/security/provider/HmacDrbg.java + src/java.base/share/classes/sun/security/provider/MoreDrbgParameters.java ! src/java.base/share/classes/sun/security/provider/SHA5.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/conf/security/java.security + test/com/sun/crypto/provider/Mac/HmacSHA512.java + test/java/security/SecureRandom/DrbgParametersSpec.java ! test/java/security/SecureRandom/Serialize.java + test/sun/security/provider/MessageDigest/SHA512.java + test/sun/security/provider/SecureRandom/AbstractDrbgSpec.java + test/sun/security/provider/SecureRandom/AutoReseed.java + test/sun/security/provider/SecureRandom/CommonSeeder.java + test/sun/security/provider/SecureRandom/DRBGAlg.java + test/sun/security/provider/SecureRandom/DrbgCavp.java - test/sun/security/provider/SecureRandom/SelfSeed.java ! test/sun/security/provider/SecureRandom/StrongSeedReader.java Changeset: 160221b05c27 Author: mchung Date: 2016-05-05 22:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/160221b05c27 8155513: Deprivilege jdk.charsets Reviewed-by: alanb, chegar ! src/java.base/share/conf/security/java.policy ! test/java/nio/charset/spi/basic.sh ! test/java/nio/charset/spi/default-pol Changeset: 335bbeff90c5 Author: jdv Date: 2016-05-06 06:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/335bbeff90c5 7116979: Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Summary: Unexpected pixel colour when converting images to TYPE_BYTE_INDEXED Reviewed-by: prr, flar ! make/data/x11wrappergen/sizes.32 ! make/data/x11wrappergen/sizes.64 ! make/data/x11wrappergen/sizes.64-solaris-i386 ! make/data/x11wrappergen/xlibtypes.txt ! src/java.desktop/share/native/libawt/awt/image/BufImgSurfaceData.c ! src/java.desktop/share/native/libawt/java2d/SurfaceData.h ! src/java.desktop/share/native/libawt/java2d/loops/ByteIndexed.h ! src/java.desktop/unix/native/common/awt/colordata.h ! src/java.desktop/windows/native/libawt/windows/colordata.h + test/sun/java2d/loops/ConvertToByteIndexedTest.java Changeset: 098e5d482a66 Author: michaelm Date: 2016-05-06 11:30 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/098e5d482a66 8153572: [JEP 110] IOException (connection closed for reading) is thrown when try to connect HTTPS service Reviewed-by: rriggs ! src/java.httpclient/share/classes/java/net/http/AsyncSSLDelegate.java ! src/java.httpclient/share/classes/java/net/http/HttpClientImpl.java ! src/java.httpclient/share/classes/java/net/http/SSLDelegate.java ! test/java/net/httpclient/http2/BasicTest.java ! test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestExchange.java ! test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestServerConnection.java Changeset: 3edef8d5081a Author: ntv Date: 2016-05-06 11:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3edef8d5081a 8015070: Antialiased text on translucent backgrounds gets bright artifacts Reviewed-by: flar, prr, jdv Contributed-by: prahalad.kumar.narayanan at oracle.com ! src/java.desktop/share/native/libawt/java2d/loops/FourByteAbgr.h ! src/java.desktop/share/native/libawt/java2d/loops/FourByteAbgrPre.h ! src/java.desktop/share/native/libawt/java2d/loops/IntArgb.h ! src/java.desktop/share/native/libawt/java2d/loops/IntArgbBm.h ! src/java.desktop/share/native/libawt/java2d/loops/IntArgbPre.h ! src/java.desktop/share/native/libawt/java2d/loops/LoopMacros.h + test/java/awt/Graphics2D/DrawString/AntialiasedTextArtifact.java Changeset: b9760b7afe0d Author: ntv Date: 2016-05-06 12:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9760b7afe0d 8148949: DateTimeFormatter pattern letters 'A','n','N' Summary: Changed the definition of pattern letters 'A','n','N' because it does not match the definition of CLDR Reviewed-by: rriggs, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java Changeset: c5467b18921b Author: smarks Date: 2016-05-06 11:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c5467b18921b 8139233: add initial compact immutable collection implementations Reviewed-by: plevart, forax, dfuchs, chegar, alanb, scolebourne + src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/java/util/List.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/Set.java + test/java/util/Map/EntrySetIterator.java Changeset: b9ed1a4feefb Author: sherman Date: 2016-05-06 14:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b9ed1a4feefb 8150496: (zipfs) Fix performance issues in zip-fs 8150366: (zipfs) lastAccessTime and createTime returned as null instead of default value Reviewed-by: alanb, redestad, shade ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileAttributes.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java ! test/jdk/nio/zipfs/Basic.java ! test/jdk/nio/zipfs/PathOps.java Changeset: 60795927342a Author: stuefe Date: 2016-05-07 00:26 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/60795927342a 8155211: Ucrypto Library leaks native memory Summary: Free the memory allocated by calloc(0, x) calls Reviewed-by: valeriep, igerasim ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCrypto.c Changeset: ad74c39cac12 Author: redestad Date: 2016-05-07 01:49 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad74c39cac12 8150044: Generate classlists at build-time Reviewed-by: alanb, mchung, iklam Contributed-by: claes.redestad at oracle.com, erik.joelsson at oracle.com + make/GenerateClasslist.gmk - make/data/classlist/classlist.aix - make/data/classlist/classlist.linux - make/data/classlist/classlist.macosx - make/data/classlist/classlist.solaris - make/data/classlist/classlist.windows ! make/gendata/Gendata-java.base.gmk + make/src/classes/build/tools/classlist/HelloClasslist.java Changeset: 4aa52dc73711 Author: redestad Date: 2016-05-07 02:53 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4aa52dc73711 Merge - make/data/classlist/classlist.aix - make/data/classlist/classlist.linux - make/data/classlist/classlist.macosx - make/data/classlist/classlist.solaris - make/data/classlist/classlist.windows Changeset: 8674acefce79 Author: sspitsyn Date: 2016-05-06 12:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8674acefce79 8156147: NPE in InstrumentationImpl.transform when loading classes from -Xbootclasspath/a Summary: Use the jdk.internal.loader.Bootloader if the loader argument is null Reviewed-by: alanb ! src/java.base/share/classes/module-info.java ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java + test/java/lang/instrument/BootstrapClassPathAgent.java + test/java/lang/instrument/BootstrapClassPathSetUp.sh + test/java/lang/instrument/BootstrapClassPathTest.java Changeset: 963fa7af5548 Author: sspitsyn Date: 2016-05-06 20:36 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/963fa7af5548 Merge Changeset: a2d6a296010f Author: sspitsyn Date: 2016-05-06 23:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a2d6a296010f Merge Changeset: 7f1ef660db8b Author: sspitsyn Date: 2016-05-07 00:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f1ef660db8b Merge Changeset: 59fbc3a41b16 Author: simonis Date: 2016-05-07 08:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/59fbc3a41b16 8156020: 8145547 breaks AIX and and uses RTLD_NOLOAD incorrectly Reviewed-by: prr, serb ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.c Changeset: 01f92e15cf1e Author: ntv Date: 2016-05-08 07:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01f92e15cf1e 8079628: java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value` Summary: Change the definition of 'DD' to match with CLDR Reviewed-by: rriggs, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java ! test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java Changeset: a0fe57307d3b Author: jlahoda Date: 2016-05-08 22:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a0fe57307d3b 8147984: WindowsTerminal should support function keys Reviewed-by: smarks ! src/jdk.internal.le/share/classes/jdk/internal/jline/WindowsTerminal.java Changeset: fbe3daace0b7 Author: xuelei Date: 2016-05-08 23:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fbe3daace0b7 8156502: Use short name of SupportedEllipticCurvesExtension.java Reviewed-by: vinnie ! src/java.base/share/classes/sun/security/ssl/ClientHandshaker.java + src/java.base/share/classes/sun/security/ssl/EllipticCurvesExtension.java + src/java.base/share/classes/sun/security/ssl/EllipticPointFormatsExtension.java ! src/java.base/share/classes/sun/security/ssl/HandshakeMessage.java ! src/java.base/share/classes/sun/security/ssl/HelloExtensions.java ! src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java - src/java.base/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java - src/java.base/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java Changeset: e87c5b70b365 Author: peytoia Date: 2016-05-09 17:46 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e87c5b70b365 8154295: Currency iso code is int and hence looses the preceeding zero. Reviewed-by: naoto, okutsu, peytoia Contributed-by: Nishit Jain ! src/java.base/share/classes/java/util/Currency.java + test/java/util/Currency/Bug8154295.java Changeset: 5d2b5a53001b Author: michaelm Date: 2016-05-09 10:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5d2b5a53001b 8155888: java/net/httpclient/QuickResponses.java intermittently failed with java.util.ConcurrentModificationException Reviewed-by: chegar ! test/java/net/httpclient/QuickResponses.java ! test/java/net/httpclient/Server.java ! test/java/net/httpclient/SplitResponse.java Changeset: 26cff22692a5 Author: amlu Date: 2016-05-09 18:06 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/26cff22692a5 8156512: Mark several tests from java/nio as intermittently failing Reviewed-by: alanb ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/FileChannel/InterruptMapDeadlock.java Changeset: 5f4aff1d2242 Author: amlu Date: 2016-05-09 18:11 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f4aff1d2242 8156529: Problem list java/nio/file/WatchService/DeleteInterference.java Reviewed-by: alanb ! test/ProblemList.txt Changeset: e1eba5cfa5cc Author: mchung Date: 2016-05-09 09:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e1eba5cfa5cc 8153912: Reconsider StackFrame::getFileName and StackFrame::getLineNumber Summary: Add StackFrame::getByteCodeIndex method. Revised getFileName and getLineNumber method. Reviewed-by: dfuchs, bchristi ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/StackWalker.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangInvokeAccess.java ! test/java/lang/StackWalker/EmbeddedStackWalkTest.java ! test/java/lang/StackWalker/StackRecorderUtil.java + test/java/lang/StackWalker/TestBCI.java Changeset: 647431dccd71 Author: lana Date: 2016-05-12 15:15 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/647431dccd71 Added tag jdk-9+118 for changeset e1eba5cfa5cc ! .hgtags Changeset: d53359734725 Author: alanb Date: 2016-05-12 19:12 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d53359734725 Merge ! .hgtags ! make/Tools.gmk - make/data/classlist/classlist.aix - make/data/classlist/classlist.linux - make/data/classlist/classlist.macosx - make/data/classlist/classlist.solaris - make/data/classlist/classlist.windows ! make/gendata/Gendata-java.base.gmk ! make/gendata/GendataBreakIterator.gmk ! make/launcher/Launcher-java.desktop.gmk ! make/launcher/Launcher-java.scripting.gmk ! make/launcher/Launcher-jdk.compiler.gmk ! make/launcher/Launcher-jdk.javadoc.gmk ! make/launcher/Launcher-jdk.jlink.gmk ! make/launcher/Launcher-jdk.scripting.nashorn.shell.gmk ! 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/System.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/java/lang/module/ModulePath.java ! src/java.base/share/classes/java/lang/module/ModuleReader.java ! src/java.base/share/classes/java/lang/module/ModuleReference.java ! src/java.base/share/classes/java/lang/module/ModuleReferences.java ! src/java.base/share/classes/java/lang/module/Resolver.java ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.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/lang/reflect/Proxy.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ServiceLoader.java ! src/java.base/share/classes/java/util/jar/Pack200.java ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java ! src/java.base/share/classes/jdk/internal/loader/BootLoader.java ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangModuleAccess.java ! src/java.base/share/classes/jdk/internal/misc/JavaLangReflectModuleAccess.java ! src/java.base/share/classes/jdk/internal/module/Builder.java ! src/java.base/share/classes/jdk/internal/module/ClassFileAttributes.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/classes/jdk/internal/module/ModuleHashes.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java ! src/java.base/share/classes/jdk/internal/module/Modules.java ! src/java.base/share/classes/jdk/internal/module/ServicesCatalog.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java ! src/java.base/share/classes/sun/security/jca/ProviderConfig.java - src/java.base/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java - src/java.base/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/java.base/share/conf/security/java.policy ! src/java.base/share/conf/security/java.security ! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/MemoryHandler.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/java.naming/share/classes/com/sun/naming/internal/FactoryEnumeration.java ! src/java.naming/share/classes/com/sun/naming/internal/ResourceManager.java ! src/java.naming/share/classes/javax/naming/spi/NamingManager.java ! src/java.prefs/share/classes/java/util/prefs/Preferences.java ! src/java.rmi/share/classes/java/rmi/activation/ActivationID.java ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/sun/rmi/server/Activation.java ! src/java.sql.rowset/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/spi/SyncFactory.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/AbstractCharsetProvider.java ! src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OptimizationPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties ! src/jdk.localedata/share/classes/sun/util/resources/provider/LocaleDataProvider.java ! test/ProblemList.txt ! test/TEST.ROOT ! test/TEST.groups ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/javax/xml/jaxp/common/8035437/run.sh ! test/javax/xml/soap/spi/SAAJFactoryTest.java ! test/sun/security/provider/PolicyFile/Modules.java - test/sun/security/provider/SecureRandom/SelfSeed.java ! test/tools/jar/modularJar/Basic.java ! test/tools/jar/modularJar/src/bar/jdk/test/bar/Bar.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLink2Test.java ! test/tools/jlink/JLinkTest.java ! test/tools/jlink/plugins/FileCopierPluginTest.java ! test/tools/jlink/plugins/IncludeLocalesPluginTest.java ! test/tools/jmod/JmodNegativeTest.java ! test/tools/jmod/hashes/HashesTest.java ! test/tools/jmod/hashes/src/m1/module-info.java ! test/tools/jmod/hashes/src/m1/org/m1/Main.java ! test/tools/jmod/hashes/src/m2/module-info.java ! test/tools/jmod/hashes/src/m2/org/m2/Util.java ! test/tools/jmod/hashes/src/m3/module-info.java ! test/tools/jmod/hashes/src/m3/org/m3/Name.java ! test/tools/launcher/ToolsOpts.java ! test/tools/launcher/modules/addmods/AddModsTest.java ! test/tools/launcher/modules/addreads/AddReadsTest.java ! test/tools/launcher/modules/patch/PatchTest.java ! test/tools/lib/tests/JImageGenerator.java From Sergey.Bylokhov at oracle.com Wed May 11 12:41:26 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 May 2016 15:41:26 +0300 Subject: Having problem building jdk9-dev In-Reply-To: <6135110E-E907-4536-8B2C-4222AF073143@oracle.com> References: <7A68F28A-6273-42FF-A7F3-D721AE30E960@oracle.com> <57331415.3010506@oracle.com> <57331751.1040709@oracle.com> <573318E9.2030804@oracle.com> <6135110E-E907-4536-8B2C-4222AF073143@oracle.com> Message-ID: <55bedae4-8ff6-2d73-b0d0-586d7371af95@oracle.com> On 11.05.16 14:48, James Laskey wrote: > Wonder if we should have a configuration warning when an inappropriate version is used. +1, is it possible to implement? > > Sent from my iPhone > >> On May 11, 2016, at 8:35 AM, Aleksey Shipilev wrote: >> >>> On 05/11/2016 02:28 PM, Alan Bateman wrote: >>>> On 11/05/2016 12:14, Aleksey Shipilev wrote: >>>> Got the same today, and figured it only fails with JDK 9 as the boot >>>> JDK. Builds fine with JDK 8 as boot JDK. Filed: >>>> https://bugs.openjdk.java.net/browse/JDK-8156740 >>> You can never guarantee that the JDK N in development will build with a >>> older build of JDK N, there is just too much churn. Boot cycles builds >>> should be fine of course, meaning a JDK build should be able to build >>> itself (make bootcycle-images). >> >> No problem with that. Let's close the bug with WNF and this description >> then, so the next person facing this particular issue knows the >> corrective action immediately. >> >> Thanks, >> -Aleksey >> >> > -- Best regards, Sergey. From sundararajan.athijegannathan at oracle.com Fri May 13 08:20:26 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 13 May 2016 13:50:26 +0530 Subject: RFR 8156914: jlink API minor cleanups Message-ID: Please review http://cr.openjdk.java.net/~sundar/8156914/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8156914 Thanks, -Sundar From martinrb at google.com Fri May 13 19:04:48 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 May 2016 12:04:48 -0700 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL Message-ID: I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg won't start. A simple repro is: jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 . Agent[0].stdout: Bad value for -Xpatch, no module name specified Agent[0].stderr: Error: Could not create the Java Virtual Machine. Agent[0].stderr: Error: A fatal exception has occurred. Program will exit. It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of that has changed. strace shows the flag "-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches" Jonathan has been making -Xpatch related changes to jtreg in mercurial that may have already fixed it, but if so, making a 4.2-b03 release is urgent. It would be nice if there were one jtreg binary that could work with any jdk9 build, but that's understandably difficult. Of course, jsr166 wants to add its own -Xpatch flags; hopefully that will be able to peacefully coexist with whatever jtreg ends up doing. From Alan.Bateman at oracle.com Fri May 13 19:18:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 20:18:17 +0100 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL In-Reply-To: References: Message-ID: <57362879.8050602@oracle.com> On 13/05/2016 20:04, Martin Buchholz wrote: > I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg > won't start. > A simple repro is: > > jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 . > Agent[0].stdout: Bad value for -Xpatch, no module name specified > Agent[0].stderr: Error: Could not create the Java Virtual Machine. > Agent[0].stderr: Error: A fatal exception has occurred. Program will exit. > > It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of > that has changed. > > strace shows the flag > "-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches" > > Jonathan has been making -Xpatch related changes to jtreg in mercurial > that may have already fixed it, but if so, making a 4.2-b03 release is > urgent. It would be nice if there were one jtreg binary that could > work with any jdk9 build, but that's understandably difficult. > > Of course, jsr166 wants to add its own -Xpatch flags; hopefully that > will be able to peacefully coexist with whatever jtreg ends up doing. We transitioned to the new form of -Xpatch in jdk-9+118. jtreg 4.2 b02 can use the old or new form. It's configured via the useNewXpatch property in the test suite configuration. In jdk-9+118 then each test root had its TEST.ROOT changed to include useNewXpatch=true so that jtreg uses the new form of -Xpatch. For jtreg 4.2 b03 then Jon has removed support for the old form of -Xpatch. I don't think you need that just yet. So is this test suit a jsr166 test suite? If so then useNewXpatch=true or jtreg tip should be okay. I'll need to defer to Jon on peacefully co-existing as you are both patching java.base. You can only specify -Xpatch:java.base= only but the value can specify multiple locations. I suspect -othervm should be fine, -agentvm mode is where jtreg needs to inject. -Alan. From martinrb at google.com Fri May 13 19:29:16 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 13 May 2016 12:29:16 -0700 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL In-Reply-To: <57362879.8050602@oracle.com> References: <57362879.8050602@oracle.com> Message-ID: On Fri, May 13, 2016 at 12:18 PM, Alan Bateman wrote: > On 13/05/2016 20:04, Martin Buchholz wrote: >> >> I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg >> won't start. >> A simple repro is: >> >> jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 . >> Agent[0].stdout: Bad value for -Xpatch, no module name specified >> Agent[0].stderr: Error: Could not create the Java Virtual Machine. >> Agent[0].stderr: Error: A fatal exception has occurred. Program will exit. >> >> It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of >> that has changed. >> >> strace shows the flag >> "-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches" >> >> Jonathan has been making -Xpatch related changes to jtreg in mercurial >> that may have already fixed it, but if so, making a 4.2-b03 release is >> urgent. It would be nice if there were one jtreg binary that could >> work with any jdk9 build, but that's understandably difficult. >> >> Of course, jsr166 wants to add its own -Xpatch flags; hopefully that >> will be able to peacefully coexist with whatever jtreg ends up doing. > > We transitioned to the new form of -Xpatch in jdk-9+118. > > jtreg 4.2 b02 can use the old or new form. It's configured via the > useNewXpatch property in the test suite configuration. In jdk-9+118 then > each test root had its TEST.ROOT changed to include useNewXpatch=true so > that jtreg uses the new form of -Xpatch. Thanks! That explains why I can still run jtreg -agentvm on openjdk itself. (But useNewXpatch feels wrong because it's not a property of the test suite itself, but of the testjdk ...) > For jtreg 4.2 b03 then Jon has removed support for the old form of -Xpatch. > I don't think you need that just yet. I'll probably wait for 4.2-b03. From mandy.chung at oracle.com Fri May 13 19:36:56 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 May 2016 12:36:56 -0700 Subject: RFR 8156914: jlink API minor cleanups In-Reply-To: References: Message-ID: <32FE6EF8-4DE3-4D62-A72F-91473024CB71@oracle.com> > On May 13, 2016, at 1:20 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8156914/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8156914 > This patch looks okay. The renamed TransformerPlugin::transformAndCopy method does not really do the copying wherease the plugin provider has to do the copying. Since you are going to have iterate on it, it?s fine to push this clean up. make/Javadoc.gmk should be updated to only include jdk.tools.jlink.plugin package. Mandy From Alan.Bateman at oracle.com Fri May 13 19:38:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 May 2016 20:38:05 +0100 Subject: jtreg 4.2-b02 -agentvm + jdk-9+118 = FAIL In-Reply-To: References: <57362879.8050602@oracle.com> Message-ID: <57362D1D.2010001@oracle.com> On 13/05/2016 20:29, Martin Buchholz wrote: > : > Thanks! That explains why I can still run jtreg -agentvm on openjdk itself. > (But useNewXpatch feels wrong because it's not a property of the test > suite itself, but of the testjdk ...) > I agree but it was just for transition purposes to keep existing jtreg usages working. It's removed from jtreg tip and we'll drop it from TEST.ROOT once there is an overall upgrade to jtreg 4.2 b03. -Alan From alexandre.iline at oracle.com Fri May 13 22:54:34 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 13 May 2016 15:54:34 -0700 Subject: RFR 8156972: java/lang/reflect/Layer/LayerAndLoadersTest.java test requires jdk.compiler Message-ID: <77FEAFE0-C7F8-4D08-813A-76FE63E2EDDE@oracle.com> Hi. Could you please take a look on the fix: http://cr.openjdk.java.net/~shurailine/8156972/webrev.00/ Besides adding @modules, I have also added a couple of lines to the library class, because I have found the NPE which I was getting originally non-informative. Shura From Alan.Bateman at oracle.com Sat May 14 15:37:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 14 May 2016 16:37:14 +0100 Subject: RFR 8156972: java/lang/reflect/Layer/LayerAndLoadersTest.java test requires jdk.compiler In-Reply-To: <77FEAFE0-C7F8-4D08-813A-76FE63E2EDDE@oracle.com> References: <77FEAFE0-C7F8-4D08-813A-76FE63E2EDDE@oracle.com> Message-ID: <5737462A.2000702@oracle.com> On 13/05/2016 23:54, Alexandre (Shura) Iline wrote: > Hi. > > Could you please take a look on the fix: > http://cr.openjdk.java.net/~shurailine/8156972/webrev.00/ > > Besides adding @modules, I have also added a couple of lines to the library class, because I have found the NPE which I was getting originally non-informative. > The @modules looks good. For CompileUtils then it might be better to throw UOE instead of ISE for this case. Also would be good to add this exception to the @throws list in the javadoc. -Alan. From everson.c.junior at gmail.com Sun May 15 18:16:16 2016 From: everson.c.junior at gmail.com (Everson Ferreira da Cunha Junior) Date: Sun, 15 May 2016 15:16:16 -0300 Subject: Project JIGSAW does not work Message-ID: Hi guys! I'm disappoint with jigsaw project. I've run the first example of guide on Ubuntu Linux, but it has not worked. Follow the error: "src/com.greetings/module-info.java:1: error: class, interface, or enum expected module com.greetings { }" I've found nothing in internet about it. What can it be ? Thank you. Regards, Everson Jr From forax at univ-mlv.fr Sun May 15 18:46:01 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 15 May 2016 20:46:01 +0200 (CEST) Subject: Project JIGSAW does not work In-Reply-To: References: Message-ID: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> Hi Everson, let start with a simple question, do you have checked that you use the java 9 version of javac (javac -version) ? cheers, R?mi ----- Mail original ----- > De: "Everson Ferreira da Cunha Junior" > ?: jigsaw-dev at openjdk.java.net > Envoy?: Dimanche 15 Mai 2016 20:16:16 > Objet: Project JIGSAW does not work > > Hi guys! > > I'm disappoint with jigsaw project. I've run the first example of guide on > Ubuntu Linux, but it has not worked. Follow the error: > > "src/com.greetings/module-info.java:1: error: class, interface, or enum > expected > module com.greetings { }" > > > I've found nothing in internet about it. What can it be ? > > Thank you. > > Regards, > Everson Jr > From Alan.Bateman at oracle.com Sun May 15 19:31:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 15 May 2016 20:31:25 +0100 Subject: Project JIGSAW does not work In-Reply-To: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> References: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> Message-ID: <5738CE8D.1090403@oracle.com> On 15/05/2016 19:46, Remi Forax wrote: > Hi Everson, > let start with a simple question, > do you have checked that you use the java 9 version of javac (javac -version) ? > > Right, the output looks like JDK 8 or older is being used. -Alan. From pbenedict at apache.org Mon May 16 02:22:15 2016 From: pbenedict at apache.org (Paul Benedict) Date: Sun, 15 May 2016 21:22:15 -0500 Subject: Project JIGSAW does not work In-Reply-To: References: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> <5738CE8D.1090403@oracle.com> Message-ID: It would be helpful in the next update to emit an error message specific to finding the "module" keyword and report it's only available in -source 9. That kind of little stuff can go a long way in helping users. On May 15, 2016 2:32 PM, "Alan Bateman" wrote: On 15/05/2016 19:46, Remi Forax wrote: > Hi Everson, > let start with a simple question, > do you have checked that you use the java 9 version of javac (javac > -version) ? > > > Right, the output looks like JDK 8 or older is being used. -Alan. From felix.yang at oracle.com Mon May 16 08:18:11 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 16 May 2016 16:18:11 +0800 Subject: Ping - Re: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: References: <56D5312E.9030508@oracle.com> <56D64FC0.2050609@oracle.com> <57076334.2080607@oracle.com> <570F5899.2000401@oracle.com> <6a3f7043-b831-b39c-c936-08a44328a8b0@oracle.com> Message-ID: Hi Stuart, please review the updated webrev, which remove not-suggested filesystem modification and codebase stuff: http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/ Thanks, Felix From uschindler at apache.org Mon May 16 14:28:15 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 16 May 2016 16:28:15 +0200 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module Message-ID: <02eb01d1af7f$31529c60$93f7d520$@apache.org> Hi, the Lucene team installed JDK9 build 118 today and this failed our build during some checks. The reason is that some classes are missing from the unnamed module (standard Java 8 classpath-only application). Just try this test: public class Test { public static void main(String... args) throws Exception { Class.forName("javax.xml.bind.DatatypeConverter"); } } $ javac Test.java $ java Test Exception in thread "main" java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter at jdk.internal.loader.BuiltinClassLoader.loadClass(java.base at 9-ea/BuiltinClassLoader.java:366) at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(java.base at 9-ea/ClassLoaders.java:184) at java.lang.ClassLoader.loadClass(java.base at 9-ea/ClassLoader.java:419) at java.lang.Class.forName0(java.base at 9-ea/Native Method) at java.lang.Class.forName(java.base at 9-ea/Class.java:294) at Test.main(Test.java:3) $ java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+118) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+118, mixed mode) This works with build 116 and Java 8. This is not the only class that?s missing at runtime, there are more: I do not have the complete list, but our checks using the forbiddenapis Ant/Maven/Gradle plugin fails to load classes around JAXB/XML (javax.xml.bind.*, javax.jws.*) and CORBA (org.omg.CORBA.*), but also "javax.activation.ActivationDataFlavor". But there may be more packages missing. It looks like some module exports are missing because the classes are all listed on the JDK docs: http://download.java.net/java/jdk9/118/docs/api/index.html I'd suggest to add a check in the packaging that validates that all classes also visible in the Javadocs are visible at runtime from applications not using the module system. Should I open bug report or can we shortcut this through the mailing list? Greetings from the Lucene team, Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From jonathan.gibbons at oracle.com Mon May 16 14:44:41 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 16 May 2016 07:44:41 -0700 Subject: Project JIGSAW does not work In-Reply-To: References: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> <5738CE8D.1090403@oracle.com> Message-ID: <5739DCD9.1050406@oracle.com> In general, it's not practical to go back and fix updates to older releases so that the compiler is cognisant of all syntax changes in subsequent releases, especially changes in features that are still under development. For example, it's possible that the original submitter was using a recent version of javac, but just not recent enough. [1] Should we have had forward looking error detection in early builds of JDK 9 as well? The submitter provided very little information in his post, just referring to a "example of guide on Ubuntu Linux'." It would make more sense to ensure that any such guides reference the minimal JDK version and build required for the content they contain. -- Jon [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html On 05/15/2016 07:22 PM, Paul Benedict wrote: > It would be helpful in the next update to emit an error message specific to > finding the "module" keyword and report it's only available in -source 9. > That kind of little stuff can go a long way in helping users. > On May 15, 2016 2:32 PM, "Alan Bateman" wrote: > > > > On 15/05/2016 19:46, Remi Forax wrote: > >> Hi Everson, >> let start with a simple question, >> do you have checked that you use the java 9 version of javac (javac >> -version) ? >> >> >> Right, the output looks like JDK 8 or older is being used. > -Alan. From Alan.Bateman at oracle.com Mon May 16 14:45:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 15:45:20 +0100 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module In-Reply-To: <02eb01d1af7f$31529c60$93f7d520$@apache.org> References: <02eb01d1af7f$31529c60$93f7d520$@apache.org> Message-ID: <5739DD00.6070400@oracle.com> On 16/05/2016 15:28, Uwe Schindler wrote: > : > > This is not the only class that?s missing at runtime, there are more: I do not have the complete list, but our checks using the forbiddenapis Ant/Maven/Gradle plugin fails to load classes around JAXB/XML (javax.xml.bind.*, javax.jws.*) and CORBA (org.omg.CORBA.*), but also "javax.activation.ActivationDataFlavor". But there may be more packages missing. > jdk-9+118 is the first JDK 9 build to have the policy for root modules that is described in JEP 261. This has been changed in the Jigsaw EA builds some time and only merged into the main line for build 118. I hope to send mail to jdk9-dev shortly about this - we know it will be a surprise to some. As to what is going on? The java.corba and the EE modules are no longer resolved by default when compiling code in the unnamed module or where the main class is loaded from class path. This means the types in these modules are not visible. Nothing has been removed and if you run with `-addmods java.se.ee` then each of the Java EE modules will be resolved as they were previously. We have updated text for JEP 261 that describes this in more detail, along with the rational. We will likely assess the impact of this change later in JDK 9 but for now, there is easy workaround for those that depend on these components being in the JDK. -Alan From everson.c.junior at gmail.com Mon May 16 15:04:13 2016 From: everson.c.junior at gmail.com (Everson Ferreira da Cunha Junior) Date: Mon, 16 May 2016 12:04:13 -0300 Subject: Project JIGSAW does not work In-Reply-To: <5739DCD9.1050406@oracle.com> References: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> <5738CE8D.1090403@oracle.com> <5739DCD9.1050406@oracle.com> Message-ID: Hi Jon. What's recommend to do ? Do I need to find other version case it exists? I've read some information about this problem. It advice to add this project into jdk 9. Is it correct? Thanks guys! On May 16, 2016 11:45, "Jonathan Gibbons" wrote: > In general, it's not practical to go back and fix updates to older > releases so that the compiler is cognisant of all syntax changes > in subsequent releases, especially changes in features that are > still under development. > > For example, it's possible that the original submitter was using > a recent version of javac, but just not recent enough. [1] > Should we have had forward looking error detection in early > builds of JDK 9 as well? > > The submitter provided very little information in his post, just > referring to a "example of guide on Ubuntu Linux'." It would > make more sense to ensure that any such guides reference > the minimal JDK version and build required for the content they > contain. > > -- Jon > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html > > On 05/15/2016 07:22 PM, Paul Benedict wrote: > >> It would be helpful in the next update to emit an error message specific >> to >> finding the "module" keyword and report it's only available in -source 9. >> That kind of little stuff can go a long way in helping users. >> On May 15, 2016 2:32 PM, "Alan Bateman" wrote: >> >> >> >> On 15/05/2016 19:46, Remi Forax wrote: >> >> Hi Everson, >>> let start with a simple question, >>> do you have checked that you use the java 9 version of javac (javac >>> -version) ? >>> >>> >>> Right, the output looks like JDK 8 or older is being used. >>> >> -Alan. >> > > From uschindler at apache.org Mon May 16 15:19:15 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 16 May 2016 17:19:15 +0200 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module In-Reply-To: <5739DD00.6070400@oracle.com> References: <02eb01d1af7f$31529c60$93f7d520$@apache.org> <5739DD00.6070400@oracle.com> Message-ID: <030101d1af86$51ae4930$f50adb90$@apache.org> Thanks Alan, so this means we should better remove the references to the mentioned class from the Apache Solr code if not needed (I don't think we need the Java EE features here, it might be an oversight). I just wonder why Javac succeeded in our case to build. I have to dig. For now I added "-addmods java.se.ee" to our build server's testing Java configuration, to be able to test build 118. Is it planned to have those classes disabled for pre-Java-9 apps by default in Java 9? Would't it be better for standard unnamed classpath apps to "fall back" in a backwards compatible way? In addition, the Javadocs don't say anything about which modules are visible by default. I think this should be added, too. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Monday, May 16, 2016 4:45 PM > To: Uwe Schindler ; jigsaw-dev at openjdk.java.net > Cc: rory.odonnell at oracle.com; dev at lucene.apache.org > Subject: Re: Java 9 build 118 is hiding some documented & public classes from > unnamed module > > On 16/05/2016 15:28, Uwe Schindler wrote: > > : > > > > This is not the only class that?s missing at runtime, there are more: I do not > have the complete list, but our checks using the forbiddenapis > Ant/Maven/Gradle plugin fails to load classes around JAXB/XML > (javax.xml.bind.*, javax.jws.*) and CORBA (org.omg.CORBA.*), but also > "javax.activation.ActivationDataFlavor". But there may be more packages > missing. > > > jdk-9+118 is the first JDK 9 build to have the policy for root modules > that is described in JEP 261. This has been changed in the Jigsaw EA > builds some time and only merged into the main line for build 118. I > hope to send mail to jdk9-dev shortly about this - we know it will be a > surprise to some. > > As to what is going on? The java.corba and the EE modules are no longer > resolved by default when compiling code in the unnamed module or where > the main class is loaded from class path. This means the types in these > modules are not visible. Nothing has been removed and if you run with > `-addmods java.se.ee` then each of the Java EE modules will be resolved > as they were previously. We have updated text for JEP 261 that describes > this in more detail, along with the rational. We will likely assess the > impact of this change later in JDK 9 but for now, there is easy > workaround for those that depend on these components being in the JDK. > > -Alan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org > For additional commands, e-mail: dev-help at lucene.apache.org From alexandre.iline at oracle.com Mon May 16 17:28:58 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 16 May 2016 10:28:58 -0700 Subject: RFR 8156972: java/lang/reflect/Layer/LayerAndLoadersTest.java test requires jdk.compiler In-Reply-To: <5737462A.2000702@oracle.com> References: <77FEAFE0-C7F8-4D08-813A-76FE63E2EDDE@oracle.com> <5737462A.2000702@oracle.com> Message-ID: You are right, Alan. Thank you. http://cr.openjdk.java.net/~shurailine/8156972/webrev.01/ I have also tried to think of a better message, since it is UOE not and not ISE ? but decided it is descriptive enough as it is. Shura > On May 14, 2016, at 8:37 AM, Alan Bateman wrote: > > On 13/05/2016 23:54, Alexandre (Shura) Iline wrote: >> Hi. >> >> Could you please take a look on the fix: >> http://cr.openjdk.java.net/~shurailine/8156972/webrev.00/ >> >> Besides adding @modules, I have also added a couple of lines to the library class, because I have found the NPE which I was getting originally non-informative. >> > The @modules looks good. For CompileUtils then it might be better to throw UOE instead of ISE for this case. Also would be good to add this exception to the @throws list in the javadoc. > > -Alan. From Alan.Bateman at oracle.com Mon May 16 18:53:52 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 19:53:52 +0100 Subject: 8156989: Trailing empty element in classpath ignored Message-ID: <573A1740.1070600@oracle.com> Martin's MineField test has been excluded for some time, one reason is that it exercised -Xbootclasspath/p and so doesn't work with JDK 9. Jon is cleaning up this test via JDK-8156989 and lo behold, it finds a corner case. The corner case is where the last element of the class is the empty string. Long standing behavior is to treat empty elements on the class path as the working directory. The issue crept in because the implementation uses String.split and is easily fixed: http://cr.openjdk.java.net/~alanb/8156989/webrev/ For tests then Jon will be pushing the updated MineField to jdk9/dev soon. We need to go over the new options and get javac and the runtime consistent. I think we want it so that empty elements in the new options are ignored, leaving class path for legacy reasons. -Alan. From Alan.Bateman at oracle.com Mon May 16 18:56:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 19:56:27 +0100 Subject: RFR 8156972: java/lang/reflect/Layer/LayerAndLoadersTest.java test requires jdk.compiler In-Reply-To: References: <77FEAFE0-C7F8-4D08-813A-76FE63E2EDDE@oracle.com> <5737462A.2000702@oracle.com> Message-ID: <573A17DB.1070905@oracle.com> On 16/05/2016 18:28, Alexandre (Shura) Iline wrote: > You are right, Alan. Thank you. > > http://cr.openjdk.java.net/~shurailine/8156972/webrev.01/ > > I have also tried to think of a better message, since it is UOE not and not ISE ? but decided it is descriptive enough as it is. > I think UOE is better here. My comment about the @throws was to put it in the javadoc. It doesn't have to be in the throws declaration because it's unchecked but no big deal. I'm happy to sponsor this change. -Alan From Alan.Bateman at oracle.com Mon May 16 18:59:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 May 2016 19:59:36 +0100 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module In-Reply-To: <030101d1af86$51ae4930$f50adb90$@apache.org> References: <02eb01d1af7f$31529c60$93f7d520$@apache.org> <5739DD00.6070400@oracle.com> <030101d1af86$51ae4930$f50adb90$@apache.org> Message-ID: <573A1898.8080002@oracle.com> On 16/05/2016 16:19, Uwe Schindler wrote: > Thanks Alan, > > so this means we should better remove the references to the mentioned class from the Apache Solr code if not needed (I don't think we need the Java EE features here, it might be an oversight). I just wonder why Javac succeeded in our case to build. I have to dig. > > For now I added "-addmods java.se.ee" to our build server's testing Java configuration, to be able to test build 118. Good. > > Is it planned to have those classes disabled for pre-Java-9 apps by default in Java 9? Would't it be better for standard unnamed classpath apps to "fall back" in a backwards compatible way? Once JEP 261 is update then I hope the rational will be clearer. It's not really a problem to resolve java.xml.bind and java.activation by default, the others are problems though. > > In addition, the Javadocs don't say anything about which modules are visible by default. I think this should be added, too. > I think TBD, partly because this is really JDK policy. -Alan From mandy.chung at oracle.com Mon May 16 19:36:45 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 16 May 2016 12:36:45 -0700 Subject: 8156989: Trailing empty element in classpath ignored In-Reply-To: <573A1740.1070600@oracle.com> References: <573A1740.1070600@oracle.com> Message-ID: <5435DD23-093F-4173-AF29-600AC349CF3C@oracle.com> > On May 16, 2016, at 11:53 AM, Alan Bateman wrote: > > > Martin's MineField test has been excluded for some time, one reason is that it exercised -Xbootclasspath/p and so doesn't work with JDK 9. Jon is cleaning up this test via JDK-8156989 and lo behold, it finds a corner case. > > The corner case is where the last element of the class is the empty string. Long standing behavior is to treat empty elements on the class path as the working directory. The issue crept in because the implementation uses String.split and is easily fixed: > http://cr.openjdk.java.net/~alanb/8156989/webrev/ > This looks fine. > For tests then Jon will be pushing the updated MineField to jdk9/dev soon. We need to go over the new options and get javac and the runtime consistent. I think we want it so that empty elements in the new options are ignored, leaving class path for legacy reasons. Yes we should add new tests to ensure the javac and runtime consistency of the new options. Mandy From jonathan.gibbons at oracle.com Mon May 16 20:11:36 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 16 May 2016 13:11:36 -0700 Subject: 8156989: Trailing empty element in classpath ignored In-Reply-To: <5435DD23-093F-4173-AF29-600AC349CF3C@oracle.com> References: <573A1740.1070600@oracle.com> <5435DD23-093F-4173-AF29-600AC349CF3C@oracle.com> Message-ID: <573A2978.20900@oracle.com> On 05/16/2016 12:36 PM, Mandy Chung wrote: >> >For tests then Jon will be pushing the updated MineField to jdk9/dev soon. We need to go over the new options and get javac and the runtime consistent. I think we want it so that empty elements in the new options are ignored, leaving class path for legacy reasons. > Yes we should add new tests to ensure the javac and runtime consistency of the new options. > Mandy To give context, the "minefield" term refers to a specific complex test in the langtools repo to compare option handling between java and javac. The conceptual minefield has forked. I have been working on a new minefield framework to support minefield-type tests for all the new module-related JDK 9 options, but it does not adapt well to the original JDK 5-era MineField test. So that test will continue, in some modified form, and separately, we will have a new test framework to support new tests and test cases. -- Jon From everson.c.junior at gmail.com Tue May 17 02:40:28 2016 From: everson.c.junior at gmail.com (Everson Ferreira da Cunha Junior) Date: Mon, 16 May 2016 23:40:28 -0300 Subject: Project JIGSAW does not work In-Reply-To: References: <1020926175.622371.1463337961715.JavaMail.zimbra@u-pem.fr> <5738CE8D.1090403@oracle.com> <5739DCD9.1050406@oracle.com> Message-ID: Hi guys! I found the solution for my problem. Maybe this information can be important for other developer. If you desire to run JIGSAW project's examples cod, so you need download open-jdk-9 with jigsaw project: https://jdk9.java.net/jigsaw/. It appears obvious, but I didn't know. Thank you. On Mon, May 16, 2016 at 12:04 PM, Everson Ferreira da Cunha Junior < everson.c.junior at gmail.com> wrote: > Hi Jon. > What's recommend to do ? Do I need to find other version case it exists? > I've read some information about this problem. It advice to add this > project into jdk 9. Is it correct? > > Thanks guys! > On May 16, 2016 11:45, "Jonathan Gibbons" > wrote: > >> In general, it's not practical to go back and fix updates to older >> releases so that the compiler is cognisant of all syntax changes >> in subsequent releases, especially changes in features that are >> still under development. >> >> For example, it's possible that the original submitter was using >> a recent version of javac, but just not recent enough. [1] >> Should we have had forward looking error detection in early >> builds of JDK 9 as well? >> >> The submitter provided very little information in his post, just >> referring to a "example of guide on Ubuntu Linux'." It would >> make more sense to ensure that any such guides reference >> the minimal JDK version and build required for the content they >> contain. >> >> -- Jon >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003877.html >> >> On 05/15/2016 07:22 PM, Paul Benedict wrote: >> >>> It would be helpful in the next update to emit an error message specific >>> to >>> finding the "module" keyword and report it's only available in -source 9. >>> That kind of little stuff can go a long way in helping users. >>> On May 15, 2016 2:32 PM, "Alan Bateman" wrote: >>> >>> >>> >>> On 15/05/2016 19:46, Remi Forax wrote: >>> >>> Hi Everson, >>>> let start with a simple question, >>>> do you have checked that you use the java 9 version of javac (javac >>>> -version) ? >>>> >>>> >>>> Right, the output looks like JDK 8 or older is being used. >>>> >>> -Alan. >>> >> >> From georgiy.rakov at oracle.com Wed May 18 12:53:30 2016 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Wed, 18 May 2016 15:53:30 +0300 Subject: Fwd: Re: Modules with packages duplication In-Reply-To: References: Message-ID: <22751676-e2b8-d08d-97f2-ece21baa9ccc@oracle.com> Hello Jon, we've encountered situation when class files resulted from successful compilation cause runtime error; the sources are compiled by single javac invocation. This looks like incorrect javac behavior, namely it seems that javac should produce compile-time error if one tries to compile sources which will cause error at runtime. Could you please confirm if it's really is. More details are provided in the forwarded message below. I have also attached an archive with minimized testcase and scripts to run it. In order to run it please: 1. Unzip attached archive to some machine (Windows or Unix); 2. If it's Windows rename test18/test_bat to test18/test.bat. 3. Modify JDK_HOME variable inside test18/test.bat (or test18/test.sh) to point to your JDK installation. 4. Run test18/test.bat (or test18/test.sh). Thank you, Georgiy. -------- Forwarded Message -------- Subject: Re: Modules with packages duplication Date: Thu, 05 May 2016 18:21:20 +0300 From: Konstantin Barzilovich Organization: Oracle Corporation To: ML OpenJDK Jigsaw Developers , Alan Bateman Hello Alan, Thank you for the answer. I have one more question connected with duplication of packages. Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them. But in case of these two modules are readable by third module, in runtime it will result in error of boot Layer, as you said. Is it okey, that compiler allow us to compile code, that will cause runtime failure? Here is minimal test case: ------------------------------ module1/module-info.java module module1 { exports pack; } module1/pack/A.java: package pack; public class A{} module2/module-info.java module module2 { } module2/pack/A.java: package pack; public class A{} module3/module-info.java: module module3{ requires module1; requires module2; } Thanks, Konstantin. > > On 04/05/2016 14:18, Konstantin Barzilovich wrote: >> Hello, >> >> I can see that RI checks if there are packages with the same names in >> different modules (named or unnamed). >> This check fails even if there is no clash (no module can read both >> packages). >> Will it be the same in final version of JDK9 or it can be changed soon? >> > I think you are asking about modules on the application module path > (`java -modulepath ...`) that are resolved at startup. These are defined > to the application class loader so they cannot have overlapping > packages. It's trivial to do things like map each module in its own > class loader but that messes with visibility with lots of implications > (particularly when running with both a class path and module path or > where you bringing automatic modules into the picture). So what you are > seeing is specific to the boot Layer and no specific short term plans to > change this. > > -Alan From jarthana at in.ibm.com Wed May 18 13:42:54 2016 From: jarthana at in.ibm.com (Jayaprakash Arthanareeswaran) Date: Wed, 18 May 2016 19:12:54 +0530 Subject: Eclipse wouldn't load with b118 Message-ID: <201605181343.u4IDh5St29950060@d28relay08.in.ibm.com> Hello everyone, People reported that they are not able to run Eclipse with the latest JDK build (b118). This is critical for us and would like to see it resolved as soon as possible. We believe this is caused by change in resolution of EE modules and further discussion can be found here - https://bugs.eclipse.org/bugs/show_bug.cgi?id=493761 One of the work around discussed is adding the following to our launch configuration: -addmods java.se.ee But looks like there might be issues in using this work around. Are there other alternatives we could use? Regards, Jay From Alan.Bateman at oracle.com Wed May 18 14:04:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 May 2016 15:04:13 +0100 Subject: Eclipse wouldn't load with b118 In-Reply-To: <201605181343.u4IDh5St29950060@d28relay08.in.ibm.com> References: <201605181343.u4IDh5St29950060@d28relay08.in.ibm.com> Message-ID: <573C765D.7090203@oracle.com> On 18/05/2016 14:42, Jayaprakash Arthanareeswaran wrote: > > Hello everyone, > > People reported that they are not able to run Eclipse with the latest JDK > build (b118). This is critical for us and would like to see it resolved as > soon as possible. We believe this is caused by change in resolution of EE > modules and further discussion can be found here - > https://bugs.eclipse.org/bugs/show_bug.cgi?id=493761 > > One of the work around discussed is adding the following to our launch > configuration: > > -addmods > java.se.ee > > But looks like there might be issues in using this work around. Are there > other alternatives we could use? > The change you see in jdk-9+118 is expected and is a consequence of aligning the policy for root modules to that described in JEP 261 [1]. See also a note to jdk9-dev [2] about this. The workaround is `-addmods java.se.ee` as noted in the bug. In this case then `-addmods java.annotations.common` might be enough, it depends on whether you use other EE modules or not. So is Eclipse creating the VM with the JNI invocation API? I can't quite tell from the issue. At this time then `-addmods` is a java launcher option but we are looking to push this into VM so that it can be used by custom launchers. This gives you control on whether the option is to be ignored when launching older JDKs that don't know about this option. -Alan [1] http://openjdk.java.net/jeps/261 [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html From david.lloyd at redhat.com Wed May 18 15:04:05 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 18 May 2016 10:04:05 -0500 Subject: Mutable modules In-Reply-To: <573C6CEA.5010105@redhat.com> References: <573C6CEA.5010105@redhat.com> Message-ID: <573C8465.307@redhat.com> I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. On 05/18/2016 08:23 AM, David M. Lloyd wrote: > Related to #MutableConfigurations, in order to support dynamically > changing deployments for containers (including, I believe, > OSGi-compliant containers) where deployments are modules, it is > necessary to allow a module's dependency graph to be mutated at run > time. The behavior of such things in existing systems is such that any > already-loaded/linked dependency classes remain, thus such action is > usually only guaranteed to be "safe" when adding dependencies, or when > it can be somehow guaranteed that no lingering dependency classes exist, > or that such lingering classes can safely be ignored. > > While this operation isn't 100% safe, it is supported by containers in > existence today, so should at least be considered. The primary obstacle to this request seems to be that module packages declared inside the JVM in Module::define_module, whose purpose I haven't decoded yet but am assuming that it is used to look up the module info for a given package name when constructing exception stack traces (I deduced this from the fact that the module name and version are passed in as strings here). Am I correct about this? Does this code have any other function? Would it not be possible to instead use the class itself, which already has a reference to the Module, to get this sort of information? The String-ified module version could simply be stored as a field on the Module (as could the String-ified location information, whose purpose I have not yet determined). -- - DML From jonathan.gibbons at oracle.com Wed May 18 15:16:46 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 18 May 2016 08:16:46 -0700 Subject: Fwd: Re: Modules with packages duplication In-Reply-To: <22751676-e2b8-d08d-97f2-ece21baa9ccc@oracle.com> References: <22751676-e2b8-d08d-97f2-ece21baa9ccc@oracle.com> Message-ID: <573C875E.3080606@oracle.com> Without yet looking at your zip file, it is possible to compile classes that will not load in the application class loader, because of the restrictions defined for the boot layer. That does not imply the classes themselves are invalid, since they can be loaded and run in suitable configured layers/classloaders. -- Jon On 05/18/2016 05:53 AM, Georgiy Rakov wrote: > > Hello Jon, > > we've encountered situation when class files resulted from successful > compilation cause runtime error; the sources are compiled by single > javac invocation. This looks like incorrect javac behavior, namely it > seems that javac should produce compile-time error if one tries to > compile sources which will cause error at runtime. Could you please > confirm if it's really is. > > More details are provided in the forwarded message below. I have also > attached an archive with minimized testcase and scripts to run it. In > order to run it please: > > 1. Unzip attached archive to some machine (Windows or Unix); > > 2. If it's Windows rename test18/test_bat to test18/test.bat. > > 3. Modify JDK_HOME variable inside test18/test.bat (or test18/test.sh) > to point to your JDK installation. > > 4. Run test18/test.bat (or test18/test.sh). > > Thank you, > > Georgiy. > > > > -------- Forwarded Message -------- > Subject: Re: Modules with packages duplication > Date: Thu, 05 May 2016 18:21:20 +0300 > From: Konstantin Barzilovich > Organization: Oracle Corporation > To: ML OpenJDK Jigsaw Developers , Alan > Bateman > > > > Hello Alan, > > Thank you for the answer. > > I have one more question connected with duplication of packages. > Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them. > But in case of these two modules are readable by third module, in runtime it will result in error of boot Layer, as you said. > Is it okey, that compiler allow us to compile code, that will cause runtime failure? > > Here is minimal test case: > ------------------------------ > module1/module-info.java > module module1 { > exports pack; > } > > module1/pack/A.java: > package pack; > public class A{} > > module2/module-info.java > module module2 { > } > > module2/pack/A.java: > package pack; > public class A{} > > module3/module-info.java: > module module3{ > requires module1; > requires module2; > } > > Thanks, > Konstantin. > > > > > On 04/05/2016 14:18, Konstantin Barzilovich wrote: > >> Hello, > >> > >> I can see that RI checks if there are packages with the same names in >> different modules (named or unnamed). > >> This check fails even if there is no clash (no module can read both >> packages). > >> Will it be the same in final version of JDK9 or it can be changed soon? > >> > > I think you are asking about modules on the application module path > (`java -modulepath ...`) that are resolved at startup. These are defined > to the application class loader so they cannot have overlapping > packages. It's trivial to do things like map each module in its own > class loader but that messes with visibility with lots of implications > (particularly when running with both a class path and module path or > where you bringing automatic modules into the picture). So what you are > seeing is specific to the boot Layer and no specific short term plans to > change this. > > > > -Alan From Alan.Bateman at oracle.com Wed May 18 15:35:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 May 2016 16:35:05 +0100 Subject: Mutable modules In-Reply-To: <573C8465.307@redhat.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> Message-ID: <573C8BA9.90604@oracle.com> On 18/05/2016 16:04, David M. Lloyd wrote: > I just raised this issue on the JPMS experts list, but I want to > discuss the technical issues here. > > On 05/18/2016 08:23 AM, David M. Lloyd wrote: >> Related to #MutableConfigurations, in order to support dynamically >> changing deployments for containers (including, I believe, >> OSGi-compliant containers) where deployments are modules, it is >> necessary to allow a module's dependency graph to be mutated at run >> time. The behavior of such things in existing systems is such that any >> already-loaded/linked dependency classes remain, thus such action is >> usually only guaranteed to be "safe" when adding dependencies, or when >> it can be somehow guaranteed that no lingering dependency classes exist, >> or that such lingering classes can safely be ignored. >> >> While this operation isn't 100% safe, it is supported by containers in >> existence today, so should at least be considered. > > The primary obstacle to this request seems to be that module packages > declared inside the JVM in Module::define_module, whose purpose I > haven't decoded yet but am assuming that it is used to look up the > module info for a given package name when constructing exception stack > traces (I deduced this from the fact that the module name and version > are passed in as strings here). Am I correct about this? Does this > code have any other function? For #MutableConfigurations then I think it would be useful to provide an example to explain what you are looking to do. Are you generating code at runtime into existing modules/packages and with static references to types that the host modules doesn't know about? Or maybe you mean more loosely coupled services where modules are interacting with other modules with a different lifetime? A simple example would help set the scene. As regards Module::define_module (assuming we are talking the implementation in HotSpot) then the VM needs to know about the module before any classes are loaded from that module. It would otherwise not know which module that the class is a member of. and that membership is needed in order to do access control. Remember that this project is not making fundamental changes to class loading. Also there is nothing in the class bytes to indicate which module the class is in. If you work through a few examples (say with a <= v52.0 class file) and existing uses of ClassLoader::defineClass then I hope you'll see what I mean. I don't see the connection to #MutableConfigurations. The only pieces of information that are not critical to the VM are the module version and location. These are passed to the VM when creating modules and used for diagnostics purposes only. Neither is required and you'll find a number of cases where dynamically modules have neither. -Alan From david.lloyd at redhat.com Wed May 18 16:13:26 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 18 May 2016 11:13:26 -0500 Subject: Mutable modules In-Reply-To: <573C8BA9.90604@oracle.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> Message-ID: <573C94A6.5030001@redhat.com> On 05/18/2016 10:35 AM, Alan Bateman wrote: > On 18/05/2016 16:04, David M. Lloyd wrote: >> I just raised this issue on the JPMS experts list, but I want to >> discuss the technical issues here. >> >> On 05/18/2016 08:23 AM, David M. Lloyd wrote: >>> Related to #MutableConfigurations, in order to support dynamically >>> changing deployments for containers (including, I believe, >>> OSGi-compliant containers) where deployments are modules, it is >>> necessary to allow a module's dependency graph to be mutated at run >>> time. The behavior of such things in existing systems is such that any >>> already-loaded/linked dependency classes remain, thus such action is >>> usually only guaranteed to be "safe" when adding dependencies, or when >>> it can be somehow guaranteed that no lingering dependency classes exist, >>> or that such lingering classes can safely be ignored. >>> >>> While this operation isn't 100% safe, it is supported by containers in >>> existence today, so should at least be considered. >> >> The primary obstacle to this request seems to be that module packages >> declared inside the JVM in Module::define_module, whose purpose I >> haven't decoded yet but am assuming that it is used to look up the >> module info for a given package name when constructing exception stack >> traces (I deduced this from the fact that the module name and version >> are passed in as strings here). Am I correct about this? Does this >> code have any other function? > For #MutableConfigurations then I think it would be useful to provide an > example to explain what you are looking to do. Are you generating code > at runtime into existing modules/packages and with static references to > types that the host modules doesn't know about? Or maybe you mean more > loosely coupled services where modules are interacting with other > modules with a different lifetime? A simple example would help set the > scene. At present, you can remove a module or a bundle even if existing dependent module classes are statically referring to their contents. It'll work fine as long as those classes haven't been loaded yet. So we'd basically be taking away this capability with the code as it is, if we try to put existing deployments or bundles into named Modules. Another thing presently possible is expanding the existing class path of a deployment module, and replacing class contents (again this may fail if any of the replaced classes were already loaded). To expand it more to a logical statement, the set of capabilities allowed to a class loader is greater than the set allowed to a named module, so as long as this is true, moving to named modules will necessarily cost functionality. > As regards Module::define_module (assuming we are talking the > implementation in HotSpot) then the VM needs to know about the module > before any classes are loaded from that module. It would otherwise not > know which module that the class is a member of. and that membership is > needed in order to do access control. Remember that this project is not > making fundamental changes to class loading. Also there is nothing in > the class bytes to indicate which module the class is in. If you work > through a few examples (say with a <= v52.0 class file) and existing > uses of ClassLoader::defineClass then I hope you'll see what I mean. I > don't see the connection to #MutableConfigurations. Ah okay, so the access control angle is one I didn't examine. In some cases access control is split between HotSpot and the JDK, and I assumed that the new access controls were all on the JDK side, which was a bad assumption it seems. > The only pieces of information that are not critical to the VM are the > module version and location. These are passed to the VM when creating > modules and used for diagnostics purposes only. Neither is required and > you'll find a number of cases where dynamically modules have neither. Would it be possible to somehow allow the unnamed module to, well, have a name (and a version string), so that it appears in stack traces? -- - DML From Alan.Bateman at oracle.com Wed May 18 17:36:32 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 18 May 2016 18:36:32 +0100 Subject: Mutable modules In-Reply-To: <573C94A6.5030001@redhat.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> Message-ID: <573CA820.5090302@oracle.com> On 18/05/2016 17:13, David M. Lloyd wrote: > > At present, you can remove a module or a bundle even if existing > dependent module classes are statically referring to their contents. > It'll work fine as long as those classes haven't been loaded yet. So > we'd basically be taking away this capability with the code as it is, > if we try to put existing deployments or bundles into named Modules. When you say "remove a module" then do you mean the module artifact, as in the JAR file? At least for built-in class loaders then a module artifactsis opened lazily when the first class in the module is loaded. It's possible of course for someone to be loading from modules with their own class loaders where module artifacts are opened eagerly (not something the JDK can control). That said, if you really do mean removing or replacing module artifacts that are potentially in use then you are skating on thin ice. The system could blow up at any time. > > Another thing presently possible is expanding the existing class path > of a deployment module, and replacing class contents (again this may > fail if any of the replaced classes were already loaded). When you say "class path of a deployment module" then do you mean a side class path, meaning loading code that is not in a named module? There aren't any changes there. I might not understand what you mean here but just to say that you can create a layer of modules where the class loaders for the modules in that layer delegate to a parent class loader for types that are not in named modules. If that class loader can dynamically expand then it should just work as before. > > To expand it more to a logical statement, the set of capabilities > allowed to a class loader is greater than the set allowed to a named > module, so as long as this is true, moving to named modules will > necessarily cost functionality. There are different concepts so I'm not sure how to answer this. > > Would it be possible to somehow allow the unnamed module to, well, > have a name (and a version string), so that it appears in stack traces? > It would be an oxymoron for unnamed modules to have names and would lead to some inconsistencies (Module::isNamed would return false but Module::getName would return a name???). However, technically then if you could name a ClassLoader then its unnamed Module could have a name. I'm not sure that we want to go there. -Alan. From greggwon at cox.net Wed May 18 17:39:51 2016 From: greggwon at cox.net (Gregg Wonderly) Date: Wed, 18 May 2016 12:39:51 -0500 Subject: Mutable modules In-Reply-To: References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> Message-ID: <1CF4553B-80C4-4846-A55F-EF12A928EC17@cox.net> The runtime environment needs to have a way that developers can impose version consistencies that make sense. In some cases it is just data consistencies which can be managed literally with data construction. But when code versions are mixed in with data versions, the runtime context needs to yield something too. It could be an application, ThreadLocal value providing a version identity or something that the module versioning injects into a Thread object when it is created. It may need to be mutated by the app or the module system. In some cases it might make sense for module version changes at runtime to control Thread lifecycle events too. Runtime code updates need to remain possible with predictable and controllable outcome. Gregg Sent from my iPhone > On May 18, 2016, at 10:35 AM, Alan Bateman wrote: > >> On 18/05/2016 16:04, David M. Lloyd wrote: >> I just raised this issue on the JPMS experts list, but I want to discuss the technical issues here. >> >>> On 05/18/2016 08:23 AM, David M. Lloyd wrote: >>> Related to #MutableConfigurations, in order to support dynamically >>> changing deployments for containers (including, I believe, >>> OSGi-compliant containers) where deployments are modules, it is >>> necessary to allow a module's dependency graph to be mutated at run >>> time. The behavior of such things in existing systems is such that any >>> already-loaded/linked dependency classes remain, thus such action is >>> usually only guaranteed to be "safe" when adding dependencies, or when >>> it can be somehow guaranteed that no lingering dependency classes exist, >>> or that such lingering classes can safely be ignored. >>> >>> While this operation isn't 100% safe, it is supported by containers in >>> existence today, so should at least be considered. >> >> The primary obstacle to this request seems to be that module packages declared inside the JVM in Module::define_module, whose purpose I haven't decoded yet but am assuming that it is used to look up the module info for a given package name when constructing exception stack traces (I deduced this from the fact that the module name and version are passed in as strings here). Am I correct about this? Does this code have any other function? > For #MutableConfigurations then I think it would be useful to provide an example to explain what you are looking to do. Are you generating code at runtime into existing modules/packages and with static references to types that the host modules doesn't know about? Or maybe you mean more loosely coupled services where modules are interacting with other modules with a different lifetime? A simple example would help set the scene. > > As regards Module::define_module (assuming we are talking the implementation in HotSpot) then the VM needs to know about the module before any classes are loaded from that module. It would otherwise not know which module that the class is a member of. and that membership is needed in order to do access control. Remember that this project is not making fundamental changes to class loading. Also there is nothing in the class bytes to indicate which module the class is in. If you work through a few examples (say with a <= v52.0 class file) and existing uses of ClassLoader::defineClass then I hope you'll see what I mean. I don't see the connection to #MutableConfigurations. > > The only pieces of information that are not critical to the VM are the module version and location. These are passed to the VM when creating modules and used for diagnostics purposes only. Neither is required and you'll find a number of cases where dynamically modules have neither. > > -Alan From ryan at iernst.net Wed May 18 21:24:37 2016 From: ryan at iernst.net (Ryan Ernst) Date: Wed, 18 May 2016 14:24:37 -0700 Subject: Compact profiles broken? Message-ID: It appears at least in the latest b118 of jdk9 (I haven't tried any earlier yet), compact profiles mappings to modules are broken? Doing an import of, for example, javax.crypto.Cipher, which should exist in all 3 compact profiles according to java 8 docs [1], fails with java 9. $ javac -profile compact3 Test.java Test.java:2: error: Cipher is not available in profile 'compact3' Have compact profiles changed in some way I don't understand? [1] https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html From david.lloyd at redhat.com Wed May 18 21:47:26 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 18 May 2016 16:47:26 -0500 Subject: Mutable modules In-Reply-To: <573CA820.5090302@oracle.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> <573CA820.5090302@oracle.com> Message-ID: <573CE2EE.80806@redhat.com> On 05/18/2016 12:36 PM, Alan Bateman wrote: > On 18/05/2016 17:13, David M. Lloyd wrote: >> >> At present, you can remove a module or a bundle even if existing >> dependent module classes are statically referring to their contents. >> It'll work fine as long as those classes haven't been loaded yet. So >> we'd basically be taking away this capability with the code as it is, >> if we try to put existing deployments or bundles into named Modules. > When you say "remove a module" then do you mean the module artifact, as > in the JAR file? > > At least for built-in class loaders then a module artifactsis opened > lazily when the first class in the module is loaded. It's possible of > course for someone to be loading from modules with their own class > loaders where module artifacts are opened eagerly (not something the JDK > can control). > > That said, if you really do mean removing or replacing module artifacts > that are potentially in use then you are skating on thin ice. The system > could blow up at any time. > >> Another thing presently possible is expanding the existing class path >> of a deployment module, and replacing class contents (again this may >> fail if any of the replaced classes were already loaded). > When you say "class path of a deployment module" then do you mean a side > class path, meaning loading code that is not in a named module? There > aren't any changes there. I mean in *our* current concept of a module, we can add/remove/modify the contents of a module (its "class path") at run time. It is up to the user to ensure that doing so makes sense. > I might not understand what you mean here but just to say that you can > create a layer of modules where the class loaders for the modules in > that layer delegate to a parent class loader for types that are not in > named modules. If that class loader can dynamically expand then it > should just work as before. What I'm really trying to do here is to shoehorn our current module concept into Jigsaw's so we can get the benefit of nice stack traces and maybe some measure of interoperability. I could just *not* do that, and say, well, our deployments can never be Jigsaw modules, but if Java EE 9 rolls around and makes everyone use named modules for applications, we're going to be severely broken. Our modules each correspond to their own class loader: so far so good, we can just have one Module per class loader. Problem is that we support circularity, and also we support dependencies that go across module systems with isolated namespaces (basically, our module loaders are a higher order of the exact same concept of class loaders). Our modules support specifications including the content of the module ("resource loaders") and the dependencies of the module. At run time, custom ModuleLoader implementations can change the resource loader list and/or the dependency list at any time, causing the module to be relinked on the spot; the most useful aspect of this is the ability to incrementally deploy applications which may include circular dependencies. We also support delegating "fallback" class loading decisions to outside suppliers for dynamic class loading behavior (this was done to support a dynamic OSGi environment). The ongoing integrity of the system is up to the party doing the relinking (the EE deployer or the OSGi resolver); most of the time it can reason about what is "safe" and what might cause system breakage (but still might be useful to do anyway). These are the features we can't seem to support under Jigsaw, architecturally speaking. Specifically this includes (but is not limited to) changing the package set associated with a JDK module at run time, something that this native code block makes impossible. Also the ability to dynamically change module dependencies is an essential ingredient to making this work. In my view, architecturally speaking, most of the constraints imposed by the core module framework should be layer policy. If the system's core module layer wants to maintain strict, static integrity, name constraints, version syntax and semantics, etc., that's fine, but why should all modules everywhere be forced to the same constraints? There is no way that existing containers and class loading environments (other than, apparently, WebLogic) can conform to Jigsaw's constraints without losing functionality (and I'm trying hard to find ways to make it work). This is where most of my raised issues are coming from. All these problems seem surmountable to me, but it becomes substantially more difficult when it is necessary to report all of a module's packages to the module when it is created, since this information is now not easily changed. >> To expand it more to a logical statement, the set of capabilities >> allowed to a class loader is greater than the set allowed to a named >> module, so as long as this is true, moving to named modules will >> necessarily cost functionality. > There are different concepts so I'm not sure how to answer this. > >> >> Would it be possible to somehow allow the unnamed module to, well, >> have a name (and a version string), so that it appears in stack traces? >> > It would be an oxymoron for unnamed modules to have names and would lead > to some inconsistencies (Module::isNamed would return false but > Module::getName would return a name???). However, technically then if > you could name a ClassLoader then its unnamed Module could have a name. > I'm not sure that we want to go there. In lieu of actually creating Modules via Configurations, I'd be satisfied with maintaining only the appearance of having created a Module (including parsing out the descriptors and translating them into JBoss-compatible deployment information) as long as we got the stack traces and any other useful module metadata such that a Jigsaw module application cannot tell the difference. I can interoperate with real Jigsaw modules in the same way we interoperate with the JDK today - as a one-way relationship. -- - DML From mandy.chung at oracle.com Thu May 19 01:41:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 18 May 2016 18:41:01 -0700 Subject: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules Message-ID: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html This is to allow to patch java.base with an exploded image for JDK development purpose like this: $ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -version jdk.internal.module.SystemModules class is generated at link time to allow fast reconstitution of ModuleDescriptor. If an image is patched with java.base of an exploded image, it will fall back to read and parse module-info.class from the jimage. Hashes of tied modules are recorded in jdk.internal.module.SystemModules class in the fast path. If patched, this fix will use the hashes recorded in the Hashes attribute for integrity check (that already validated at link time). Mandy From Alan.Bateman at oracle.com Thu May 19 05:49:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 06:49:55 +0100 Subject: Compact profiles broken? In-Reply-To: References: Message-ID: <573D5403.4020801@oracle.com> On 18/05/2016 22:24, Ryan Ernst wrote: > It appears at least in the latest b118 of jdk9 (I haven't tried any earlier > yet), compact profiles mappings to modules are broken? Doing an import of, > for example, javax.crypto.Cipher, which should exist in all 3 compact > profiles according to java 8 docs [1], fails with java 9. > > $ javac -profile compact3 Test.java > Test.java:2: error: Cipher is not available in profile 'compact3' > > Have compact profiles changed in some way I don't understand? > The aggregator modules java.compact1, java.compact2, and java.compact3 provide compatibility when moving from the compact Profiles in Java SE 8 to modules. There is an open issue [1] to examine how javac handles -profile and map it to -limitmods. In the mean-time then this should work: java -release 8 -profile compact3 ... or specify -limitmods, as in: java -limitmods java.compact3 ... -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8133881 From Alan.Bateman at oracle.com Thu May 19 06:27:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 07:27:30 +0100 Subject: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules In-Reply-To: References: Message-ID: <573D5CD2.2050205@oracle.com> On 19/05/2016 02:41, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html > > This is to allow to patch java.base with an exploded image for JDK development purpose like this: > $ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -version > > jdk.internal.module.SystemModules class is generated at link time to allow fast reconstitution of ModuleDescriptor. If an image is patched with java.base of an exploded image, it will fall back to read and parse module-info.class from the jimage. Hashes of tied modules are recorded in jdk.internal.module.SystemModules class in the fast path. If patched, this fix will use the hashes recorded in the Hashes attribute for integrity check (that already validated at link time). > A complicated scenario but the approach looks okay. No need to use JavaLangModuleAccess to get at the hashes, just use descriptor.hashes(). The patch test directory already has a basic test for -Xpatch and might be confusing to have the modules for both tests in the same tree. I wonder if we should move each both tests in their own sub-directory to keep it easier to understand. -Alan. From Alan.Bateman at oracle.com Thu May 19 06:54:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 07:54:34 +0100 Subject: Compact profiles broken? In-Reply-To: <573D5403.4020801@oracle.com> References: <573D5403.4020801@oracle.com> Message-ID: <573D632A.3040505@oracle.com> On 19/05/2016 06:49, Alan Bateman wrote: > : > > In the mean-time then this should work: > > java -release 8 -profile compact3 ... > > or specify -limitmods, as in: > > java -limitmods java.compact3 ... > Oops, I meant `javac` here of course (not `java`). -Alan From uschindler at apache.org Thu May 19 07:10:22 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 19 May 2016 09:10:22 +0200 Subject: Compact profiles broken? In-Reply-To: <573D632A.3040505@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> Message-ID: <034101d1b19d$84c638a0$8e52a9e0$@apache.org> Hi Alan, Interestingly, compiling large amounts of code with the Java SE8 option for "compact1" or "compact3" works successfully. It is just this class/package failing. How can that be? The issue is not visible to the outside (requires login). Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of Alan Bateman > Sent: Thursday, May 19, 2016 8:55 AM > To: Ryan Ernst ; jigsaw-dev at openjdk.java.net > Subject: Re: Compact profiles broken? > > On 19/05/2016 06:49, Alan Bateman wrote: > > : > > > > In the mean-time then this should work: > > > > java -release 8 -profile compact3 ... > > > > or specify -limitmods, as in: > > > > java -limitmods java.compact3 ... > > > Oops, I meant `javac` here of course (not `java`). > > -Alan From Alan.Bateman at oracle.com Thu May 19 10:26:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 11:26:54 +0100 Subject: 8157290: jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java failing Message-ID: <573D94EE.1090600@oracle.com> The jdk9/client -> jdk9/dev integration yesterday included the fix for JDK-8154539 which breaks a test that has been assuming sun.misc is in java.base. I suspect this test was missed in previous rounds that laid the ground for jdk.unsupported. Trivial change to get the test back to use a package that overlaps with a package in java.base. http://cr.openjdk.java.net/~alanb/8157290/webrev/ Thanks, Alan From jan.lahoda at oracle.com Thu May 19 10:33:39 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 19 May 2016 12:33:39 +0200 Subject: Compact profiles broken? In-Reply-To: <034101d1b19d$84c638a0$8e52a9e0$@apache.org> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> Message-ID: <573D9683.9070908@oracle.com> This appears to be a bug in the current profiles handling in javac - currently (without "-release X"), javac uses "ct.properties" to determine the profile of a class. This file contains mapping from package to extra metadata, esp. profile. And this file does not contain mapping for javax.crypto, so javac thinks it belongs to the default profile. I guess this is because ct.properties only contains mapping for packages from rt.jar, and javax.crypto was not part of rt.jar (was in jce.jar). It would be relatively easy to use modules to detect profiles, but there is a problem with "-source 8 -profile compactX", as with -source 8, javac does not keep information about modules, and so cannot do module-based checks. So I guess we may need to regenerate ct.properties. Jan On 19.5.2016 09:10, Uwe Schindler wrote: > Hi Alan, > > Interestingly, compiling large amounts of code with the Java SE8 option for "compact1" or "compact3" works successfully. It is just this class/package failing. How can that be? The issue is not visible to the outside (requires login). > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf >> Of Alan Bateman >> Sent: Thursday, May 19, 2016 8:55 AM >> To: Ryan Ernst ; jigsaw-dev at openjdk.java.net >> Subject: Re: Compact profiles broken? >> >> On 19/05/2016 06:49, Alan Bateman wrote: >>> : >>> >>> In the mean-time then this should work: >>> >>> java -release 8 -profile compact3 ... >>> >>> or specify -limitmods, as in: >>> >>> java -limitmods java.compact3 ... >>> >> Oops, I meant `javac` here of course (not `java`). >> >> -Alan > From Alan.Bateman at oracle.com Thu May 19 11:49:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 12:49:30 +0100 Subject: 8148834: Update module-info reader/writer to 53.0 Message-ID: <573DA84A.8070707@oracle.com> javac has been switched to generate v53.0 class files. ASM, pack200 and several other areas have been updated too. We have two places in the module-info reader/writing that needs to be updated so I need a Reviewer to get this into jdk9/dev. -Alan 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 @@ -154,7 +154,7 @@ int minor_version = in.readUnsignedShort(); int major_version = in.readUnsignedShort(); if (major_version < 53) { - // throw invalidModuleDescriptor"Must be >= 53.0"); + throw invalidModuleDescriptor("Must be >= 53.0"); } ConstantPool cpool = new ConstantPool(in); diff --git a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java @@ -54,7 +54,7 @@ ClassWriter cw = new ClassWriter(0); String name = md.name().replace('.', '/') + "/module-info"; - cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null); + cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null); cw.visitAttribute(new ModuleAttribute(md)); cw.visitAttribute(new ConcealedPackagesAttribute(md.conceals())); From sundararajan.athijegannathan at oracle.com Thu May 19 11:52:07 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 19 May 2016 17:22:07 +0530 Subject: 8148834: Update module-info reader/writer to 53.0 In-Reply-To: <573DA84A.8070707@oracle.com> References: <573DA84A.8070707@oracle.com> Message-ID: <78545964-f97f-0bc3-6737-0010c5e304eb@oracle.com> +1 On 5/19/2016 5:19 PM, Alan Bateman wrote: > javac has been switched to generate v53.0 class files. ASM, pack200 > and several other areas have been updated too. We have two places in > the module-info reader/writing that needs to be updated so I need a > Reviewer to get this into jdk9/dev. > > -Alan > > 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 > @@ -154,7 +154,7 @@ > int minor_version = in.readUnsignedShort(); > int major_version = in.readUnsignedShort(); > if (major_version < 53) { > - // throw invalidModuleDescriptor"Must be >= 53.0"); > + throw invalidModuleDescriptor("Must be >= 53.0"); > } > > ConstantPool cpool = new ConstantPool(in); > diff --git > a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > --- > a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > +++ > b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > @@ -54,7 +54,7 @@ > ClassWriter cw = new ClassWriter(0); > > String name = md.name().replace('.', '/') + "/module-info"; > - cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null); > + cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null); > > cw.visitAttribute(new ModuleAttribute(md)); > cw.visitAttribute(new > ConcealedPackagesAttribute(md.conceals())); From chris.hegarty at oracle.com Thu May 19 12:03:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 May 2016 13:03:39 +0100 Subject: 8157290: jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java failing In-Reply-To: <573D94EE.1090600@oracle.com> References: <573D94EE.1090600@oracle.com> Message-ID: On 19 May 2016, at 11:26, Alan Bateman wrote: > > The jdk9/client -> jdk9/dev integration yesterday included the fix for JDK-8154539 which breaks a test that has been assuming sun.misc is in java.base. I suspect this test was missed in previous rounds that laid the ground for jdk.unsupported. Trivial change to get the test back to use a package that overlaps with a package in java.base. > > http://cr.openjdk.java.net/~alanb/8157290/webrev/ This looks fine. Yes, it was missed in previous jdk.unsupported changes. -Chris. From chris.hegarty at oracle.com Thu May 19 12:04:50 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 19 May 2016 13:04:50 +0100 Subject: 8148834: Update module-info reader/writer to 53.0 In-Reply-To: <573DA84A.8070707@oracle.com> References: <573DA84A.8070707@oracle.com> Message-ID: <6BF28208-1348-4C4F-B5EE-A795EAC918C3@oracle.com> On 19 May 2016, at 12:49, Alan Bateman wrote: > javac has been switched to generate v53.0 class files. ASM, pack200 and several other areas have been updated too. We have two places in the module-info reader/writing that needs to be updated so I need a Reviewer to get this into jdk9/dev. > > -Alan > > 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 > @@ -154,7 +154,7 @@ > int minor_version = in.readUnsignedShort(); > int major_version = in.readUnsignedShort(); > if (major_version < 53) { > - // throw invalidModuleDescriptor"Must be >= 53.0"); > + throw invalidModuleDescriptor("Must be >= 53.0"); > } > > ConstantPool cpool = new ConstantPool(in); > diff --git a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > --- a/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > +++ b/src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java > @@ -54,7 +54,7 @@ > ClassWriter cw = new ClassWriter(0); > > String name = md.name().replace('.', '/') + "/module-info"; > - cw.visit(Opcodes.V1_8, ACC_MODULE, name, null, null, null); > + cw.visit(Opcodes.V1_9, ACC_MODULE, name, null, null, null); > > cw.visitAttribute(new ModuleAttribute(md)); > cw.visitAttribute(new ConcealedPackagesAttribute(md.conceals())); This looks good to me Alan. -Chris. From uschindler at apache.org Thu May 19 12:08:52 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 19 May 2016 14:08:52 +0200 Subject: Compact profiles broken? In-Reply-To: <573D9683.9070908@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> Message-ID: <002f01d1b1c7$37dddc30$a7999490$@apache.org> Hi, that clearly explains what we are seeing. Elasticsearch and Apache Lucene/Solr are compiled with "-source 1.8 -target 1.8" and use the compact profile settings (Lucene Core with compact1, the rest with compact3, same for Elasticsearch). This works everywhere, except for the javax crypto packages, because those are missing in the ct.properties file, that is used for source/target 1.8. Your explanation is very good, now I understand the problem! Thanks! FYI, this also explains why we did not see a compile failure about the java.xml.bind issue (see previous mails)! This only failed at runtime, because with Jigsaw, the java.xml.bind is not exposed by the root modules. But while compiling it seems to see all those classes, as its compiled against source/target 8 where the module system is ignored. So there is also room for improvement! Alan? So many thanks for this explanation! Uwe > -----Original Message----- > From: Jan Lahoda [mailto:jan.lahoda at oracle.com] > Sent: Thursday, May 19, 2016 12:34 PM > To: Uwe Schindler ; 'Alan Bateman' > ; jigsaw-dev at openjdk.java.net > Subject: Re: Compact profiles broken? > > This appears to be a bug in the current profiles handling in javac - > currently (without "-release X"), javac uses "ct.properties" to > determine the profile of a class. This file contains mapping from > package to extra metadata, esp. profile. And this file does not contain > mapping for javax.crypto, so javac thinks it belongs to the default profile. > > I guess this is because ct.properties only contains mapping for packages > from rt.jar, and javax.crypto was not part of rt.jar (was in jce.jar). > > It would be relatively easy to use modules to detect profiles, but there > is a problem with "-source 8 -profile compactX", as with -source 8, > javac does not keep information about modules, and so cannot do > module-based checks. So I guess we may need to regenerate ct.properties. > > Jan > > On 19.5.2016 09:10, Uwe Schindler wrote: > > Hi Alan, > > > > Interestingly, compiling large amounts of code with the Java SE8 option for > "compact1" or "compact3" works successfully. It is just this class/package > failing. How can that be? The issue is not visible to the outside (requires > login). > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > >> -----Original Message----- > >> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On > Behalf > >> Of Alan Bateman > >> Sent: Thursday, May 19, 2016 8:55 AM > >> To: Ryan Ernst ; jigsaw-dev at openjdk.java.net > >> Subject: Re: Compact profiles broken? > >> > >> On 19/05/2016 06:49, Alan Bateman wrote: > >>> : > >>> > >>> In the mean-time then this should work: > >>> > >>> java -release 8 -profile compact3 ... > >>> > >>> or specify -limitmods, as in: > >>> > >>> java -limitmods java.compact3 ... > >>> > >> Oops, I meant `javac` here of course (not `java`). > >> > >> -Alan > > From james.laskey at oracle.com Thu May 19 13:03:34 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 19 May 2016 10:03:34 -0300 Subject: RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException Message-ID: <2FC8523D-AC23-4E9E-937F-F73818431D92@oracle.com> On 32 bit, a shared jimage channel closed by an interrupted thread (ClosedChannelException) disrupts other threads sharing jimage. Fix is to reopen channel on not interrupted thread. http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8156602 From georgiy.rakov at oracle.com Thu May 19 13:26:41 2016 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 19 May 2016 16:26:41 +0300 Subject: Fwd: Re: Modules with packages duplication In-Reply-To: <573C875E.3080606@oracle.com> References: <22751676-e2b8-d08d-97f2-ece21baa9ccc@oracle.com> <573C875E.3080606@oracle.com> Message-ID: <356eac73-254a-d299-4d32-21b46ef9cbde@oracle.com> I've attached zip file with test.sh renamed to test_sh, hope this will help. On 18.05.2016 18:16, Jonathan Gibbons wrote: > Without yet looking at your zip file, it is possible to compile > classes that will not load in the application class loader, because of > the restrictions defined for the boot layer. That does not imply the > classes themselves are invalid, since they can be loaded and run in > suitable configured layers/classloaders. > > -- Jon > > > On 05/18/2016 05:53 AM, Georgiy Rakov wrote: >> >> Hello Jon, >> >> we've encountered situation when class files resulted from successful >> compilation cause runtime error; the sources are compiled by single >> javac invocation. This looks like incorrect javac behavior, namely it >> seems that javac should produce compile-time error if one tries to >> compile sources which will cause error at runtime. Could you please >> confirm if it's really is. >> >> More details are provided in the forwarded message below. I have also >> attached an archive with minimized testcase and scripts to run it. In >> order to run it please: >> >> 1. Unzip attached archive to some machine (Windows or Unix); >> >> 2. If it's Windows rename test18/test_bat to test18/test.bat. >> >> 3. Modify JDK_HOME variable inside test18/test.bat (or >> test18/test.sh) to point to your JDK installation. >> >> 4. Run test18/test.bat (or test18/test.sh). >> >> Thank you, >> >> Georgiy. >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: Modules with packages duplication >> Date: Thu, 05 May 2016 18:21:20 +0300 >> From: Konstantin Barzilovich >> Organization: Oracle Corporation >> To: ML OpenJDK Jigsaw Developers , Alan >> Bateman >> >> >> >> Hello Alan, >> >> Thank you for the answer. >> >> I have one more question connected with duplication of packages. >> Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them. >> But in case of these two modules are readable by third module, in runtime it will result in error of boot Layer, as you said. >> Is it okey, that compiler allow us to compile code, that will cause runtime failure? >> >> Here is minimal test case: >> ------------------------------ >> module1/module-info.java >> module module1 { >> exports pack; >> } >> >> module1/pack/A.java: >> package pack; >> public class A{} >> >> module2/module-info.java >> module module2 { >> } >> >> module2/pack/A.java: >> package pack; >> public class A{} >> >> module3/module-info.java: >> module module3{ >> requires module1; >> requires module2; >> } >> >> Thanks, >> Konstantin. >> >> > >> > On 04/05/2016 14:18, Konstantin Barzilovich wrote: >> >> Hello, >> >> >> >> I can see that RI checks if there are packages with the same names in >> different modules (named or unnamed). >> >> This check fails even if there is no clash (no module can read both >> packages). >> >> Will it be the same in final version of JDK9 or it can be changed soon? >> >> >> > I think you are asking about modules on the application module path > (`java -modulepath ...`) that are resolved at startup. These are defined > to the application class loader so they cannot have overlapping > packages. It's trivial to do things like map each module in its own > class loader but that messes with visibility with lots of implications > (particularly when running with both a class path and module path or > where you bringing automatic modules into the picture). So what you are > seeing is specific to the boot Layer and no specific short term plans to > change this. >> > >> > -Alan > From mandy.chung at oracle.com Thu May 19 13:33:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 06:33:24 -0700 Subject: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules In-Reply-To: <573D5CD2.2050205@oracle.com> References: <573D5CD2.2050205@oracle.com> Message-ID: > On May 18, 2016, at 11:27 PM, Alan Bateman wrote: > > On 19/05/2016 02:41, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.00/index.html >> >> This is to allow to patch java.base with an exploded image for JDK development purpose like this: >> $ images/jdk/bin/java -Xpatch:java.base=jdk/modules/java.base -version >> >> jdk.internal.module.SystemModules class is generated at link time to allow fast reconstitution of ModuleDescriptor. If an image is patched with java.base of an exploded image, it will fall back to read and parse module-info.class from the jimage. Hashes of tied modules are recorded in jdk.internal.module.SystemModules class in the fast path. If patched, this fix will use the hashes recorded in the Hashes attribute for integrity check (that already validated at link time). >> > A complicated scenario but the approach looks okay. No need to use JavaLangModuleAccess to get at the hashes, just use descriptor.hashes(). > Ah, of course, SystemModuleFinder is in java.lang.module (I got mixed up with jdk.internal.module.SystemModules) > The patch test directory already has a basic test for -Xpatch and might be confusing to have the modules for both tests in the same tree. I wonder if we should move each both tests in their own sub-directory to keep it easier to understand. That?s good. I was looking for your opinion on this. I considered putting them in a separate sub-directory and think it makes it clearer. Will move them before I push. Mandy From Alan.Bateman at oracle.com Thu May 19 13:46:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 14:46:05 +0100 Subject: RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException In-Reply-To: <2FC8523D-AC23-4E9E-937F-F73818431D92@oracle.com> References: <2FC8523D-AC23-4E9E-937F-F73818431D92@oracle.com> Message-ID: <573DC39D.30205@oracle.com> On 19/05/2016 14:03, Jim Laskey (Oracle) wrote: > On 32 bit, a shared jimage channel closed by an interrupted thread (ClosedChannelException) disrupts other threads sharing jimage. Fix is to reopen channel on not interrupted thread. > > http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8156602 Does this work? The interrupt status isn't cleared so I would expect the second and subsequent reads to fail and so hit the retry limit. In generally them I'm uneasy about this approach and would prefer if we used non-interruptible I/O. I don't mind working on it if you'd like to get rid of it. -Alan From james.laskey at oracle.com Thu May 19 14:00:38 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 19 May 2016 11:00:38 -0300 Subject: RFR: JDK-8156602 - javac crashes again on Windows 32-bit with ClosedChannelException In-Reply-To: <573DC39D.30205@oracle.com> References: <2FC8523D-AC23-4E9E-937F-F73818431D92@oracle.com> <573DC39D.30205@oracle.com> Message-ID: This does work for the test provided. The interrupted thread fails on the closed channel, but other theads continue to run on reopened channel. The problem with the non-interruptible I/O is the jdk8 backport issue. There is no way to use the non-interruptible read without loading new classes at start up (reflection or method handles.) I could check version and use different paths on JDK-9 and JDK-8. Other suggestions? ? Jim > On May 19, 2016, at 10:46 AM, Alan Bateman wrote: > > On 19/05/2016 14:03, Jim Laskey (Oracle) wrote: >> On 32 bit, a shared jimage channel closed by an interrupted thread (ClosedChannelException) disrupts other threads sharing jimage. Fix is to reopen channel on not interrupted thread. >> >> http://cr.openjdk.java.net/~jlaskey/8156602/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8156602 > Does this work? The interrupt status isn't cleared so I would expect the second and subsequent reads to fail and so hit the retry limit. > > In generally them I'm uneasy about this approach and would prefer if we used non-interruptible I/O. I don't mind working on it if you'd like to get rid of it. > > -Alan From georgiy.rakov at oracle.com Thu May 19 14:22:49 2016 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Thu, 19 May 2016 17:22:49 +0300 Subject: Fwd: Re: Modules with packages duplication In-Reply-To: <573C875E.3080606@oracle.com> References: <22751676-e2b8-d08d-97f2-ece21baa9ccc@oracle.com> <573C875E.3080606@oracle.com> Message-ID: <61fc7182-a7b7-b519-8782-b95c8d27052e@oracle.com> Attempt to attach zip failed. Attaching the same content as a patch files.diff. It can be "extracted" by invoking: hg init hg import files.diff -m comments On 18.05.2016 18:16, Jonathan Gibbons wrote: > Without yet looking at your zip file, it is possible to compile > classes that will not load in the application class loader, because of > the restrictions defined for the boot layer. That does not imply the > classes themselves are invalid, since they can be loaded and run in > suitable configured layers/classloaders. > > -- Jon > > > On 05/18/2016 05:53 AM, Georgiy Rakov wrote: >> >> Hello Jon, >> >> we've encountered situation when class files resulted from successful >> compilation cause runtime error; the sources are compiled by single >> javac invocation. This looks like incorrect javac behavior, namely it >> seems that javac should produce compile-time error if one tries to >> compile sources which will cause error at runtime. Could you please >> confirm if it's really is. >> >> More details are provided in the forwarded message below. I have also >> attached an archive with minimized testcase and scripts to run it. In >> order to run it please: >> >> 1. Unzip attached archive to some machine (Windows or Unix); >> >> 2. If it's Windows rename test18/test_bat to test18/test.bat. >> >> 3. Modify JDK_HOME variable inside test18/test.bat (or >> test18/test.sh) to point to your JDK installation. >> >> 4. Run test18/test.bat (or test18/test.sh). >> >> Thank you, >> >> Georgiy. >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: Modules with packages duplication >> Date: Thu, 05 May 2016 18:21:20 +0300 >> From: Konstantin Barzilovich >> Organization: Oracle Corporation >> To: ML OpenJDK Jigsaw Developers , Alan >> Bateman >> >> >> >> Hello Alan, >> >> Thank you for the answer. >> >> I have one more question connected with duplication of packages. >> Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them. >> But in case of these two modules are readable by third module, in runtime it will result in error of boot Layer, as you said. >> Is it okey, that compiler allow us to compile code, that will cause runtime failure? >> >> Here is minimal test case: >> ------------------------------ >> module1/module-info.java >> module module1 { >> exports pack; >> } >> >> module1/pack/A.java: >> package pack; >> public class A{} >> >> module2/module-info.java >> module module2 { >> } >> >> module2/pack/A.java: >> package pack; >> public class A{} >> >> module3/module-info.java: >> module module3{ >> requires module1; >> requires module2; >> } >> >> Thanks, >> Konstantin. >> >> > >> > On 04/05/2016 14:18, Konstantin Barzilovich wrote: >> >> Hello, >> >> >> >> I can see that RI checks if there are packages with the same names in >> different modules (named or unnamed). >> >> This check fails even if there is no clash (no module can read both >> packages). >> >> Will it be the same in final version of JDK9 or it can be changed soon? >> >> >> > I think you are asking about modules on the application module path > (`java -modulepath ...`) that are resolved at startup. These are defined > to the application class loader so they cannot have overlapping > packages. It's trivial to do things like map each module in its own > class loader but that messes with visibility with lots of implications > (particularly when running with both a class path and module path or > where you bringing automatic modules into the picture). So what you are > seeing is specific to the boot Layer and no specific short term plans to > change this. >> > >> > -Alan > -------------- next part -------------- diff -r 000000000000 -r 73c08b4cf501 module1/module-info.java --- /dev/null +++ b/module1/module-info.java @@ -0,0 +1,3 @@ +module module1 { + exports pack; +} diff -r 000000000000 -r 73c08b4cf501 module1/pack/A.java --- /dev/null +++ b/module1/pack/A.java @@ -0,0 +1,3 @@ +package pack; + +public class A{} diff -r 000000000000 -r 73c08b4cf501 module2/module-info.java --- /dev/null +++ b/module2/module-info.java @@ -0,0 +1,2 @@ +module module2 { +} diff -r 000000000000 -r 73c08b4cf501 module2/pack/A.java --- /dev/null +++ b/module2/pack/A.java @@ -0,0 +1,3 @@ +package pack; + +public class A{} diff -r 000000000000 -r 73c08b4cf501 module3/mainpack/Main.java --- /dev/null +++ b/module3/mainpack/Main.java @@ -0,0 +1,7 @@ +package mainpack; + +public class Main { + public static void main(String args[]) { + System.out.println("Hello world"); + } +} \ No newline at end of file diff -r 000000000000 -r 73c08b4cf501 module3/module-info.java --- /dev/null +++ b/module3/module-info.java @@ -0,0 +1,5 @@ +module module3{ + requires module1; + requires module2; + exports mainpack; +} \ No newline at end of file diff -r 000000000000 -r 73c08b4cf501 test.bat --- /dev/null +++ b/test.bat @@ -0,0 +1,21 @@ + at echo off +set JDK_HOME= +set JDK_BIN=%JDK_HOME%\bin +set JAVAC=%JDK_BIN%\javac +set JAVA=%JDK_BIN%\java +set CUR_DIR=%~dp0 +set OUT_DIR=%CUR_DIR%out +set FILES=module1\module-info.java^ + module1\pack\A.java^ + module2\module-info.java^ + module2\pack\A.java^ + module3\module-info.java^ + module3\mainpack\Main.java + +rmdir %OUT_DIR% /S /Q +mkdir %OUT_DIR% + + at echo on + +%JAVAC% -d %OUT_DIR% -modulesourcepath %CUR_DIR% %FILES% +%JAVA% -modulepath %OUT_DIR% -m module3/mainpack.Main \ No newline at end of file diff -r 000000000000 -r 73c08b4cf501 test.sh --- /dev/null +++ b/test.sh @@ -0,0 +1,26 @@ +#!/usr/ccs/bin/bash +JDK_HOME= +JDK_BIN=$JDK_HOME/bin +JAVAC=$JDK_BIN/javac +JAVA=$JDK_BIN/java +CUR_DIR=${0%/*} +OUT_DIR=$CUR_DIR/out +MSP=$CUR_DIR/test/modules +FILES="module1/module-info.java \ + module1/pack/A.java \ + module2/module-info.java \ + module2/pack/A.java \ + module3/module-info.java + module3/mainpack/Main.java" + +rm -rf $OUT_DIR +mkdir $OUT_DIR + +JAVAC_INVOCATION="$JAVAC -d $OUT_DIR -modulesourcepath $CUR_DIR $FILES" +JAVA_INVOCATION="$JAVA -modulepath $OUT_DIR -m module3/mainpack.Main" + +#echo $JAVAC_INVOCATION +$JAVAC_INVOCATION + +#echo $JAVA_INVOCATION +$JAVA_INVOCATION From mandy.chung at oracle.com Thu May 19 14:48:26 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 07:48:26 -0700 Subject: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules In-Reply-To: References: <573D5CD2.2050205@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.01/index.html Mandy From Alan.Bateman at oracle.com Thu May 19 16:19:03 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 May 2016 17:19:03 +0100 Subject: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules In-Reply-To: References: <573D5CD2.2050205@oracle.com> Message-ID: <573DE777.50506@oracle.com> On 19/05/2016 15:48, Mandy Chung wrote: > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.01/index.html > > Mandy > This looks okay except the naming of the sub-directories (basic and SystemModules) is inconsistent. Maybe it needs to be systemmodules/PatchSystemModules.java. -Alan. From mandy.chung at oracle.com Thu May 19 16:27:48 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 May 2016 09:27:48 -0700 Subject: Review request: 8157068 ExceptionInInitializerError if images build patched to use exploded version of java.lang.module.SystemModules In-Reply-To: <573DE777.50506@oracle.com> References: <573D5CD2.2050205@oracle.com> <573DE777.50506@oracle.com> Message-ID: <6E69EB7F-4D11-4551-82EC-71FB9B4236E7@oracle.com> > On May 19, 2016, at 9:19 AM, Alan Bateman wrote: > > > On 19/05/2016 15:48, Mandy Chung wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8157068/webrev.01/index.html >> >> Mandy >> > This looks okay except the naming of the sub-directories (basic and SystemModules) is inconsistent. Maybe it needs to be systemmodules/PatchSystemModules.java. I?m okay to rename them. Mandy From alan.bateman at oracle.com Fri May 20 06:27:11 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:11 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201605200627.u4K6RBaG028990@aojmv0008.oracle.com> Changeset: ecd0d6a71c7c Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/ecd0d6a71c7c Added tag jdk-9+119 for changeset 331a825f849a ! .hgtags Changeset: 7e979d9e857b Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/7e979d9e857b Merge From alan.bateman at oracle.com Fri May 20 06:27:14 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:14 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201605200627.u4K6REsT028997@aojmv0008.oracle.com> Changeset: 5943b791e131 Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5943b791e131 Added tag jdk-9+119 for changeset daf533920b12 ! .hgtags Changeset: 5be3e5d01967 Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/5be3e5d01967 Merge From alan.bateman at oracle.com Fri May 20 06:27:13 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:13 +0000 Subject: hg: jigsaw/jake/nashorn: 9 new changesets Message-ID: <201605200627.u4K6RDki028994@aojmv0008.oracle.com> Changeset: fb8b5b560a57 Author: sundar Date: 2016-05-10 22:26 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/fb8b5b560a57 8156665: ES6 for..of should work on Java Iterables and Java arrays Reviewed-by: attila, hannesw ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/es6/JDK-8156665.js + test/script/basic/es6/JDK-8156665.js.EXPECTED Changeset: 2470510268c7 Author: sla Date: 2016-05-11 11:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2470510268c7 8156658: Common way to run jtreg tests Reviewed-by: erikj, dsamersoff + test/Makefile Changeset: 21421eec73d6 Author: attila Date: 2016-05-11 19:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/21421eec73d6 8156738: Use StackWalker for DynamicLinker.getLinkedCallSiteLocation Reviewed-by: hannesw, sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinker.java + test/src/jdk/dynalink/test/LinkedCallSiteLocationTest.java Changeset: ad496474746e Author: sundar Date: 2016-05-12 13:07 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ad496474746e 8156820: Nashorn nightly test failure after fix for 8156738 Reviewed-by: hannesw, mhaupt ! test/src/jdk/dynalink/test/LinkedCallSiteLocationTest.java Changeset: 4b118e012ac4 Author: lana Date: 2016-05-12 18:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/4b118e012ac4 Merge Changeset: 809ef81502ed Author: hannesw Date: 2016-05-13 14:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/809ef81502ed 8156896: Script stack trace should display function names Reviewed-by: attila, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/NashornException.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! test/script/basic/JDK-8025515.js + test/script/basic/JDK-8156896.js Changeset: 621ad507bf9b Author: hannesw Date: 2016-05-13 18:38 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/621ad507bf9b 8156714: Parsing issue with automatic semicolon insertion Reviewed-by: jlaskey, sundar ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8156714.js ! test/script/nosecurity/parserapi.js.EXPECTED Changeset: eac5955924af Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/eac5955924af Added tag jdk-9+119 for changeset 621ad507bf9b ! .hgtags Changeset: 7b912985fb7e Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7b912985fb7e Merge ! .hgtags From alan.bateman at oracle.com Fri May 20 06:27:14 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:14 +0000 Subject: hg: jigsaw/jake/jaxp: 9 new changesets Message-ID: <201605200627.u4K6REjI029004@aojmv0008.oracle.com> Changeset: 6390a20678d6 Author: joehw Date: 2016-05-09 14:58 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/6390a20678d6 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant Reviewed-by: dfuchs ! src/java.xml/share/classes/module-info.java ! src/java.xml/share/classes/org/xml/sax/AttributeList.java ! src/java.xml/share/classes/org/xml/sax/DocumentHandler.java ! src/java.xml/share/classes/org/xml/sax/Parser.java ! src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java ! src/java.xml/share/classes/org/xml/sax/helpers/ParserFactory.java ! src/java.xml/share/classes/org/xml/sax/helpers/SecuritySupport.java ! src/java.xml/share/classes/org/xml/sax/helpers/XMLReaderFactory.java Changeset: 78b710ed047a Author: amlu Date: 2016-05-10 10:45 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/78b710ed047a 8156513: Problem list javax/xml/jaxp/unittest/stream/FactoryFindTest.java Reviewed-by: rriggs, joehw ! test/ProblemList.txt Changeset: a3c5b5a6b125 Author: fyuan Date: 2016-05-10 00:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a3c5b5a6b125 8156119: Update ServiceProviderTest for XMLReaderFactory Reviewed-by: joehw Contributed-by: Frank Yuan ! test/javax/xml/jaxp/module/ServiceProviderTest/BasicModularXMLParserTest.java ! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java + test/javax/xml/jaxp/module/ServiceProviderTest/XMLReaderFactoryTest.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/test/test/XMLFactoryHelper.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/unnamed/Main.java ! test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/module-info.java + test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider2/xp2/XMLReaderImpl.java + test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider3/legacy/META-INF/services/org.xml.sax.driver + test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider3/service/META-INF/services/org.xml.sax.XMLReader + test/javax/xml/jaxp/module/ServiceProviderTest/src/xmlprovider3/xp3/XMLReaderImpl.java Changeset: bfc9ec1a816b Author: joehw Date: 2016-05-10 16:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/bfc9ec1a816b 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RE.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REProgram.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RETest.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REUtil.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/recompile.java Changeset: e59017d60861 Author: sla Date: 2016-05-11 11:05 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/e59017d60861 8156658: Common way to run jtreg tests Reviewed-by: erikj, dsamersoff ! test/Makefile Changeset: f2bd0abeb775 Author: lana Date: 2016-05-12 18:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f2bd0abeb775 Merge - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RE.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REProgram.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RETest.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REUtil.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/recompile.java Changeset: f92e8518bb34 Author: aefimov Date: 2016-05-13 01:19 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f92e8518bb34 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter Reviewed-by: joehw ! src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java + test/javax/xml/jaxp/unittest/stream/XMLStreamWriterTest/SurrogatesTest.java Changeset: f066b3e99084 Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f066b3e99084 Added tag jdk-9+119 for changeset f92e8518bb34 ! .hgtags Changeset: c99e7158db11 Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c99e7158db11 Merge - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RE.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REProgram.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/RETest.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/REUtil.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/java.xml/share/classes/com/sun/org/apache/regexp/internal/recompile.java ! src/java.xml/share/classes/module-info.java ! src/java.xml/share/classes/org/xml/sax/helpers/NewInstance.java From alan.bateman at oracle.com Fri May 20 06:27:20 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:20 +0000 Subject: hg: jigsaw/jake: 9 new changesets Message-ID: <201605200627.u4K6RK4K029016@aojmv0008.oracle.com> Changeset: 95b270614957 Author: chegar Date: 2016-05-10 13:34 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/95b270614957 8074716: IntelliJ IDEA project support Reviewed-by: rriggs Contributed-by: Chris Hegarty , Maurizio Cimadamore ! .hgignore + common/bin/idea.sh + make/idea/idea.gmk + make/idea/template/.name + make/idea/template/ant.xml + make/idea/template/build.xml + make/idea/template/compiler.xml + make/idea/template/copyright/profiles_settings.xml + make/idea/template/jdk.iml + make/idea/template/misc.xml + make/idea/template/modules.xml + make/idea/template/scopes/scope_settings.xml + make/idea/template/src/idea/JdkIdeaAntLogger.java + make/idea/template/vcs.xml + make/idea/template/workspace.xml + test/make/TestIdea.gmk ! test/make/TestMake.gmk Changeset: 9dc9039053d5 Author: erikj Date: 2016-05-11 13:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/9dc9039053d5 8156733: JIB fails to follow redirects Summary: Make jib more resilient, let it follow redirects, and handle network hickups with 3 retries. Reviewed-by: erikj Contributed-by: Stefan Sarne ! common/bin/jib.sh Changeset: 733c7be12b39 Author: sla Date: 2016-05-11 11:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/733c7be12b39 8156658: Common way to run jtreg tests Reviewed-by: erikj, dsamersoff ! test/Makefile Changeset: b12ea8f800aa Author: erikj Date: 2016-05-11 14:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b12ea8f800aa 8155587: Cross compilation may cause compiler warnings for "build" compiler Reviewed-by: dholmes, cjplummer ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 1e9f3cc22044 Author: redestad Date: 2016-05-12 14:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1e9f3cc22044 8156756: Enable build-time use of resource ordering plugin Reviewed-by: jlaskey, alanb, erikj ! make/Images.gmk Changeset: 996f9fa4f8e6 Author: lana Date: 2016-05-12 18:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/996f9fa4f8e6 Merge Changeset: 3463a3f14f0f Author: erikj Date: 2016-05-13 09:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/3463a3f14f0f 8156837: RC resource compilation on windows generates false build failure reports Reviewed-by: tbell, prr ! make/common/NativeCompilation.gmk Changeset: e3b62687563c Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e3b62687563c Added tag jdk-9+119 for changeset 3463a3f14f0f ! .hgtags Changeset: 8dc9e89c0fb2 Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8dc9e89c0fb2 Merge ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! make/Images.gmk ! make/common/NativeCompilation.gmk ! test/make/TestMake.gmk From alan.bateman at oracle.com Fri May 20 06:27:21 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:21 +0000 Subject: hg: jigsaw/jake/hotspot: 5 new changesets Message-ID: <201605200627.u4K6RLGf029019@aojmv0008.oracle.com> Changeset: c4db9d7b2ee1 Author: sla Date: 2016-05-11 11:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/c4db9d7b2ee1 8156658: Common way to run jtreg tests Reviewed-by: erikj, dsamersoff ! test/Makefile Changeset: a389eb33db44 Author: mchung Date: 2016-05-12 11:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a389eb33db44 8155977: ObjectInputStream::resolveClass & resolveProxyClass for platform loader Reviewed-by: acorn, alanb, chegar, dfuchs ! src/share/vm/prims/jvm.cpp Changeset: 15f3fe264872 Author: lana Date: 2016-05-12 18:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/15f3fe264872 Merge Changeset: 7eab471aeaf0 Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7eab471aeaf0 Added tag jdk-9+119 for changeset 15f3fe264872 ! .hgtags Changeset: f2c539d0681f Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f2c539d0681f Merge ! .hgtags ! src/share/vm/prims/jvm.cpp From alan.bateman at oracle.com Fri May 20 06:27:24 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:24 +0000 Subject: hg: jigsaw/jake/langtools: 11 new changesets Message-ID: <201605200627.u4K6RPlK029027@aojmv0008.oracle.com> Changeset: f92cc177314f Author: jjg Date: 2016-05-09 16:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f92cc177314f 8075703: jdk.javadoc module exports com.sun.tools.javadoc package which contains a lot of internal API. Reviewed-by: ksrini ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Comment.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocLocale.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/FieldDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocClassFinder.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTodo.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Main.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Messager.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MethodDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ModifierFilter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PackageDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParamTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PrimitiveType.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/RootDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerializedForm.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeMaker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AbstractTypeImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotatedTypeImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationDescImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationTypeDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationTypeElementDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationValueImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ClassDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Comment.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ConstructorDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocEnv.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocLocale.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocletInvoker.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ExecutableMemberDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/FieldDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocClassFinder.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocEnter.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocMemberEnter.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocTodo.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocTool.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/MemberDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Messager.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/MethodDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ModifierFilter.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/PackageDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ParamTagImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ParameterImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ParameterizedTypeImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/PrimitiveType.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ProgramElementDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/RootDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SeeTagImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SerialFieldTagImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SerializedForm.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SourcePositionImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Start.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/TagImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ThrowsTagImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/TypeMaker.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/TypeVariableImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/WildcardTypeImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: 6c4309f7b31b Author: jlahoda Date: 2016-05-05 12:55 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6c4309f7b31b 8153761: JShell: Completion -- Show parameter names if possible Summary: Compiling code with -parameters; keeping parameter names when reading classfiles; searching JDK sources if parameter names are not available. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/Util.java ! test/jdk/jshell/CompletionSuggestionTest.java Changeset: b42e6d7b1b99 Author: jjg Date: 2016-05-10 15:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b42e6d7b1b99 8150011: Update javac to generate V53.0 class files Reviewed-by: darcy Contributed-by: vicente.romero at oracle.com, jonathan.gibbons at oracle.com ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/6330997/T6330997.java ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/Versions.java Changeset: dc0578912ee5 Author: sla Date: 2016-05-11 11:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dc0578912ee5 8156658: Common way to run jtreg tests Reviewed-by: erikj, dsamersoff ! test/Makefile Changeset: 2f8aacbb1a90 Author: jlahoda Date: 2016-05-11 17:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2f8aacbb1a90 8156097: docs build fails with StackOverflowError on Solaris Summary: Avoiding deep recursion in TypeEnter.MembersPhase Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java + test/tools/javac/importscope/TestDeepFinishClassStack.java Changeset: c51b40933e0c Author: bpatel Date: 2016-05-11 20:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/c51b40933e0c 8154262: Navigation bar in javadoc generated pages needs to be updated to display module information Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! test/jdk/javadoc/doclet/testModules/TestModules.java + test/jdk/javadoc/doclet/testModules/testpkgnomodule/TestClassNoModule.java Changeset: 04fcbc7234a4 Author: jjg Date: 2016-05-12 11:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/04fcbc7234a4 8149843: StandardJavaFileManager should provide a way to get paths from strings 8150111: Need to change signature of StandardJavaFileManager.setLocationFromPaths Reviewed-by: vromero, jlahoda ! src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/FSInfo.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/PathFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/RelativePath.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java Changeset: 41b5241b25d3 Author: lana Date: 2016-05-12 18:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/41b5241b25d3 Merge - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Comment.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocLocale.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/FieldDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocClassFinder.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTodo.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Messager.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MethodDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ModifierFilter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PackageDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParamTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PrimitiveType.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/RootDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerializedForm.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeMaker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java Changeset: 6347efd1be03 Author: ksrini Date: 2016-05-14 08:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/6347efd1be03 8156950: NPE while accessing ExportsDirectives.getTargetModules Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java Changeset: 1578b957d223 Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1578b957d223 Added tag jdk-9+119 for changeset 6347efd1be03 ! .hgtags Changeset: d8e11be92f08 Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d8e11be92f08 Merge ! .hgtags ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Directive.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/PathFileObject.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ClassDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Comment.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocEnv.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocLocale.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/DocletInvoker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/FieldDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocClassFinder.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTodo.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/JavadocTool.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Messager.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/MethodDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ModifierFilter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PackageDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParamTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/PrimitiveType.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/RootDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SeeTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SerializedForm.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Start.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/ToolOption.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeMaker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ClassDocImpl.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocEnv.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocletInvoker.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocTool.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Start.java + src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/Makefile ! test/jdk/jshell/CompletionSuggestionTest.java ! test/tools/javac/6330997/T6330997.java From alan.bateman at oracle.com Fri May 20 06:27:29 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 20 May 2016 06:27:29 +0000 Subject: hg: jigsaw/jake/jdk: 42 new changesets Message-ID: <201605200627.u4K6RUYs029084@aojmv0008.oracle.com> Changeset: e935f0b48514 Author: prappo Date: 2016-05-09 23:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e935f0b48514 8087113: Websocket API and implementation Reviewed-by: chegar - src/java.httpclient/share/classes/java/net/http/CharsetToolkit.java ! src/java.httpclient/share/classes/java/net/http/RawChannel.java + src/java.httpclient/share/classes/java/net/http/WS.java + src/java.httpclient/share/classes/java/net/http/WSBuilder.java + src/java.httpclient/share/classes/java/net/http/WSCharsetToolkit.java + src/java.httpclient/share/classes/java/net/http/WSDisposable.java + src/java.httpclient/share/classes/java/net/http/WSDisposableText.java + src/java.httpclient/share/classes/java/net/http/WSFrame.java + src/java.httpclient/share/classes/java/net/http/WSFrameConsumer.java + src/java.httpclient/share/classes/java/net/http/WSMessageConsumer.java + src/java.httpclient/share/classes/java/net/http/WSMessageSender.java + src/java.httpclient/share/classes/java/net/http/WSOpeningHandshake.java + src/java.httpclient/share/classes/java/net/http/WSOutgoingMessage.java + src/java.httpclient/share/classes/java/net/http/WSProtocolException.java + src/java.httpclient/share/classes/java/net/http/WSReceiver.java + src/java.httpclient/share/classes/java/net/http/WSShared.java + src/java.httpclient/share/classes/java/net/http/WSSharedPool.java + src/java.httpclient/share/classes/java/net/http/WSSignalHandler.java + src/java.httpclient/share/classes/java/net/http/WSTransmitter.java + src/java.httpclient/share/classes/java/net/http/WSUtils.java + src/java.httpclient/share/classes/java/net/http/WSWriter.java + src/java.httpclient/share/classes/java/net/http/WebSocket.java + src/java.httpclient/share/classes/java/net/http/WebSocketHandshakeException.java ! src/java.httpclient/share/classes/java/net/http/package-info.java + test/java/net/httpclient/BasicWebSocketAPITest.java + test/java/net/httpclient/HandshakePhase.java Changeset: 2569a85ce76a Author: xuelei Date: 2016-05-10 00:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2569a85ce76a 8154344: sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java fails on solaris Reviewed-by: weijun ! test/sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java Changeset: f2553c90dbc2 Author: mli Date: 2016-05-10 15:12 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f2553c90dbc2 8156002: java/nio/channels/SocketChannel/AdaptSocket.java Fails in Mesos on OSX Reviewed-by: dfuchs ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/TestServers.java Changeset: c4fa801257f9 Author: redestad Date: 2016-05-10 13:28 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c4fa801257f9 8155795: Optimize Integer/Long.reverse by using reverseBytes Reviewed-by: redestad, shade Contributed-by: jaroslav at kamenik.cz ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/Long.java ! test/java/lang/Integer/BitTwiddle.java ! test/java/lang/Long/BitTwiddle.java Changeset: b2f12e28d97b Author: redestad Date: 2016-05-10 13:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2f12e28d97b 8156560: Remove AddJsum Reviewed-by: alanb, erikj ! make/Tools.gmk - make/src/classes/build/tools/addjsum/AddJsum.java Changeset: deac814a49a0 Author: redestad Date: 2016-05-10 14:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/deac814a49a0 8156561: Remove makeClasslist.js Reviewed-by: erikj, chegar - make/non-build-utils/src/build/tools/makeclasslist/makeClasslist.js Changeset: 1049321b86cb Author: igerasim Date: 2016-05-10 17:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1049321b86cb 8156661: Handful of typos in javadoc Reviewed-by: prappo, rriggs ! src/java.base/share/classes/java/lang/Integer.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java ! src/java.base/share/classes/java/math/BigInteger.java ! src/java.base/share/classes/java/net/InetSocketAddress.java ! src/java.base/share/classes/java/net/URLDecoder.java ! src/java.base/share/classes/java/net/URLEncoder.java ! src/java.base/share/classes/java/security/InvalidAlgorithmParameterException.java ! src/java.base/share/classes/java/security/InvalidKeyException.java ! src/java.base/share/classes/java/security/ProtectionDomain.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/security/Security.java ! src/java.base/share/classes/java/security/spec/InvalidKeySpecException.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/OffsetTime.java ! src/java.base/share/classes/java/time/ZonedDateTime.java ! src/java.base/share/classes/java/util/Comparator.java ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/javax/security/auth/callback/UnsupportedCallbackException.java ! src/java.base/share/classes/sun/net/ftp/FtpClient.java ! src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java ! src/java.management/share/classes/javax/management/AttributeList.java ! src/java.management/share/classes/javax/management/MBeanFeatureInfo.java ! src/java.management/share/classes/javax/management/MBeanInfo.java ! src/java.management/share/classes/sun/management/Sensor.java ! src/java.management/share/classes/sun/management/counter/perf/InstrumentationException.java ! src/java.naming/share/classes/com/sun/jndi/ldap/EventQueue.java ! src/java.naming/share/classes/javax/naming/event/EventContext.java ! src/java.naming/share/classes/javax/naming/event/NamingListener.java ! src/java.naming/share/classes/javax/naming/ldap/UnsolicitedNotificationListener.java ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/EncryptionKey.java ! src/java.sql.rowset/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/java.sql.rowset/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/java.sql/share/classes/java/sql/CallableStatement.java ! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java ! src/jdk.jdi/share/classes/com/sun/jdi/InvalidModuleException.java Changeset: d1dfc4f0b24b Author: weijun Date: 2016-05-11 08:39 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d1dfc4f0b24b 8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom Reviewed-by: wetmore ! src/java.base/unix/classes/sun/security/provider/NativePRNG.java + test/java/security/SecureRandom/MacNativePRNGSetSeed.java Changeset: d0c319c32334 Author: sherman Date: 2016-05-10 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0c319c32334 6328855: String: Matches hangs at short and easy Strings containing \r \n 6192895: java.util.regex.Matcher: Performance issue 6345469: java.util.regex.Matcher utilizes 100% of the CPU 6988218: RegEx matcher loops 6693451: RegEx matcher goes into infinite delay 7006761: Matcher.matches() has infinite loop 8140212: Slow performance of Matcher.find 8151481: j.u.regex.Pattern cleanup 6609854: Regex does not match correctly for negative nested character classes 4916384: CANON_EQ supports only combining character sequences with non-spacing marks 4867170: Pattern doesn't work with composite character in CANON_EQ mode 6995635: CANON_EQ pattern flag is buggy 6728861: ExceptionInInitializerError is caught when the pattern has precomposed character 6736245: A character in Composition Exclusion Table does not match itself 7080302: the normalization in java regex pattern may have flaw Reviewed-by: rriggs, okutsu, alanb ! src/java.base/share/classes/java/security/ProtectionDomain.java ! src/java.base/share/classes/java/security/SecureClassLoader.java + src/java.base/share/classes/java/util/regex/CharPredicates.java + src/java.base/share/classes/java/util/regex/IntHashSet.java ! src/java.base/share/classes/java/util/regex/Matcher.java ! src/java.base/share/classes/java/util/regex/Pattern.java + src/java.base/share/classes/java/util/regex/PrintPattern.java - src/java.base/share/classes/java/util/regex/UnicodeProp.java ! test/java/util/regex/RegExTest.java ! test/java/util/regex/TestCases.txt Changeset: 07b7895425c8 Author: weijun Date: 2016-05-11 12:32 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/07b7895425c8 8154523: SHA1PRNG output should change after setSeed Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/SecureRandom.java + test/sun/security/provider/SecureRandom/SHA1PRNGReseed.java Changeset: 5c8065ff20dd Author: xuelei Date: 2016-05-11 05:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c8065ff20dd 8156716: Incorrect condition in test SupportedDHKeys.java Reviewed-by: weijun ! test/sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java Changeset: 0df4fcfad601 Author: shurailine Date: 2016-05-10 13:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0df4fcfad601 8151914: java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences Reviewed-by: chegar - test/java/util/jar/JarFile/MultiReleaseJarAPI.java - test/java/util/jar/JarFile/MultiReleaseJarHttpProperties.java - test/java/util/jar/JarFile/MultiReleaseJarIterators.java - test/java/util/jar/JarFile/MultiReleaseJarProperties.java - test/java/util/jar/JarFile/MultiReleaseJarSecurity.java + test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java + test/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java + test/java/util/jar/JarFile/mrjar/MultiReleaseJarIterators.java + test/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java + test/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java + test/java/util/jar/JarFile/mrjar/TEST.properties ! test/lib/testlibrary/java/util/jar/Compiler.java Changeset: 523526742d62 Author: bgopularam Date: 2016-05-11 10:28 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/523526742d62 8062804: IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR too lenient Summary: Addded the necessary chck in IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR Reviewed-by: rriggs, scolebourne ! src/java.base/share/classes/java/time/temporal/IsoFields.java ! test/java/time/tck/java/time/temporal/TCKIsoFields.java Changeset: f398d5ab5939 Author: sla Date: 2016-05-11 11:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f398d5ab5939 8156658: Common way to run jtreg tests Reviewed-by: erikj, dsamersoff ! test/Makefile Changeset: 75be15404ae9 Author: jlaskey Date: 2016-05-11 11:26 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/75be15404ae9 8155237: jlink plugin to order resources should take a class list as input Reviewed-by: redestad ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginOrderingGraph.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OrderResourcesPlugin.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/module-info.java Changeset: d70b2b4f58d0 Author: jlaskey Date: 2016-05-11 12:01 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d70b2b4f58d0 8156766: jdk/test/tools/jlink/plugins/SorterPluginTest.java broken Reviewed-by: redestad ! test/ProblemList.txt Changeset: 21b1b5d178ff Author: shurailine Date: 2016-05-10 14:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/21b1b5d178ff 8156695: Fix @modules in tests in java/lang/management Summary: As part of JDK-8155993, tests are updated to declare dependencies on jdk.management. Reviewed-by: mchung ! test/java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java ! test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java ! test/java/lang/management/MXBean/MXBeanBehavior.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/GetPlatformManagementInterfaces.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/MXBeanException.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/ManagementFactory/PlatformMBeanServerTest.java ! test/java/lang/management/ManagementFactory/ProxyExceptions.java ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/GetMBeanInfo.java ! test/java/lang/management/MemoryMXBean/MemoryManagement.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/management/ThreadMXBean/ThreadInfoArray.java Changeset: 271f5910f067 Author: dfuchs Date: 2016-05-11 19:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/271f5910f067 8156153: java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java fails with java.lang.RuntimeException Summary: runs each scenario in its own VM to avoid unwanted interaction and start from a clean slate. Reviewed-by: mchung ! test/java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java Changeset: 53be425cbb83 Author: rriggs Date: 2016-05-11 14:01 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/53be425cbb83 8155978: Remove HTTP proxy implementation and tests from RMI Reviewed-by: smarks ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPConnection.java + src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPDirectSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPTransport.java - test/java/rmi/transport/httpSocket/HttpSocketTest.java - test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java - test/java/rmi/transport/httpSocket/security.policy - test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java - test/sun/rmi/transport/proxy/EagerHttpFallback.java - test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java - test/sun/rmi/transport/tcp/blockAccept/TestIface.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java - test/sun/rmi/transport/tcp/blockAccept/security.policy Changeset: 5a2605c6b1a0 Author: jlaskey Date: 2016-05-11 16:17 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5a2605c6b1a0 8156781: change to jlink has result in test failure Reviewed-by: redestad ! test/ProblemList.txt ! test/tools/jlink/JLinkTest.java + test/tools/jlink/plugins/OrderResourcesPluginTest.java - test/tools/jlink/plugins/SorterPluginTest.java Changeset: 77f87ce87d2f Author: smarks Date: 2016-05-11 17:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/77f87ce87d2f 8156810: remove redundant sentence in SecurityManager.checkMemberAccess doc Reviewed-by: darcy ! src/java.base/share/classes/java/lang/SecurityManager.java Changeset: df10e768c7cc Author: weijun Date: 2016-05-12 09:49 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/df10e768c7cc 8156501: DRBG not synchronized at reseeding Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/AbstractDrbg.java ! src/java.base/share/classes/sun/security/provider/CtrDrbg.java ! src/java.base/share/classes/sun/security/provider/HashDrbg.java ! src/java.base/share/classes/sun/security/provider/HmacDrbg.java Changeset: 698b526d7c3b Author: weijun Date: 2016-05-12 13:06 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/698b526d7c3b 8156213: Remove SHA-1 and 3KeyTDEA algorithms from DRBG Reviewed-by: wetmore, xuelei ! src/java.base/share/classes/java/security/DrbgParameters.java ! src/java.base/share/classes/sun/security/provider/AbstractDrbg.java ! src/java.base/share/classes/sun/security/provider/AbstractHashDrbg.java ! src/java.base/share/classes/sun/security/provider/CtrDrbg.java ! src/java.base/share/conf/security/java.security ! test/sun/security/provider/SecureRandom/DRBGAlg.java ! test/sun/security/provider/SecureRandom/DrbgCavp.java Changeset: 7aa6fef2b351 Author: michaelm Date: 2016-05-12 16:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7aa6fef2b351 8156801: java/net/httpclient/security/Driver.java failed with RuntimeException: Non zero return value Reviewed-by: chegar ! test/java/net/httpclient/security/Security.java Changeset: fe3e1508653e Author: clanger Date: 2016-05-12 16:33 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fe3e1508653e 8156521: Minor fixes and cleanups in NetworkInterface.c Reviewed-by: alanb, chegar, dsamersoff, msheppar ! src/java.base/unix/native/libnet/NetworkInterface.c Changeset: 64706740c26b Author: mchung Date: 2016-05-12 11:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/64706740c26b 8155977: ObjectInputStream::resolveClass & resolveProxyClass for platform loader Reviewed-by: acorn, alanb, chegar, dfuchs ! make/mapfiles/libjava/mapfile-vers ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/jdk/internal/misc/VM.java ! src/java.base/share/native/libjava/VM.c ! src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java Changeset: bbf917638fd3 Author: lana Date: 2016-05-12 18:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bbf917638fd3 Merge - make/non-build-utils/src/build/tools/makeclasslist/makeClasslist.js - make/src/classes/build/tools/addjsum/AddJsum.java - src/java.base/share/classes/java/util/regex/UnicodeProp.java - src/java.httpclient/share/classes/java/net/http/CharsetToolkit.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java - test/java/rmi/transport/httpSocket/HttpSocketTest.java - test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java - test/java/rmi/transport/httpSocket/security.policy - test/java/util/jar/JarFile/MultiReleaseJarAPI.java - test/java/util/jar/JarFile/MultiReleaseJarHttpProperties.java - test/java/util/jar/JarFile/MultiReleaseJarIterators.java - test/java/util/jar/JarFile/MultiReleaseJarProperties.java - test/java/util/jar/JarFile/MultiReleaseJarSecurity.java - test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java - test/sun/rmi/transport/proxy/EagerHttpFallback.java - test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java - test/sun/rmi/transport/tcp/blockAccept/TestIface.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java - test/sun/rmi/transport/tcp/blockAccept/security.policy - test/tools/jlink/plugins/SorterPluginTest.java Changeset: b14b89e259ac Author: darcy Date: 2016-05-12 14:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b14b89e259ac 8156890: Temporarily problem list ListKeychainStore.sh on Mac Reviewed-by: vinnie ! test/ProblemList.txt Changeset: 8e897a655b37 Author: darcy Date: 2016-05-12 15:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e897a655b37 8156897: Problem list ShortRSAKey1024.sh on windows Reviewed-by: mullan ! test/ProblemList.txt Changeset: 24934d5364dd Author: rhalade Date: 2016-05-12 16:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/24934d5364dd 8156671: Refactor sun/security/rsa/SignatureTest.java Reviewed-by: valeriep ! test/sun/security/rsa/SignatureTest.java Changeset: d7741bbbeaf9 Author: peytoia Date: 2016-05-13 12:52 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7741bbbeaf9 8150702: change in javadoc for parseObject for MessageFormat - JDK-8073211 Reviewed-by: okutsu, peytoia Contributed-by: Vaibhav Choudhary ! src/java.base/share/classes/java/text/MessageFormat.java Changeset: c029ee7fc04a Author: erikj Date: 2016-05-13 09:22 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c029ee7fc04a 8156837: RC resource compilation on windows generates false build failure reports Reviewed-by: tbell, prr ! make/launcher/Launcher-java.base.gmk ! make/lib/Awt2dLibraries.gmk Changeset: 5d05dfcf0045 Author: asmotrak Date: 2016-05-13 11:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5d05dfcf0045 8156710: HttpTimeoutException should be thrown if server doesn't respond Reviewed-by: michaelm ! src/java.httpclient/share/classes/java/net/http/Stream.java + test/java/net/httpclient/http2/Timeout.java + test/java/net/httpclient/http2/keystore.p12 Changeset: 48148c98c95a Author: ntv Date: 2016-05-13 18:58 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48148c98c95a 8155823: Add date-time patterns 'v' and 'vvvv' Summary: Addded necessary methodss Reviewed-by: rriggs, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/zone/ZoneRules.java ! test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java Changeset: d7e0283a937c Author: martin Date: 2016-05-12 18:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d7e0283a937c 8156584: Initialization race in sun.security.x509.AlgorithmId.get Summary: Use safe variant of double-checked locking to initialize oidTable Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/x509/AlgorithmId/OidTableInit.java Changeset: 9db62c197dcd Author: valeriep Date: 2016-05-14 03:44 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9db62c197dcd 8000415: Add support for SHA-3 Summary: Add SHA-3 support to SUN and OracleUcrypto provider Reviewed-by: ascarpino, jnimeh ! make/mapfiles/libj2ucrypto/mapfile-vers ! src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java + src/java.base/share/classes/sun/security/provider/SHA3.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/ssl/HandshakeHash.java + src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/LibMDMech.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeDigest.java + src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/NativeDigestMD.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/UcryptoMech.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/UcryptoProvider.java - src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/libsoftcrypto.h ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCrypto.c ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCrypto.h + src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeCryptoMD.c ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeFunc.c ! src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/nativeFunc.h ! test/com/oracle/security/ucrypto/TestDigest.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java Changeset: 7ea7d502b4b5 Author: valeriep Date: 2016-05-14 03:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7ea7d502b4b5 Merge Changeset: 815881042b42 Author: xuelei Date: 2016-05-16 01:05 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/815881042b42 8156991: Problem list UnsupportedDHKeys.java on windows Reviewed-by: igerasim ! test/ProblemList.txt Changeset: 2e8edc311532 Author: psandoz Date: 2016-05-16 07:01 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2e8edc311532 8154049: DualPivot sorting calculates incorrect runs for nearly sorted arrays Reviewed-by: shade ! src/java.base/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/SortingNearlySortedPrimitive.java Changeset: bad3f8a33db2 Author: prappo Date: 2016-05-16 09:54 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bad3f8a33db2 8156931: java.nio.Buffer tests cleanup Reviewed-by: alanb ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/LimitDirectMemory.java ! test/java/nio/Buffer/Order.java ! test/java/nio/Buffer/SwapMicroBenchmark.java Changeset: f8a3c1510f95 Author: lana Date: 2016-05-19 17:48 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f8a3c1510f95 Added tag jdk-9+119 for changeset bad3f8a33db2 ! .hgtags Changeset: e22b2b63ddfd Author: alanb Date: 2016-05-20 07:15 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e22b2b63ddfd Merge ! .hgtags ! make/Tools.gmk ! make/launcher/Launcher-java.base.gmk ! make/lib/Awt2dLibraries.gmk ! make/mapfiles/libjava/mapfile-vers - make/non-build-utils/src/build/tools/makeclasslist/makeClasslist.js - make/src/classes/build/tools/addjsum/AddJsum.java ! src/java.base/share/classes/java/io/ObjectInputStream.java ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/InaccessibleObjectException.java ! src/java.base/share/classes/java/security/Provider.java - src/java.base/share/classes/java/util/regex/UnicodeProp.java ! src/java.base/share/classes/jdk/internal/misc/VM.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/conf/security/java.security ! src/java.base/share/native/libjava/VM.c - src/java.httpclient/share/classes/java/net/http/CharsetToolkit.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/UcryptoMech.java ! src/jdk.crypto.ucrypto/solaris/classes/com/oracle/security/ucrypto/UcryptoProvider.java - src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/libsoftcrypto.h ! src/jdk.jdi/share/classes/com/sun/jdi/InvalidModuleException.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OrderResourcesPlugin.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/module-info.java ! test/Makefile ! test/ProblemList.txt ! test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/GarbageCollectorMXBean/GcInfoCompositeType.java ! test/java/lang/management/MXBean/MXBeanBehavior.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/ProxyExceptions.java ! test/java/lang/management/ManagementFactory/ProxyTypeMapping.java ! test/java/lang/management/ManagementFactory/ValidateOpenTypes.java ! test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/management/ThreadMXBean/ThreadInfoArray.java - test/java/rmi/transport/httpSocket/HttpSocketTest.java - test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java - test/java/rmi/transport/httpSocket/security.policy - test/java/util/jar/JarFile/MultiReleaseJarAPI.java - test/java/util/jar/JarFile/MultiReleaseJarHttpProperties.java - test/java/util/jar/JarFile/MultiReleaseJarIterators.java - test/java/util/jar/JarFile/MultiReleaseJarProperties.java - test/java/util/jar/JarFile/MultiReleaseJarSecurity.java - test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java - test/sun/rmi/transport/proxy/EagerHttpFallback.java - test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java - test/sun/rmi/transport/tcp/blockAccept/TestIface.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java - test/sun/rmi/transport/tcp/blockAccept/security.policy ! test/tools/jlink/JLinkTest.java + test/tools/jlink/plugins/OrderResourcesPluginTest.java - test/tools/jlink/plugins/SorterPluginTest.java From Alan.Bateman at oracle.com Fri May 20 14:12:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 15:12:01 +0100 Subject: Mutable modules In-Reply-To: <573CE2EE.80806@redhat.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> <573CA820.5090302@oracle.com> <573CE2EE.80806@redhat.com> Message-ID: <573F1B31.4020003@oracle.com> On 18/05/2016 22:47, David M. Lloyd wrote: > > I mean in *our* current concept of a module, we can add/remove/modify > the contents of a module (its "class path") at run time. It is up to > the user to ensure that doing so makes sense. I don't think I can relate to the use case. As you probably know then ZIP files have historically had their central directory mapped into memory. Removing or replacing a file that is memory mapped will likely lead to processes accessing the mapped file to crash (SIGBUS usually). So if users are really doing such hairy things they would need a lot of insight into what is running and whether the file is opened before taking this risk. > : > > Our modules each correspond to their own class loader: so far so good, > we can just have one Module per class loader. Problem is that we > support circularity, and also we support dependencies that go across > module systems with isolated namespaces (basically, our module loaders > are a higher order of the exact same concept of class loaders). If there are cyclic relationships between your modules then it will be problematic. Do you see much of this? If you've read Alex's JavaOne slides then you'll know that some of us like Kirk Knoernschild's book on Java Application Architecture and section "4.4 Cyclic Dependencies - the Death Knell" where he poses the question "Are Cycles Always Bad?". I don't want to say too much on this topic here as it is listed as an open issue on the JSR issues list. > > Our modules support specifications including the content of the module > ("resource loaders") and the dependencies of the module. At run time, > custom ModuleLoader implementations can change the resource loader > list and/or the dependency list at any time, causing the module to be > relinked on the spot; the most useful aspect of this is the ability to > incrementally deploy applications which may include circular > dependencies. Aside from cycles then what other use-cases do you have here? I read "change the resource loader list" to mean that the set of resources in the module changes, which is a bit weird if those resources are class files that have already been loaded. Maybe there is dynamic code generation with class bytes generated to the file system or into somewhere virtual? Or maybe these resources are something else, data files? I'm just trying to understand what you mean as we are using differently terminology. > We also support delegating "fallback" class loading decisions to > outside suppliers for dynamic class loading behavior (this was done to > support a dynamic OSGi environment). The ongoing integrity of the > system is up to the party doing the relinking (the EE deployer or the > OSGi resolver); most of the time it can reason about what is "safe" > and what might cause system breakage (but still might be useful to do > anyway). These are the features we can't seem to support under > Jigsaw, architecturally speaking. This sounds like class loader delegation to resolve types that are not in the module. > > Specifically this includes (but is not limited to) changing the > package set associated with a JDK module at run time, something that > this native code block makes impossible. Also the ability to > dynamically change module dependencies is an essential ingredient to > making this work. Suppose that module m has package p and p.C has been loaded. Are you saying that you can drop package p from the module? As things currently stand in JDK 9 then packages may be added to modules at runtime, the main use case is the dynamic proxy to a public interface in a non-exported packages. So I can relate to adding packages for code gen cases, I'm less sure about a module starting out as an XML API and suddenly changing into a JDBC driver. Do you really mean the same module instance? > > In my view, architecturally speaking, most of the constraints imposed > by the core module framework should be layer policy. If the system's > core module layer wants to maintain strict, static integrity, name > constraints, version syntax and semantics, etc., that's fine, but why > should all modules everywhere be forced to the same constraints? Using module names as an example, then it should be possible to develop a module that is deployed on the application module path or instantiated in a layer of modules that a container creates. The author of the module (that chooses the name) isn't going to know in advance how the module is deployed. I'm not even sure how such a module could be compiled or how anyone could depend on it when the characters or format can vary like this. I see there is an issue on the JSR issues list so I don't want to say any more on this topic. > There is no way that existing containers and class loading > environments (other than, apparently, WebLogic) can conform to > Jigsaw's constraints without losing functionality (and I'm trying hard > to find ways to make it work). This is where most of my raised issues > are coming from. The module system imposes surprising few constraints. If you are using your own class loaders then the delegation needs to respect module readability, something that should not be controversial. However it is possible that you are still at the starting line because your have a dependency graph with cycles and/or modules that don't have names that can be expressed as a Java identifier, is that right? > > All these problems seem surmountable to me, but it becomes > substantially more difficult when it is necessary to report all of a > module's packages to the module when it is created, since this > information is now not easily changed. I'm surprised that this is an issue as module membership is critical to access control. -Alan. From njbartlett at gmail.com Fri May 20 15:19:46 2016 From: njbartlett at gmail.com (Neil Bartlett) Date: Fri, 20 May 2016 16:19:46 +0100 Subject: Mutable modules In-Reply-To: <573F1B31.4020003@oracle.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> <573CA820.5090302@oracle.com> <573CE2EE.80806@redhat.com> <573F1B31.4020003@oracle.com> Message-ID: <2E6471AA-8205-484B-A6A9-D122BA58F1C6@gmail.com> > On 20 May 2016, at 15:12, Alan Bateman wrote: > > On 18/05/2016 22:47, David M. Lloyd wrote: >> >> I mean in *our* current concept of a module, we can add/remove/modify the contents of a module (its "class path") at run time. It is up to the user to ensure that doing so makes sense. > I don't think I can relate to the use case. As you probably know then ZIP files have historically had their central directory mapped into memory. Removing or replacing a file that is memory mapped will likely lead to processes accessing the mapped file to crash (SIGBUS usually). So if users are really doing such hairy things they would need a lot of insight into what is running and whether the file is opened before taking this risk. > Mutable module graphs have an 18 year history in OSGi, so they are certainly practical, of course with certain limitations. The use cases are to allow runtime installation or upgrade of modules without shutting down an entire application. Such capabilities proved indispensable in OSGi?s original market of home gateways, and now in the IoT world. They key point is that it is a cooperative mechanism. When a module is uninstalled in OSGi, a callback is sent to the module in question, and it is then responsible for safely cleaning up anything that it was doing. If it does so properly then the module, along with all of its loaded objects, their classes and the classloader, become available for garbage collection. When a module is updated, a new classloader is created for the new version. Therefore if a module fails to implement correct clean-up and is updated many times, you have a memory leak. This is inescapable? the JVM can no more force a module to unload then it can force a thread to stop, and we all know the dire consequences of calling Thread#stop(). In case of a dependency (module A imports a package from module B), when B is uninstalled then module A must be refreshed. This involves calling the shutdown callback on modules A and B, and then re-resolving A. That resolution will likely fail as it will not be able to import the required packaged (unless they are exported from somewhere else). Obviously this model depends heavily on a 1-to-1 mapping of classloaders to modules, in common with the JBoss Module System as described previously by David Lloyd. >> : >> >> Our modules each correspond to their own class loader: so far so good, we can just have one Module per class loader. Problem is that we support circularity, and also we support dependencies that go across module systems with isolated namespaces (basically, our module loaders are a higher order of the exact same concept of class loaders). > If there are cyclic relationships between your modules then it will be problematic. Do you see much of this? If you've read Alex's JavaOne slides then you'll know that some of us like Kirk Knoernschild's book on Java Application Architecture and section "4.4 Cyclic Dependencies - the Death Knell" where he poses the question "Are Cycles Always Bad?". I don't want to say too much on this topic here as it is listed as an open issue on the JSR issues list. > OSGi permits cyclical dependencies, but such cycles can only be resolved all-at-once. This is essentially why OSGi separates its resolution phase (i.e. solving all dependencies) from its activation phase. Modules involved in a cycle will not be GC?d until all of the modules in that cycle are uninstalled or refreshed. >> >> Our modules support specifications including the content of the module ("resource loaders") and the dependencies of the module. At run time, custom ModuleLoader implementations can change the resource loader list and/or the dependency list at any time, causing the module to be relinked on the spot; the most useful aspect of this is the ability to incrementally deploy applications which may include circular dependencies. > Aside from cycles then what other use-cases do you have here? I read "change the resource loader list" to mean that the set of resources in the module changes, which is a bit weird if those resources are class files that have already been loaded. Maybe there is dynamic code generation with class bytes generated to the file system or into somewhere virtual? Or maybe these resources are something else, data files? I'm just trying to understand what you mean as we are using differently terminology. > >> We also support delegating "fallback" class loading decisions to outside suppliers for dynamic class loading behavior (this was done to support a dynamic OSGi environment). The ongoing integrity of the system is up to the party doing the relinking (the EE deployer or the OSGi resolver); most of the time it can reason about what is "safe" and what might cause system breakage (but still might be useful to do anyway). These are the features we can't seem to support under Jigsaw, architecturally speaking. > This sounds like class loader delegation to resolve types that are not in the module. > >> >> Specifically this includes (but is not limited to) changing the package set associated with a JDK module at run time, something that this native code block makes impossible. Also the ability to dynamically change module dependencies is an essential ingredient to making this work. > Suppose that module m has package p and p.C has been loaded. Are you saying that you can drop package p from the module? > > As things currently stand in JDK 9 then packages may be added to modules at runtime, the main use case is the dynamic proxy to a public interface in a non-exported packages. So I can relate to adding packages for code gen cases, I'm less sure about a module starting out as an XML API and suddenly changing into a JDBC driver. Do you really mean the same module instance? Modules coming and going affects the state of the service registry. It?s true that an API module (say, one that exports a bunch of interfaces) does not often need to dynamically change, and when it does change it causes a substantial amount of churn in the dependency graph. But If a module that provides a service is dynamically updated then consumers of that service should immediately see the new service implementation. If the provider module does not export any packages then it cannot have an affect on the imports of other modules, so the resolution can be done entirely locally to that module. We have found that the dynamics in the service registry are extremely valuable because service availability can be used to reflect the availability of the real-world resources that those services represent. So OSGi?s dynamics are about far more than just module updates. Indeed, my enterprise customers rarely perform runtime module updates but they do employ service dynamics heavily. > >> >> In my view, architecturally speaking, most of the constraints imposed by the core module framework should be layer policy. If the system's core module layer wants to maintain strict, static integrity, name constraints, version syntax and semantics, etc., that's fine, but why should all modules everywhere be forced to the same constraints? > Using module names as an example, then it should be possible to develop a module that is deployed on the application module path or instantiated in a layer of modules that a container creates. The author of the module (that chooses the name) isn't going to know in advance how the module is deployed. I'm not even sure how such a module could be compiled or how anyone could depend on it when the characters or format can vary like this. I see there is an issue on the JSR issues list so I don't want to say any more on this topic. > > >> There is no way that existing containers and class loading environments (other than, apparently, WebLogic) can conform to Jigsaw's constraints without losing functionality (and I'm trying hard to find ways to make it work). This is where most of my raised issues are coming from. > The module system imposes surprising few constraints. If you are using your own class loaders then the delegation needs to respect module readability, something that should not be controversial. > > However it is possible that you are still at the starting line because your have a dependency graph with cycles and/or modules that don't have names that can be expressed as a Java identifier, is that right? > As a disclaimer, I am not involved with OSGi?s official effort to evaluate and integrate the Java 9 module system but I am interested in the subject. The biggest decision that needs to be made is whether to create a direct mapping of OSGi bundles to J9 modules, or to exist in parallel with it. To achieve the former, there seem to be four major problems that must be tackled: 1. Lack of extensibility in the module-info.java format for version, imports and other metadata; 2. No reflective access to non-exported packages ? often needed for frameworks like dependency injectors; 3. No dependency cycles at the module level ? this is not encouraged in OSGi but has never been forbidden because there was no need to. To forbid it now would be a backwards-incompatible change for us; 4. Lack of dynamics. Nothing in the currently published API for J9 modules suggests to me that we can support the refresh, update, uninstall or install operations. Regards, Neil > >> >> All these problems seem surmountable to me, but it becomes substantially more difficult when it is necessary to report all of a module's packages to the module when it is created, since this information is now not easily changed. > I'm surprised that this is an issue as module membership is critical to access control. > > -Alan. From david.lloyd at redhat.com Fri May 20 15:20:26 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 20 May 2016 10:20:26 -0500 Subject: Mutable modules In-Reply-To: <573F1B31.4020003@oracle.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> <573CA820.5090302@oracle.com> <573CE2EE.80806@redhat.com> <573F1B31.4020003@oracle.com> Message-ID: <573F2B3A.7060402@redhat.com> On 05/20/2016 09:12 AM, Alan Bateman wrote: > On 18/05/2016 22:47, David M. Lloyd wrote: >> >> I mean in *our* current concept of a module, we can add/remove/modify >> the contents of a module (its "class path") at run time. It is up to >> the user to ensure that doing so makes sense. > I don't think I can relate to the use case. As you probably know then > ZIP files have historically had their central directory mapped into > memory. Removing or replacing a file that is memory mapped will likely > lead to processes accessing the mapped file to crash (SIGBUS usually). > So if users are really doing such hairy things they would need a lot of > insight into what is running and whether the file is opened before > taking this risk. No, we don't support replacement of JAR files; more like we symbolically remove the resources and add overlays. Internally, we generally explode JAR files for various reasons. It has nothing to do with JAR files, more to do with the logical presence and absence of class files and resources. >> Our modules each correspond to their own class loader: so far so good, >> we can just have one Module per class loader. Problem is that we >> support circularity, and also we support dependencies that go across >> module systems with isolated namespaces (basically, our module loaders >> are a higher order of the exact same concept of class loaders). > If there are cyclic relationships between your modules then it will be > problematic. Do you see much of this? If you've read Alex's JavaOne > slides then you'll know that some of us like Kirk Knoernschild's book on > Java Application Architecture and section "4.4 Cyclic Dependencies - the > Death Knell" where he poses the question "Are Cycles Always Bad?". I > don't want to say too much on this topic here as it is listed as an open > issue on the JSR issues list. We use circular dependencies in both our static module layouts and also in our dynamic deployment system. I don't think we have a clear path out if we can't support them; it will certainly be a difficult situation. >> Our modules support specifications including the content of the module >> ("resource loaders") and the dependencies of the module. At run time, >> custom ModuleLoader implementations can change the resource loader >> list and/or the dependency list at any time, causing the module to be >> relinked on the spot; the most useful aspect of this is the ability to >> incrementally deploy applications which may include circular >> dependencies. > Aside from cycles then what other use-cases do you have here? I read > "change the resource loader list" to mean that the set of resources in > the module changes, which is a bit weird if those resources are class > files that have already been loaded. Maybe there is dynamic code > generation with class bytes generated to the file system or into > somewhere virtual? Or maybe these resources are something else, data > files? I'm just trying to understand what you mean as we are using > differently terminology. Within our module concept, the "class path" is a sort of colloquial term which refers to the series of resource loaders used to locate classes and resources within each module. Functionally it's somewhat analogous to the URLClassPath concept in the JDK, in the way that resources are sought (i.e. by a linear search from start to end of the list). This is separate from the module dependency list, which, when combined with the resource loader list, is used to construct an index by path (which is a superset of packages that includes not just classes but also resources) which refers to dependencies and/or internal resources. When the resource list is changed, all future lookups for classes and resources will use the new index. If there are already classes loaded from the previous list, and those classes are sufficiently incompatible with the new code, obviously this will result in errors; however, this is usually not the case when (say) making incremental changes during development. This is generally an edge case, but it is one which we presently support. Changing the dependency list has effects that are somewhat similar. Existing loaded classes which have already linked against classes of the previous dependency may malfunction when doing this. But in the hot deployment situation, most of the time these changes are additive, so the effect is generally to enable previously unlinked code to become linkable. This could happen, for example, when deploying a JAR some time after a first JAR was deployed, which resolves some missing dependencies in the first JAR. >> We also support delegating "fallback" class loading decisions to >> outside suppliers for dynamic class loading behavior (this was done to >> support a dynamic OSGi environment). The ongoing integrity of the >> system is up to the party doing the relinking (the EE deployer or the >> OSGi resolver); most of the time it can reason about what is "safe" >> and what might cause system breakage (but still might be useful to do >> anyway). These are the features we can't seem to support under >> Jigsaw, architecturally speaking. > This sounds like class loader delegation to resolve types that are not > in the module. Exactly. Our OSGi people have told me in the past that OSGi that can't function to spec without this ability. >> Specifically this includes (but is not limited to) changing the >> package set associated with a JDK module at run time, something that >> this native code block makes impossible. Also the ability to >> dynamically change module dependencies is an essential ingredient to >> making this work. > Suppose that module m has package p and p.C has been loaded. Are you > saying that you can drop package p from the module? Yes - although normally you would only drop p if you knew specifically that p.C *hadn't* been loaded, for obvious reasons. It's probably more common to *add* than to drop. > As things currently stand in JDK 9 then packages may be added to modules > at runtime, the main use case is the dynamic proxy to a public interface > in a non-exported packages. So I can relate to adding packages for code > gen cases, I'm less sure about a module starting out as an XML API and > suddenly changing into a JDBC driver. Do you really mean the same module > instance? A more apt example might be to update a part of a module which hasn't yet been loaded. >> In my view, architecturally speaking, most of the constraints imposed >> by the core module framework should be layer policy. If the system's >> core module layer wants to maintain strict, static integrity, name >> constraints, version syntax and semantics, etc., that's fine, but why >> should all modules everywhere be forced to the same constraints? > Using module names as an example, then it should be possible to develop > a module that is deployed on the application module path or instantiated > in a layer of modules that a container creates. The author of the module > (that chooses the name) isn't going to know in advance how the module is > deployed. I'm not even sure how such a module could be compiled or how > anyone could depend on it when the characters or format can vary like > this. I see there is an issue on the JSR issues list so I don't want to > say any more on this topic. The idea of a "module" that I keep referring to is one that is described in the JSR requirements: "... named, self-describing program components consisting of code and data". A plain old JAR file meets this definition just as readily as the current Jigsaw concept. Java 8 javac can compile things that more than meet the definition of "module". The important and relevant part of a module is the ABI it exposes, not its name or even its internal structure (which should be encapsulated in numerous senses of the word). This becomes even more clear when you are assembling an environment consisting of hundreds of artifacts from hundreds of authors. We package many, many artifacts whose authors never gave a thought to modularity at all. The responsibility of assigning a name to an ABI and behavior has to lie with the environment assembler; it just doesn't make sense in the hands of the original author, who is necessarily concerned only with the parameters of their problem space, and not with that of any greater ecosystem in which their project might find itself. This is the very definition of encapsulation. For an example of why we may need flexible naming, I can deploy an application into a Java EE container called "my-cool-application.ear". In this case, I might expect my module to be named "my-cool-application.ear" or perhaps "my-cool-application". I might expect nested JARs to correspond to modules named by their relative JAR locations (including "/" separators). Really the only constraint is the validity of the name on the filesystem. Java EE certainly places no limitations on this today. I might name my modules based on Maven group and artifact IDs, which have different syntax requirements, or by OSGi bundle name. You get the idea. The point is that, yes, you are correct: you *don't* know how a module is going to be deployed; not before Java 9 and likely not after it either. It doesn't even make any sense to define the module name inside the module when the name is going to be 100% dependent on the environment in which the module is used. You can't, on one hand, define a universal namespace and syntax for modules and their versions in the JDK or establish hard constraints on layer and module graph structure, and on the other hand expect other module systems with differing existing constraints to unify on the JDK module system. You're basically cutting these systems off at the knees and forcing them to reinvent everything, unless you completely coincidentally have a system that already conforms to this structure (if so, you are either very fortunate or maybe starting off in a rather privileged position). >> There is no way that existing containers and class loading >> environments (other than, apparently, WebLogic) can conform to >> Jigsaw's constraints without losing functionality (and I'm trying hard >> to find ways to make it work). This is where most of my raised issues >> are coming from. > The module system imposes surprising few constraints. If you are using > your own class loaders then the delegation needs to respect module > readability, something that should not be controversial. See earlier posts about the controversy of making "public" no longer be "public". The email thread is still unresolved and unanswered. > However it is possible that you are still at the starting line because > your have a dependency graph with cycles and/or modules that don't have > names that can be expressed as a Java identifier, is that right? Yes, and also isolated module namespaces which nevertheless need to link with one another. Also version syntax and schemes which are not compatible with the Jigsaw scheme. But these issues are all raised in the document. >> All these problems seem surmountable to me, but it becomes >> substantially more difficult when it is necessary to report all of a >> module's packages to the module when it is created, since this >> information is now not easily changed. > I'm surprised that this is an issue as module membership is critical to > access control. Sure, I get that, but it's only critical to *new* access control rules that were introduced with Jigsaw. The classical rules wherein public=public that we have relied on this past decade would ease this situation substantially, since in this case the only reason module information would pass to the JVM would be for diagnostics; since each class has a module membership, the JVM theoretically would already have access to everything it needs for this purpose. As long as we're talking access control though... the idea of replacing this idea with "friend packages" and using them to selectively expand package-private access has never been resolved or even seriously discussed as far as I can see. It's been brought up several times and basically ignored. But this idea would allow not only modules but *all* Java code to take advantage of better security by removing public qualifiers from things that are not public instead of relying on special packages (because package identity is defined by class loader and package name, meaning modules are not central to the concept though they can easily take advantage of it), which makes far more sense to me at least (in particular, within the JDK code itself - all those "shared secrets" classes!) and imposes far less risk on the access control model by keeping it homogeneous instead of making it bi-layered. I would deeply wish to resurrect this discussion at some point. Readability and exports have been nothing but a problem for users as far as I can see; the current security model certainly isn't doing me any favors. -- - DML From david.lloyd at redhat.com Fri May 20 15:30:05 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 20 May 2016 10:30:05 -0500 Subject: Mutable modules In-Reply-To: <573F2B3A.7060402@redhat.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> <573CA820.5090302@oracle.com> <573CE2EE.80806@redhat.com> <573F1B31.4020003@oracle.com> <573F2B3A.7060402@redhat.com> Message-ID: <573F2D7D.1000302@redhat.com> I had one last follow-up thought, see below: On 05/20/2016 10:20 AM, David M. Lloyd wrote: > You can't, on one hand, define a universal namespace and syntax for > modules and their versions in the JDK or establish hard constraints on > layer and module graph structure, and on the other hand expect other > module systems with differing existing constraints to unify on the JDK > module system. You're basically cutting these systems off at the knees > and forcing them to reinvent everything, unless you completely > coincidentally have a system that already conforms to this structure (if > so, you are either very fortunate or maybe starting off in a rather > privileged position). To be clear, what I'm advocating for is to separate these constraints from *at least* the diagnostic benefits and (f we can resurrect the access control discussion) the security benefits of JDK modules at run time. This might take the form of much greater autonomy for Layers as I've proposed in the issues. But, it might also take the form of allowing non-Jigsaw-style code to (separately, independently) arbitrarily create and manage Modules at run time, completely separate from descriptors, linking behavior, etc. In other words, if I can establish a Class or Package in my class loader, while at the same time defining its module diagnostic information (name, version string, location string, etc.) and security information (what packages can access the nonpublic members of this package, preferably a (possibly wholly or partly weak) set that can be added to at run time), then suddenly Jigsaw-style module artifacts can coexist with other module systems without any drawbacks that I can see, and other existing module systems will then gain access to the fancy stack traces I like so much and any new access checking capabilities that are established. The changes I or other maintainers need to make become minimal because the constraints that Jigsaw imposes are no longer stumbling blocks. Whether or not this means I have to define a real Module becomes immaterial from an implementation standpoint. I hope these ideas are making some kind of sense. -- - DML From stephen.felts at oracle.com Fri May 20 15:31:49 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 20 May 2016 08:31:49 -0700 (PDT) Subject: Mutable modules In-Reply-To: <2E6471AA-8205-484B-A6A9-D122BA58F1C6@gmail.com> References: <573C6CEA.5010105@redhat.com> <573C8465.307@redhat.com> <573C8BA9.90604@oracle.com> <573C94A6.5030001@redhat.com> <573CA820.5090302@oracle.com> <573CE2EE.80806@redhat.com> <573F1B31.4020003@oracle.com> <2E6471AA-8205-484B-A6A9-D122BA58F1C6@gmail.com> Message-ID: <623c27bd-7ba6-48d9-96d9-84ed030350dd@default> I was on a project using OSGi where some of the applications relied on removing and replacing modules. Generally they replaced applications modules at the top with no dependencies into the module. For example, in one application that dealt with RFID, it was common for new RFID clients to be introduced or modifications required to existing RFID clients (the technology was changing very quickly). The handling of these clients was done with modules that could be swapped in as necessary. There were well defined interfaces with various implementations for the different clients. -----Original Message----- From: Neil Bartlett [mailto:njbartlett at gmail.com] Sent: Friday, May 20, 2016 11:20 AM To: Alan Bateman Cc: jigsaw-dev Subject: Re: Mutable modules > On 20 May 2016, at 15:12, Alan Bateman wrote: > > On 18/05/2016 22:47, David M. Lloyd wrote: >> >> I mean in *our* current concept of a module, we can add/remove/modify the contents of a module (its "class path") at run time. It is up to the user to ensure that doing so makes sense. > I don't think I can relate to the use case. As you probably know then ZIP files have historically had their central directory mapped into memory. Removing or replacing a file that is memory mapped will likely lead to processes accessing the mapped file to crash (SIGBUS usually). So if users are really doing such hairy things they would need a lot of insight into what is running and whether the file is opened before taking this risk. > Mutable module graphs have an 18 year history in OSGi, so they are certainly practical, of course with certain limitations. The use cases are to allow runtime installation or upgrade of modules without shutting down an entire application. Such capabilities proved indispensable in OSGi?s original market of home gateways, and now in the IoT world. They key point is that it is a cooperative mechanism. When a module is uninstalled in OSGi, a callback is sent to the module in question, and it is then responsible for safely cleaning up anything that it was doing. If it does so properly then the module, along with all of its loaded objects, their classes and the classloader, become available for garbage collection. When a module is updated, a new classloader is created for the new version. Therefore if a module fails to implement correct clean-up and is updated many times, you have a memory leak. This is inescapable? the JVM can no more force a module to unload then it can force a thread to stop, and we all know the dire consequences of calling Thread#stop(). In case of a dependency (module A imports a package from module B), when B is uninstalled then module A must be refreshed. This involves calling the shutdown callback on modules A and B, and then re-resolving A. That resolution will likely fail as it will not be able to import the required packaged (unless they are exported from somewhere else). Obviously this model depends heavily on a 1-to-1 mapping of classloaders to modules, in common with the JBoss Module System as described previously by David Lloyd. >> : >> >> Our modules each correspond to their own class loader: so far so good, we can just have one Module per class loader. Problem is that we support circularity, and also we support dependencies that go across module systems with isolated namespaces (basically, our module loaders are a higher order of the exact same concept of class loaders). > If there are cyclic relationships between your modules then it will be problematic. Do you see much of this? If you've read Alex's JavaOne slides then you'll know that some of us like Kirk Knoernschild's book on Java Application Architecture and section "4.4 Cyclic Dependencies - the Death Knell" where he poses the question "Are Cycles Always Bad?". I don't want to say too much on this topic here as it is listed as an open issue on the JSR issues list. > OSGi permits cyclical dependencies, but such cycles can only be resolved all-at-once. This is essentially why OSGi separates its resolution phase (i.e. solving all dependencies) from its activation phase. Modules involved in a cycle will not be GC?d until all of the modules in that cycle are uninstalled or refreshed. >> >> Our modules support specifications including the content of the module ("resource loaders") and the dependencies of the module. At run time, custom ModuleLoader implementations can change the resource loader list and/or the dependency list at any time, causing the module to be relinked on the spot; the most useful aspect of this is the ability to incrementally deploy applications which may include circular dependencies. > Aside from cycles then what other use-cases do you have here? I read "change the resource loader list" to mean that the set of resources in the module changes, which is a bit weird if those resources are class files that have already been loaded. Maybe there is dynamic code generation with class bytes generated to the file system or into somewhere virtual? Or maybe these resources are something else, data files? I'm just trying to understand what you mean as we are using differently terminology. > >> We also support delegating "fallback" class loading decisions to outside suppliers for dynamic class loading behavior (this was done to support a dynamic OSGi environment). The ongoing integrity of the system is up to the party doing the relinking (the EE deployer or the OSGi resolver); most of the time it can reason about what is "safe" and what might cause system breakage (but still might be useful to do anyway). These are the features we can't seem to support under Jigsaw, architecturally speaking. > This sounds like class loader delegation to resolve types that are not in the module. > >> >> Specifically this includes (but is not limited to) changing the package set associated with a JDK module at run time, something that this native code block makes impossible. Also the ability to dynamically change module dependencies is an essential ingredient to making this work. > Suppose that module m has package p and p.C has been loaded. Are you saying that you can drop package p from the module? > > As things currently stand in JDK 9 then packages may be added to modules at runtime, the main use case is the dynamic proxy to a public interface in a non-exported packages. So I can relate to adding packages for code gen cases, I'm less sure about a module starting out as an XML API and suddenly changing into a JDBC driver. Do you really mean the same module instance? Modules coming and going affects the state of the service registry. It?s true that an API module (say, one that exports a bunch of interfaces) does not often need to dynamically change, and when it does change it causes a substantial amount of churn in the dependency graph. But If a module that provides a service is dynamically updated then consumers of that service should immediately see the new service implementation. If the provider module does not export any packages then it cannot have an affect on the imports of other modules, so the resolution can be done entirely locally to that module. We have found that the dynamics in the service registry are extremely valuable because service availability can be used to reflect the availability of the real-world resources that those services represent. So OSGi?s dynamics are about far more than just module updates. Indeed, my enterprise customers rarely perform runtime module updates but they do employ service dynamics heavily. > >> >> In my view, architecturally speaking, most of the constraints imposed by the core module framework should be layer policy. If the system's core module layer wants to maintain strict, static integrity, name constraints, version syntax and semantics, etc., that's fine, but why should all modules everywhere be forced to the same constraints? > Using module names as an example, then it should be possible to develop a module that is deployed on the application module path or instantiated in a layer of modules that a container creates. The author of the module (that chooses the name) isn't going to know in advance how the module is deployed. I'm not even sure how such a module could be compiled or how anyone could depend on it when the characters or format can vary like this. I see there is an issue on the JSR issues list so I don't want to say any more on this topic. > > >> There is no way that existing containers and class loading environments (other than, apparently, WebLogic) can conform to Jigsaw's constraints without losing functionality (and I'm trying hard to find ways to make it work). This is where most of my raised issues are coming from. > The module system imposes surprising few constraints. If you are using your own class loaders then the delegation needs to respect module readability, something that should not be controversial. > > However it is possible that you are still at the starting line because your have a dependency graph with cycles and/or modules that don't have names that can be expressed as a Java identifier, is that right? > As a disclaimer, I am not involved with OSGi?s official effort to evaluate and integrate the Java 9 module system but I am interested in the subject. The biggest decision that needs to be made is whether to create a direct mapping of OSGi bundles to J9 modules, or to exist in parallel with it. To achieve the former, there seem to be four major problems that must be tackled: 1. Lack of extensibility in the module-info.java format for version, imports and other metadata; 2. No reflective access to non-exported packages ? often needed for frameworks like dependency injectors; 3. No dependency cycles at the module level ? this is not encouraged in OSGi but has never been forbidden because there was no need to. To forbid it now would be a backwards-incompatible change for us; 4. Lack of dynamics. Nothing in the currently published API for J9 modules suggests to me that we can support the refresh, update, uninstall or install operations. Regards, Neil > >> >> All these problems seem surmountable to me, but it becomes substantially more difficult when it is necessary to report all of a module's packages to the module when it is created, since this information is now not easily changed. > I'm surprised that this is an issue as module membership is critical to access control. > > -Alan. From aleksey.shipilev at oracle.com Fri May 20 15:55:04 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 20 May 2016 18:55:04 +0300 Subject: Weird use case: compiling against dummy sun.misc.* class Message-ID: <573F3358.1090209@oracle.com> Hi, I have a weird use case in jcstress around @Contended. In order to support both JDK 8 and JDK 9 we build against *our own* sun.misc.Contended and jdk.internal.annotations.Contended. This works arguably well for both compiling and running with both JDK 8 and JDK 9: the real annotation gets picked up from the JDK. However, since JDK 9b118 we cannot build anymore, because: LongResult1_jcstress.java:[3,13] error: Contended is not visible because package sun.misc is not visible ...even though sun/misc/Contended.java is right here in my source tree. Is there a magic incantation to make javac proceed? The usual tricks did not help (probably because the target class is not in jdk.unsupported, but rather in the source tree itself): -addmods jdk.unsupported -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED -XaddReads:jdk.unsupported=ALL-UNNAMED Thanks, -Aleksey From chris.hegarty at oracle.com Fri May 20 15:55:33 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 May 2016 16:55:33 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs Message-ID: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> What do you get if you mix JEP 261 [1] with JEP 238 [2]? A Multi-release modular JAR. This issue proposes to add support to the jar tool for creating and updating modular JAR files with an optional module-info.class in the versioned section. MRJARs are intended to target multiple releases of the Java platform, so it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be able to declare a different set of dependencies on modules that are part of the Java platform. The reasoning here is that these are implementation details rather than parts of a module's API surface, and that one may well want to change them as the JDK itself evolves. The runtime already has support for loading from the versioned section. Specifically, a versioned module descriptor must be identical to the root module descriptor, with two exceptions: - A versioned descriptor can have different non-public `requires` clauses of platform ( `java.*` and `jdk.*` ) modules, and - A versioned descriptor can have different `uses` clauses, even of service types defined outside of `java.*` and `jdk.*` modules. http://cr.openjdk.java.net/~chegar/8156497.00/ Note: while there are some new test scenarios added, which give reasonable coverage, further tests will be added later. Steve has some additional jar tools support coming for easier creation of MRJARS. -Chris. [1] http://openjdk.java.net/jeps/261 [2] http://openjdk.java.net/jeps/238 From jonathan.gibbons at oracle.com Fri May 20 16:01:20 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 May 2016 09:01:20 -0700 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> Message-ID: <573F34D0.5090100@oracle.com> It would be good if (eventually) there were test cases involving the use of MRM jars, both via the JarFile API and jar-fs file system, perhaps extending to the use of MRM jars in javac as well. -- Jon On 05/20/2016 08:55 AM, Chris Hegarty wrote: > What do you get if you mix JEP 261 [1] with JEP 238 [2]? > A Multi-release modular JAR. > > This issue proposes to add support to the jar tool for creating and > updating modular JAR files with an optional module-info.class in the > versioned section. > > MRJARs are intended to target multiple releases of the Java platform, so > it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be > able to declare a different set of dependencies on modules that are part > of the Java platform. The reasoning here is that these are > implementation details rather than parts of a module's API surface, and > that one may well want to change them as the JDK itself evolves. The > runtime already has support for loading from the versioned section. > > Specifically, a versioned module descriptor must be identical to the > root module descriptor, with two exceptions: > > - A versioned descriptor can have different non-public `requires` > clauses of platform ( `java.*` and `jdk.*` ) modules, and > > - A versioned descriptor can have different `uses` clauses, even of > service types defined outside of `java.*` and `jdk.*` modules. > > http://cr.openjdk.java.net/~chegar/8156497.00/ > > Note: while there are some new test scenarios added, which give > reasonable coverage, further tests will be added later. Steve has some > additional jar tools support coming for easier creation of MRJARS. > > -Chris. > > [1] http://openjdk.java.net/jeps/261 > [2] http://openjdk.java.net/jeps/238 From alexandre.iline at oracle.com Fri May 20 16:10:33 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 20 May 2016 09:10:33 -0700 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> Message-ID: Chris, Does the test need to use @modules for jdk.jartool and java.compiler? Shura > On May 20, 2016, at 8:55 AM, Chris Hegarty wrote: > > What do you get if you mix JEP 261 [1] with JEP 238 [2]? > A Multi-release modular JAR. > > This issue proposes to add support to the jar tool for creating and > updating modular JAR files with an optional module-info.class in the > versioned section. > > MRJARs are intended to target multiple releases of the Java platform, so > it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be > able to declare a different set of dependencies on modules that are part > of the Java platform. The reasoning here is that these are > implementation details rather than parts of a module's API surface, and > that one may well want to change them as the JDK itself evolves. The > runtime already has support for loading from the versioned section. > > Specifically, a versioned module descriptor must be identical to the > root module descriptor, with two exceptions: > > - A versioned descriptor can have different non-public `requires` > clauses of platform ( `java.*` and `jdk.*` ) modules, and > > - A versioned descriptor can have different `uses` clauses, even of > service types defined outside of `java.*` and `jdk.*` modules. > > http://cr.openjdk.java.net/~chegar/8156497.00/ > > Note: while there are some new test scenarios added, which give > reasonable coverage, further tests will be added later. Steve has some > additional jar tools support coming for easier creation of MRJARS. > > -Chris. > > [1] http://openjdk.java.net/jeps/261 > [2] http://openjdk.java.net/jeps/238 From alex.buckley at oracle.com Fri May 20 16:13:12 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 20 May 2016 09:13:12 -0700 Subject: Weird use case: compiling against dummy sun.misc.* class In-Reply-To: <573F3358.1090209@oracle.com> References: <573F3358.1090209@oracle.com> Message-ID: <573F3798.3040802@oracle.com> If you have your own sun.misc.FOO on the classpath, then you DON'T want a module exporting sun.misc to be readable, because that module is where javac and the runtime will get sun.misc.* types from. So, no need to add readability of the jdk.unsupported module which is not read by default on JDK 9b118. javac "should" be observing your sun.misc.Contended type out of the box -- there may be a javac bug or some other problem with how javac is invoked, please send more details. I assume that the jdk.internal.annotations package exists in java.base so at run time you'll need to -Xpatch your jdk.internal.annotations.Contended type into java.base. Alex On 5/20/2016 8:55 AM, Aleksey Shipilev wrote: > Hi, > > I have a weird use case in jcstress around @Contended. > > In order to support both JDK 8 and JDK 9 we build against *our own* > sun.misc.Contended and jdk.internal.annotations.Contended. This works > arguably well for both compiling and running with both JDK 8 and JDK 9: > the real annotation gets picked up from the JDK. > > However, since JDK 9b118 we cannot build anymore, because: > > LongResult1_jcstress.java:[3,13] error: Contended is not visible because > package sun.misc is not visible > > ...even though sun/misc/Contended.java is right here in my source tree. > Is there a magic incantation to make javac proceed? The usual tricks did > not help (probably because the target class is not in jdk.unsupported, > but rather in the source tree itself): > -addmods jdk.unsupported > -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED > -XaddReads:jdk.unsupported=ALL-UNNAMED > > Thanks, > -Aleksey > From Alan.Bateman at oracle.com Fri May 20 16:13:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 17:13:43 +0100 Subject: Weird use case: compiling against dummy sun.misc.* class In-Reply-To: <573F3358.1090209@oracle.com> References: <573F3358.1090209@oracle.com> Message-ID: <573F37B7.4030704@oracle.com> On 20/05/2016 16:55, Aleksey Shipilev wrote: > Hi, > > I have a weird use case in jcstress around @Contended. > > In order to support both JDK 8 and JDK 9 we build against *our own* > sun.misc.Contended and jdk.internal.annotations.Contended. This works > arguably well for both compiling and running with both JDK 8 and JDK 9: > the real annotation gets picked up from the JDK. > > However, since JDK 9b118 we cannot build anymore, because: > > LongResult1_jcstress.java:[3,13] error: Contended is not visible because > package sun.misc is not visible > > ...even though sun/misc/Contended.java is right here in my source tree. > Is there a magic incantation to make javac proceed? The usual tricks did > not help (probably because the target class is not in jdk.unsupported, > but rather in the source tree itself): > -addmods jdk.unsupported > -XaddExports:jdk.unsupported/sun.misc=ALL-UNNAMED > -XaddReads:jdk.unsupported=ALL-UNNAMED > jcstress is boot loader so I assume multi-release JARs are out of the question? So what is the javac command that you are using? If you are compiling sun/misc/Contented.java then I would expect to see `javac -Xmodule:jdk.unsupported` so that it is compiled "as if" part of the jdk.unsupported module. -Alan From alex.buckley at oracle.com Fri May 20 16:18:37 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 20 May 2016 09:18:37 -0700 Subject: Weird use case: compiling against dummy sun.misc.* class In-Reply-To: <573F3798.3040802@oracle.com> References: <573F3358.1090209@oracle.com> <573F3798.3040802@oracle.com> Message-ID: <573F38DD.5040009@oracle.com> On 5/20/2016 9:13 AM, Alex Buckley wrote: > If you have your own sun.misc.FOO on the classpath, then you DON'T want > a module exporting sun.misc to be readable, because that module is where > javac and the runtime will get sun.misc.* types from. So, no need to add > readability of the jdk.unsupported module which is not read by default > on JDK 9b118. I (sort of) take that back -- jdk.unsupported will be read at runtime since it exports at least one package without qualification, but I seem to recall something about not making it readable by default at compile time. Alex From chris.hegarty at oracle.com Fri May 20 16:30:27 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 May 2016 17:30:27 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> Message-ID: <65A4479F-69BC-424E-818D-C80E9E852493@oracle.com> On 20 May 2016, at 17:10, Alexandre (Shura) Iline wrote: > > Chris, > > Does the test need to use @modules for jdk.jartool and java.compiler? Yes, of course. Added, and updated in-place. http://cr.openjdk.java.net/~chegar/8156497.00/ -Chris. > > Shura > >> On May 20, 2016, at 8:55 AM, Chris Hegarty wrote: >> >> What do you get if you mix JEP 261 [1] with JEP 238 [2]? >> A Multi-release modular JAR. >> >> This issue proposes to add support to the jar tool for creating and >> updating modular JAR files with an optional module-info.class in the >> versioned section. >> >> MRJARs are intended to target multiple releases of the Java platform, so >> it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be >> able to declare a different set of dependencies on modules that are part >> of the Java platform. The reasoning here is that these are >> implementation details rather than parts of a module's API surface, and >> that one may well want to change them as the JDK itself evolves. The >> runtime already has support for loading from the versioned section. >> >> Specifically, a versioned module descriptor must be identical to the >> root module descriptor, with two exceptions: >> >> - A versioned descriptor can have different non-public `requires` >> clauses of platform ( `java.*` and `jdk.*` ) modules, and >> >> - A versioned descriptor can have different `uses` clauses, even of >> service types defined outside of `java.*` and `jdk.*` modules. >> >> http://cr.openjdk.java.net/~chegar/8156497.00/ >> >> Note: while there are some new test scenarios added, which give >> reasonable coverage, further tests will be added later. Steve has some >> additional jar tools support coming for easier creation of MRJARS. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/261 >> [2] http://openjdk.java.net/jeps/238 > From chris.hegarty at oracle.com Fri May 20 17:00:40 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 20 May 2016 18:00:40 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <573F34D0.5090100@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> <573F34D0.5090100@oracle.com> Message-ID: > On 20 May 2016, at 17:01, Jonathan Gibbons wrote: > > It would be good if (eventually) there were test cases involving the use > of MRM jars, both via the JarFile API and jar-fs file system, perhaps > extending to the use of MRM jars in javac as well. I agree. Just to note, the updated test in the webrev is already exercising the JarFile API, indirectly. Support for Modular JARs on the module path uses the JarFile constructor that accepts a JarFile.Release value when opening. The test exercises this when it verifies the newly created, or updated, JAR file by running the module?s entry point. But I agree, more test scenarios will need to be added. -Chris. > -- Jon > > On 05/20/2016 08:55 AM, Chris Hegarty wrote: >> What do you get if you mix JEP 261 [1] with JEP 238 [2]? >> A Multi-release modular JAR. >> >> This issue proposes to add support to the jar tool for creating and >> updating modular JAR files with an optional module-info.class in the >> versioned section. >> >> MRJARs are intended to target multiple releases of the Java platform, so >> it seems reasonable for a Multi-release modular JAR ( MRMJAR ) to be >> able to declare a different set of dependencies on modules that are part >> of the Java platform. The reasoning here is that these are >> implementation details rather than parts of a module's API surface, and >> that one may well want to change them as the JDK itself evolves. The >> runtime already has support for loading from the versioned section. >> >> Specifically, a versioned module descriptor must be identical to the >> root module descriptor, with two exceptions: >> >> - A versioned descriptor can have different non-public `requires` >> clauses of platform ( `java.*` and `jdk.*` ) modules, and >> >> - A versioned descriptor can have different `uses` clauses, even of >> service types defined outside of `java.*` and `jdk.*` modules. >> >> http://cr.openjdk.java.net/~chegar/8156497.00/ >> >> Note: while there are some new test scenarios added, which give >> reasonable coverage, further tests will be added later. Steve has some >> additional jar tools support coming for easier creation of MRJARS. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/261 >> [2] http://openjdk.java.net/jeps/238 > From aleksey.shipilev at oracle.com Fri May 20 17:02:50 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 20 May 2016 20:02:50 +0300 Subject: Weird use case: compiling against dummy sun.misc.* class In-Reply-To: <573F37B7.4030704@oracle.com> References: <573F3358.1090209@oracle.com> <573F37B7.4030704@oracle.com> Message-ID: <573F433A.6050007@oracle.com> On 05/20/2016 07:13 PM, Alan Bateman wrote: > On 20/05/2016 16:55, Aleksey Shipilev wrote: > jcstress is boot loader so I assume multi-release JARs are out of the > question? Yes, a simple workaround would be better than doing MR JARs at this point. We have >50 Mb JARs as it is, MR JARs would be at least twice as that if we ship JDK <=8 and JDK >=9 classes in the same package. > So what is the javac command that you are using? If you are compiling > sun/misc/Contented.java then I would expect to see `javac > -Xmodule:jdk.unsupported` so that it is compiled "as if" part of the > jdk.unsupported module. -Xmodule:jdk.unsupported definitely works, thanks! What are the drawbacks for enabling this? I can easily enable that globally for the entire project, but that would compile all project files as if in the jdk.unsupported module? I guess that does not matter if I don't produce/deploy the module as the build artifact. (Aside: by reading the javac source code, I discovered -XDnoModules, which also works, but hidden, unsupported, fragile, and scary) Thanks, -Aleksey From Alan.Bateman at oracle.com Fri May 20 18:03:00 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 19:03:00 +0100 Subject: Weird use case: compiling against dummy sun.misc.* class In-Reply-To: <573F433A.6050007@oracle.com> References: <573F3358.1090209@oracle.com> <573F37B7.4030704@oracle.com> <573F433A.6050007@oracle.com> Message-ID: <573F5154.3070208@oracle.com> On 20/05/2016 18:02, Aleksey Shipilev wrote: > : > -Xmodule:jdk.unsupported definitely works, thanks! > > What are the drawbacks for enabling this? I can easily enable that > globally for the entire project, but that would compile all project > files as if in the jdk.unsupported module? I guess that does not matter > if I don't produce/deploy the module as the build artifact. It would compile everyone as if part of this module. That module currently exports all its packages so there isn't a risk that you successfully compile with a reference to a type in a non-exported package. Also are you compiling jdk.internal.annotations.Contended too? That is in java.base. > > (Aside: by reading the javac source code, I discovered -XDnoModules, > which also works, but hidden, unsupported, fragile, and scary) > Jon has it on the list to remove, see JDK-8152785. -Alan From Alan.Bateman at oracle.com Fri May 20 20:57:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 21:57:55 +0100 Subject: 8152650: ModuleFinder.compose should accept varargs Message-ID: <573F7A53.8010700@oracle.com> There are several patches that didn't go in with the last update, the change to ModuleFinder.compose to use varargs was one of them. The other part to this is removing the empty() method as it is redundant. The changes are straight-forward: http://cr.openjdk.java.net/~alanb/8152650/webrev/ I dropped the changes to the langtools repo as Jon/Vicente have a patch in flight that drops empty(). Also the last round of jdeps updates removed the use of empty(). -Alan. From Alan.Bateman at oracle.com Fri May 20 21:24:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 22:24:41 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> Message-ID: <573F8099.2090006@oracle.com> On 20/05/2016 16:55, Chris Hegarty wrote: > : > > http://cr.openjdk.java.net/~chegar/8156497.00/ > > Note: while there are some new test scenarios added, which give > reasonable coverage, further tests will be added later. Steve has some > additional jar tools support coming for easier creation of MRJARS. > > The checks looks right. In checkModuleInfos then I assume you can use findFirst instead of collecting the module-infos into a set. The comment in computeHashes is confusing - too many "as" :-) You might want to re-read the error messages to see if they can be improved. For example "Invalid versioned module-info.class ..." might be better as "module-info.class in versioned section ...". Another one is "Unexpected versioned module-info.class without root module-info.class" where it might be clearer to say "module-info.class found in versions section of JAR file, no module-info.class found in root directory" or something like that. Looks like the copyright headers have the Classpath exception so now might be a good time to fix those. -Alan From Alan.Bateman at oracle.com Fri May 20 21:32:08 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 May 2016 22:32:08 +0100 Subject: Compact profiles broken? In-Reply-To: <002f01d1b1c7$37dddc30$a7999490$@apache.org> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> Message-ID: <573F8258.1040906@oracle.com> On 19/05/2016 13:08, Uwe Schindler wrote: > : > > FYI, this also explains why we did not see a compile failure about the java.xml.bind issue (see previous mails)! This only failed at runtime, because with Jigsaw, the java.xml.bind is not exposed by the root modules. But while compiling it seems to see all those classes, as its compiled against source/target 8 where the module system is ignored. So there is also room for improvement! Alan? > I think that's right as when compiling with -source/-target 8 they you are also specifying -bootclasspath (at least I assume you are) and so those types should be visible. -Alan. From uschindler at apache.org Fri May 20 22:22:43 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 21 May 2016 00:22:43 +0200 Subject: Compact profiles broken? In-Reply-To: <573F8258.1040906@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> Message-ID: <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> Hi, > > FYI, this also explains why we did not see a compile failure about the > java.xml.bind issue (see previous mails)! This only failed at runtime, because > with Jigsaw, the java.xml.bind is not exposed by the root modules. But while > compiling it seems to see all those classes, as its compiled against > source/target 8 where the module system is ignored. So there is also room > for improvement! Alan? > > > I think that's right as when compiling with -source/-target 8 they you > are also specifying -bootclasspath (at least I assume you are) and so > those types should be visible. No, we don't. But they were still visible to javac. But that?s fixed already in our build (we removed the class reference and we changed the build in Java 9, see below)! Please note: I changed the Lucene/Solr build to now use "-release" if it detects Java 9 (very easy with Apache Ant). Elasticsearch is still investiagting how to do this with Gradle... :( https://issues.apache.org/jira/browse/LUCENE-7292 Uwe From uschindler at apache.org Fri May 20 22:54:55 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 21 May 2016 00:54:55 +0200 Subject: Compact profiles broken? In-Reply-To: <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> Message-ID: <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> Hi Alan, Look here: import javax.xml.bind.DatatypeConverter; public class Test { public static void main(String... args) throws Exception { DatatypeConverter.parseBoolean("true"); } } $ javac Test.java Test.java:1: error: package javax.xml.bind does not exist import javax.xml.bind.DatatypeConverter; ^ Test.java:5: error: cannot find symbol DatatypeConverter.parseBoolean("true"); ^ symbol: variable DatatypeConverter location: class Test 2 errors $ javac -source 8 -target 8 Test.java warning: [options] bootstrap class path not set in conjunction with -source 1.8 1 warning Of course it also passes with -release 8, but thats very clear, because it uses ct.sym of older version. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of Uwe Schindler > Sent: Saturday, May 21, 2016 12:23 AM > To: 'Alan Bateman' ; jigsaw- > dev at openjdk.java.net > Subject: RE: Compact profiles broken? > > Hi, > > > > FYI, this also explains why we did not see a compile failure about the > > java.xml.bind issue (see previous mails)! This only failed at runtime, > because > > with Jigsaw, the java.xml.bind is not exposed by the root modules. But > while > > compiling it seems to see all those classes, as its compiled against > > source/target 8 where the module system is ignored. So there is also room > > for improvement! Alan? > > > > > I think that's right as when compiling with -source/-target 8 they you > > are also specifying -bootclasspath (at least I assume you are) and so > > those types should be visible. > > No, we don't. But they were still visible to javac. But that?s fixed already in > our build (we removed the class reference and we changed the build in Java > 9, see below)! > > Please note: I changed the Lucene/Solr build to now use "-release" if it > detects Java 9 (very easy with Apache Ant). Elasticsearch is still investiagting > how to do this with Gradle... :( > > https://issues.apache.org/jira/browse/LUCENE-7292 > > Uwe From mandy.chung at oracle.com Fri May 20 23:13:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 May 2016 16:13:01 -0700 Subject: 8152650: ModuleFinder.compose should accept varargs In-Reply-To: <573F7A53.8010700@oracle.com> References: <573F7A53.8010700@oracle.com> Message-ID: > On May 20, 2016, at 1:57 PM, Alan Bateman wrote: > > > There are several patches that didn't go in with the last update, the change to ModuleFinder.compose to use varargs was one of them. The other part to this is removing the empty() method as it is redundant. The changes are straight-forward: > http://cr.openjdk.java.net/~alanb/8152650/webrev/ This looks good to me. Mandy From stuart.marks at oracle.com Fri May 20 23:52:28 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 20 May 2016 16:52:28 -0700 Subject: Ping - Re: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: References: <56D5312E.9030508@oracle.com> <56D64FC0.2050609@oracle.com> <57076334.2080607@oracle.com> <570F5899.2000401@oracle.com> <6a3f7043-b831-b39c-c936-08a44328a8b0@oracle.com> Message-ID: On 5/16/16 1:18 AM, Felix Yang wrote: > please review the updated webrev, which remove not-suggested filesystem > modification and codebase stuff: > > http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/ Hi Felix, OK, this is looking much better and simpler. The big improvement is, as we had discussed, the creation of a common fixture for the tests. The tests then use the same fixture in different ways to exercise the different cases. This makes this more easily extensible to additional cases. First to be done are a few easy cleanups: * Since we're no longer using a registry, the starting and stopping of the registry process in the start- and shutdownRMIRegistry() methods is no longer necessary. They can be removed entirely, along with the rmiRegistry field. * The imports they required, along with some other unused import statements, can also be removed. * The fixture setup method, compileAll(), should be annotated @BeforeTest instead of @BeforeMethod. Compiling once at the beginning of the test should be sufficient. With these out of the way, my observation is that it's still really quite difficult to follow what the test is doing, particularly in setting up the text fixture. One reason for this is the repeated conversions between Path and String. Some places need Paths and some need Strings. Path elements are concatenated in some places with path.resolve(String) and string concatenation with File.separator or File.pathSeparator in others. In some cases, fields such as MODS_DIR = Paths.get("mods") are defined when in my opinion it'd just be better to use the string literal "mods" in a couple places. In any case I've taken the liberty of posting some cleanups to a branch in the sandbox. I've written a couple utilities to concatenate strings using File.separator and File.pathSeparator, and I've kept things mostly as strings, only converting to Paths when absolutely necessary. I've also renamed the directory of compiled classes as the "exploded" directory since that's sort-of the descriptive term in use for a hierarchy of individual class files. The sandbox branch is JDK-8078812-branch and the diff from your webrev can be viewed here: http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/befcc172e68e and the ModuleTest.java file (the only one I modified) can be viewed here: http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/befcc172e68e/test/java/rmi/module/ModuleTest.java It's up to you whether you want to accept my changes and continue from this point, or go in a different direction, but to my eye this is cleaner and easier to follow. * * * Now, finally, on to more substantive review issues. :-) One thing that seemed to be missing was that the application itself wasn't wrapped up into a jar file. I've added another Jar command that does this. Now we have the client, server, and app as separate hierarchies under the "exploded" directory, and as modules under the "mods" directory. I think the idea of having the "exploded" class hierarchy as well as jar files useful as modules is a good one. This will let you add cases, where different components are on the classpath or are loaded as modules, in addition to the two already present here. One issue here is that there's a module-info class for the app. This makes the app an actual named module (I think) as opposed to an automatic module like the client and server jar files. It seems like it would be preferable to be consistent and have them all be automatic modules. Given this arrangement, it should be pretty easy to have tests for any of the combinations we want of classpath vs modules. I guess there are 8 combinations: three components, each of which can be on the classpath or as a module. It's not clear to me that we need all 8 combinations. It's probably sufficient to have a reasonable subset. An idea for possible future expansion is to mix automatic modules with named modules. I'm not entirely sure how to do that. Perhaps one way is to have module-info files for all the components, and then create variant jar files with the module-info.class omitted. That way we'd have a modular jar, and then a "plain" jar (without module-info.class) that'd be suitable for use as an automatic module or to be put on the classpath. That'd be 3^3=27 combinations, which I certainly think is overkill. In any case, for this initial changeset, I think it's sufficient to test a few combinations of automatic modules vs. classpath. We can extend the cases to include named modules later. Please make a recommendation for some set of combinations and implement it, and then send it out for a final round of review. Thanks. s'marks From jonathan.gibbons at oracle.com Fri May 20 23:59:28 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 20 May 2016 16:59:28 -0700 Subject: Ping - Re: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: References: <56D5312E.9030508@oracle.com> <56D64FC0.2050609@oracle.com> <57076334.2080607@oracle.com> <570F5899.2000401@oracle.com> <6a3f7043-b831-b39c-c936-08a44328a8b0@oracle.com> Message-ID: <573FA4E0.2090608@oracle.com> Stuart, While I would agree on the use of one type, not two, for file paths, I would question the choice to use String instead of Path. If something is a file path, use the type system to say so, and use a Path. -- Jon On 05/20/2016 04:52 PM, Stuart Marks wrote: > On 5/16/16 1:18 AM, Felix Yang wrote: >> please review the updated webrev, which remove not-suggested >> filesystem >> modification and codebase stuff: >> >> http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/ > > Hi Felix, > > OK, this is looking much better and simpler. The big improvement is, > as we had discussed, the creation of a common fixture for the tests. > The tests then use the same fixture in different ways to exercise the > different cases. This makes this more easily extensible to additional > cases. > > First to be done are a few easy cleanups: > > * Since we're no longer using a registry, the starting and stopping of > the registry process in the start- and shutdownRMIRegistry() methods > is no longer necessary. They can be removed entirely, along with the > rmiRegistry field. > > * The imports they required, along with some other unused import > statements, can also be removed. > > * The fixture setup method, compileAll(), should be annotated > @BeforeTest instead of @BeforeMethod. Compiling once at the beginning > of the test should be sufficient. > > With these out of the way, my observation is that it's still really > quite difficult to follow what the test is doing, particularly in > setting up the text fixture. > > One reason for this is the repeated conversions between Path and > String. Some places need Paths and some need Strings. Path elements > are concatenated in some places with path.resolve(String) and string > concatenation with File.separator or File.pathSeparator in others. In > some cases, fields such as > > MODS_DIR = Paths.get("mods") > > are defined when in my opinion it'd just be better to use the string > literal "mods" in a couple places. > > In any case I've taken the liberty of posting some cleanups to a > branch in the sandbox. I've written a couple utilities to concatenate > strings using File.separator and File.pathSeparator, and I've kept > things mostly as strings, only converting to Paths when absolutely > necessary. I've also renamed the directory of compiled classes as the > "exploded" directory since that's sort-of the descriptive term in use > for a hierarchy of individual class files. > > The sandbox branch is JDK-8078812-branch and the diff from your webrev > can be viewed here: > > http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/befcc172e68e > > and the ModuleTest.java file (the only one I modified) can be viewed > here: > > > http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/befcc172e68e/test/java/rmi/module/ModuleTest.java > > > It's up to you whether you want to accept my changes and continue from > this point, or go in a different direction, but to my eye this is > cleaner and easier to follow. > > * * * > > Now, finally, on to more substantive review issues. :-) > > One thing that seemed to be missing was that the application itself > wasn't wrapped up into a jar file. I've added another Jar command that > does this. > > Now we have the client, server, and app as separate hierarchies under > the "exploded" directory, and as modules under the "mods" directory. > > I think the idea of having the "exploded" class hierarchy as well as > jar files useful as modules is a good one. This will let you add > cases, where different components are on the classpath or are loaded > as modules, in addition to the two already present here. > > One issue here is that there's a module-info class for the app. This > makes the app an actual named module (I think) as opposed to an > automatic module like the client and server jar files. It seems like > it would be preferable to be consistent and have them all be automatic > modules. > > Given this arrangement, it should be pretty easy to have tests for any > of the combinations we want of classpath vs modules. I guess there are > 8 combinations: three components, each of which can be on the > classpath or as a module. It's not clear to me that we need all 8 > combinations. It's probably sufficient to have a reasonable subset. > > An idea for possible future expansion is to mix automatic modules with > named modules. I'm not entirely sure how to do that. Perhaps one way > is to have module-info files for all the components, and then create > variant jar files with the module-info.class omitted. That way we'd > have a modular jar, and then a "plain" jar (without module-info.class) > that'd be suitable for use as an automatic module or to be put on the > classpath. That'd be 3^3=27 combinations, which I certainly think is > overkill. > > In any case, for this initial changeset, I think it's sufficient to > test a few combinations of automatic modules vs. classpath. We can > extend the cases to include named modules later. Please make a > recommendation for some set of combinations and implement it, and then > send it out for a final round of review. > > Thanks. > > s'marks From chris.hegarty at oracle.com Sat May 21 07:40:57 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 21 May 2016 08:40:57 +0100 Subject: 8152650: ModuleFinder.compose should accept varargs In-Reply-To: References: <573F7A53.8010700@oracle.com> Message-ID: <0C39917E-04C0-453D-98C4-0F64B9F364E7@oracle.com> > On 21 May 2016, at 00:13, Mandy Chung wrote: > > >> On May 20, 2016, at 1:57 PM, Alan Bateman wrote: >> >> >> There are several patches that didn't go in with the last update, the change to ModuleFinder.compose to use varargs was one of them. The other part to this is removing the empty() method as it is redundant. The changes are straight-forward: >> http://cr.openjdk.java.net/~alanb/8152650/webrev/ > > This looks good to me. +1 -Chris. From Alan.Bateman at oracle.com Sat May 21 09:54:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 May 2016 10:54:22 +0100 Subject: Compact profiles broken? In-Reply-To: <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> Message-ID: <5740304E.7050204@oracle.com> On 20/05/2016 23:54, Uwe Schindler wrote: > : > > > $ javac Test.java > Test.java:1: error: package javax.xml.bind does not exist > import javax.xml.bind.DatatypeConverter; > ^ > Test.java:5: error: cannot find symbol > DatatypeConverter.parseBoolean("true"); > ^ > symbol: variable DatatypeConverter > location: class Test > 2 errors Right, as expected. > > $ javac -source 8 -target 8 Test.java > warning: [options] bootstrap class path not set in conjunction with -source 1.8 > 1 warning > So the question is how should javac behave with -source/-target when -bootclasspath is not specified. This has always been a problematic usage because it means javac compiling for the older edition of the Java Language but with the APIs for the runtime that javac is running on. The warning was added in JDK 7 to try to bring attention to the problematic usage. I'm not sure if anything should change now to align it with the policy for root modules. This may be something that Jon can comment on. The right thing is of course to add -bootclasspath or just replace the usage with `javac -release 8`. -Alan From uschindler at apache.org Sat May 21 10:15:31 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 21 May 2016 12:15:31 +0200 Subject: Compact profiles broken? In-Reply-To: <5740304E.7050204@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> <5740304E.7050204@oracle.com> Message-ID: <001201d1b349$b737ffa0$25a7fee0$@apache.org> Hi, > > $ javac -source 8 -target 8 Test.java > > warning: [options] bootstrap class path not set in conjunction with -source > 1.8 > > 1 warning > > > So the question is how should javac behave with -source/-target when > -bootclasspath is not specified. This has always been a problematic > usage because it means javac compiling for the older edition of the Java > Language but with the APIs for the runtime that javac is running on. The > warning was added in JDK 7 to try to bring attention to the problematic > usage. I'm not sure if anything should change now to align it with the > policy for root modules. This may be something that Jon can comment on. > The right thing is of course to add -bootclasspath or just replace the > usage with `javac -release 8`. I agree, that's already done in Lucene since yesterday: https://issues.apache.org/jira/browse/LUCENE-7292 With that -release option, it of course does not fail, because it uses older ct.sym. The problem is now that you get no "warning" that the compilation may not work with Java 9. I would have expected to get a warning by javac where it says: "java.xml.bind" won't work by default in Java 9. Of course that's another discussion about pros and cons. Here is one problem, I figured out about "-release": Lot's of tools like Maven or Gradle make it really hard to pass "-release 8", because those tools have automatisms to automatically pass "source/target" to the javac compiler and you cannot do anything against that. Lucene/Solr is fine, because it uses Ant - but Elasticsearch has a hard time with Gradle: Gradle detects the Java version and passes the targeted release version as "1.8" automatically. If you add "-release 8", it fails because of incompatible command line arguments. In addition, most tools still use "1.8" for everything before 9. So if you make it pass "-release" using the build systems's variables, it would pass "1.8". Unfortunately, it only accepts "-release 8", not "-release 1.8". I'd suggest to add support for old version numbers in the same way like source/target accepts both "1.8" and "8". My proposal would be: If you start javac with "-source 1.8 -target 1.8" and don't pass a bootclasspath, it should switch to "-release 8" for convenience. What do you think? Alternatively allow source and target when passing release if it's not incompatible. Uwe From rcmuir at gmail.com Sat May 21 12:51:31 2016 From: rcmuir at gmail.com (Robert Muir) Date: Sat, 21 May 2016 08:51:31 -0400 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module In-Reply-To: <5739DD00.6070400@oracle.com> References: <02eb01d1af7f$31529c60$93f7d520$@apache.org> <5739DD00.6070400@oracle.com> Message-ID: On Mon, May 16, 2016 at 10:45 AM, Alan Bateman wrote: > > As to what is going on? The java.corba and the EE modules are no longer > resolved by default when compiling code in the unnamed module or where the > main class is loaded from class path. This means the types in these modules > are not visible. Nothing has been removed and if you run with `-addmods > java.se.ee` then each of the Java EE modules will be resolved as they were > previously. We have updated text for JEP 261 that describes this in more > detail, along with the rational. We will likely assess the impact of this > change later in JDK 9 but for now, there is easy workaround for those that > depend on these components being in the JDK. > Just a little followup: It seems most code impacted by this change is just using jaxb's base64 class. We've seen it not just with Solr but with cloud libraries like AWS SDK and so on. I'm not really suggesting anything here but just mentioning it as a possible "easy win" from usages I have seen. From Alan.Bateman at oracle.com Sun May 22 19:36:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 May 2016 20:36:38 +0100 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module In-Reply-To: References: <02eb01d1af7f$31529c60$93f7d520$@apache.org> <5739DD00.6070400@oracle.com> Message-ID: <57420A46.3000306@oracle.com> On 21/05/2016 13:51, Robert Muir wrote: > : > Just a little followup: It seems most code impacted by this change is > just using jaxb's base64 class. We've seen it not just with Solr but > with cloud libraries like AWS SDK and so on. > > I'm not really suggesting anything here but just mentioning it as a > possible "easy win" from usages I have seen. This is useful - thanks! We've also had a few tests in the JDK test suite that needlessly used javax.xml.bind.DatatypeConverter because it defines methods such as printHexBinary. -Alan From Alan.Bateman at oracle.com Sun May 22 19:47:19 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 22 May 2016 20:47:19 +0100 Subject: Compact profiles broken? In-Reply-To: <001201d1b349$b737ffa0$25a7fee0$@apache.org> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> <5740304E.7050204@oracle.com> <001201d1b349$b737ffa0$25a7fee0$@apache.org> Message-ID: <57420CC7.5080005@oracle.com> On 21/05/2016 11:15, Uwe Schindler wrote: > : > > My proposal would be: If you start javac with "-source 1.8 -target 1.8" and don't pass a bootclasspath, it should switch to "-release 8" for convenience. What do you think? Alternatively allow source and target when passing release if it's not incompatible. > I'd prefer to defer to Jan/Jon on this as they have a statement in JEP 247 to say that -release is incompatible with these options. In any case, it does feel like the tools needs to take -release into account. If -release is specified then Gradle shouldn't be added -source/-target. This may be a timing thing as JDK 9 is still in development and it always takes time for the tools to catch up. -Alan. From rcmuir at gmail.com Sun May 22 20:54:58 2016 From: rcmuir at gmail.com (Robert Muir) Date: Sun, 22 May 2016 16:54:58 -0400 Subject: Java 9 build 118 is hiding some documented & public classes from unnamed module In-Reply-To: <57420A46.3000306@oracle.com> References: <02eb01d1af7f$31529c60$93f7d520$@apache.org> <5739DD00.6070400@oracle.com> <57420A46.3000306@oracle.com> Message-ID: Yes, sorry to be clear, DatatypeConverter base64 stuff is the same class/methods I am seeing. On Sun, May 22, 2016 at 3:36 PM, Alan Bateman wrote: > > > On 21/05/2016 13:51, Robert Muir wrote: >> >> : >> Just a little followup: It seems most code impacted by this change is >> just using jaxb's base64 class. We've seen it not just with Solr but >> with cloud libraries like AWS SDK and so on. >> >> I'm not really suggesting anything here but just mentioning it as a >> possible "easy win" from usages I have seen. > > This is useful - thanks! We've also had a few tests in the JDK test suite > that needlessly used javax.xml.bind.DatatypeConverter because it defines > methods such as printHexBinary. > > -Alan From adinn at redhat.com Mon May 23 12:51:13 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 23 May 2016 13:51:13 +0100 Subject: Issue trying to use CORBA classes from javac Message-ID: <5742FCC1.6080304@redhat.com> Hi All, Red Hat's Transactions developers are having problems compiling their Corba-based code using the latest early access release of JDK9 (9-ea-b119). When the maven compiler plugin executes javac the compile fails because various corba packages are not visible. These are /not/ classes belonging to concealed packages. Some of the relevant error messages are shown in the first listing following my sig. Indeed, what is more strange is that we found that we could remedy the first of these errors by adding an explicit addExports for the relevant package to the javac arguments configured in the maven pom: -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED The second listing shows the difference this makes. Note that package org.omg.CORBA is now recognised. No doubt the same sort of fix would apply to remove the other errors but I don't understand why the use of addExports is necessary. When I run jmod describe on the java.corba module it tells me that org.omg.CORBA etc are already exported. So, java.corba does not seem to be a special sort of package different to all the others in the jmod dir. Is there some hidden switch which disables exports for this module? If so then is there a switch (equally as well hidden :-) which allows me to re-instate them? If not then does anyone have any idea why are we seeing these missing package errors? n.b. please keep Mike Musgrove in the cc for any replies as he is not subscribed to this list. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander Errors with no compiler X args: ------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[32,21] package org.omg.CORBA does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[33,21] package org.omg.CORBA does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30] package org.omg.PortableServer does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48] package org.omg.PortableServer.POAManagerPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41] package org.omg.PortableServer.POAPackage does not exist . . . Errors after using -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED -------------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30] package org.omg.PortableServer does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48] package org.omg.PortableServer.POAManagerPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41] package org.omg.PortableServer.POAPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[37,41] package org.omg.PortableServer.POAPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[39,32] org.omg.CORBA.ORBPackage.InvalidName is not visible because package org.omg.CORBA.ORBPackage is not visible [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[40,30] package org.omg.PortableServer does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[41,48] package org.omg.PortableServer.POAManagerPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/oa/core/POAImple.java:[36,32] org.omg.CORBA.ORBPackage.InvalidName is not visible because package org.omg.CORBA.ORBPackage is not visible . . . From sander.mak at luminis.eu Mon May 23 13:14:42 2016 From: sander.mak at luminis.eu (Sander Mak) Date: Mon, 23 May 2016 13:14:42 +0000 Subject: Issue trying to use CORBA classes from javac In-Reply-To: <5742FCC1.6080304@redhat.com> References: <5742FCC1.6080304@redhat.com> Message-ID: Hi Andrew, Michael, It's come up several times recently on this list, but this should clear up the issue: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html In short: use `-addmods java.corba` when compiling as of 9-ea-b119. Sander On 23 May 2016, at 14:51, Andrew Dinn > wrote: Hi All, Red Hat's Transactions developers are having problems compiling their Corba-based code using the latest early access release of JDK9 (9-ea-b119). When the maven compiler plugin executes javac the compile fails because various corba packages are not visible. These are /not/ classes belonging to concealed packages. Some of the relevant error messages are shown in the first listing following my sig. Indeed, what is more strange is that we found that we could remedy the first of these errors by adding an explicit addExports for the relevant package to the javac arguments configured in the maven pom: -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED The second listing shows the difference this makes. Note that package org.omg.CORBA is now recognised. No doubt the same sort of fix would apply to remove the other errors but I don't understand why the use of addExports is necessary. When I run jmod describe on the java.corba module it tells me that org.omg.CORBA etc are already exported. So, java.corba does not seem to be a special sort of package different to all the others in the jmod dir. Is there some hidden switch which disables exports for this module? If so then is there a switch (equally as well hidden :-) which allows me to re-instate them? If not then does anyone have any idea why are we seeing these missing package errors? n.b. please keep Mike Musgrove in the cc for any replies as he is not subscribed to this list. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander Errors with no compiler X args: ------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[32,21] package org.omg.CORBA does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[33,21] package org.omg.CORBA does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30] package org.omg.PortableServer does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48] package org.omg.PortableServer.POAManagerPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41] package org.omg.PortableServer.POAPackage does not exist . . . Errors after using -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED -------------------------------------------------------------------- [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[34,30] package org.omg.PortableServer does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[35,48] package org.omg.PortableServer.POAManagerPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[36,41] package org.omg.PortableServer.POAPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/ibmorb/oa/implementations/ibmorb_7_1.java:[37,41] package org.omg.PortableServer.POAPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[39,32] org.omg.CORBA.ORBPackage.InvalidName is not visible because package org.omg.CORBA.ORBPackage is not visible [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[40,30] package org.omg.PortableServer does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/internal/orbspecific/oa/implementations/POABase.java:[41,48] package org.omg.PortableServer.POAManagerPackage does not exist [ERROR] /home/mmusgrov/source/forks/narayana/master/ArjunaJTS/orbportability/classes/com/arjuna/orbportability/oa/core/POAImple.java:[36,32] org.omg.CORBA.ORBPackage.InvalidName is not visible because package org.omg.CORBA.ORBPackage is not visible . . . From Alan.Bateman at oracle.com Mon May 23 13:27:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 May 2016 14:27:54 +0100 Subject: Issue trying to use CORBA classes from javac In-Reply-To: <5742FCC1.6080304@redhat.com> References: <5742FCC1.6080304@redhat.com> Message-ID: <5743055A.8040002@oracle.com> On 23/05/2016 13:51, Andrew Dinn wrote: > Hi All, > > Red Hat's Transactions developers are having problems compiling their > Corba-based code using the latest early access release of JDK9 > (9-ea-b119). When the maven compiler plugin executes javac the compile > fails because various corba packages are not visible. These are /not/ > classes belonging to concealed packages. > > Some of the relevant error messages are shown in the first listing > following my sig. > > Indeed, what is more strange is that we found that we could remedy the > first of these errors by adding an explicit addExports for the relevant > package to the javac arguments configured in the maven pom: > > > -XaddExports:java.corba/org.omg.CORBA=ALL-UNNAMED > > > The second listing shows the difference this makes. Note that package > org.omg.CORBA is now recognised. > > > No doubt the same sort of fix would apply to remove the other errors but > I don't understand why the use of addExports is necessary. When I run > jmod describe on the java.corba module it tells me that org.omg.CORBA > etc are already exported. So, java.corba does not seem to be a special > sort of package different to all the others in the jmod dir. > > Is there some hidden switch which disables exports for this module? If > so then is there a switch (equally as well hidden :-) which allows me to > re-instate them? If not then does anyone have any idea why are we seeing > these missing package errors? > > n.b. please keep Mike Musgrove in the cc for any replies as he is not > subscribed to this list. > As Sander said, compiling with `-addmods java.corba` will ensure that the java.corba module is resolved. That said, I'm puzzled as to why -XaddExports makes a difference here, also by some of the types mentioned in the compilation messages as they aren't types in the JDK java.corba module. It would help if you or Michael could summarize what org.omg.** classes are in the environment. We've had problems off-list with another app server in this area too. In that case, it was augmenting the CORBA version in the JDK with additional classes as part of adding support for OMG APIs that the JDK version doesn't support. I don't know if we've got something similar here. If so, then bring a packed lunch as it will be a long day :-) -Alan From adinn at redhat.com Mon May 23 14:52:41 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 23 May 2016 15:52:41 +0100 Subject: Issue trying to use CORBA classes from javac In-Reply-To: <5743055A.8040002@oracle.com> References: <5742FCC1.6080304@redhat.com> <5743055A.8040002@oracle.com> Message-ID: <57431939.5090302@redhat.com> Hi Alan, On 23/05/16 14:27, Alan Bateman wrote: > As Sander said, compiling with `-addmods java.corba` will ensure that > the java.corba module is resolved. Thanks to you and Sanders for the advice. The relevant packages now appear. Could you explain how the disabled status of this module is arrived at in the final build? Is it excluded from the standard visible set by virtue of being listed in UPGRADEABLE_MODULES? I couldn't find anywhere else where any different treatment might be applied. > That said, I'm puzzled as to why -XaddExports makes a difference here, > also by some of the types mentioned in the compilation messages as they > aren't types in the JDK java.corba module. Hmm, perhaps -XaddExports requires a check to see that it does not add any exports unless the module has also been added. > It would help if you or Michael could summarize what org.omg.** classes > are in the environment. We've had problems off-list with another app > server in this area too. In that case, it was augmenting the CORBA > version in the JDK with additional classes as part of adding support for > OMG APIs that the JDK version doesn't support. I don't know if we've got > something similar here. If so, then bring a packed lunch as it will be a > long day :-) Mike is currently checking this -- his tweaking of the maven poms during testing may actually be responsible for some of the problems you noticed. So, he is checking that before he can be sure that this resolves the problems using the SE-provided orb. Essentially, for this build, where we are using the SE ORB, there should be no other org.omg.** classes in the env. However, we do interoperate with 2 other orbs and in those cases we currently provide the relevant CORBA classes via the classpath using -Xbootclasspath:p (which I have explained is no longer going to work). I think that this command line option was adopted merely in order to pre-empt the SE Corba classes in rt.jar. So, I am hoping that if we omit -addmod java.corba and add the alternatrive ORB jar to the system classpath then we will actually be safe. If you have reason to believe otherwise please let me know. Meanwhile, I'll get back to you if and when this turns into a packed lunch problem. Thanks for the help. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From chris.hegarty at oracle.com Mon May 23 15:05:23 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 May 2016 16:05:23 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <573F8099.2090006@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> <573F8099.2090006@oracle.com> Message-ID: <57431C33.8050901@oracle.com> On 20/05/16 22:24, Alan Bateman wrote: > On 20/05/2016 16:55, Chris Hegarty wrote: >> : >> >> http://cr.openjdk.java.net/~chegar/8156497.00/ >> >> Note: while there are some new test scenarios added, which give >> reasonable coverage, further tests will be added later. Steve has some >> additional jar tools support coming for easier creation of MRJARS. >> >> > The checks looks right. > > In checkModuleInfos then I assume you can use findFirst instead of > collecting the module-infos into a set. Yes, of course. done > The comment in computeHashes is confusing - too many "as" :-) Updated. > You might want to re-read the error messages to see if they can be > improved. For example "Invalid versioned module-info.class ..." might be > better as "module-info.class in versioned section ...". Another one is > "Unexpected versioned module-info.class without root module-info.class" > where it might be clearer to say "module-info.class found in versions > section of JAR file, no module-info.class found in root directory" or > something like that. That is certainly better. done. > Looks like the copyright headers have the Classpath exception so now > might be a good time to fix those. D'oh. Fixed. Updated webrev: http://cr.openjdk.java.net/~chegar/8156497.01/ -Chris. From Alan.Bateman at oracle.com Mon May 23 15:24:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 May 2016 16:24:13 +0100 Subject: Issue trying to use CORBA classes from javac In-Reply-To: <57431939.5090302@redhat.com> References: <5742FCC1.6080304@redhat.com> <5743055A.8040002@oracle.com> <57431939.5090302@redhat.com> Message-ID: <5743209D.7040604@oracle.com> On 23/05/2016 15:52, Andrew Dinn wrote: > : > > Thanks to you and Sanders for the advice. The relevant packages now appear. > > Could you explain how the disabled status of this module is arrived at > in the final build? Is it excluded from the standard visible set by > virtue of being listed in UPGRADEABLE_MODULES? I couldn't find anywhere > else where any different treatment might be applied. The section entitled "Root modules" in JEP 261 is the section to read. It's essentially that the java.se rather than java.se.ee is resolved by default when compiling code in the unnamed module or running and the initial class is loaded from the class path. > : > Hmm, perhaps -XaddExports requires a check to see that it does not add > any exports unless the module has also been added. javac and java behave slightly differently for this case, it's something we need to fix. > : > > However, we do interoperate with 2 other orbs and in those cases we > currently provide the relevant CORBA classes via the classpath using > -Xbootclasspath:p (which I have explained is no longer going to work). > I think that this command line option was adopted merely in order to > pre-empt the SE Corba classes in rt.jar. So, I am hoping that if we > omit -addmod java.corba and add the alternatrive ORB jar to the system > classpath then we will actually be safe. If you have reason to believe > otherwise please let me know. Meanwhile, I'll get back to you if and > when this turns into a packed lunch problem. Thanks for the help. If you have complete replacement/upgrade for the java.corba module then you can deploy on it on the class path and it should work. Alternatively you can deploy it on the upgrade module path to upgrade/override the module in the JDK (`-upgrademodulepath mycorba.jar -addmods java.corba`). On the other hand, if you adding to the JDK java.corba module then you'll need to use -Xpatch to augment or override what is in the JDK (`-Xpatch:java.corba=mycorbapatch.jar -addmods java.corba`). -Alan. From Alan.Bateman at oracle.com Mon May 23 15:27:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 May 2016 16:27:14 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <57431C33.8050901@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> <573F8099.2090006@oracle.com> <57431C33.8050901@oracle.com> Message-ID: <57432152.4030009@oracle.com> On 23/05/2016 16:05, Chris Hegarty wrote: > > D'oh. Fixed. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/8156497.01/ This version looks good. -Alan From Alan.Bateman at oracle.com Mon May 23 16:49:28 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 May 2016 17:49:28 +0100 Subject: 8157598: ModuleReader find returns incorrect URI when modular JAR is a multi-release JAR Message-ID: <57433498.8030703@oracle.com> JDK-8151542 changed the URL scheme for resources in the versioned section of a multi-release JAR. The ModuleReader API can be used to get a URI to a resource in a modular JAR and it needs a corresponding update to align with the JEP 238 update. The change is simple: http://cr.openjdk.java.net/~alanb/8157598/webrev/ There is still some remaining work to have modular JARs be multi-release JARs, jlink mostly, but it is otherwise aligning nicely. -Alan From jonathan.gibbons at oracle.com Mon May 23 16:59:11 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 May 2016 09:59:11 -0700 Subject: Compact profiles broken? In-Reply-To: <57420CC7.5080005@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> <5740304E.7050204@oracle.com> <001201d1b349$b737ffa0$25a7fee0$@apache.org> <57420CC7.5080005@oracle.com> Message-ID: <574336DF.5030600@oracle.com> On 05/22/2016 12:47 PM, Alan Bateman wrote: > On 21/05/2016 11:15, Uwe Schindler wrote: >> : >> >> My proposal would be: If you start javac with "-source 1.8 -target >> 1.8" and don't pass a bootclasspath, it should switch to "-release 8" >> for convenience. What do you think? Alternatively allow source and >> target when passing release if it's not incompatible. >> > I'd prefer to defer to Jan/Jon on this as they have a statement in JEP > 247 to say that -release is incompatible with these options. In any > case, it does feel like the tools needs to take -release into account. > If -release is specified then Gradle shouldn't be added > -source/-target. This may be a timing thing as JDK 9 is still in > development and it always takes time for the tools to catch up. > > -Alan. I think it would be reasonable to relax the restrictions on -source -target if they match the value for -release. The main goal here is to avoid having to resolve conflicts, but if there's no conflict, there's no problem. I think that allowing the older form of numbers (1.8, 1.7, etc) for older releases is OK too, in which case the check between -source and -release should (probably) be on the normalized numbers, i.e. although perverse, the intent of -source 1.7 -release 7 is clear. -- Jon From uschindler at apache.org Mon May 23 17:33:50 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 23 May 2016 19:33:50 +0200 Subject: Compact profiles broken? In-Reply-To: <574336DF.5030600@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> <5740304E.7050204@oracle.com> <001201d1b349$b737ffa0$25a7fee0$@apache.org> <57420CC7.5080005@oracle.com> <574336DF.5030600@oracle.com> Message-ID: <007f01d1b519$478abea0$d6a03be0$@apache.org> Hi, > I think it would be reasonable to relax the restrictions on -source > -target if they match the value for -release. The main goal here is to > avoid having to resolve conflicts, but if there's no conflict, there's > no problem. > > I think that allowing the older form of numbers (1.8, 1.7, etc) for > older releases is OK too, in which case the check between -source and > -release should (probably) be on the normalized numbers, i.e. although > perverse, the intent of -source 1.7 -release 7 is clear. That's exactly how I had this in mind! One other thing: The current warning about bootstrap classpath when you only have "-source -target" could maybe extended to notify the user that it might be better to use "-release" instead: warning: [options] bootstrap class path not set in conjunction with -source 1.8 Maybe change to something like: warning: [options] bootstrap class path not set in conjunction with -source 1.8; consider using -target 1.8 Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From jonathan.gibbons at oracle.com Mon May 23 17:54:55 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 May 2016 10:54:55 -0700 Subject: Compact profiles broken? In-Reply-To: <007f01d1b519$478abea0$d6a03be0$@apache.org> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> <5740304E.7050204@oracle.com> <001201d1b349$b737ffa0$25a7fee0$@apache.org> <57420CC7.5080005@oracle.com> <574336DF.5030600@oracle.com> <007f01d1b519$478abea0$d6a03be0$@apache.org> Message-ID: <574343EF.9070806@oracle.com> On 05/23/2016 10:33 AM, Uwe Schindler wrote: > Maybe change to something like: > > warning: [options] bootstrap class path not set in conjunction with -source 1.8; consider using -target 1.8 > > Uwe I presume you meant -release, not -target: warning: [options] bootstrap class path not set in conjunction with -source 1.8; consider using -release 1.8 From uschindler at apache.org Mon May 23 18:45:33 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 23 May 2016 18:45:33 +0000 Subject: Compact profiles broken? In-Reply-To: <574343EF.9070806@oracle.com> References: <573D5403.4020801@oracle.com> <573D632A.3040505@oracle.com> <034101d1b19d$84c638a0$8e52a9e0$@apache.org> <573D9683.9070908@oracle.com> <002f01d1b1c7$37dddc30$a7999490$@apache.org> <573F8258.1040906@oracle.com> <00e301d1b2e6$233a2390$69ae6ab0$@apache.org> <00fa01d1b2ea$a2cf21b0$e86d6510$@apache.org> <5740304E.7050204@oracle.com> <001201d1b349$b737ffa0$25a7fee0$@apache.org> <57420CC7.5080005@oracle.com> <574336DF.5030600@oracle.com> <007f01d1b519$478abea0$d6a03be0$@apache.org> <574343EF.9070806@oracle.com> Message-ID: <93802E80-49A3-4034-ACDA-E8B166A4D385@apache.org> Sorry, yes! Am 23. Mai 2016 19:54:55 MESZ, schrieb Jonathan Gibbons : > > >On 05/23/2016 10:33 AM, Uwe Schindler wrote: >> Maybe change to something like: >> >> warning: [options] bootstrap class path not set in conjunction with >-source 1.8; consider using -target 1.8 >> >> Uwe > >I presume you meant -release, not -target: > >warning: [options] bootstrap class path not set in conjunction with >-source 1.8; consider using -release 1.8 From chris.hegarty at oracle.com Mon May 23 20:27:25 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 May 2016 21:27:25 +0100 Subject: 8157598: ModuleReader find returns incorrect URI when modular JAR is a multi-release JAR In-Reply-To: <57433498.8030703@oracle.com> References: <57433498.8030703@oracle.com> Message-ID: > On 23 May 2016, at 17:49, Alan Bateman wrote: > > > JDK-8151542 changed the URL scheme for resources in the versioned section of a multi-release JAR. The ModuleReader API can be used to get a URI to a resource in a modular JAR and it needs a corresponding update to align with the JEP 238 update. The change is simple: > http://cr.openjdk.java.net/~alanb/8157598/webrev/ This looks good to me Alan. -Chris. From stuart.marks at oracle.com Mon May 23 21:31:41 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 23 May 2016 14:31:41 -0700 Subject: Ping - Re: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: <573FA4E0.2090608@oracle.com> References: <56D5312E.9030508@oracle.com> <56D64FC0.2050609@oracle.com> <57076334.2080607@oracle.com> <570F5899.2000401@oracle.com> <6a3f7043-b831-b39c-c936-08a44328a8b0@oracle.com> <573FA4E0.2090608@oracle.com> Message-ID: <3463040d-5d92-5718-4bf5-8fa429000d6c@oracle.com> On 5/20/16 4:59 PM, Jonathan Gibbons wrote: > While I would agree on the use of one type, not two, for file paths, I would > question the choice to use String instead of Path. If something is a file path, > use the type system to say so, and use a Path. Sure, either way will work. I had started with String because the data originates as strings, either from system properties or from string literals. I switched things around to see what things looked like, starting with Path and converting to String as necessary. Basically I declared the constants using Paths.get(). This meant fileJoin() could disappear, since Paths.get() can concatenate multiple elements. Paths.get() disappeared from several places inline, and was replaced with a chain of calls to resolve() in a couple others. I had to add toString() in a few places as well. The pathJoin() helper had to change a bit though. Formerly it concatenated strings with File.pathSeparator; now it has to convert Path objects to strings before doing so. The easiest way to do this was to use a short stream: static String pathJoin(Path... paths) { return Arrays.stream(paths) .map(Path::toString) .collect(Collectors.joining(File.pathSeparator)); } Overall I'd say six of one, half a dozen of the other. s'marks From jonathan.gibbons at oracle.com Mon May 23 22:34:49 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 23 May 2016 15:34:49 -0700 Subject: Ping - Re: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: <3463040d-5d92-5718-4bf5-8fa429000d6c@oracle.com> References: <56D5312E.9030508@oracle.com> <56D64FC0.2050609@oracle.com> <57076334.2080607@oracle.com> <570F5899.2000401@oracle.com> <6a3f7043-b831-b39c-c936-08a44328a8b0@oracle.com> <573FA4E0.2090608@oracle.com> <3463040d-5d92-5718-4bf5-8fa429000d6c@oracle.com> Message-ID: <57438589.5030402@oracle.com> On 05/23/2016 02:31 PM, Stuart Marks wrote: > On 5/20/16 4:59 PM, Jonathan Gibbons wrote: >> While I would agree on the use of one type, not two, for file paths, >> I would >> question the choice to use String instead of Path. If something is a >> file path, >> use the type system to say so, and use a Path. > > Sure, either way will work. I had started with String because the data > originates as strings, either from system properties or from string > literals. > > I switched things around to see what things looked like, starting with > Path and converting to String as necessary. Basically I declared the > constants using Paths.get(). This meant fileJoin() could disappear, > since Paths.get() can concatenate multiple elements. > > Paths.get() disappeared from several places inline, and was replaced > with a chain of calls to resolve() in a couple others. I had to add > toString() in a few places as well. > > The pathJoin() helper had to change a bit though. Formerly it > concatenated strings with File.pathSeparator; now it has to convert > Path objects to strings before doing so. The easiest way to do this > was to use a short stream: > > static String pathJoin(Path... paths) { > return Arrays.stream(paths) > .map(Path::toString) > .collect(Collectors.joining(File.pathSeparator)); > } > > Overall I'd say six of one, half a dozen of the other. > > s'marks Yes, and the example is small enough that maybe six of one really does balance half a dozen of the other. But as a general matter of style, I think it is preferable to use Path when you really want paths. That being said, it would be nice to have a method on the Paths API to create a search path from a series of Path objects. (your pathJoin method) -- Jon From sha.jiang at oracle.com Tue May 24 03:34:34 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 24 May 2016 11:34:34 +0800 Subject: (9) RFR: 8157633: Fix module dependencies for /com/* tests Message-ID: <7487bca1-544c-acda-6ee6-9e82ac007a52@oracle.com> Hi, Please review this small patch on fixing module dependencies for /com/* tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8157633 Webrev: http://cr.openjdk.java.net/~jjiang/8157633/webrev.00/ Best regards, John Jiang From mandy.chung at oracle.com Tue May 24 03:58:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 May 2016 20:58:03 -0700 Subject: 8157598: ModuleReader find returns incorrect URI when modular JAR is a multi-release JAR In-Reply-To: <57433498.8030703@oracle.com> References: <57433498.8030703@oracle.com> Message-ID: <67C19463-752D-452D-9855-831A94144D08@oracle.com> > On May 23, 2016, at 9:49 AM, Alan Bateman wrote: > > > JDK-8151542 changed the URL scheme for resources in the versioned section of a multi-release JAR. The ModuleReader API can be used to get a URI to a resource in a modular JAR and it needs a corresponding update to align with the JEP 238 update. The change is simple: > http://cr.openjdk.java.net/~alanb/8157598/webrev/ +1 Mandy From ivankrylov.java at gmail.com Tue May 24 05:26:28 2016 From: ivankrylov.java at gmail.com (Ivan Krylov) Date: Tue, 24 May 2016 08:26:28 +0300 Subject: RFR: JDK-8155786: Determine modules depending on upgradeable modules directly and indirectly In-Reply-To: <574301D9.6070307@oracle.com> References: <573C7EAC.7000108@oracle.com> <573DBC57.8040600@oracle.com> <3582c22c-fd37-b3a9-1ed9-f394b8126817@gmail.com> <574301D9.6070307@oracle.com> Message-ID: <1071b908-e5ca-01b6-7211-e119b1cfbd45@gmail.com> On 23/05/2016 16:12, Alan Bateman wrote: > On 23/05/2016 13:27, Ivan Krylov wrote: >> (perhaps this question belongs to the jigsaw-dev list..) >> How upgradable modules are defined. >> JEP-261 uses this term but does not define it AFAICS. > make/commons/Modules.gmk defines the list of upgradeable modules, look > for UPGRADEABLE_MODULES. A module is upgradeable can be > overridden/upgraded by deploying it on the upgrade module path > (`-upgrademodulepath` to javac or java). If you want to go into more > details then we should probably move the discussion to jigsaw-dev. > > -Alan I was looking not for the specific list of modules, but rather the definition of the concept. As for the list in that Modules.gmk - those 6 modules are the ones that since build 118 are not visible from unnamed modules. That is not a coincidence but I do not follow the logic either. Perhaps it was discussed here earlier - sorry about my ignorance then. Thanks, Ivan From mandy.chung at oracle.com Tue May 24 05:28:19 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 23 May 2016 22:28:19 -0700 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: <57431C33.8050901@oracle.com> References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> <573F8099.2090006@oracle.com> <57431C33.8050901@oracle.com> Message-ID: > On May 23, 2016, at 8:05 AM, Chris Hegarty wrote: > > Updated webrev: > http://cr.openjdk.java.net/~chegar/8156497.01/ Looks fine to me. Minor comment on the test, ?9? is hardcoded in a few places. It might be good to prepare for the future release e.g. use Runtime.version().major() + 1 instead. e.g. 257 "-C", mrjarDir.toString(), "META-INF/versions/9/module-info.class?, 760 Path versionSection = metaInfDir.resolve("versions").resolve("9"); Mandy From sha.jiang at oracle.com Tue May 24 06:35:23 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 24 May 2016 14:35:23 +0800 Subject: (9) RFR: 8157635: Fix module dependencies for /sun/* tests Message-ID: Hi, Please review this patch on fixing module dependencies for /sun/* tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8157635 Webrev: http://cr.openjdk.java.net/~jjiang/8157635/webrev.00/ Best regards, John Jiang From Alan.Bateman at oracle.com Tue May 24 06:49:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 07:49:36 +0100 Subject: (9) RFR: 8157633: Fix module dependencies for /com/* tests In-Reply-To: <7487bca1-544c-acda-6ee6-9e82ac007a52@oracle.com> References: <7487bca1-544c-acda-6ee6-9e82ac007a52@oracle.com> Message-ID: <5743F980.9050906@oracle.com> On 24/05/2016 04:34, John Jiang wrote: > Hi, > Please review this small patch on fixing module dependencies for > /com/* tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8157633 > Webrev: http://cr.openjdk.java.net/~jjiang/8157633/webrev.00/ Looks okay to me. -Alan From Alan.Bateman at oracle.com Tue May 24 06:59:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 07:59:47 +0100 Subject: (9) RFR: 8157635: Fix module dependencies for /sun/* tests In-Reply-To: References: Message-ID: <5743FBE3.9070709@oracle.com> On 24/05/2016 07:35, John Jiang wrote: > Hi, > Please review this patch on fixing module dependencies for /sun/* tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8157635 > Webrev: http://cr.openjdk.java.net/~jjiang/8157635/webrev.00/ Is dns/cname.sh really using module java.naming now? Just asking because I thought the name service provider mechanism has been removed so InetAddress can no longer be configured to use the JNDI DNS provider. In sun/security/provider/PolicyFile/Modules.java then it would be good to sort the module names as it will be others hard to maintain this list. -Alan From sha.jiang at oracle.com Tue May 24 07:02:17 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 24 May 2016 15:02:17 +0800 Subject: (9) RFR: 8157633: Fix module dependencies for /com/* tests In-Reply-To: <5743F980.9050906@oracle.com> References: <7487bca1-544c-acda-6ee6-9e82ac007a52@oracle.com> <5743F980.9050906@oracle.com> Message-ID: <4666501e-5733-cd3b-ac38-bd0c80762301@oracle.com> Hi Alan, Thanks for your review. And I have to update the copyright notice year [1]. [1] http://cr.openjdk.java.net/~jjiang/8157633/webrev.01 Best regards, John Jiang On 2016/5/24 14:49, Alan Bateman wrote: > > > On 24/05/2016 04:34, John Jiang wrote: >> Hi, >> Please review this small patch on fixing module dependencies for >> /com/* tests. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8157633 >> Webrev: http://cr.openjdk.java.net/~jjiang/8157633/webrev.00/ > Looks okay to me. > > -Alan > From chris.hegarty at oracle.com Tue May 24 08:31:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 May 2016 09:31:06 +0100 Subject: RFR 8156497: Add jar tool support for Multi-release modular JARs In-Reply-To: References: <648C6C23-0168-4E9E-9717-4FCEB328B1CD@oracle.com> <573F8099.2090006@oracle.com> <57431C33.8050901@oracle.com> Message-ID: On 24 May 2016, at 06:28, Mandy Chung wrote: > > >> On May 23, 2016, at 8:05 AM, Chris Hegarty wrote: >> >> Updated webrev: >> http://cr.openjdk.java.net/~chegar/8156497.01/ > > > Looks fine to me. Thanks Mandy. > Minor comment on the test, ?9? is hardcoded in a few places. It might be good to prepare for the future release e.g. use Runtime.version().major() + 1 instead. > > e.g. > 257 "-C", mrjarDir.toString(), "META-INF/versions/9/module-info.class?, > 760 Path versionSection = metaInfDir.resolve("versions").resolve("9?); Since this is already pushed, and I want to revisit the test once other MRJAR tooling support is in, I filed the following bug to track this: https://bugs.openjdk.java.net/browse/JDK-8157658 -Chris. From Alan.Bateman at oracle.com Tue May 24 10:11:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 11:11:48 +0100 Subject: RFR: JDK-8155786: Determine modules depending on upgradeable modules directly and indirectly In-Reply-To: <1071b908-e5ca-01b6-7211-e119b1cfbd45@gmail.com> References: <573C7EAC.7000108@oracle.com> <573DBC57.8040600@oracle.com> <3582c22c-fd37-b3a9-1ed9-f394b8126817@gmail.com> <574301D9.6070307@oracle.com> <1071b908-e5ca-01b6-7211-e119b1cfbd45@gmail.com> Message-ID: <574428E4.7030904@oracle.com> On 24/05/2016 06:26, Ivan Krylov wrote: > > I was looking not for the specific list of modules, but rather the > definition of the concept. > As for the list in that Modules.gmk - those 6 modules are the ones > that since build 118 are not visible from unnamed modules. > That is not a coincidence but I do not follow the logic either. > Perhaps it was discussed here earlier - sorry about my ignorance then. Think of upgradeable modules as the replacement for the Endorsed Standard Override Mechanism [1]. That mechanism was rarely used but it was the supported way for EE/app servers to deploy upgraded version of the endorsed APIs or standard technologies. The old mechanism was essentially -Xbootclasspath/p to override classes defined to the boot loader and so doesn't make sense with JDK 9. One reason is that most of these APIs, the APIs shared with Java EE in particular, have been moved from the boot loader and are not defined to the platform (formerly extension) class loader. The other reason is that the unit of replacement is at the level of module rather class files and so it much more reliable. If you want the Java EE version of the Java Transaction API for example, then you deploy it as a module to override (as opposed to augment) the module in the JDK. As regards the list of modules that are upgradeable then I assume this will be agreed in JSR 379 (the JSR for Java SE 9). As things currently stand in the implementation then the java.corba + EE modules can be upgraded. The other standard and JDK modules cannot be upgraded. There is a simple mechanism, bashed on the hash of the packaged module, to prevent accidental upgrading of modules that are not meant to be upgradeable. This is interesting at link time, for example, to prevent accidental linking of standard/JDK modules from different JDK builds. The hashes are checked in other phases too. Hope this helps, -Alan [1] http://docs.oracle.com/javase/8/docs/technotes/guides/standards/index.html From sha.jiang at oracle.com Tue May 24 10:59:29 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 24 May 2016 18:59:29 +0800 Subject: (9) RFR: 8157635: Fix module dependencies for /sun/* tests In-Reply-To: <5743FBE3.9070709@oracle.com> References: <5743FBE3.9070709@oracle.com> Message-ID: <667b02fa-41fb-4796-92c1-213ac3942e65@oracle.com> Hi Alan, On 2016/5/24 14:59, Alan Bateman wrote: > On 24/05/2016 07:35, John Jiang wrote: >> Hi, >> Please review this patch on fixing module dependencies for /sun/* tests. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8157635 >> Webrev: http://cr.openjdk.java.net/~jjiang/8157635/webrev.00/ > > Is dns/cname.sh really using module java.naming now? Just asking > because I thought the name service provider mechanism has been removed > so InetAddress can no longer be configured to use the JNDI DNS provider. CanonicalName.java, which is a part of the test, is using java.naming APIs. > In sun/security/provider/PolicyFile/Modules.java then it would be good > to sort the module names as it will be others hard to maintain this list. Please review the updated webrev [1]. [1] http://cr.openjdk.java.net/~jjiang/8157635/webrev.01 Best regards, John Jiang From Alan.Bateman at oracle.com Tue May 24 11:39:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 12:39:02 +0100 Subject: (9) RFR: 8157633: Fix module dependencies for /com/* tests In-Reply-To: <4666501e-5733-cd3b-ac38-bd0c80762301@oracle.com> References: <7487bca1-544c-acda-6ee6-9e82ac007a52@oracle.com> <5743F980.9050906@oracle.com> <4666501e-5733-cd3b-ac38-bd0c80762301@oracle.com> Message-ID: <57443D56.90609@oracle.com> On 24/05/2016 08:02, John Jiang wrote: > Hi Alan, > Thanks for your review. > And I have to update the copyright notice year [1]. > > [1] http://cr.openjdk.java.net/~jjiang/8157633/webrev.01 +1 From Alan.Bateman at oracle.com Tue May 24 11:40:56 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 12:40:56 +0100 Subject: (9) RFR: 8157635: Fix module dependencies for /sun/* tests In-Reply-To: <667b02fa-41fb-4796-92c1-213ac3942e65@oracle.com> References: <5743FBE3.9070709@oracle.com> <667b02fa-41fb-4796-92c1-213ac3942e65@oracle.com> Message-ID: <57443DC8.8030409@oracle.com> On 24/05/2016 11:59, John Jiang wrote: > >> Is dns/cname.sh really using module java.naming now? Just asking >> because I thought the name service provider mechanism has been >> removed so InetAddress can no longer be configured to use the JNDI >> DNS provider. > CanonicalName.java, which is a part of the test, is using java.naming > APIs. Ah okay, I was confused by the -Dsun.net.spi.nameservice.provider.1=dns,sun and now wonder whether this should be removed. > >> In sun/security/provider/PolicyFile/Modules.java then it would be >> good to sort the module names as it will be others hard to maintain >> this list. > Please review the updated webrev [1]. > > [1] http://cr.openjdk.java.net/~jjiang/8157635/webrev.01 Looks good. From adinn at redhat.com Tue May 24 15:51:05 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 May 2016 16:51:05 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <572C4E52.7000906@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C4E52.7000906@redhat.com> Message-ID: <57447869.8040104@redhat.com> Hi Alan, I have looked into the available options for providing my agent (or indeed any other agent) with access to Reflection and I think the available options, while usable, are a significant limitation wrt to the status quo. The simplest, safe way to allow an agent to acquire the privileged reflective access available to java.base classes (i.e. not subject to module checks) is for the agent to delegate to an extension class added to java.base using the command line option -Xpatch. Having played around with the relevant class loaders I think that command line option appears to be the only clean way to inveigle a class into a platform module (without begging the question by assuming that you already have the ability to use stuff in java.base such as Unsafe.defineClass). It certainly does not appear to me as if there is any non-ugly way to introduce a class into this module at run time. The only route I could find is temporarily redefining a public method of a java.base class so that it hands over a privileged instance (such as an Unsafe instance) to agent code, making a call to the redefined code, and then redefining the method so that it reverts back to normal. This could probably be made relatively safe (need to worry about recursive calls and ensure it is idempotent in case something else uses the API) but it's pretty tacky and it's a rather crazy path for all agents to have to follow to obtain privileged access. The reason I am unhappy with just using -Xpatch is that it has two usability problems and also raises the issue of redundancy. Firstly, agents can be loaded dynamically when they are needed. That's often true with Byteman where an agent is used to diagnose errant behaviour if and when it happens. If the agent can only do what it needs on the condition that the user had the foresight to start the JVM with the relevant -Xpath option then this is not going to happen in lots of cases. For repeatable problems that's fine -- just restart the JVM. But for intermittent problems this is exactly when you don't want to be kicked by hindsight for your lack of foresight. The second reason is that it requires using two jars, the extension jar used by -Xpatch and then the agent jar. This may sound a small thing but it's easy to underestimate how hard it is for many users to get this sort of thing right, especially when they have to configure access to the jar as a java command line option in a maven pom. I have managed to hide the loading of the Byteman agent jar when running Byteman-based tests in maven by auto-loading the agent dynamically -- all users need to do is ensure that the agent jar and the jar which implement the JTest/TestNG API extensions supported by Byteman are provided as test dependencies. However, I cannot automate setting java command line options from maven. This is going to confuse and, ultimately, lose a lot of users. The redundancy issue is that following this path will require every agent to do something similar, provide a -Xpatch jar, have it /safely/ export an accessor instance to the agent code (and only the agent code) and then have the agent redirect all operations requiring privlege to that accessor instance. Why do all agents need to do this when providing a setAccessible method on class Instrumentation will immediately give every agent a secure channel for doing the same thing? Given the impending guillotine for completion of JDK I intend to raise a JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as still needing a fix and suggesting a modification to Instrumenatation as the way to achieve it. If you have any other alternatives to the ones I have described for how to provide agents with java.base privileges I'd be very pleased to hear them and consider them as alternative implementations. Meanwhile I'll look at providing a webrev which implements what would be needed to provide the necessary capability via Instrumenatation. regards, Andrew Dinn ----------- From Alan.Bateman at oracle.com Tue May 24 18:28:38 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 May 2016 19:28:38 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <57447869.8040104@redhat.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C4E52.7000906@redhat.com> <57447869.8040104@redhat.com> Message-ID: <57449D56.4050403@oracle.com> On 24/05/2016 16:51, Andrew Dinn wrote: > : > > Given the impending guillotine for completion of JDK I intend to raise a > JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as > still needing a fix and suggesting a modification to Instrumenatation as > the way to achieve it. If you have any other alternatives to the ones I > have described for how to provide agents with java.base privileges I'd > be very pleased to hear them and consider them as alternative > implementations. Meanwhile I'll look at providing a webrev which > implements what would be needed to provide the necessary capability via > Instrumenatation. > Adding an API to make it easy to break encapsulation has concerns so this is why it was not included in the API updates to java.lang.instrument and JVM TI. For now, the issue is on the JSR issues list pending discussion/agreement on the right way to proceed. In general then we haven't seen problems with instrumentation for use-cases that instrument code to call into supporting classes (profilers for example). It just works for cases where the agent supporting classes are on the class path or boot class append path. It also works, via the API, for agent supporting classes in named module too. The use-cases that aren't directly supported at this time is where the agent want to access types in non-exported packages or where an agent instruments code that needs to access non-exported packages of other modules. Some of potential usages may fall out of the wash with #ReflectiveAccessToNonExportedTypes [1] but we'll have to see. The other approach that I mentioned is where the agent does load time instrumentation, in which case it it can add an initalizer to any non-interface class in the module (doesn't have to public, doesn't have to be in an exported package). The agent can trigger the initializer to run and export the module internals to the agent or other modules. This doesn't help the late binding agent case of course but we are down to a much small part of the problem space at that point. So no need to panic, it is on the issue list, and there will be tinkering of the design, implementation and API for a few months yet. -Alan. [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes From adinn at redhat.com Tue May 24 19:51:49 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 24 May 2016 20:51:49 +0100 Subject: #ReflectiveAccessByInstrumentationAgents In-Reply-To: <57449D56.4050403@oracle.com> References: <571617F4.5010007@oracle.com> <57166446.4080608@redhat.com> <57176AB6.4070800@oracle.com> <571881E0.2010900@redhat.com> <5718B500.2080806@gmail.com> <5718D656.4010805@oracle.com> <572B757B.6070801@redhat.com> <572BA417.3060700@oracle.com> <62231f35-dfbf-7794-922e-796af27d1575@gmail.com> <572C4E52.7000906@redhat.com> <57447869.8040104@redhat.com> <57449D56.4050403@oracle.com> Message-ID: <5744B0D5.6080207@redhat.com> On 24/05/16 19:28, Alan Bateman wrote: > On 24/05/2016 16:51, Andrew Dinn wrote: >> : >> >> Given the impending guillotine for completion of JDK I intend to raise a >> JIRA to mark the #ReflectiveAccessByInstrumentationAgents requirement as >> still needing a fix and suggesting a modification to Instrumenatation as >> the way to achieve it. If you have any other alternatives to the ones I >> have described for how to provide agents with java.base privileges I'd >> be very pleased to hear them and consider them as alternative >> implementations. Meanwhile I'll look at providing a webrev which >> implements what would be needed to provide the necessary capability via >> Instrumenatation. >> > Adding an API to make it easy to break encapsulation has concerns so > this is why it was not included in the API updates to > java.lang.instrument and JVM TI. For now, the issue is on the JSR issues > list pending discussion/agreement on the right way to proceed. Well, I'll be happy as long as issues in the JSR issues list actually are discussed, agreed and, where necessary, acted upon before JDK9 is released. > In general then we haven't seen problems with instrumentation for > use-cases that instrument code to call into supporting classes > (profilers for example). It just works for cases where the agent > supporting classes are on the class path or boot class append path. It > also works, via the API, for agent supporting classes in named module too. No, indeed that works in a pretty starightforward way -- but it's not the case I am concerned with. > The use-cases that aren't directly supported at this time is where the > agent want to access types in non-exported packages or where an agent > instruments code that needs to access non-exported packages of other > modules. Some of potential usages may fall out of the wash with > #ReflectiveAccessToNonExportedTypes [1] but we'll have to see. The other My interest is almost the same as #ReflectiveAccessToNonExportedTypes except the use case is restricted to providing the opportunity to call setAccessible to /agents only/ and even with very tight control over how the enabled AccessibleObject is is employed. I am very much /not/ interested in granting package access to arbitrary modules. If I have to use modules to do this then the only module which will be allowed to call AccessibleObject.setAccessible will be one local to the agent. Of course, I'd prefer to obtain the ability to perform this task via the Instrumentation instance since that's an already existing channel for granting special rights provided to every agent. Note that any AccessibleObject created and enabled by the agent is used either directly from agent code or from agent-generated bytecode. So, the agent can guarantee that this use is limited only to operations requested via the agent's control API. So, there is no risk of leakage of access beyond that requested of the agent itself by whoever installed the agent. > approach that I mentioned is where the agent does load time > instrumentation, in which case it it can add an initalizer to any > non-interface class in the module (doesn't have to public, doesn't have > to be in an exported package). The agent can trigger the initializer to > run and export the module internals to the agent or other modules. This > doesn't help the late binding agent case of course but we are down to a > much small part of the problem space at that point. Well, as I said, that's not really relevant in the case I am looking at where I don't intend to allow some arbitrary app code in any old package to be able to perform accesses. However, I'll also note that ignoring the dynamic agent case is not a small part of the problem space but a really significant loss of functionality. Usage of the Byteman agent is almost exclusively via dynamic loading. It is critical to Byteman's widespread use in testing since with command line loading the configuration of test cases from maven is extremely difficult to manage. Bymamic installation is also extremely important to most users as regards its acceptability for monitoring and diagnostics. Most users are very unhappy with having an agent present in normal running and only want it to be installed if and when things ave gone wrong. > So no need to panic, it is on the issue list, and there will be > tinkering of the design, implementation and API for a few months yet. Oh, it's ok, I'm not panicking. I just wanted to make sure that the issues list is going to be addressed before JDK9 is released. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From sundararajan.athijegannathan at oracle.com Wed May 25 06:09:20 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 11:39:20 +0530 Subject: RFR 8157801: spurious > character in the javadoc comment for ModuleEntry.java Message-ID: Please review http://cr.openjdk.java.net/~sundar/8157801/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8157801 Thanks, -Sundar From Alan.Bateman at oracle.com Wed May 25 06:11:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 07:11:21 +0100 Subject: RFR 8157801: spurious > character in the javadoc comment for ModuleEntry.java In-Reply-To: References: Message-ID: <57454209.4010705@oracle.com> On 25/05/2016 07:09, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8157801/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8157801 > Looks good. -Alan From sha.jiang at oracle.com Wed May 25 06:44:47 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 25 May 2016 14:44:47 +0800 Subject: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests Message-ID: Hi, Please review this patch on fixing module dependencies for /javax/* and /jdk/* tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8157783 Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/ Best regards, John Jiang From felix.yang at oracle.com Wed May 25 07:07:56 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 25 May 2016 15:07:56 +0800 Subject: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests In-Reply-To: References: Message-ID: <65a5bad2-a891-b768-e90c-253d739492e5@oracle.com> Hi John, I think changes for javax/* tests are not needed. Please have a look at the bug below. We are waiting for the next jtreg promotion to push the change, otherwise those tests will be skipped silently. https://bugs.openjdk.java.net/browse/JDK-8157135 -Felix On 2016/5/25 14:44, John Jiang wrote: > Hi, > Please review this patch on fixing module dependencies for /javax/* > and /jdk/* tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8157783 > Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/ > > Best regards, > John Jiang > From blackdrag at gmx.org Wed May 25 07:22:07 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 25 May 2016 09:22:07 +0200 Subject: creating proxies for interfaces with default methods Message-ID: <5745529F.60304@gmx.org> Hi all, so in earlier mails to this list I described a bit the problems I got into with the way Groovy produces proxies and handles default methods for those. I would like to see how the correct solution to this is supposed to be.... so we have code like m.sortReversed{a,b -> a.value <=> b.value}, where sortReversed is getting a Comperator and will call reversed() on it. This is not actual API, this is just an example! So far the logic has been, that kind of lambda {a,b -> a.value <=> b.value}, is called for every non-default, non-static method. If we are talking about functional interfaces, there is only one such method. The problem now arises what we are supposed to do if a default method is called. Dynamic proxies and invocation handlers won't do the job, as they do not provide an implementation of the interface I can call the default method on. Which means I have to use LambdaMetaFactory or maybe MethodHandleProxies. This may solve the problem... A second usage is for a kind of mocking. which means we have either a map of lambdas, or a lambda which can accept any kind of argument constellation...and now multiple non-static, non-default methods to proxy. We did use dynamic proxies for that in the past. I do not see how that can work with either of the three. So runtime generated classes is the only option left? Including all the problems with class loaders.... bye Jochen From sha.jiang at oracle.com Wed May 25 07:28:31 2016 From: sha.jiang at oracle.com (John Jiang) Date: Wed, 25 May 2016 15:28:31 +0800 Subject: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests In-Reply-To: <65a5bad2-a891-b768-e90c-253d739492e5@oracle.com> References: <65a5bad2-a891-b768-e90c-253d739492e5@oracle.com> Message-ID: <29ff8c42-9b5d-ecc8-9ca4-e99ba500ee06@oracle.com> OK, I'll update issue JDK-8157783 and its webrev to focus on /jdk/* only. Thanks! John Jiang On 2016/5/25 15:07, Felix Yang wrote: > Hi John, > > I think changes for javax/* tests are not needed. Please have a > look at the bug below. We are waiting for the next jtreg promotion to > push the change, otherwise those tests will be skipped silently. > > https://bugs.openjdk.java.net/browse/JDK-8157135 > > -Felix > On 2016/5/25 14:44, John Jiang wrote: >> Hi, >> Please review this patch on fixing module dependencies for /javax/* >> and /jdk/* tests. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8157783 >> Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/ >> >> Best regards, >> John Jiang >> > > From felix.yang at oracle.com Wed May 25 07:58:30 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 25 May 2016 15:58:30 +0800 Subject: Ping - Re: RFR 8078812, Test RMI with client and servers as modules In-Reply-To: References: <56D5312E.9030508@oracle.com> <56D64FC0.2050609@oracle.com> <57076334.2080607@oracle.com> <570F5899.2000401@oracle.com> <6a3f7043-b831-b39c-c936-08a44328a8b0@oracle.com> Message-ID: <893e0db2-e3c7-3bca-9116-4cb5bd29dddd@oracle.com> Hi Stuart, thanks for the comments. On 2016/5/21 7:52, Stuart Marks wrote: > On 5/16/16 1:18 AM, Felix Yang wrote: >> please review the updated webrev, which remove not-suggested >> filesystem >> modification and codebase stuff: >> >> http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.02/ > > Hi Felix, > > OK, this is looking much better and simpler. The big improvement is, > as we had discussed, the creation of a common fixture for the tests. > The tests then use the same fixture in different ways to exercise the > different cases. This makes this more easily extensible to additional > cases. > ... > > It's up to you whether you want to accept my changes and continue from > this point, or go in a different direction, but to my eye this is > cleaner and easier to follow. I accept your changes. 'pathJoin' looks cool. Though, I personally prefer to work with Path rather than strings (fileJoin). Any way, both ways are OK for me. Thanks, Felix > > * * * > > Now, finally, on to more substantive review issues. :-) > > One thing that seemed to be missing was that the application itself > wasn't wrapped up into a jar file. I've added another Jar command that > does this. > > Now we have the client, server, and app as separate hierarchies under > the "exploded" directory, and as modules under the "mods" directory. > > I think the idea of having the "exploded" class hierarchy as well as > jar files useful as modules is a good one. This will let you add > cases, where different components are on the classpath or are loaded > as modules, in addition to the two already present here. > > One issue here is that there's a module-info class for the app. This > makes the app an actual named module (I think) as opposed to an > automatic module like the client and server jar files. It seems like > it would be preferable to be consistent and have them all be automatic > modules. > > Given this arrangement, it should be pretty easy to have tests for any > of the combinations we want of classpath vs modules. I guess there are > 8 combinations: three components, each of which can be on the > classpath or as a module. It's not clear to me that we need all 8 > combinations. It's probably sufficient to have a reasonable subset. OK, I updated the test to a pure automatic modules version. Following subset is selected. Please suggest: 1. all in automatic modules 2. only dummy app as automatic module, and others are in classpath 3. client/server as automatic module, and dummy app is in classpath 4. server/app as automatic module, and client is in classpath Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8078812/webrev.03/ Thanks, Felix > > An idea for possible future expansion is to mix automatic modules with > named modules. I'm not entirely sure how to do that. Perhaps one way > is to have module-info files for all the components, and then create > variant jar files with the module-info.class omitted. That way we'd > have a modular jar, and then a "plain" jar (without module-info.class) > that'd be suitable for use as an automatic module or to be put on the > classpath. That'd be 3^3=27 combinations, which I certainly think is > overkill. How about try this in later expansion? All declared as named modules Compile to exploded dir as usual Enhance the JarUtil to accept a filter to exclude any file during creating jars (in this case, module-info.class) Then expand the test by specifying mp/cp with automatic modules, explored named modules -Felix > > In any case, for this initial changeset, I think it's sufficient to > test a few combinations of automatic modules vs. classpath. We can > extend the cases to include named modules later. Please make a > recommendation for some set of combinations and implement it, and then > send it out for a final round of review. > > Thanks. > > s'marks From chris.hegarty at oracle.com Wed May 25 08:02:14 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 09:02:14 +0100 Subject: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests In-Reply-To: References: Message-ID: > On 25 May 2016, at 07:44, John Jiang wrote: > > Hi, > Please review this patch on fixing module dependencies for /javax/* and /jdk/* tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8157783 > Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/ The changes to the non-javax tests look fine. Just a question on scripts, GetCallerClassTest.sh in this case, but the question is more general. You have added '@modules java.base/jdk.internal.reflect?, but what does this actually do? I can see the value of explicitly declaring that the script requires a particular set of modules, which could be used for test selection depending on the runtime. But the qualified export appears meaningless. Also, since the module is java.base, the dependency is implicit and not required. -Chris. From Alan.Bateman at oracle.com Wed May 25 09:40:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 10:40:15 +0100 Subject: 8156143: Module.getResourceAsStream throws unspecified SecurityException with module in custom Layer Message-ID: <574572FF.5000409@oracle.com> This is minor mismatch between javadoc + implementation when getResourceAsStream is called on a module in a custom Layer and access is denied by the security manager. It's a one line fix, this is mostly just a new test: http://cr.openjdk.java.net/~alanb/8156143/webrev/ Thanks, -Alan From Alan.Bateman at oracle.com Wed May 25 11:09:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 12:09:34 +0100 Subject: 8150668: Layer.defineModulesXXX with a Configuration containing java.base throws undocumented exception Message-ID: <574587EE.7090608@oracle.com> This is another small fix where the Layer javadoc doesn't make it clear that there can only be one "java.base" module in the VM. The enforcement has been there but it wasn't specified and there weren't tests for this scenario. http://cr.openjdk.java.net/~alanb/8150668/webrev/ Thanks, Alan. From Alan.Bateman at oracle.com Wed May 25 11:49:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 12:49:54 +0100 Subject: 8156142: ModuleReader instances don't always throw NPE for passed null args Message-ID: <57459162.8040200@oracle.com> Another trivial patch, this time it's the ModuleReader for the system modules is missing a null check so that it doesn't throw the expected NPE. The patch is to mostly just expand test coverage. http://cr.openjdk.java.net/~alanb/8156142/webrev/ Thanks, Alan From sundararajan.athijegannathan at oracle.com Wed May 25 11:56:43 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 25 May 2016 17:26:43 +0530 Subject: 8156142: ModuleReader instances don't always throw NPE for passed null args In-Reply-To: <57459162.8040200@oracle.com> References: <57459162.8040200@oracle.com> Message-ID: <0016ee37-f7dc-7e72-c3e8-48401ca5dc8a@oracle.com> Looks good -Sundar On 5/25/2016 5:19 PM, Alan Bateman wrote: > > Another trivial patch, this time it's the ModuleReader for the system > modules is missing a null check so that it doesn't throw the expected > NPE. The patch is to mostly just expand test coverage. > http://cr.openjdk.java.net/~alanb/8156142/webrev/ > > Thanks, > Alan From chris.hegarty at oracle.com Wed May 25 12:48:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 13:48:56 +0100 Subject: 8156142: ModuleReader instances don't always throw NPE for passed null args In-Reply-To: <57459162.8040200@oracle.com> References: <57459162.8040200@oracle.com> Message-ID: <3ED7BECD-24D4-4645-BC90-6DABB42A1B95@oracle.com> > On 25 May 2016, at 12:49, Alan Bateman wrote: > > > Another trivial patch, this time it's the ModuleReader for the system modules is missing a null check so that it doesn't throw the expected NPE. The patch is to mostly just expand test coverage. > http://cr.openjdk.java.net/~alanb/8156142/webrev/ I think this is fine. Does the @implSpec on release(ByteBuffer) need to be updated too? -Chris. From chris.hegarty at oracle.com Wed May 25 13:13:43 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 May 2016 14:13:43 +0100 Subject: 8150668: Layer.defineModulesXXX with a Configuration containing java.base throws undocumented exception In-Reply-To: <574587EE.7090608@oracle.com> References: <574587EE.7090608@oracle.com> Message-ID: <48579E7E-3F49-4945-80C8-C259235F67BB@oracle.com> > On 25 May 2016, at 12:09, Alan Bateman wrote: > > This is another small fix where the Layer javadoc doesn't make it clear that there can only be one "java.base" module in the VM. The enforcement has been there but it wasn't specified and there weren't tests for this scenario. > http://cr.openjdk.java.net/~alanb/8150668/webrev/ This looks fine. -Chris. From mandy.chung at oracle.com Wed May 25 17:20:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 10:20:22 -0700 Subject: 8150668: Layer.defineModulesXXX with a Configuration containing java.base throws undocumented exception In-Reply-To: <574587EE.7090608@oracle.com> References: <574587EE.7090608@oracle.com> Message-ID: <57565D7E-DAF7-418C-B166-D960CEFC8E49@oracle.com> > On May 25, 2016, at 4:09 AM, Alan Bateman wrote: > > > This is another small fix where the Layer javadoc doesn't make it clear that there can only be one "java.base" module in the VM. The enforcement has been there but it wasn't specified and there weren't tests for this scenario. > http://cr.openjdk.java.net/~alanb/8150668/webrev/ Looks good. Thanks Mandy From mandy.chung at oracle.com Wed May 25 17:51:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 10:51:55 -0700 Subject: 8156142: ModuleReader instances don't always throw NPE for passed null args In-Reply-To: <57459162.8040200@oracle.com> References: <57459162.8040200@oracle.com> Message-ID: <74CF4349-6C6C-42FE-94D2-329DC0EF3400@oracle.com> > On May 25, 2016, at 4:49 AM, Alan Bateman wrote: > > > Another trivial patch, this time it's the ModuleReader for the system modules is missing a null check so that it doesn't throw the expected NPE. The patch is to mostly just expand test coverage. > http://cr.openjdk.java.net/~alanb/8156142/webrev/ Looks good. Mandy From alex.buckley at oracle.com Wed May 25 18:08:26 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 25 May 2016 11:08:26 -0700 Subject: creating proxies for interfaces with default methods In-Reply-To: <5745529F.60304@gmx.org> References: <5745529F.60304@gmx.org> Message-ID: <5745EA1A.9000605@oracle.com> On 5/25/2016 12:22 AM, Jochen Theodorou wrote: > so in earlier mails to this list I described a bit the problems I got > into with the way Groovy produces proxies and handles default methods > for those. Pointer? The most relevant thread I could find was "Groovy with Jigsaw" from September 2015 but even it didn't talk much about proxies. > I would like to see how the correct solution to this is supposed to be.... > > so we have code like m.sortReversed{a,b -> a.value <=> b.value}, where > sortReversed is getting a Comperator and will call reversed() on it. > This is not actual API, this is just an example! So far the logic has > been, that kind of lambda {a,b -> a.value <=> b.value}, is called for > every non-default, non-static method. If we are talking about functional > interfaces, there is only one such method. The problem now arises what > we are supposed to do if a default method is called. What is m, some collection of reflection objects for methods? > Dynamic proxies and invocation handlers won't do the job, as they do not > provide an implementation of the interface I can call the default method > on. Is this a general limitation of j.l.r.Proxy? At first glance it doesn't seem like you're hitting an accessibility issue due to Jigsaw. > Which means I have to use LambdaMetaFactory or maybe > MethodHandleProxies. This may solve the problem... > > A second usage is for a kind of mocking. which means we have either a > map of lambdas, or a lambda which can accept any kind of argument > constellation...and now multiple non-static, non-default methods to > proxy. We did use dynamic proxies for that in the past. I do not see how > that can work with either of the three. > > So runtime generated classes is the only option left? Including all the > problems with class loaders.... This doesn't jibe with your closing comments in the "Groovy with Jigsaw" thread, where you said "We use our own class loaders in several areas, as well as runtime generated classes. ... generating classes using a new classloader is the standard for us." Alex From Alan.Bateman at oracle.com Wed May 25 18:36:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 25 May 2016 19:36:21 +0100 Subject: 8156142: ModuleReader instances don't always throw NPE for passed null args In-Reply-To: <3ED7BECD-24D4-4645-BC90-6DABB42A1B95@oracle.com> References: <57459162.8040200@oracle.com> <3ED7BECD-24D4-4645-BC90-6DABB42A1B95@oracle.com> Message-ID: <5745F0A5.8000808@oracle.com> On 25/05/2016 13:48, Chris Hegarty wrote: > : > I think this is fine. Does the @implSpec on release(ByteBuffer) need > to be updated too? > Fair point, it would be clearer if it said that it doesn't do anything except check for null. -Alan From blackdrag at gmx.org Wed May 25 20:12:05 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Wed, 25 May 2016 22:12:05 +0200 Subject: creating proxies for interfaces with default methods In-Reply-To: <5745EA1A.9000605@oracle.com> References: <5745529F.60304@gmx.org> <5745EA1A.9000605@oracle.com> Message-ID: <57460715.9020201@gmx.org> On 25.05.2016 20:08, Alex Buckley wrote: > On 5/25/2016 12:22 AM, Jochen Theodorou wrote: >> so in earlier mails to this list I described a bit the problems I got >> into with the way Groovy produces proxies and handles default methods >> for those. > > Pointer? The most relevant thread I could find was "Groovy with Jigsaw" > from September 2015 but even it didn't talk much about proxies. Look at "running Groovy on JDK9". There is a bit discussion about this, but not really much yet, since I had first to rethink the situation. I came to it because we hack the Lokup object to be able to do a invokespecial invocation for default methods.... and this does not work anymore in JDK9.... at least not in the way I did it. >> I would like to see how the correct solution to this is supposed to >> be.... >> >> so we have code like m.sortReversed{a,b -> a.value <=> b.value}, where >> sortReversed is getting a Comperator and will call reversed() on it. >> This is not actual API, this is just an example! So far the logic has >> been, that kind of lambda {a,b -> a.value <=> b.value}, is called for >> every non-default, non-static method. If we are talking about functional >> interfaces, there is only one such method. The problem now arises what >> we are supposed to do if a default method is called. > > What is m, some collection of reflection objects for methods? No, could be any collection or array. Groovy "adds" method to jdk classes. The code above is to be understood as Groovy code with similarities to Java code, but not a direct copy. >> Dynamic proxies and invocation handlers won't do the job, as they do not >> provide an implementation of the interface I can call the default method >> on. > > Is this a general limitation of j.l.r.Proxy? At first glance it doesn't > seem like you're hitting an accessibility issue due to Jigsaw. I have not found a way to call a default method with reflection. I have no instance of the interface in the Proxy, so what am I supposed to call the method on? Java can use an invokespecial on the interface method, but you cannot do an invokespecial with reflection (to me knowledge). With MethodHandles you can in theory do that - it exceeds my knowledge on what you actually call it, since there is no implementation. But then again, what if the default method calls another method of the interface? what is "this" there? >> Which means I have to use LambdaMetaFactory or maybe >> MethodHandleProxies. This may solve the problem... >> >> A second usage is for a kind of mocking. which means we have either a >> map of lambdas, or a lambda which can accept any kind of argument >> constellation...and now multiple non-static, non-default methods to >> proxy. We did use dynamic proxies for that in the past. I do not see how >> that can work with either of the three. >> >> So runtime generated classes is the only option left? Including all the >> problems with class loaders.... > > This doesn't jibe with your closing comments in the "Groovy with Jigsaw" > thread, where you said "We use our own class loaders in several areas, > as well as runtime generated classes. ... generating classes using a new > classloader is the standard for us." That?s because you do not know what tricks we have to leverage to get what we want. There are basically 3 cases: (1) scripts as classes, compiled at runtime (2) callsite caching using the pre invokedynamic code (3) proxies in certain cases (1) is less a problem so far.. largely because we ignore modules for now (2) will work only if "sun.reflect.MagicAccessorImpl" is accessible to us.... I doubt that is still the case in JDK9. So this will essentially run on reflection without runtime class generation for JDK9 (3) our own proxy generation code is not written to handle the case I am describing here, these are written to catch all invocations and redirect them to an dynamic implementation. The code can be extended to handle default methods differently as option of course, but it also means this proxy generator was not much in use in the past. I have problems foreseeing if it will work properly in all cases the dynamic proxy handles right now. I mean that already starts with the question of what classloader to use or what the parent to the class loader should be that is used. Well, maybe I worry to much, since the unnamed modules read all modules.... but I wonder if it will every be possible to have a module written in Groovy with private API, since the runtime still needs to access the unexported parts. bye Jochen From mandy.chung at oracle.com Wed May 25 20:32:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 13:32:36 -0700 Subject: creating proxies for interfaces with default methods In-Reply-To: <57460715.9020201@gmx.org> References: <5745529F.60304@gmx.org> <5745EA1A.9000605@oracle.com> <57460715.9020201@gmx.org> Message-ID: <40FF082E-4362-4ED2-AEA9-373593F8F0EC@oracle.com> > On May 25, 2016, at 1:12 PM, Jochen Theodorou wrote: > >>> Dynamic proxies and invocation handlers won't do the job, as they do not >>> provide an implementation of the interface I can call the default method >>> on. >> >> Is this a general limitation of j.l.r.Proxy? At first glance it doesn't >> seem like you're hitting an accessibility issue due to Jigsaw. I agree this is not related to jigsaw. The generated proxy class does not treat default methods any different than interface methods. The invocation handler will be the one handling it in its intended way. As you said, you need a way to invoke the default method with reflection for implementing such an invocation handler. > > I have not found a way to call a default method with reflection. I have no instance of the interface in the Proxy, so what am I supposed to call the method on? Java can use an invokespecial on the interface method, but you cannot do an invokespecial with reflection (to me knowledge). With MethodHandles you can in theory do that - it exceeds my knowledge on what you actually call it, since there is no implementation. But then again, what if the default method calls another method of the interface? what is "this" there? Perhaps you can ask this at mlvm-dev at openjdk.java.net Mandy From mandy.chung at oracle.com Wed May 25 21:25:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 14:25:27 -0700 Subject: 8156143: Module.getResourceAsStream throws unspecified SecurityException with module in custom Layer In-Reply-To: <574572FF.5000409@oracle.com> References: <574572FF.5000409@oracle.com> Message-ID: <1353B6B8-30D7-4981-AB36-605F8BD364CA@oracle.com> > On May 25, 2016, at 2:40 AM, Alan Bateman wrote: > > This is minor mismatch between javadoc + implementation when getResourceAsStream is called on a module in a custom Layer and access is denied by the security manager. It's a one line fix, this is mostly just a new test: > http://cr.openjdk.java.net/~alanb/8156143/webrev/ Looks okay. On a related note (nothing to deal with this issue), the javadoc of ClassLoader::findResource(String) should be updated to reflect that it returns null if access to the resource is denied by the security manager, at least for built-in class loader as an implementation note. Mandy From kevin.rushforth at oracle.com Wed May 25 22:38:29 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 May 2016 15:38:29 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 Message-ID: <57462965.7070806@oracle.com> Please review the following: https://bugs.openjdk.java.net/browse/JDK-8131888 http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). Details are in JBS. -- Kevin From mandy.chung at oracle.com Thu May 26 00:43:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 25 May 2016 17:43:53 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57462965.7070806@oracle.com> References: <57462965.7070806@oracle.com> Message-ID: <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> > On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8131888 > http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ > > This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. FXCanvas.java 247 System.err.println("FXCanvas class successfully initialized?); 294 System.err.println("FXCanvas: FX platform is initlialized?); PlatformImpl.java 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); 309 ex.printStackTrace(); I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. ModuleHelper.java 57 // ignore This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. Otherwise, look fine to me. Mandy From amy.lu at oracle.com Thu May 26 05:10:19 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 26 May 2016 13:10:19 +0800 Subject: JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt Message-ID: <5746853B.8010203@oracle.com> tools/jimage/JImageTest.java This test is in ProblemList.txt with related bugid JDK-8150975. JDK-8150975 has been closed since previously reported image recreate issue now is not an issue anymore because the support for jimage recreate has been removed in JDK-8154090, in which test also updated. This patch is to remove mentioned test from ProblemList.txt. bug: https://bugs.openjdk.java.net/browse/JDK-8157663 webrev: http://cr.openjdk.java.net/~amlu/8157663/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 +++ new/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 @@ -390,7 +390,5 @@ # core_tools -tools/jimage/JImageTest.java 8150975 linux-i586,windows-i586 - ############################################################################ From joe.darcy at oracle.com Thu May 26 05:13:36 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 25 May 2016 22:13:36 -0700 Subject: JDK 9 RFR of JDK-8157663: Remove tools/jimage/JImageTest.java from ProblemList.txt In-Reply-To: <5746853B.8010203@oracle.com> References: <5746853B.8010203@oracle.com> Message-ID: <721a07e5-e236-2d30-eed0-71b2b46d0d6b@oracle.com> Looks fine Amy; thanks, -Joe On 5/25/2016 10:10 PM, Amy Lu wrote: > tools/jimage/JImageTest.java > > This test is in ProblemList.txt with related bugid JDK-8150975. > JDK-8150975 has been closed since previously reported image recreate > issue now is not an issue anymore because the support for jimage > recreate has been removed in JDK-8154090, in which test also updated. > > This patch is to remove mentioned test from ProblemList.txt. > > bug: https://bugs.openjdk.java.net/browse/JDK-8157663 > webrev: http://cr.openjdk.java.net/~amlu/8157663/webrev.00/ > > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 > +++ new/test/ProblemList.txt 2016-05-26 12:45:36.000000000 +0800 > @@ -390,7 +390,5 @@ > > # core_tools > > -tools/jimage/JImageTest.java 8150975 linux-i586,windows-i586 > - > ############################################################################ > > > > From blackdrag at gmx.org Thu May 26 06:04:49 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 26 May 2016 08:04:49 +0200 Subject: creating proxies for interfaces with default methods In-Reply-To: <40FF082E-4362-4ED2-AEA9-373593F8F0EC@oracle.com> References: <5745529F.60304@gmx.org> <5745EA1A.9000605@oracle.com> <57460715.9020201@gmx.org> <40FF082E-4362-4ED2-AEA9-373593F8F0EC@oracle.com> Message-ID: <57469201.2070201@gmx.org> On 25.05.2016 22:32, Mandy Chung wrote: > >> On May 25, 2016, at 1:12 PM, Jochen Theodorou wrote: >> >>>> Dynamic proxies and invocation handlers won't do the job, as they do not >>>> provide an implementation of the interface I can call the default method >>>> on. >>> >>> Is this a general limitation of j.l.r.Proxy? At first glance it doesn't >>> seem like you're hitting an accessibility issue due to Jigsaw. > > I agree this is not related to jigsaw. > > The generated proxy class does not treat default methods any different than interface methods. The invocation handler will be the one handling it in its intended way. As you said, you need a way to invoke the default method with reflection for implementing such an invocation handler. you cannot invoke the default method with reflection without implementation of the interface >> I have not found a way to call a default method with reflection. I have no instance of the interface in the Proxy, so what am I supposed to call the method on? Java can use an invokespecial on the interface method, but you cannot do an invokespecial with reflection (to me knowledge). With MethodHandles you can in theory do that - it exceeds my knowledge on what you actually call it, since there is no implementation. But then again, what if the default method calls another method of the interface? what is "this" there? > > Perhaps you can ask this at mlvm-dev at openjdk.java.net It does only partially matter, since I cannot normally get a Lookup object, that allows me to do that. And the way I did that, does not work anymore in JDK9. But maybe not because of jigsaw bye Jochen From Alan.Bateman at oracle.com Thu May 26 07:03:15 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 May 2016 08:03:15 +0100 Subject: creating proxies for interfaces with default methods In-Reply-To: <57469201.2070201@gmx.org> References: <5745529F.60304@gmx.org> <5745EA1A.9000605@oracle.com> <57460715.9020201@gmx.org> <40FF082E-4362-4ED2-AEA9-373593F8F0EC@oracle.com> <57469201.2070201@gmx.org> Message-ID: <57469FB3.9060007@oracle.com> On 26/05/2016 07:04, Jochen Theodorou wrote: > > you cannot invoke the default method with reflection without > implementation of the interface It sounds like you want to invoke the default method without a receiver. This does seem like sorcery for mlvm-dev. -Alan From Alan.Bateman at oracle.com Thu May 26 07:14:44 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 May 2016 08:14:44 +0100 Subject: 8156143: Module.getResourceAsStream throws unspecified SecurityException with module in custom Layer In-Reply-To: <1353B6B8-30D7-4981-AB36-605F8BD364CA@oracle.com> References: <574572FF.5000409@oracle.com> <1353B6B8-30D7-4981-AB36-605F8BD364CA@oracle.com> Message-ID: <5746A264.3040400@oracle.com> On 25/05/2016 22:25, Mandy Chung wrote: > On a related note (nothing to deal with this issue), the javadoc of ClassLoader::findResource(String) should be updated to reflect that it returns null if access to the resource is denied by the security manager, at least for built-in class loader as an implementation note. > > I agree as it is long standing (but unspecified) behavior. -Alan. From blackdrag at gmx.org Thu May 26 07:21:15 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Thu, 26 May 2016 09:21:15 +0200 Subject: creating proxies for interfaces with default methods In-Reply-To: <57469FB3.9060007@oracle.com> References: <5745529F.60304@gmx.org> <5745EA1A.9000605@oracle.com> <57460715.9020201@gmx.org> <40FF082E-4362-4ED2-AEA9-373593F8F0EC@oracle.com> <57469201.2070201@gmx.org> <57469FB3.9060007@oracle.com> Message-ID: <5746A3EB.4010607@gmx.org> On 26.05.2016 09:03, Alan Bateman wrote: > On 26/05/2016 07:04, Jochen Theodorou wrote: >> >> you cannot invoke the default method with reflection without >> implementation of the interface > It sounds like you want to invoke the default method without a receiver. > This does seem like sorcery for mlvm-dev. the problem is, that if I use a dynamic proxy as receiver and reflection as invocation method, I will end up in the invocation hadler again. bye Jochen From sha.jiang at oracle.com Thu May 26 07:50:51 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 26 May 2016 15:50:51 +0800 Subject: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests In-Reply-To: References: Message-ID: <404d5a33-dd99-7189-c951-ec084a070682@oracle.com> Hi Chris, Thanks for your comment! Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.01 It excludes the /javax/* tests. Best regards, John Jiang On 2016/5/25 16:02, Chris Hegarty wrote: >> On 25 May 2016, at 07:44, John Jiang wrote: >> >> Hi, >> Please review this patch on fixing module dependencies for /javax/* and /jdk/* tests. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8157783 >> Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/ > The changes to the non-javax tests look fine. > > Just a question on scripts, GetCallerClassTest.sh in this case, but the > question is more general. > > You have added '@modules java.base/jdk.internal.reflect?, but what > does this actually do? I can see the value of explicitly declaring that > the script requires a particular set of modules, which could be used > for test selection depending on the runtime. But the qualified export > appears meaningless. > > Also, since the module is java.base, the dependency is implicit and > not required. > > -Chris. From chris.hegarty at oracle.com Thu May 26 07:54:28 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 May 2016 08:54:28 +0100 Subject: (9) RFR: 8157783: Fix module dependencies for /javax/* and /jdk/* tests In-Reply-To: <404d5a33-dd99-7189-c951-ec084a070682@oracle.com> References: <404d5a33-dd99-7189-c951-ec084a070682@oracle.com> Message-ID: > On 26 May 2016, at 08:50, John Jiang wrote: > > Hi Chris, > Thanks for your comment! > Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.01 I?m fine with the changes. -Chris. > It excludes the /javax/* tests. > > Best regards, > John Jiang > > > On 2016/5/25 16:02, Chris Hegarty wrote: >>> On 25 May 2016, at 07:44, John Jiang wrote: >>> >>> Hi, >>> Please review this patch on fixing module dependencies for /javax/* and /jdk/* tests. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8157783 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8157783/webrev.00/ >> The changes to the non-javax tests look fine. >> >> Just a question on scripts, GetCallerClassTest.sh in this case, but the >> question is more general. >> >> You have added '@modules java.base/jdk.internal.reflect?, but what >> does this actually do? I can see the value of explicitly declaring that >> the script requires a particular set of modules, which could be used >> for test selection depending on the runtime. But the qualified export >> appears meaningless. >> >> Also, since the module is java.base, the dependency is implicit and >> not required. >> >> -Chris. > From felix.yang at oracle.com Thu May 26 10:58:41 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 26 May 2016 18:58:41 +0800 Subject: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds Message-ID: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> Hi there, please review the following change. Webrev: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8157931 The test "jdk/internal/jrtfs/Basic.java" fails when testing with exploded builds. It tried to access jrt-fs.jar which not exists in exploded builds. In this fix, those tests will be skipped, if the build is identified as an exploded one. And please note that, a bug (JDK-8157936 ) was found with the updated test. Thanks, Felix From james.laskey at oracle.com Thu May 26 11:11:05 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 26 May 2016 08:11:05 -0300 Subject: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds In-Reply-To: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> References: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> Message-ID: +1 > On May 26, 2016, at 7:58 AM, Felix Yang wrote: > > Hi there, > > please review the following change. > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157931 > > > The test "jdk/internal/jrtfs/Basic.java" fails when testing with exploded builds. It tried to access jrt-fs.jar which not exists in exploded builds. > > In this fix, those tests will be skipped, if the build is identified as an exploded one. And please note that, a bug (JDK-8157936 ) was found with the updated test. > > Thanks, > > Felix > From sundararajan.athijegannathan at oracle.com Thu May 26 11:16:00 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 26 May 2016 16:46:00 +0530 Subject: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds In-Reply-To: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> References: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> Message-ID: +1 On 5/26/2016 4:28 PM, Felix Yang wrote: > Hi there, > > please review the following change. > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157931 > > > The test "jdk/internal/jrtfs/Basic.java" fails when testing with > exploded builds. It tried to access jrt-fs.jar which not exists in > exploded builds. > > In this fix, those tests will be skipped, if the build is identified > as an exploded one. And please note that, a bug (JDK-8157936 > ) was found with the > updated test. > > Thanks, > > Felix > From Alan.Bateman at oracle.com Thu May 26 11:22:02 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 May 2016 12:22:02 +0100 Subject: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds In-Reply-To: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> References: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> Message-ID: <5746DC5A.8090304@oracle.com> On 26/05/2016 11:58, Felix Yang wrote: > Hi there, > > please review the following change. > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/ > The approach looks okay but would be good to do a few clean ups before pushing this. One thing is the indentation in setup() is messed up by the removal of try/catch. I also think it should use notExists rather than !exists (remember !exists will return true if the existence cannot be determined so the test should fail for this case). testKnownClassFiles now prints the file size, I assume that is for another issue. -Alan From forax at univ-mlv.fr Thu May 26 12:00:32 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 26 May 2016 14:00:32 +0200 (CEST) Subject: creating proxies for interfaces with default methods In-Reply-To: <5746A3EB.4010607@gmx.org> References: <5745529F.60304@gmx.org> <5745EA1A.9000605@oracle.com> <57460715.9020201@gmx.org> <40FF082E-4362-4ED2-AEA9-373593F8F0EC@oracle.com> <57469201.2070201@gmx.org> <57469FB3.9060007@oracle.com> <5746A3EB.4010607@gmx.org> Message-ID: <267151581.2143722.1464264032036.JavaMail.zimbra@u-pem.fr> Not if you use Lookup.findSpecial() [1] Anyway, you can not use it because you can not get the Lookup object associated with the proxy class. That's why i've written the Proxy2 library [2]. so the solutions are either you use the Proxy2 library (which doesn't work with jdk9 yet) or we retrofit the interface InvocationHandler to take a supplementary Lookup object. regards, R?mi [1] http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandles.Lookup.html#findSpecial%28java.lang.Class,%20java.lang.String,%20java.lang.invoke.MethodType,%20java.lang.Class%29 [2] https://github.com/forax/proxy2 ----- Mail original ----- > De: "Jochen Theodorou" > ?: "Alan Bateman" > Cc: "jigsaw-dev" > Envoy?: Jeudi 26 Mai 2016 09:21:15 > Objet: Re: creating proxies for interfaces with default methods > > On 26.05.2016 09:03, Alan Bateman wrote: > > On 26/05/2016 07:04, Jochen Theodorou wrote: > >> > >> you cannot invoke the default method with reflection without > >> implementation of the interface > > It sounds like you want to invoke the default method without a receiver. > > This does seem like sorcery for mlvm-dev. > > the problem is, that if I use a dynamic proxy as receiver and reflection > as invocation method, I will end up in the invocation hadler again. > > bye Jochen > > From kevin.rushforth at oracle.com Thu May 26 14:50:01 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 May 2016 07:50:01 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> Message-ID: <57470D19.6000303@oracle.com> Mandy, Thanks for your feedback. Comments inline. Mandy Chung wrote: > >> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8131888 >> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >> >> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >> > > The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. > Filenames with two dots are a little odd, so I went with the dash. It doesn't much matter, though. > I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. > > FXCanvas.java > 247 System.err.println("FXCanvas class successfully initialized?); > 294 System.err.println("FXCanvas: FX platform is initlialized?); > > PlatformImpl.java > 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); > 309 ex.printStackTrace(); > Right. I noted this in the JBS evaluation and will remove all when I post the final webrev. > I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. > I had considered adding the check for the module name, but was concerned about the OSGi case, as mentioned by Tom Schindl in the bug report, in which they add the jar file via a custom classloader; the concern is that there is no support in the JDK to make it an automatic module in this case. I will file a follow-up issue to improve the integrity checking. > ModuleHelper.java > 57 // ignore > > This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. > Actually, we can't do this yet, because we still build and test with JDK 9 build 109 which doesn't have support for the module system. Until we upgrade to a JDK with the module system enabled we need this to be a silent no-op or all of our tests will fail. -- Kevin > Otherwise, look fine to me. > Mandy From felix.yang at oracle.com Thu May 26 14:50:22 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 26 May 2016 22:50:22 +0800 Subject: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds In-Reply-To: <5746DC5A.8090304@oracle.com> References: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> <5746DC5A.8090304@oracle.com> Message-ID: Hi all, thanks for review. A clean-up version: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.01/ - Felix On 2016/5/26 19:22, Alan Bateman wrote: > > > On 26/05/2016 11:58, Felix Yang wrote: >> Hi there, >> >> please review the following change. >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.00/ >> > The approach looks okay but would be good to do a few clean ups before > pushing this. > > One thing is the indentation in setup() is messed up by the removal of > try/catch. > > I also think it should use notExists rather than !exists (remember > !exists will return true if the existence cannot be determined so the > test should fail for this case). > > testKnownClassFiles now prints the file size, I assume that is for > another issue. > > -Alan From kevin.rushforth at oracle.com Thu May 26 15:17:42 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 May 2016 08:17:42 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> Message-ID: <57471396.6020601@oracle.com> If you add javafx-swt.jar to the custom classpath created by the OSGI container it should work in the same way it does today when you add jfxswt.jar. Can you suggest an easy way that I can test this? -- Kevin Tom Schindl wrote: > Hi, > > I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. > > The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? > > Tom > > Von meinem iPhone gesendet > > >> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >> >> >> >> >>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>> >>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>> >> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >> >> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >> >> FXCanvas.java >> 247 System.err.println("FXCanvas class successfully initialized?); >> 294 System.err.println("FXCanvas: FX platform is initlialized?); >> >> PlatformImpl.java >> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >> 309 ex.printStackTrace(); >> >> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >> >> ModuleHelper.java >> 57 // ignore >> >> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >> >> Otherwise, look fine to me. >> Mandy >> > > From kevin.rushforth at oracle.com Thu May 26 15:38:46 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 May 2016 08:38:46 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> Message-ID: <57471886.10703@oracle.com> Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. -- Kevin Tom Schindl wrote: > Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work > > Tom > > Von meinem iPhone gesendet > > >> Am 26.05.2016 um 16:51 schrieb Tom Schindl : >> >> Hi, >> >> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >> >> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >> >> Tom >> >> Von meinem iPhone gesendet >> >> >>> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >>> >>> >>> >>> >>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>> >>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>> >>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>> >>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>> >>> FXCanvas.java >>> 247 System.err.println("FXCanvas class successfully initialized?); >>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>> >>> PlatformImpl.java >>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>> 309 ex.printStackTrace(); >>> >>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>> >>> ModuleHelper.java >>> 57 // ignore >>> >>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>> >>> Otherwise, look fine to me. >>> Mandy >>> > > From Alan.Bateman at oracle.com Thu May 26 15:45:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 26 May 2016 16:45:34 +0100 Subject: RFR 8157931, jdk/internal/jrtfs/Basic.java fails with exploded builds In-Reply-To: References: <8a7388c1-53ea-5c37-fbd4-13d7074afc0a@oracle.com> <5746DC5A.8090304@oracle.com> Message-ID: <57471A1E.2080509@oracle.com> On 26/05/2016 15:50, Felix Yang wrote: > Hi all, > > thanks for review. A clean-up version: > > http://cr.openjdk.java.net/~xiaofeya/8157931/webrev.01/ > This looks okay to me. -Alan From mandy.chung at oracle.com Thu May 26 15:47:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 26 May 2016 08:47:16 -0700 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57471886.10703@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: > On May 26, 2016, at 8:38 AM, Kevin Rushforth wrote: > > Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. an automatic module needs to be on modulepath. For container-like environment, it can create a Layer to load javafx.swt with a parent class loader that loads SWT classes - would that be feasible? Mandy > > -- Kevin > > > Tom Schindl wrote: >> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work >> >> Tom >> >> Von meinem iPhone gesendet >> >> >> >>> Am 26.05.2016 um 16:51 schrieb Tom Schindl >>> : >>> >>> Hi, >>> >>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >>> >>> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >>> >>> Tom >>> >>> Von meinem iPhone gesendet >>> >>> >>> >>>> Am 26.05.2016 um 02:43 schrieb Mandy Chung >>>> : >>>> >>>> >>>> >>>> >>>> >>>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth >>>>> wrote: >>>>> >>>>> Please review the following: >>>>> >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>>> >>>>> >>>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>>> >>>>> >>>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>>> >>>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>>> >>>> FXCanvas.java >>>> 247 System.err.println("FXCanvas class successfully initialized?); >>>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>>> >>>> PlatformImpl.java >>>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>>> 309 ex.printStackTrace(); >>>> >>>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>>> >>>> ModuleHelper.java >>>> 57 // ignore >>>> >>>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>>> >>>> Otherwise, look fine to me. >>>> Mandy >>>> >>>> >> >> >> From tom.schindl at bestsolution.at Thu May 26 14:51:04 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 26 May 2016 16:51:04 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> Message-ID: <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> Hi, I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? Tom Von meinem iPhone gesendet > Am 26.05.2016 um 02:43 schrieb Mandy Chung : > > > >> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8131888 >> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >> >> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). > > The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. > > I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. > > FXCanvas.java > 247 System.err.println("FXCanvas class successfully initialized?); > 294 System.err.println("FXCanvas: FX platform is initlialized?); > > PlatformImpl.java > 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); > 309 ex.printStackTrace(); > > I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. > > ModuleHelper.java > 57 // ignore > > This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. > > Otherwise, look fine to me. > Mandy From tom.schindl at bestsolution.at Thu May 26 15:30:24 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 26 May 2016 17:30:24 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> Message-ID: <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work Tom Von meinem iPhone gesendet > Am 26.05.2016 um 16:51 schrieb Tom Schindl : > > Hi, > > I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. > > The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? > > Tom > > Von meinem iPhone gesendet > >> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >> >> >> >>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>> >>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >> >> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >> >> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >> >> FXCanvas.java >> 247 System.err.println("FXCanvas class successfully initialized?); >> 294 System.err.println("FXCanvas: FX platform is initlialized?); >> >> PlatformImpl.java >> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >> 309 ex.printStackTrace(); >> >> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >> >> ModuleHelper.java >> 57 // ignore >> >> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >> >> Otherwise, look fine to me. >> Mandy > From tom.schindl at bestsolution.at Thu May 26 15:53:58 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 26 May 2016 17:53:58 +0200 Subject: [9] review request: 8131888: Deliver javafx.swt as a modular jar in JDK 9 In-Reply-To: <57471886.10703@oracle.com> References: <57462965.7070806@oracle.com> <15B907CC-666E-4CA4-BEF6-361176A15DD5@oracle.com> <7C9108C2-2715-402B-826F-F113CA04EB7F@bestsolution.at> <45A8B280-0571-4BFE-BF3C-DCDE8F5B8D69@bestsolution.at> <57471886.10703@oracle.com> Message-ID: <94C22365-098C-4481-8718-3B40F9B196A5@bestsolution.at> I'll prepare a simple osgi swt test app Tom Von meinem iPhone gesendet > Am 26.05.2016 um 17:38 schrieb Kevin Rushforth : > > Yes, I've tested it in both modes (with a simple HelloFXCanvas program) -- as an automatic jar file and as just an ordinary jar on the classpath. > > -- Kevin > > > Tom Schindl wrote: >> >> Rereading the jira it take that back if javafx.swt can still be loaded as a simple jar things will work >> >> Tom >> >> Von meinem iPhone gesendet >> >> >>>> Am 26.05.2016 um 16:51 schrieb Tom Schindl : >>>> >>>> Hi, >>>> >>>> I highly doubt this will work in an OSGi-Env like Eclipse (which the 99%) use case for SWT useage. >>>> >>>> The SWT jar is not on the application classpath so how should a module (named or unnamed) find the SWT classes? >>>> >>>> Tom >>>> >>>> Von meinem iPhone gesendet >>>> >>>> >>>>> Am 26.05.2016 um 02:43 schrieb Mandy Chung : >>>>> >>>>> >>>>> >>>>> >>>>> On May 25, 2016, at 3:38 PM, Kevin Rushforth wrote: >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8131888 >>>>> http://cr.openjdk.java.net/~kcr/8131888/webrev.00/ >>>>> >>>>> This adds support for the javafx.embed.swt package back into the JDK, which will be delivered as an automatic module in $JAVA_HOME/lib/javafx-swt.jar (final location is TBD). >>>>> >>>> The approach to have javafx.swt be an automatic module that can access org.eclipse.swt.* (that may be from an unnamed module) sounds reasonable. I wonder what the JAR file should be named - javafx.swt.jar or javafx-swt.jar? They both have the same module name ?javafx.swt?. >>>> >>>> I skimmed through the change. There are several System.err.println calls that I assume are debugging code to be removed. e.g. >>>> >>>> FXCanvas.java >>>> 247 System.err.println("FXCanvas class successfully initialized?); >>>> 294 System.err.println("FXCanvas: FX platform is initlialized?); >>>> >>>> PlatformImpl.java >>>> 308 System.err.println("FXCanvas: no permission to access JavaFX internals"); >>>> 309 ex.printStackTrace(); >>>> >>>> I reviewed mainly addExportsToFXCanvas and addExportsToFXCanvas methods. Happy to see StackWalker be useful in this case. The check to compare the class name with ?javafx.embed.swt.FXCanvas? to derermine whether qualified exports should be added. You can consider checking the caller's module name as a starter. I know you are planning to look into the integrity check as a follows up. >>>> >>>> ModuleHelper.java >>>> 57 // ignore >>>> >>>> This deserves to be an InternalError. This is temporary until FX is transitioned to be built with JDK 9. >>>> >>>> Otherwise, look fine to me. >>>> Mandy >>>> From alan.bateman at oracle.com Thu May 26 18:51:43 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:51:43 +0000 Subject: hg: jigsaw/jake/jaxws: 2 new changesets Message-ID: <201605261851.u4QIphQl008523@aojmv0008.oracle.com> Changeset: fb771fa3a986 Author: lana Date: 2016-05-26 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/fb771fa3a986 Added tag jdk-9+120 for changeset ecd0d6a71c7c ! .hgtags Changeset: cb4cd9596539 Author: alanb Date: 2016-05-26 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/cb4cd9596539 Merge From alan.bateman at oracle.com Thu May 26 18:51:42 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:51:42 +0000 Subject: hg: jigsaw/jake/corba: 2 new changesets Message-ID: <201605261851.u4QIpgQC008449@aojmv0008.oracle.com> Changeset: 9a5fc5a27560 Author: lana Date: 2016-05-26 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/9a5fc5a27560 Added tag jdk-9+120 for changeset 5943b791e131 ! .hgtags Changeset: 79e446fcbde1 Author: alanb Date: 2016-05-26 18:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/79e446fcbde1 Merge From alan.bateman at oracle.com Thu May 26 18:51:43 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:51:43 +0000 Subject: hg: jigsaw/jake/jaxp: 8 new changesets Message-ID: <201605261851.u4QIphk5008526@aojmv0008.oracle.com> Changeset: 7b69a75155a2 Author: joehw Date: 2016-05-17 14:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/7b69a75155a2 8156845: Uri is getting incorrectly unwrapped Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/catalog/CatalogResolverImpl.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogUriResolverImpl.java ! src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java ! src/java.xml/share/classes/javax/xml/catalog/Normalizer.java ! src/java.xml/share/classes/javax/xml/catalog/UriEntry.java ! src/java.xml/share/classes/javax/xml/catalog/Util.java ! test/javax/xml/jaxp/unittest/catalog/CatalogTest.java + test/javax/xml/jaxp/unittest/catalog/uri.xml Changeset: a2bb3c17a0fc Author: lana Date: 2016-05-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a2bb3c17a0fc Merge Changeset: 5897218666d1 Author: joehw Date: 2016-05-19 16:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/5897218666d1 8139585: Typo: "APIi" instead of "API" Reviewed-by: mchung ! src/java.xml/share/classes/org/w3c/dom/package.html Changeset: 1b19c0704f90 Author: joehw Date: 2016-05-20 13:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/1b19c0704f90 8054632: [since-tag]: javadoc for xml classes has invalid @since tag Reviewed-by: lancea ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSS2Properties.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSCharsetRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSFontFaceRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSImportRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSMediaRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSPageRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSPrimitiveValue.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSRuleList.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSStyleDeclaration.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSStyleRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSStyleSheet.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSUnknownRule.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSValue.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/CSSValueList.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/Counter.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/DOMImplementationCSS.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/DocumentCSS.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/ElementCSSInlineStyle.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/RGBColor.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/Rect.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/css/ViewCSS.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLAnchorElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLAppletElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLAreaElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLBRElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLBaseElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLBaseFontElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLBodyElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLButtonElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLCollection.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLDListElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLDOMImplementation.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLDirectoryElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLDivElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLDocument.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLFieldSetElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLFontElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLFormElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLFrameElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLFrameSetElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLHRElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLHeadElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLHeadingElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLHtmlElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLIFrameElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLImageElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLInputElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLIsIndexElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLLIElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLLabelElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLLegendElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLLinkElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLMapElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLMenuElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLMetaElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLModElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLOListElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLObjectElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLOptGroupElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLOptionElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLParagraphElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLParamElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLPreElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLQuoteElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLScriptElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLSelectElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLStyleElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTableCaptionElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTableCellElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTableColElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTableElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTableRowElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTableSectionElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTextAreaElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLTitleElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/html/HTMLUListElement.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/stylesheets/DocumentStyle.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/stylesheets/LinkStyle.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/stylesheets/MediaList.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/stylesheets/StyleSheet.java ! src/jdk.xml.dom/share/classes/org/w3c/dom/stylesheets/StyleSheetList.java Changeset: f2f4b16d2cac Author: alanb Date: 2016-05-21 08:00 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/f2f4b16d2cac 8152650: ModuleFinder.compose should accept varargs Reviewed-by: mchung ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java ! test/javax/xml/jaxp/module/ServiceProviderTest/LayerModularXMLParserTest.java Changeset: ecbe72546137 Author: sla Date: 2016-05-24 12:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/ecbe72546137 8157605: Can't set both CONCURRENCY and EXTRA_JTREG_OPTIONS when running tests Reviewed-by: tbell, erikj ! test/Makefile Changeset: a265b8116058 Author: lana Date: 2016-05-26 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/a265b8116058 Added tag jdk-9+120 for changeset ecbe72546137 ! .hgtags Changeset: 8d5c3794dca1 Author: alanb Date: 2016-05-26 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/8d5c3794dca1 Merge ! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java From alan.bateman at oracle.com Thu May 26 18:51:47 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:51:47 +0000 Subject: hg: jigsaw/jake: 34 new changesets Message-ID: <201605261851.u4QIplad008548@aojmv0008.oracle.com> Changeset: 48aaedf3cc38 Author: sundar Date: 2016-05-16 14:50 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/48aaedf3cc38 8156914: jlink API minor cleanups Reviewed-by: mchung ! make/Javadoc.gmk Changeset: 7bae104507e5 Author: sundar Date: 2016-05-16 20:51 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7bae104507e5 8156847: jdk.dynalink package is shown under "Other Packages" section Reviewed-by: jlaskey ! make/Javadoc.gmk Changeset: 559c65fe6b56 Author: simonis Date: 2016-04-19 13:19 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/559c65fe6b56 8154251: ANSI-C Quoting bug in hotspot.m4 during configure on SLES 10 and 11 Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 Changeset: 4a67e08031be Author: kzhaldyb Date: 2016-04-20 19:16 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4a67e08031be 8135200: Add White Box method that enumerates G1 old regions with less than specified liveness and collects statistics Reviewed-by: tschatzl, dfazunen, iignatyev ! test/lib/sun/hotspot/WhiteBox.java Changeset: 2f9a45f34f95 Author: thartmann Date: 2016-04-07 16:51 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/2f9a45f34f95 8153514: Whitebox API should allow compilation of Summary: Added Whitebox API method to trigger compilation of static initializer. Reviewed-by: zmajo, kvn, iignatyev ! test/lib/sun/hotspot/WhiteBox.java Changeset: 0f5e3a457553 Author: bharadwaj Date: 2016-04-12 14:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/0f5e3a457553 Merge Changeset: e51a92f0f1ac Author: bharadwaj Date: 2016-04-19 15:26 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/e51a92f0f1ac Merge Changeset: f800d3025f27 Author: bharadwaj Date: 2016-04-21 15:03 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f800d3025f27 Merge ! test/lib/sun/hotspot/WhiteBox.java Changeset: a79c570f52a6 Author: amurillo Date: 2016-04-22 01:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a79c570f52a6 Merge ! common/autoconf/generated-configure.sh Changeset: 8c014913a48d Author: erikj Date: 2016-04-26 13:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/8c014913a48d 8150601: Remove the old Hotspot build system Reviewed-by: ihse ! common/autoconf/basics.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh - common/autoconf/hotspot-spec.gmk.in ! common/autoconf/hotspot.m4 - make/HotspotWrapper.gmk ! make/Main.gmk Changeset: 549dd3faf2d1 Author: amurillo Date: 2016-04-28 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/549dd3faf2d1 Merge Changeset: 632d52fc10bb Author: amurillo Date: 2016-04-28 22:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/632d52fc10bb Merge Changeset: 243610cb765d Author: amurillo Date: 2016-04-28 23:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/243610cb765d Merge ! make/Main.gmk Changeset: 35e8afde6dcd Author: lmesnik Date: 2016-05-04 18:56 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/35e8afde6dcd 8155950: Add minimal VM in JIB profile on linux-x86 Reviewed-by: dholmes, erikj ! common/conf/jib-profiles.js Changeset: d58c79a94f26 Author: amurillo Date: 2016-05-05 12:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d58c79a94f26 Merge ! common/autoconf/generated-configure.sh - common/autoconf/hotspot-spec.gmk.in - make/HotspotWrapper.gmk ! make/Main.gmk Changeset: 84c9ae8170e8 Author: amurillo Date: 2016-05-06 06:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/84c9ae8170e8 Merge ! common/conf/jib-profiles.js Changeset: 65f446a2bdd7 Author: iignatyev Date: 2016-05-03 23:49 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/65f446a2bdd7 8148244: Finalize and integrate GTest implementation Reviewed-by: jwilhelm, erikj Contributed-by: stefan.karlsson at oracle.com, stefan.sarne at oracle.com, jesper.wilhelmsson at oracle.com, erik.helin at oracle.com, alexandre.iline at oracle.com, igor.ignatyev at oracle.com, erik.joelsson at oracle.com ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/autoconf/spec.gmk.in ! make/Main.gmk ! make/common/NativeCompilation.gmk ! make/jprt.properties + test/fmw/gtest/CHANGES + test/fmw/gtest/LICENSE + test/fmw/gtest/README + test/fmw/gtest/include/gtest/gtest-death-test.h + test/fmw/gtest/include/gtest/gtest-message.h + test/fmw/gtest/include/gtest/gtest-param-test.h + test/fmw/gtest/include/gtest/gtest-param-test.h.pump + test/fmw/gtest/include/gtest/gtest-printers.h + test/fmw/gtest/include/gtest/gtest-spi.h + test/fmw/gtest/include/gtest/gtest-test-part.h + test/fmw/gtest/include/gtest/gtest-typed-test.h + test/fmw/gtest/include/gtest/gtest.h + test/fmw/gtest/include/gtest/gtest_pred_impl.h + test/fmw/gtest/include/gtest/gtest_prod.h + test/fmw/gtest/include/gtest/internal/gtest-death-test-internal.h + test/fmw/gtest/include/gtest/internal/gtest-filepath.h + test/fmw/gtest/include/gtest/internal/gtest-internal.h + test/fmw/gtest/include/gtest/internal/gtest-linked_ptr.h + test/fmw/gtest/include/gtest/internal/gtest-param-util-generated.h + test/fmw/gtest/include/gtest/internal/gtest-param-util-generated.h.pump + test/fmw/gtest/include/gtest/internal/gtest-param-util.h + test/fmw/gtest/include/gtest/internal/gtest-port.h + test/fmw/gtest/include/gtest/internal/gtest-string.h + test/fmw/gtest/include/gtest/internal/gtest-tuple.h + test/fmw/gtest/include/gtest/internal/gtest-tuple.h.pump + test/fmw/gtest/include/gtest/internal/gtest-type-util.h + test/fmw/gtest/include/gtest/internal/gtest-type-util.h.pump + test/fmw/gtest/src/gtest-all.cc + test/fmw/gtest/src/gtest-death-test.cc + test/fmw/gtest/src/gtest-filepath.cc + test/fmw/gtest/src/gtest-internal-inl.h + test/fmw/gtest/src/gtest-port.cc + test/fmw/gtest/src/gtest-printers.cc + test/fmw/gtest/src/gtest-test-part.cc + test/fmw/gtest/src/gtest-typed-test.cc + test/fmw/gtest/src/gtest.cc + test/fmw/gtest/src/gtest_main.cc Changeset: a83ca44e49af Author: aph Date: 2016-05-11 20:05 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a83ca44e49af 8155627: Enable SA on AArch64 Reviewed-by: roland, dholmes ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 278dbe271a52 Author: amurillo Date: 2016-05-14 09:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/278dbe271a52 Merge ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/generated-configure.sh - common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in - make/HotspotWrapper.gmk ! make/Main.gmk ! make/common/NativeCompilation.gmk Changeset: 21f1aa535d11 Author: amurillo Date: 2016-05-17 05:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/21f1aa535d11 Merge Changeset: 23d5fbcd76fc Author: erikj Date: 2016-05-17 18:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/23d5fbcd76fc 8156036: Enable building of arm targets in default JPRT testset Reviewed-by: tbell, chegar ! make/jprt.properties Changeset: 7de7decfd096 Author: erikj Date: 2016-05-04 15:29 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7de7decfd096 8136777: Introduce bundle targets Reviewed-by: tbell, ihse ! common/autoconf/basics.m4 ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/conf/jib-profiles.js + make/Bundles.gmk ! make/Javadoc.gmk ! make/Jprt.gmk ! make/MacBundles.gmk ! make/Main.gmk ! make/common/MakeBase.gmk Changeset: 7d5aba8800cc Author: sundar Date: 2016-05-18 15:04 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7d5aba8800cc 8154192: Deprivilege java.scripting module Reviewed-by: jlaskey, alanb ! make/common/Modules.gmk Changeset: b1295842f2dd Author: ehelin Date: 2016-05-16 12:33 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/b1295842f2dd 8157028: Add make target for running gtest tests Reviewed-by: erikj, jwilhelm ! make/Main.gmk ! make/MainSupport.gmk Changeset: 4c3bcad8156d Author: erikj Date: 2016-05-19 17:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/4c3bcad8156d 8155786: Determine modules depending on upgradeable modules directly and indirectly Reviewed-by: alanb, mchung ! make/CreateJmods.gmk ! make/Main.gmk ! make/common/Modules.gmk Changeset: 1817ea79cbbf Author: mcimadamore Date: 2016-05-19 16:48 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/1817ea79cbbf 8157061: Add support for running jtreg tests from IntelliJ project Summary: Add basic capabilities for running jtreg tests from the IDE using a custom ant target Reviewed-by: chegar ! common/bin/idea.sh ! make/idea/idea.gmk ! make/idea/template/ant.xml ! make/idea/template/build.xml ! make/idea/template/src/idea/JdkIdeaAntLogger.java ! make/idea/template/workspace.xml Changeset: d2351c2d7b52 Author: lana Date: 2016-05-19 19:45 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/d2351c2d7b52 Merge - common/autoconf/hotspot-spec.gmk.in - make/HotspotWrapper.gmk Changeset: fa3dec0c2862 Author: erikj Date: 2016-05-20 10:25 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/fa3dec0c2862 8157348: Build fails with certain source configurations Reviewed-by: tbell ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 ! common/autoconf/spec.gmk.in ! make/GensrcModuleInfo.gmk ! make/Images.gmk Changeset: c52e1a56db5d Author: erikj Date: 2016-05-21 18:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/c52e1a56db5d 8157507: JDK-8157348 broke gensrc of imported modules Reviewed-by: alanb, tbell, mchung ! make/GensrcModuleInfo.gmk Changeset: 18c129c4a770 Author: erikj Date: 2016-05-21 18:23 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/18c129c4a770 8157506: Disable bootcycle build when cross compiling Reviewed-by: alanb, tbell, mchung ! make/Main.gmk Changeset: ac5b9049ea28 Author: erikj Date: 2016-05-23 11:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/ac5b9049ea28 8157511: JDK-8157348 broke gensrc of module infos with extra provides Reviewed-by: mchung ! make/GensrcModuleInfo.gmk Changeset: 647e0142a5a5 Author: erikj Date: 2016-05-24 12:21 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/647e0142a5a5 8157574: Mac fastdebug bundles have wrong directory layout Reviewed-by: mchung ! make/Bundles.gmk Changeset: f6a6d060b10c Author: lana Date: 2016-05-26 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/f6a6d060b10c Added tag jdk-9+120 for changeset 647e0142a5a5 ! .hgtags Changeset: 6525eae2c5e0 Author: alanb Date: 2016-05-26 18:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6525eae2c5e0 Merge ! common/autoconf/basics.m4 ! common/autoconf/buildjdk-spec.gmk.in ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh - common/autoconf/hotspot-spec.gmk.in ! common/autoconf/hotspot.m4 ! common/autoconf/jdk-options.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/conf/jib-profiles.js ! make/CreateJmods.gmk ! make/GensrcModuleInfo.gmk - make/HotspotWrapper.gmk ! make/Images.gmk ! make/Javadoc.gmk ! make/Jprt.gmk ! make/Main.gmk ! make/MainSupport.gmk ! make/common/MakeBase.gmk ! make/common/Modules.gmk ! make/common/NativeCompilation.gmk ! make/jprt.properties ! test/lib/sun/hotspot/WhiteBox.java From alan.bateman at oracle.com Thu May 26 18:51:47 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:51:47 +0000 Subject: hg: jigsaw/jake/nashorn: 14 new changesets Message-ID: <201605261851.u4QIplsw008554@aojmv0008.oracle.com> Changeset: c24beef07d1b Author: sundar Date: 2016-05-18 14:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c24beef07d1b 8157160: JSON.stringify does not work on ScriptObjectMirror objects Reviewed-by: hannesw, mhaupt ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeJSON.java + test/script/basic/JDK-8157160.js + test/script/basic/JDK-8157160.js.EXPECTED Changeset: c187d75b77aa Author: mhaupt Date: 2016-05-18 12:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/c187d75b77aa 8157225: adopt method handle for array length getter in BeanLinker Reviewed-by: hannesw, sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java Changeset: bb6cf30cf892 Author: sundar Date: 2016-05-18 20:17 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/bb6cf30cf892 8157241: Remove javac warnings of Nashorn "ant clean test" Reviewed-by: mhaupt, hannesw ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! test/src/jdk/nashorn/api/scripting/test/ScriptEngineSecurityTest.java Changeset: 7099f590cdec Author: mhaupt Date: 2016-05-18 17:37 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7099f590cdec 8157250: BeanLinker assumes fixed array type linkage Reviewed-by: attila, sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java + test/script/basic/JDK-8157250.js + test/script/basic/JDK-8157250.js.EXPECTED Changeset: 9a6da438e0f6 Author: hannesw Date: 2016-05-18 18:44 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/9a6da438e0f6 8066229: Fuzzing bug: Can't find scope depth Reviewed-by: sundar + test/script/basic/JDK-8066229.js - test/script/basic/JDK-8157250.js.EXPECTED Changeset: be28ce2f1054 Author: jlahoda Date: 2016-05-18 21:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/be28ce2f1054 8133549: Generalize jshell's EditingHistory Summary: Using a generic EditingHistory in jjs Reviewed-by: sundar ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Console.java ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/HistoryObject.java ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/NashornCompleter.java Changeset: b13b36ca5821 Author: hannesw Date: 2016-05-18 22:30 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/b13b36ca5821 8157263: Octane svn repository no longer exists Reviewed-by: sundar ! make/build.xml Changeset: 8ad91dc85bfa Author: lana Date: 2016-05-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8ad91dc85bfa Merge Changeset: 2d3d3a04ce6c Author: sundar Date: 2016-05-20 13:20 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/2d3d3a04ce6c 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link Reviewed-by: hannesw, attila ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java Changeset: 141d0cf2c12e Author: mhaupt Date: 2016-05-20 16:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/141d0cf2c12e 8157444: exclude jjs shebang handling test from runs Reviewed-by: sundar, hannesw, jlaskey + test/script/currently-failing/JDK-8144221.js + test/script/currently-failing/JDK-8144221.js.EXPECTED - test/script/nosecurity/JDK-8144221.js - test/script/nosecurity/JDK-8144221.js.EXPECTED Changeset: 80a95fbd3e68 Author: sla Date: 2016-05-24 12:15 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/80a95fbd3e68 8157605: Can't set both CONCURRENCY and EXTRA_JTREG_OPTIONS when running tests Reviewed-by: tbell, erikj ! test/Makefile Changeset: 7ab7fc00b147 Author: jlahoda Date: 2016-05-24 16:03 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/7ab7fc00b147 8131017: jshell tool: pasting code with tabs invokes tab completion Summary: Enabling copy-paste detection. Reviewed-by: lagergren, sundar ! src/jdk.scripting.nashorn.shell/share/classes/jdk/nashorn/tools/jjs/Console.java Changeset: a2c78af5909e Author: lana Date: 2016-05-26 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/a2c78af5909e Added tag jdk-9+120 for changeset 7ab7fc00b147 ! .hgtags Changeset: 00cea21c8949 Author: alanb Date: 2016-05-26 18:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/00cea21c8949 Merge ! .hgtags ! make/build.xml ! src/jdk.dynalink/share/classes/jdk/dynalink/beans/CallerSensitiveDynamicMethod.java ! src/jdk.dynalink/share/classes/jdk/dynalink/linker/support/Lookup.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java - test/script/nosecurity/JDK-8144221.js - test/script/nosecurity/JDK-8144221.js.EXPECTED From alan.bateman at oracle.com Thu May 26 18:51:49 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:51:49 +0000 Subject: hg: jigsaw/jake/langtools: 37 new changesets Message-ID: <201605261851.u4QIpnri008561@aojmv0008.oracle.com> Changeset: fd398d3bb56a Author: mcimadamore Date: 2016-05-16 12:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/fd398d3bb56a 8157030: langtools dev build broken after classfile version bump Summary: fix build to use different source/target version when compiling build tools Reviewed-by: jlahoda ! make/build.properties ! make/build.xml Changeset: 5c3dfebefa4a Author: mcimadamore Date: 2016-05-16 13:05 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5c3dfebefa4a 8153884: Expression lambda erroneously compatible with void-returning descriptor Summary: Fix lambda compatibility check for void returning expressions Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/Diagnostics/compressed/T8012003b.out + test/tools/javac/diags/examples/StatExprExpected.java + test/tools/javac/lambda/8153884/T8153884.java + test/tools/javac/lambda/8153884/T8153884.out ! test/tools/javac/lambda/LambdaExpr10.out ! test/tools/javac/lambda/LambdaExprNotVoid.out Changeset: a81036905c63 Author: mcimadamore Date: 2016-05-16 13:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a81036905c63 8156180: javac accepts code that violates JLS chapter 16 Summary: DA/DU analysis should skip parenthesis around variable references Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/DefiniteAssignment/8156180/T8156180.java + test/tools/javac/DefiniteAssignment/8156180/T8156180.out Changeset: 047fbc74ebaa Author: jlahoda Date: 2016-05-16 15:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/047fbc74ebaa 8054562: document skip results in RunCodingRules.java Summary: Documenting when RunCodingRules gets skipped; adding a short description of AssertCheckAnalyzer and MutableFieldsAnalyzer Reviewed-by: jjg ! make/tools/crules/AssertCheckAnalyzer.java ! make/tools/crules/MutableFieldsAnalyzer.java ! test/tools/all/RunCodingRules.java Changeset: 97132c765562 Author: jlahoda Date: 2016-05-16 15:41 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/97132c765562 8078559: Update error message to indicate illegal character when encoding set to ascii Summary: When an input character cannot be decoded, include it in the produced error Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/unicode/Unmappable.java ! test/tools/javac/unicode/Unmappable.out Changeset: b00a838598ab Author: mcimadamore Date: 2016-05-16 14:51 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b00a838598ab 8154180: Regression: stuck expressions do not behave correctly Summary: ArgumentAttr should not cache stuck trees Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/speculative/8154180/T8154180a.java + test/tools/javac/lambda/speculative/8154180/T8154180b.java + test/tools/javac/lambda/speculative/8154180/T8154180b.out Changeset: 7e067140b496 Author: rfield Date: 2016-05-16 21:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/7e067140b496 8154812: jshell tool: value printing truncation Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/ToolFormatTest.java Changeset: d59aae1fe07b Author: rfield Date: 2016-05-16 21:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d59aae1fe07b 8153920: jshell tool: allow a parameter on the /vars /methods /classes commands Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/EditorTestBase.java ! test/jdk/jshell/ReplToolTesting.java ! test/jdk/jshell/ToolBasicTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 3f0c6071b611 Author: redestad Date: 2016-05-17 01:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3f0c6071b611 8157102: Avoid exceptional control flow in Configuration.getText Reviewed-by: jjg ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/MessageRetriever.java Changeset: d671601a2f2e Author: mcimadamore Date: 2016-05-17 17:53 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d671601a2f2e 8156954: javac incorrectly complains of incompatible types Summary: Add heuristics to pick best stuck constraint as per JLS 18.5.2 Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java + test/tools/javac/generics/inference/8156954/T8156954.java Changeset: cf467a017641 Author: jjg Date: 2016-05-17 10:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cf467a017641 8149599: Update Minefield test Reviewed-by: martin ! test/ProblemList.txt ! test/tools/javac/Paths/MineField.sh ! test/tools/javac/Paths/Util.sh Changeset: 0edb0950d500 Author: jjg Date: 2016-05-17 10:13 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0edb0950d500 Merge Changeset: e0bc2c27ecf3 Author: sadayapalam Date: 2016-05-18 11:38 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/e0bc2c27ecf3 8154997: Add examples for jigsaw diagnostics Reviewed-by: jjg, jlahoda ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/AddmodsAllModulePathInvalid/module-info.java + test/tools/javac/diags/examples/CantFindModule/CantFindModule.java + test/tools/javac/diags/examples/CyclicRequires/CyclicRequires.java + test/tools/javac/diags/examples/CyclicRequires/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/CyclicRequires/modulesourcepath/m2/module-info.java + test/tools/javac/diags/examples/DirPathElementNotDirectory/DirPathElementNotDirectory.java + test/tools/javac/diags/examples/DirPathElementNotDirectory/modulesourcepath + test/tools/javac/diags/examples/DuplicateExports/exported/Class.java + test/tools/javac/diags/examples/DuplicateExports/module-info.java + test/tools/javac/diags/examples/DuplicateModule/DuplicateModule.java + test/tools/javac/diags/examples/DuplicateModule/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/DuplicateModule/modulesourcepath/m2/module-info.java + test/tools/javac/diags/examples/DuplicateProvides/exported/Service.java + test/tools/javac/diags/examples/DuplicateProvides/impl/ServiceImplementation.java + test/tools/javac/diags/examples/DuplicateProvides/module-info.java + test/tools/javac/diags/examples/DuplicateRequires/module-info.java + test/tools/javac/diags/examples/DuplicateUses/exported/Service.java + test/tools/javac/diags/examples/DuplicateUses/module-info.java + test/tools/javac/diags/examples/IllegalArgumentForOption/IllegalArgumentForOption.java + test/tools/javac/diags/examples/InvalidArgForXPatch/InvalidArgForXpatch.java + test/tools/javac/diags/examples/ModuleDeclSbInModuleInfoJava.java + test/tools/javac/diags/examples/ModuleInfoWithXModuleSourcePath/Extra.java + test/tools/javac/diags/examples/ModuleInfoWithXModuleSourcePath/module-info.java + test/tools/javac/diags/examples/ModuleInfoWithXmoduleClasspath/ModuleInfoWithXmoduleClasspath.java + test/tools/javac/diags/examples/ModuleInfoWithXmoduleClasspath/additional/module-info.java + test/tools/javac/diags/examples/ModuleInfoWithoutModule/ModuleInfoWithoutModule.java + test/tools/javac/diags/examples/ModuleInfoWithoutModule/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/ModuleNameMismatch/ModuleNameMismatch.java + test/tools/javac/diags/examples/ModuleNameMismatch/modulesourcepath/m/module-info.java + test/tools/javac/diags/examples/ModuleNotFound/module-info.java + test/tools/javac/diags/examples/ModuleNotFoundInModuleSourcePath/ModuleNotFoundInModuleSourcePath.java + test/tools/javac/diags/examples/ModuleSourcePathMustWithDashM/ModuleSourcePathMustWithDashM.java + test/tools/javac/diags/examples/ModulesNotSupportedInSource/module-info.java + test/tools/javac/diags/examples/MultiModuleOutputCannotBeExplodedModule/MultiModuleOutputCannotBeExplodedModule.java + test/tools/javac/diags/examples/MultiModuleOutputCannotBeExplodedModule/additional/m1/module-info.java + test/tools/javac/diags/examples/MultiModuleOutputCannotBeExplodedModule/modulesourcepath/m2/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/NotDefAccessClassPackageCantAccess.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m1/p1/C1.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/module-info.java + test/tools/javac/diags/examples/NotDefAccessClassPackageCantAccess/modulesourcepath/m2/p2/C2.java + test/tools/javac/diags/examples/PackageClashFromRequires/PackageClashFromRequires.java + test/tools/javac/diags/examples/PackageClashFromRequires/modulesourcepath/lib1/exported/Api1.java + test/tools/javac/diags/examples/PackageClashFromRequires/modulesourcepath/lib1/module-info.java + test/tools/javac/diags/examples/PackageClashFromRequires/modulesourcepath/lib2/exported/Api2.java + test/tools/javac/diags/examples/PackageClashFromRequires/modulesourcepath/lib2/module-info.java + test/tools/javac/diags/examples/PackageClashFromRequires/modulesourcepath/use/module-info.java + test/tools/javac/diags/examples/PackageEmptyOrNotFound/PackageEmptyOrNotFound.java + test/tools/javac/diags/examples/PackageEmptyOrNotFound/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/PackageInOtherModule/PackageInOtherModule.java + test/tools/javac/diags/examples/ProcessorPathNoProcessorModulePath/ProcessorPathNoProcessorModulePath.java + test/tools/javac/diags/examples/ServiceDefinitionInner/ServiceDefinitionInner.java + test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/module-info.java + test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/p1/C1.java + test/tools/javac/diags/examples/ServiceDefinitionInner/modulesourcepath/m/p2/C2.java + test/tools/javac/diags/examples/ServiceDefinitionIsEnum/module-info.java + test/tools/javac/diags/examples/ServiceDefinitionIsEnum/pkg/EnumST.java + test/tools/javac/diags/examples/ServiceImplementationDoesntHaveANoArgsConstructor/exported/Service.java + test/tools/javac/diags/examples/ServiceImplementationDoesntHaveANoArgsConstructor/impl/ServiceImplementation.java + test/tools/javac/diags/examples/ServiceImplementationDoesntHaveANoArgsConstructor/module-info.java + test/tools/javac/diags/examples/ServiceImplementationIsAbstract/exported/Service.java + test/tools/javac/diags/examples/ServiceImplementationIsAbstract/impl/ServiceImplementation.java + test/tools/javac/diags/examples/ServiceImplementationIsAbstract/module-info.java + test/tools/javac/diags/examples/ServiceImplementationIsInner/exported/Service.java + test/tools/javac/diags/examples/ServiceImplementationIsInner/impl/ServiceImplementation.java + test/tools/javac/diags/examples/ServiceImplementationIsInner/module-info.java + test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/exported/Service.java + test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/impl/ServiceImplementation.java + test/tools/javac/diags/examples/ServiceImplementationNoArgsConstructorNotPublic/module-info.java + test/tools/javac/diags/examples/ServiceImplementationNotInRightModule/ServiceImplementationNotInRightModule.java + test/tools/javac/diags/examples/ServiceImplementationNotInRightModule/modulesourcepath/m1/exported/Service.java + test/tools/javac/diags/examples/ServiceImplementationNotInRightModule/modulesourcepath/m1/exported/ServiceImplementation.java + test/tools/javac/diags/examples/ServiceImplementationNotInRightModule/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/ServiceImplementationNotInRightModule/modulesourcepath/m2/module-info.java + test/tools/javac/diags/examples/ServiceProvidedButNotExportedOrUsed/ServiceProvidedButNotExportedOrUsed.java + test/tools/javac/diags/examples/ServiceProvidedButNotExportedOrUsed/modulesourcepath/m/module-info.java + test/tools/javac/diags/examples/ServiceProvidedButNotExportedOrUsed/modulesourcepath/m/p1/C1.java + test/tools/javac/diags/examples/ServiceProvidedButNotExportedOrUsed/modulesourcepath/m/p2/C2.java + test/tools/javac/diags/examples/TooManyModules/TooManyModules.java + test/tools/javac/diags/examples/TooManyModules/p1/module-info.java + test/tools/javac/diags/examples/TooManyModules/p2/module-info.java + test/tools/javac/diags/examples/UnnamedPackageInNamedModule/UnnamedPackageInNamedModule.java + test/tools/javac/diags/examples/UnnamedPackageInNamedModule/modulesourcepath/m1/UnnamedPackageInNamedModule.java + test/tools/javac/diags/examples/UnnamedPackageInNamedModule/modulesourcepath/m1/module-info.java + test/tools/javac/diags/examples/XModuleWithModulePath/XModuleWithModulePath.java + test/tools/javac/diags/examples/XaddexportsMalformedEntry.java + test/tools/javac/diags/examples/XaddexportsTooMany.java + test/tools/javac/diags/examples/XaddreadsMalformedEntry.java + test/tools/javac/diags/examples/XaddreadsTooMany.java Changeset: 3c09f576196a Author: rfield Date: 2016-05-18 11:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/3c09f576196a 8157185: jshell tool: ambiguous format -- distinguished arguments should be options Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/ToolBasicTest.java ! test/jdk/jshell/ToolFormatTest.java ! test/jdk/jshell/ToolLocaleMessageTest.java ! test/jdk/jshell/ToolReloadTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: d4aea0c5ec6e Author: jlahoda Date: 2016-05-18 21:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d4aea0c5ec6e 8133549: Generalize jshell's EditingHistory Summary: EditingHistory moved to jdk.internal.le Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditingHistory.java ! test/jdk/jshell/HistoryTest.java Changeset: 0b233e7be137 Author: mcimadamore Date: 2016-05-19 17:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0b233e7be137 8157326: Intellij langtools project should use shared run configurations Summary: Turn langtools run configurations into shared configurations. Fix minor addExport issues. Reviewed-by: jlahoda ! make/build.xml + make/intellij/runConfigurations/javac.xml + make/intellij/runConfigurations/javadoc.xml + make/intellij/runConfigurations/javah.xml + make/intellij/runConfigurations/javap.xml + make/intellij/runConfigurations/jshell.xml + make/intellij/runConfigurations/jtreg__debug_.xml + make/intellij/runConfigurations/jtreg__run_.xml + make/intellij/runConfigurations/sjavac.xml ! make/intellij/workspace.xml Changeset: 19972d5af5ab Author: mchung Date: 2016-05-19 10:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/19972d5af5ab 8153481: tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java fails intermittently Reviewed-by: dfuchs ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java ! test/ProblemList.txt Changeset: 878e51dad07c Author: mchung Date: 2016-05-19 10:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/878e51dad07c 8156680: jdeps implementation refresh Reviewed-by: dfuchs ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Graph.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsFilter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java - test/tools/jdeps/CompilerUtils.java ! test/tools/jdeps/DotFileTest.java + test/tools/jdeps/lib/CompilerUtils.java + test/tools/jdeps/lib/JdepsUtil.java ! test/tools/jdeps/m/Foo.java + test/tools/jdeps/modules/CheckModuleTest.java ! test/tools/jdeps/modules/GenModuleInfo.java + test/tools/jdeps/modules/ModuleMetaData.java ! test/tools/jdeps/modules/ModuleTest.java + test/tools/jdeps/modules/SplitPackage.java + test/tools/jdeps/modules/TransitiveDeps.java + test/tools/jdeps/modules/patches/javax/annotation/NonNull.java ! test/tools/jdeps/modules/src/m4/module-info.java ! test/tools/jdeps/modules/src/m4/p4/internal/Impl.java + test/tools/jdeps/modules/src/m5/module-info.java + test/tools/jdeps/modules/src/m5/p5/Main.java + test/tools/jdeps/modules/src/m5/p5/internal/T.java + test/tools/jdeps/modules/src/m6/module-info.java + test/tools/jdeps/modules/src/m6/p6/indirect/UnsafeRef.java + test/tools/jdeps/modules/src/m6/p6/safe/Lib.java + test/tools/jdeps/modules/src/m7/module-info.java + test/tools/jdeps/modules/src/m7/p7/Main.java + test/tools/jdeps/modules/src/m8/module-info.java + test/tools/jdeps/modules/src/m8/p8/Main.java + test/tools/jdeps/modules/src/unsafe/module-info.java + test/tools/jdeps/modules/src/unsafe/org/indirect/UnsafeRef.java + test/tools/jdeps/modules/src/unsafe/org/safe/Lib.java + test/tools/jdeps/modules/src/unsafe/org/unsafe/UseUnsafe.java ! test/tools/jdeps/unsupported/JDKUnsupportedTest.java Changeset: 292a9489d20a Author: mchung Date: 2016-05-19 11:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/292a9489d20a 8156575: Add jdeps -addmods, -system, -inverse options Reviewed-by: dfuchs + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/InverseDepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties ! test/tools/jdeps/lib/JdepsUtil.java + test/tools/jdeps/modules/InverseDeps.java Changeset: 2a49d47a37d8 Author: iris Date: 2016-05-19 11:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2a49d47a37d8 8144062: Move jdk.Version to java.lang.Runtime.Version Reviewed-by: abuckley, alanb, forax, jjg, mchung, psandoz ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/tools/javac/file/MultiReleaseJar/MultiReleaseJarAwareSJFM.java Changeset: 62278f3c373a Author: lana Date: 2016-05-19 19:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/62278f3c373a Merge - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditingHistory.java - test/tools/jdeps/CompilerUtils.java Changeset: 9c4984bd4951 Author: lana Date: 2016-05-19 20:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9c4984bd4951 Merge Changeset: 5531a8b53887 Author: mchung Date: 2016-05-19 17:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5531a8b53887 8152502: tools/jdeps/modules/GenModuleInfo.java and TransitiveDeps fails on windows Reviewed-by: jjg ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! test/tools/jdeps/modules/GenModuleInfo.java ! test/tools/jdeps/modules/InverseDeps.java ! test/tools/jdeps/modules/TransitiveDeps.java Changeset: d71cfeef72eb Author: mchung Date: 2016-05-20 09:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d71cfeef72eb 8157391: jdeps left JarFile open Reviewed-by: alanb ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! test/tools/jdeps/lib/JdepsUtil.java ! test/tools/jdeps/modules/CheckModuleTest.java ! test/tools/jdeps/modules/GenModuleInfo.java ! test/tools/jdeps/modules/InverseDeps.java ! test/tools/jdeps/modules/ModuleTest.java ! test/tools/jdeps/modules/SplitPackage.java ! test/tools/jdeps/modules/TransitiveDeps.java Changeset: 9291bcd53e07 Author: rfield Date: 2016-05-20 11:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/9291bcd53e07 8157200: jshell tool: Add /retain command to persist settings 8156910: jshell tool: crash when code with syntax error contains format specifier Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ArgTokenizer.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/ToolBasicTest.java ! test/jdk/jshell/ToolFormatTest.java + test/jdk/jshell/ToolRetainTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: 5d652ee92e99 Author: mchung Date: 2016-05-20 12:24 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5d652ee92e99 8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK Reviewed-by: dfuchs ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DepsAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties + test/tools/jdeps/jdkinternals/RemovedJDKInternals.java + test/tools/jdeps/jdkinternals/patches/java.desktop/com/sun/image/codec/jpeg/JPEGCodec.java + test/tools/jdeps/jdkinternals/patches/jdk.unsupported/sun/misc/Service.java + test/tools/jdeps/jdkinternals/patches/jdk.unsupported/sun/misc/SoftCache.java + test/tools/jdeps/jdkinternals/src/p/Main.java + test/tools/jdeps/jdkinternals/src/p/S.java + test/tools/jdeps/lib/ModuleMetaData.java - test/tools/jdeps/modules/ModuleMetaData.java Changeset: cf4046825175 Author: jjg Date: 2016-05-20 16:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/cf4046825175 8157474: clean up/simplify/rename ModuleWrappers class Reviewed-by: mchung ! make/tools/crules/MutableFieldsAnalyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java Changeset: d6224976006a Author: darcy Date: 2016-05-20 17:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d6224976006a 6415644: Make javax.lang.model.SourceVersion more informative Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! test/tools/javac/processing/model/TestSourceVersion.java Changeset: a3e92e738d92 Author: rfield Date: 2016-05-21 22:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a3e92e738d92 8156101: JShell SPI: Provide a pluggable execution control SPI Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/debug/InternalDebugControl.java + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/ClassTracker.java + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIConnection.java + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIEnv.java + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIEventHandler.java + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIExecutionControl.java + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDINotConnectedException.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.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/JShellTool.java - src/jdk.jshell/share/classes/jdk/jshell/ClassTracker.java ! src/jdk.jshell/share/classes/jdk/jshell/Corraller.java ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java - src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.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/OuterWrap.java ! src/jdk.jshell/share/classes/jdk/jshell/OuterWrapMap.java ! src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! src/jdk.jshell/share/classes/jdk/jshell/Unit.java ! src/jdk.jshell/share/classes/jdk/jshell/Util.java ! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java + src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java + src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionEnv.java + src/jdk.jshell/share/classes/jdk/jshell/spi/SPIResolutionException.java + src/jdk.jshell/share/classes/jdk/jshell/spi/package-info.java ! src/jdk.jshell/share/classes/module-info.java + test/jdk/jshell/ExecutionControlTest.java ! test/jdk/jshell/KullaTesting.java + test/jdk/jshell/LocalExecutionControl.java Changeset: 5b418ae6fe24 Author: sadayapalam Date: 2016-05-23 10:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/5b418ae6fe24 8154824: Compiler should handle java.nio.file.FileSystemNotFoundException gracefully and not abort Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java + test/tools/javac/modules/MissingJarInModulePathTest.java + test/tools/javac/modules/MissingJarInModulePathTest.out Changeset: b46cdae175b4 Author: psandoz Date: 2016-05-23 12:48 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b46cdae175b4 8149821: Add VarHandle signature-polymorphic invocation byte code tests Reviewed-by: mcimadamore ! test/tools/javac/meth/TestCP.java Changeset: a8b7c9938b74 Author: mcimadamore Date: 2016-05-23 15:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a8b7c9938b74 8157149: Inference: weird propagation of thrown inference variables Summary: Overhaul of treatment of thrown inference variables Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8157149/T8157149a.java + test/tools/javac/generics/inference/8157149/T8157149a.out + test/tools/javac/generics/inference/8157149/T8157149b.java + test/tools/javac/generics/inference/8157149/T8157149c.java Changeset: d44729b76ebc Author: rfield Date: 2016-05-23 10:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/d44729b76ebc 8157517: jshell tool: allow undoing operations 8157395: jshell tool: allow the position of options on commands to be more flexible 8157393: jshell tool: change /set newmode ... to be consistent with /retain mode Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ArgTokenizer.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Feedback.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties + test/jdk/jshell/ToolCommandOptionTest.java ! test/jdk/jshell/ToolFormatTest.java ! test/jdk/jshell/ToolLocaleMessageTest.java ! test/jdk/jshell/ToolRetainTest.java ! test/jdk/jshell/ToolSimpleTest.java Changeset: dec94c8de74e Author: rfield Date: 2016-05-23 13:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dec94c8de74e 8157528: jdk/jshell/ExecutionControlTest.java failed intermittently with NPE Reviewed-by: jlahoda ! test/jdk/jshell/LocalExecutionControl.java Changeset: 0f81cdd51b42 Author: jlahoda Date: 2016-05-24 16:02 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/0f81cdd51b42 8131017: jshell tool: pasting code with tabs invokes tab completion Summary: Enabling copy-paste detection. Reviewed-by: lagergren, rfield, sundar ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: 2f500ac6a6fe Author: lana Date: 2016-05-26 16:02 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/2f500ac6a6fe Added tag jdk-9+120 for changeset 0f81cdd51b42 ! .hgtags Changeset: 1d6df5fa1a51 Author: alanb Date: 2016-05-26 18:55 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/1d6df5fa1a51 Merge ! .hgtags ! make/build.properties ! make/build.xml ! make/tools/crules/MutableFieldsAnalyzer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties + src/jdk.compiler/share/classes/com/sun/tools/javac/util/JDK9Wrappers.java - src/jdk.compiler/share/classes/com/sun/tools/javac/util/ModuleWrappers.java ! src/jdk.javadoc/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/Configuration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Archive.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ClassFileReader.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/DependencyFinder.java + src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleAnalyzer.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleInfoBuilder.java - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModulePaths.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties + src/jdk.jshell/share/classes/jdk/internal/jshell/jdi/JDIExecutionControl.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteAgent.java - src/jdk.jshell/share/classes/jdk/internal/jshell/remote/RemoteResolutionException.java - src/jdk.jshell/share/classes/jdk/internal/jshell/tool/EditingHistory.java - src/jdk.jshell/share/classes/jdk/jshell/ClassTracker.java - src/jdk.jshell/share/classes/jdk/jshell/ExecutionControl.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/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java ! test/ProblemList.txt ! test/jdk/jshell/CommandCompletionTest.java ! test/jdk/jshell/ToolFormatTest.java ! test/tools/all/RunCodingRules.java ! test/tools/javac/T8003967/DetectMutableStaticFields.java ! test/tools/javac/diags/Example.java ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/Basic.java - test/tools/jdeps/CompilerUtils.java ! test/tools/jdeps/DotFileTest.java + test/tools/jdeps/lib/CompilerUtils.java ! test/tools/jdeps/modules/GenModuleInfo.java From alan.bateman at oracle.com Thu May 26 18:52:16 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 26 May 2016 18:52:16 +0000 Subject: hg: jigsaw/jake/jdk: 161 new changesets Message-ID: <201605261852.u4QIqM9t008704@aojmv0008.oracle.com> Changeset: 4352ddb02f68 Author: sundar Date: 2016-05-16 14:47 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4352ddb02f68 8156914: jlink API minor cleanups Reviewed-by: mchung ! src/jdk.jlink/share/classes/jdk/tools/jlink/Jlink.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginConfiguration.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModuleEntryImpl.java + src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ModulePoolImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePrevisitor.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Utils.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/packager/AppRuntimeImageBuilder.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultCompressPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeFilesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludePlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/FileCopierPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/IncludeLocalesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OptimizationPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/OrderResourcesPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StringSharingPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripDebugPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripNativeCommandsPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModuleDescriptorPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ZipPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPoolImpl.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/asm/AsmPools.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ExecutableImage.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/LinkModule.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ModuleEntry.java + src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/ModulePool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Plugin.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginContext.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/TransformerPlugin.java ! src/jdk.jlink/share/classes/module-info.java ! test/tools/jlink/DefaultProviderTest.java ! test/tools/jlink/ImageFileCreatorTest.java ! test/tools/jlink/ImageFilePoolTest.java ! test/tools/jlink/IntegrationTest.java ! test/tools/jlink/JLinkOptimTest.java ! test/tools/jlink/JLinkOptionsTest.java ! test/tools/jlink/JLinkPostProcessingTest.java ! test/tools/jlink/ResourcePoolTest.java ! test/tools/jlink/SecurityTest.java ! test/tools/jlink/asmplugin/AddForgetResourcesTest.java ! test/tools/jlink/asmplugin/AsmPluginTestBase.java ! test/tools/jlink/asmplugin/BasicTest.java ! test/tools/jlink/asmplugin/IdentityPluginTest.java ! test/tools/jlink/asmplugin/NegativeTest.java ! test/tools/jlink/asmplugin/PackageMappingTest.java ! test/tools/jlink/asmplugin/SortingTest.java ! test/tools/jlink/asmplugin/VisitorTest.java ! test/tools/jlink/customplugin/plugin/CustomPlugin.java ! test/tools/jlink/customplugin/plugin/HelloPlugin.java ! test/tools/jlink/plugins/CompressorPluginTest.java ! test/tools/jlink/plugins/ExcludeFilesPluginTest.java ! test/tools/jlink/plugins/ExcludePluginTest.java ! test/tools/jlink/plugins/ExcludeVMPluginTest.java ! test/tools/jlink/plugins/FileCopierPluginTest.java ! test/tools/jlink/plugins/LastSorterTest.java ! test/tools/jlink/plugins/OrderResourcesPluginTest.java ! test/tools/jlink/plugins/PluginOrderTest.java ! test/tools/jlink/plugins/PluginsNegativeTest.java ! test/tools/jlink/plugins/PrevisitorTest.java ! test/tools/jlink/plugins/StringSharingPluginTest.java ! test/tools/jlink/plugins/StripDebugPluginTest.java Changeset: db250cfb765a Author: prappo Date: 2016-05-16 15:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/db250cfb765a 8150785: (bf) Hoist slice and duplicate methods up to java.nio.Buffer Reviewed-by: alanb, rriggs, chegar ! src/java.base/share/classes/java/nio/Buffer.java ! src/java.base/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Order-X.java.template ! test/java/nio/Buffer/Order.java ! test/java/nio/Buffer/OrderChar.java ! test/java/nio/Buffer/OrderDouble.java ! test/java/nio/Buffer/OrderFloat.java ! test/java/nio/Buffer/OrderInt.java ! test/java/nio/Buffer/OrderLong.java ! test/java/nio/Buffer/OrderShort.java Changeset: 0c2e739fb309 Author: michaelm Date: 2016-05-16 16:04 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c2e739fb309 8156825: java/net/httpclient/BasicWebSocketAPITest.java failed with java.lang.AssertionError Reviewed-by: rriggs ! src/java.httpclient/share/classes/java/net/http/HttpClientImpl.java - src/java.httpclient/share/classes/java/net/http/HttpHeaders1.java ! src/java.httpclient/share/classes/java/net/http/HttpResponseImpl.java ! src/java.httpclient/share/classes/java/net/http/RawChannel.java ! src/java.httpclient/share/classes/java/net/http/WSOpeningHandshake.java Changeset: ee022b8f5e2d Author: rhalade Date: 2016-05-16 10:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee022b8f5e2d 8155049: New tests from 8144566 fail with "No expected Server Name Indication" Reviewed-by: xuelei ! test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java ! test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java Changeset: b26fa1a6458d Author: mullan Date: 2016-05-16 13:53 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b26fa1a6458d 8150468: ClassCircularityError on error in security policy file Reviewed-by: mchung, xuelei ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/provider/PolicyParser.java + test/sun/security/provider/PolicyFile/BadPolicyFile.java + test/sun/security/provider/PolicyFile/BadPolicyFile.policy Changeset: ced2868c2e8d Author: mullan Date: 2016-05-16 13:54 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ced2868c2e8d Merge - src/java.httpclient/share/classes/java/net/http/HttpHeaders1.java Changeset: f4a0fe7bbd75 Author: alanb Date: 2016-05-16 22:07 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f4a0fe7bbd75 8156989: Trailing empty element in classpath ignored Reviewed-by: mchung ! src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java Changeset: fbdd80a33a62 Author: xiaofeya Date: 2016-05-17 02:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fbdd80a33a62 8155088: Fix module dependencies in java/sql/* and javax/* tests Reviewed-by: alanb Contributed-by: Felix Yang + test/java/sql/TEST.properties ! test/javax/net/ssl/HttpsURLConnection/Equals.java + test/javax/rmi/TEST.properties + test/javax/script/TEST.properties + test/javax/xml/jaxp/TEST.properties Changeset: df25fad96353 Author: psandoz Date: 2016-05-17 12:06 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/df25fad96353 8156485: MethodHandles.varHandleExactInvoker should perform exact checks Reviewed-by: vlivanov ! src/java.base/share/classes/java/lang/invoke/Invokers.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template Changeset: 0dae92546feb Author: sundar Date: 2016-05-17 19:53 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0dae92546feb 8157146: Add debug printlns to tests FieldSetAccessibleTest and VerifyJimage.java Reviewed-by: alanb, shade ! test/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java ! test/tools/jimage/VerifyJimage.java Changeset: 1723608170c0 Author: ahenrie Date: 2015-11-17 23:10 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1723608170c0 8145278: Fix memory leak in splitPathList Reviewed-by: sspitsyn, dsamersoff, dcubed ! src/java.instrument/share/native/libinstrument/InvocationAdapter.c Changeset: 769777ebcc81 Author: stefank Date: 2016-04-20 09:57 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/769777ebcc81 8072921: -Xincgc should be removed from output Reviewed-by: alanb ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 1d38cf0f291c Author: dsamersoff Date: 2016-04-20 18:01 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1d38cf0f291c 8152847: JDI use of sun.boot.class.path needs to be updated for Jigsaw Summary: remove references to bootclasspath Reviewed-by: alanb, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java Changeset: 4958bdcf895d Author: dsamersoff Date: 2016-04-20 15:09 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4958bdcf895d Merge Changeset: 0508d801b1fb Author: dsamersoff Date: 2016-04-21 13:18 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0508d801b1fb 8143921: nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS Summary: Skip invalid classes Reviewed-by: sspitsyn ! src/jdk.jdwp.agent/share/native/libjdwp/VirtualMachineImpl.c Changeset: 227c77e44055 Author: ikrylov Date: 2016-03-30 17:04 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/227c77e44055 8147844: new method j.l.Thread.onSpinWait() and the corresponding x86 hotspot instrinsic Summary: see JEP-285 for details Reviewed-by: psandoz, alanb, dholmes Contributed-by: Gil Tene , Ivan Krylov ! src/java.base/share/classes/java/lang/Thread.java Changeset: 25fe2c0cecfb Author: bharadwaj Date: 2016-04-12 14:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/25fe2c0cecfb Merge Changeset: 6e607ec47322 Author: bharadwaj Date: 2016-04-19 15:26 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6e607ec47322 Merge ! src/java.base/share/classes/java/lang/Thread.java Changeset: 35ce2ada6b0a Author: bharadwaj Date: 2016-04-21 15:04 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/35ce2ada6b0a Merge Changeset: b2d898bbd0c4 Author: amurillo Date: 2016-04-22 01:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2d898bbd0c4 Merge ! src/java.base/share/classes/java/lang/Thread.java - src/java.base/share/classes/jdk/internal/jrtfs/AbstractJrtFileAttributes.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/JrtExplodedFileAttributes.java - src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedFileSystem.java - src/java.base/share/classes/jdk/internal/jrtfs/JrtExplodedPath.java - src/java.base/share/classes/jdk/internal/jrtfs/SystemImages.java - src/java.base/share/classes/sun/reflect/AccessorGenerator.java - src/java.base/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/ByteVector.java - src/java.base/share/classes/sun/reflect/ByteVectorFactory.java - src/java.base/share/classes/sun/reflect/ByteVectorImpl.java - src/java.base/share/classes/sun/reflect/CallerSensitive.java - src/java.base/share/classes/sun/reflect/ClassDefiner.java - src/java.base/share/classes/sun/reflect/ClassFileAssembler.java - src/java.base/share/classes/sun/reflect/ClassFileConstants.java - src/java.base/share/classes/sun/reflect/ConstantPool.java - src/java.base/share/classes/sun/reflect/ConstructorAccessor.java - src/java.base/share/classes/sun/reflect/ConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/DelegatingConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/DelegatingMethodAccessorImpl.java - src/java.base/share/classes/sun/reflect/FieldAccessor.java - src/java.base/share/classes/sun/reflect/FieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/FieldInfo.java - src/java.base/share/classes/sun/reflect/InstantiationExceptionConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/Label.java - src/java.base/share/classes/sun/reflect/LangReflectAccess.java - src/java.base/share/classes/sun/reflect/MagicAccessorImpl.java - src/java.base/share/classes/sun/reflect/MethodAccessor.java - src/java.base/share/classes/sun/reflect/MethodAccessorGenerator.java - src/java.base/share/classes/sun/reflect/MethodAccessorImpl.java - src/java.base/share/classes/sun/reflect/NativeConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/NativeMethodAccessorImpl.java - src/java.base/share/classes/sun/reflect/Reflection.java - src/java.base/share/classes/sun/reflect/ReflectionFactory.java - src/java.base/share/classes/sun/reflect/SerializationConstructorAccessorImpl.java - src/java.base/share/classes/sun/reflect/SignatureIterator.java - src/java.base/share/classes/sun/reflect/UTF8.java - src/java.base/share/classes/sun/reflect/UnsafeBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java - src/java.base/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedShortFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeQualifiedStaticShortFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeShortFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticBooleanFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticByteFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticCharacterFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticDoubleFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticFloatFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticLongFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticObjectFieldAccessorImpl.java - src/java.base/share/classes/sun/reflect/UnsafeStaticShortFieldAccessorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java - src/jdk.rmic/share/classes/jdk/rmi/rmic/Main.java - test/java/util/ServiceLoader/modules/BasicTest.java - test/sun/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java - test/sun/reflect/CallerSensitive/CallerSensitiveFinder.java - test/sun/reflect/CallerSensitive/MissingCallerSensitive.java - test/sun/reflect/Reflection/GetCallerClass.java - test/sun/reflect/Reflection/GetCallerClassTest.java - test/sun/reflect/Reflection/GetCallerClassTest.sh - test/sun/reflect/constantPool/ConstantPoolTest.java - test/sun/reflect/constantPool/ConstantPoolTestDummy.jasm Changeset: ce87b09f35dd Author: sspitsyn Date: 2016-04-28 00:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ce87b09f35dd 8153749: New capability can_generate_early_class_hook_events Summary: Add new capability Reviewed-by: alanb, dsamersoff ! src/java.base/share/native/include/jvmti.h Changeset: 8bc8f99ed902 Author: amurillo Date: 2016-04-28 14:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8bc8f99ed902 Merge Changeset: f39e271718d9 Author: amurillo Date: 2016-04-28 22:51 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f39e271718d9 Merge Changeset: 1a74d902715a Author: amurillo Date: 2016-04-28 23:08 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a74d902715a Merge - make/launcher/Launcher-jdk.jvmstat.rmi.gmk - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c - src/jdk.jlink/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java - src/jdk.unsupported/share/classes/sun/misc/ManagedLocalsThread.java - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java Changeset: 48363aba4811 Author: hseigel Date: 2016-04-29 15:17 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/48363aba4811 8155727: java/util/concurrent/locks/Lock/TimedAcquireLeak.java timeouts. Summary: Fix regex pattern to handle possible (module at version) text Reviewed-by: ctornqvi, martin ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java Changeset: 37b8d7571efd Author: mockner Date: 2016-04-29 22:39 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/37b8d7571efd 8154110: Update class* and safepoint* logging subsystems Summary: Refactored logging tags in class and safepoint subsystems. Reviewed-by: coleenp, rehn, hseigel ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh Changeset: d0b8cc47c117 Author: hb Date: 2016-05-05 01:52 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d0b8cc47c117 8154166: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with RuntimeException Summary: Fix the RuntimeException issue Reviewed-by: jbachorik ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java Changeset: d2f46fdfc3ca Author: bchristi Date: 2016-05-05 11:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d2f46fdfc3ca 8147039: Incorrect locals and operands in compiled frames Summary: Implement stack walking using javaVFrame instead of vframeStream Reviewed-by: mchung, vlivanov + test/java/lang/StackWalker/CountLocalSlots.java ! test/java/lang/StackWalker/LocalsAndOperands.java + test/java/lang/StackWalker/LocalsCrash.java Changeset: 73608cd4f89a Author: dsamersoff Date: 2016-05-06 11:47 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/73608cd4f89a 8154144: Tests in com/sun/jdi fails intermittently with "jdb input stream closed prematurely" Summary: Don't print stream closed message during shutdown Reviewed-by: dcubed, sla, dsamersoff Contributed-by: sharath.ballal at oracle.com ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java Changeset: 294e430e2951 Author: amurillo Date: 2016-05-05 12:35 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/294e430e2951 Merge ! src/java.base/share/classes/sun/launcher/resources/launcher.properties Changeset: 2f0dd8cb6cc0 Author: amurillo Date: 2016-05-06 06:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2f0dd8cb6cc0 Merge - src/java.base/share/classes/jdk/internal/module/Hasher.java - src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java - src/java.desktop/share/classes/sun/swing/UIClientPropertyKey.java - src/java.desktop/unix/native/common/awt/extutil.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.c - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingAreaP.h - test/javax/transaction/testng/TEST.properties - test/tools/jlink/hashes/HashesTest.java - test/tools/jlink/hashes/newsrc/m2/module-info.java - test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/tools/jlink/hashes/src/m1/module-info.java - test/tools/jlink/hashes/src/m1/org/m1/Main.java - test/tools/jlink/hashes/src/m2/module-info.java - test/tools/jlink/hashes/src/m2/org/m2/Util.java - test/tools/jlink/hashes/src/not_matched/module-info.java - test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java - test/tools/launcher/modules/addmods/src/app/Main.java - test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java - test/tools/launcher/modules/addmods/src/lib/module-info.java Changeset: b1c3c979ef6e Author: mikael Date: 2016-05-06 15:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b1c3c979ef6e 8150921: Update Unsafe getters/setters to use double-register variants Reviewed-by: dholmes, shade, psandoz, jrose ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: c43aba5fc69b Author: sgehwolf Date: 2016-04-25 15:32 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c43aba5fc69b 8154529: some places in the invoke.c that use InvokeRequest* not protected with invokerLock Reviewed-by: sspitsyn ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.c ! src/jdk.jdwp.agent/share/native/libjdwp/invoker.h Changeset: 08a5c72f79e3 Author: sspitsyn Date: 2016-05-08 08:25 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/08a5c72f79e3 Merge - make/launcher/Launcher-jdk.jvmstat.rmi.gmk - src/java.base/share/classes/jdk/internal/module/Hasher.java - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java - src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c - src/java.desktop/share/classes/sun/swing/UIClientPropertyKey.java - src/java.desktop/unix/native/common/awt/extutil.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.c - src/java.desktop/unix/native/libawt_headless/awt/VDrawingArea.h - src/java.desktop/unix/native/libawt_headless/awt/VDrawingAreaP.h - src/jdk.jlink/share/classes/jdk/tools/jimage/ExtractedImage.java - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java - src/jdk.unsupported/share/classes/sun/misc/ManagedLocalsThread.java - test/javax/transaction/testng/TEST.properties - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java - test/tools/jlink/hashes/HashesTest.java - test/tools/jlink/hashes/newsrc/m2/module-info.java - test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/tools/jlink/hashes/src/m1/module-info.java - test/tools/jlink/hashes/src/m1/org/m1/Main.java - test/tools/jlink/hashes/src/m2/module-info.java - test/tools/jlink/hashes/src/m2/org/m2/Util.java - test/tools/jlink/hashes/src/not_matched/module-info.java - test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java - test/tools/launcher/modules/addmods/src/app/Main.java - test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java - test/tools/launcher/modules/addmods/src/lib/module-info.java Changeset: c3b401bbc6fe Author: neliasso Date: 2016-04-29 09:40 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c3b401bbc6fe 8142464: PlatformLoggerTest.java throws java.lang.RuntimeException: Logger test.logger.bar does not exist Summary: Test doesn't keep strong references to loggers Reviewed-by: kvn ! test/sun/util/logging/PlatformLoggerTest.java Changeset: 909f38c3d339 Author: shade Date: 2016-05-04 17:17 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/909f38c3d339 8155739: [TESTBUG] VarHandles/Unsafe tests for weakCAS should allow spurious failures Reviewed-by: psandoz, vlivanov, simonis ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: cbd0fd67b328 Author: psandoz Date: 2016-05-05 18:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cbd0fd67b328 8155794: Move Objects.checkIndex BiFunction accepting methods to an internal package Reviewed-by: chegar, shade, forax, vlivanov ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! src/java.base/share/classes/java/util/Objects.java + src/java.base/share/classes/jdk/internal/util/Preconditions.java ! test/java/util/Objects/CheckIndex.java Changeset: 0043d6a1e416 Author: vlivanov Date: 2016-05-06 18:21 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0043d6a1e416 Merge ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/sun/util/logging/PlatformLoggerTest.java Changeset: 160c2f030a25 Author: vlivanov Date: 2016-05-09 12:39 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/160c2f030a25 Merge ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 5178f8538a52 Author: vlivanov Date: 2016-05-09 13:12 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5178f8538a52 Merge Changeset: 391c4972f6ad Author: dsamersoff Date: 2016-05-09 23:41 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/391c4972f6ad 8155091: Remove SA related functions from tmtools Summary: Remove options that enables support for non-cooperative mode Reviewed-by: alanb, mchung, sla ! src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java ! src/jdk.jcmd/share/classes/module-info.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java + test/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java + test/sun/tools/jhsdb/heapconfig/TmtoolTestScenario.java + test/sun/tools/jinfo/BasicJInfoTest.java - test/sun/tools/jinfo/JInfoHelper.java - test/sun/tools/jinfo/JInfoLauncherTest.java - test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java - test/sun/tools/jinfo/JInfoRunningProcessTest.java - test/sun/tools/jinfo/JInfoSanityTest.java ! test/sun/tools/jmap/BasicJMapTest.java - test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java - test/sun/tools/jmap/heapconfig/TmtoolTestScenario.java ! test/sun/tools/jstack/BasicJStackTest.java ! test/sun/tools/jstack/DeadlockDetectionTest.java Changeset: dd12e7b9d044 Author: rehn Date: 2016-05-10 06:52 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/dd12e7b9d044 8154985: Add the ability to use main class as lookup (as jcmd) to jinfo, jmap, jstack Reviewed-by: sla, dsamersoff + src/jdk.jcmd/share/classes/sun/tools/common/ProcessArgumentMatcher.java ! src/jdk.jcmd/share/classes/sun/tools/jcmd/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstack/JStack.java Changeset: 2053d6544876 Author: ysuenaga Date: 2016-05-07 10:32 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2053d6544876 8156033: jhsdb jmap cannot set heapdump name Reviewed-by: dsamersoff ! test/sun/tools/jhsdb/BasicLauncherTest.java Changeset: c11a9bfd9c2f Author: shade Date: 2016-05-06 17:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c11a9bfd9c2f 8155965: Unsafe.weakCompareAndSetVolatile entry points and intrinsics Reviewed-by: psandoz, vlivanov ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 72b2e58a1ac4 Author: vlivanov Date: 2016-05-06 19:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/72b2e58a1ac4 Merge ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 1ea5529a8988 Author: vlivanov Date: 2016-05-11 00:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1ea5529a8988 Merge ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: b64581fa1b03 Author: vlivanov Date: 2016-05-10 21:38 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b64581fa1b03 Merge Changeset: 3eea6819cc1f Author: amurillo Date: 2016-05-14 09:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3eea6819cc1f Merge ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java - test/sun/tools/jinfo/JInfoHelper.java - test/sun/tools/jinfo/JInfoLauncherTest.java - test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java - test/sun/tools/jinfo/JInfoRunningProcessTest.java - test/sun/tools/jinfo/JInfoSanityTest.java - test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java - test/sun/tools/jmap/heapconfig/TmtoolTestScenario.java Changeset: 2ac07d4a97d4 Author: amurillo Date: 2016-05-17 05:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2ac07d4a97d4 Merge ! src/java.base/share/classes/java/lang/invoke/VarHandle.java - src/java.httpclient/share/classes/java/net/http/HttpHeaders1.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginContext.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java ! test/java/lang/invoke/VarHandles/VarHandleBaseTest.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 0c3d4e928055 Author: amurillo Date: 2016-05-17 07:43 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c3d4e928055 Merge Changeset: 977cd1ec2fa3 Author: dfuchs Date: 2016-05-17 19:24 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/977cd1ec2fa3 8139982: Re-examine java.management dependency on java.util.logging.LoggingMXBean Summary: The logging MXBean implementation no longer implements java.util.logging.LoggingMXBean. java.lang.management.PlatformLoggingMXBean is used instead. java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are now deprecated. Types and accessors defined in java.lang.management should be used instead. Reviewed-by: mchung ! src/java.logging/share/classes/java/util/logging/LogManager.java ! src/java.logging/share/classes/java/util/logging/Logging.java ! src/java.logging/share/classes/java/util/logging/LoggingMXBean.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/java.management/share/classes/sun/management/ManagementFactoryHelper.java ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java Changeset: e4f9d7cf7ace Author: erikj Date: 2016-05-03 15:35 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e4f9d7cf7ace 8136777: Introduce bundle targets Reviewed-by: tbell, ihse ! make/Import.gmk Changeset: 5c8e80138e53 Author: shade Date: 2016-05-17 22:28 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5c8e80138e53 8157171: Hook up Unsafe.weakCompareAndSetVolatile to VarHandles Reviewed-by: psandoz, redestad ! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 1aa088ea72cb Author: bpb Date: 2016-05-17 16:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1aa088ea72cb 8130679: Writer/StringWriter.write methods do not specify index out bounds Summary: Add throws tag indicating IndexOutOfBoundsExcepion to write() methods which have an index parameter. Reviewed-by: chegar, prappo, rriggs ! src/java.base/share/classes/java/io/BufferedWriter.java ! src/java.base/share/classes/java/io/CharArrayWriter.java ! src/java.base/share/classes/java/io/FilterWriter.java ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PipedWriter.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/io/StringWriter.java ! src/java.base/share/classes/java/io/Writer.java Changeset: b512ec747d12 Author: mli Date: 2016-05-17 19:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b512ec747d12 8157011: Problem list tools/pack200/TestNormal.java and java/io/pathNames/GeneralWin32.java Reviewed-by: darcy ! test/ProblemList.txt Changeset: f735e227cd74 Author: martin Date: 2016-05-16 11:42 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f735e227cd74 8157069: Assorted ZipFile improvements Reviewed-by: sherman ! src/java.base/share/classes/java/util/zip/ZipFile.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java Changeset: fd39cefc5c8f Author: mhaupt Date: 2016-05-18 10:42 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd39cefc5c8f 8156915: introduce MethodHandle factory for array length Reviewed-by: sundar ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/ArrayLengthTest.java Changeset: 3bf3f8ac5f37 Author: sundar Date: 2016-05-18 15:03 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bf3f8ac5f37 8154192: Deprivilege java.scripting module Reviewed-by: jlaskey, alanb ! src/java.base/share/conf/security/java.policy ! test/javax/script/ProviderTest.sh Changeset: 7a2e220a737d Author: alanb Date: 2016-05-18 11:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7a2e220a737d 8156972: java/lang/reflect/Layer/LayerAndLoadersTest.java test requires jdk.compiler Reviewed-by: alanb Contributed-by: alexandre.iline at oracle.com ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java ! test/lib/testlibrary/CompilerUtils.java Changeset: 5f52de8fe40c Author: serb Date: 2016-05-18 16:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5f52de8fe40c 8156581: Cleanup of ProblemList.txt Reviewed-by: prr, alexsch ! test/ProblemList.txt Changeset: c6273069a5ad Author: xuelei Date: 2016-05-18 14:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c6273069a5ad 8157035: Use stronger algorithms and keys for JSSE testing Reviewed-by: weijun, jnimeh + test/javax/net/ssl/etc/README ! test/javax/net/ssl/etc/keystore ! test/javax/net/ssl/etc/truststore Changeset: f562a2f90620 Author: michaelm Date: 2016-05-18 16:39 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f562a2f90620 8157107: HTTP/2 client may fail with NPE if additional logging enabled Reviewed-by: michaelm Contributed-by: artem.smotrakov at oracle.com ! src/java.httpclient/share/classes/java/net/http/AsyncSSLDelegate.java ! src/java.httpclient/share/classes/java/net/http/Log.java + test/java/net/httpclient/http2/TLSConnection.java ! test/java/net/httpclient/http2/java.httpclient/java/net/http/Http2TestServer.java Changeset: 3675fb8573d4 Author: psandoz Date: 2016-05-18 18:46 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3675fb8573d4 8157152: Atomic add for VarHandle byte[]/ByteBuffer views is incorrect for endian conversion Reviewed-by: fyuan, shade, vlivanov ! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/generate-vh-tests.sh Changeset: 724ba3ead0a0 Author: serb Date: 2016-04-25 19:14 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/724ba3ead0a0 7124381: DragSourceListener.dragDropEnd() never been called on completion of dnd operation Reviewed-by: yan, ssadetsky - test/java/awt/dnd/Button2DragTest/Button2DragTest.html ! test/java/awt/dnd/Button2DragTest/Button2DragTest.java Changeset: ee787ce3d454 Author: aniyogi Date: 2016-04-27 12:08 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ee787ce3d454 8152492: [macosx swing] double key event actions when using Mac menubar Reviewed-by: serb, mhalder, alexsch ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 7d969c1f114c Author: mhalder Date: 2016-04-27 13:09 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7d969c1f114c 8151136: [macosx] According to the description, the case is failed Reviewed-by: ssadetsky, aniyogi ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m ! test/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java Changeset: 0c54d48f3380 Author: avstepan Date: 2016-04-28 19:35 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0c54d48f3380 8155021: [TEST] create one more inheritance test for @BeanProperty Reviewed-by: serb ! test/java/beans/Introspector/AnonymousClassBeanPropertyTest.java ! test/java/beans/Introspector/BeanPropertyTest.java + test/java/beans/Introspector/InheritanceBeanPropertyTest.java Changeset: 00e38df615a2 Author: alexsch Date: 2016-04-28 23:48 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/00e38df615a2 8152677: [macosx] All files filter can't be selected in JFileChooser Reviewed-by: serb ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java + test/javax/swing/JFileChooser/8152677/SelectAllFilesFilterTest.java Changeset: 2de40053200a Author: serb Date: 2016-04-29 15:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2de40053200a 8143346: Broken link in java.beans.XMLEncoder Reviewed-by: prr ! src/demo/share/jvmti/index.html ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/beans/XMLDecoder.java ! src/java.desktop/share/classes/java/beans/XMLEncoder.java ! src/java.desktop/share/classes/javax/swing/JRootPane.java ! src/java.desktop/share/classes/javax/swing/colorchooser/package.html ! src/java.desktop/share/classes/javax/swing/event/package.html ! src/java.desktop/share/classes/javax/swing/filechooser/package.html ! src/java.desktop/share/classes/javax/swing/package.html ! src/java.desktop/share/classes/javax/swing/plaf/basic/package.html ! src/java.desktop/share/classes/javax/swing/plaf/metal/package.html ! src/java.desktop/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/java.desktop/share/classes/javax/swing/plaf/multi/package.html ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/package.html ! src/java.desktop/share/classes/javax/swing/plaf/package.html ! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/java.desktop/share/classes/javax/swing/table/package.html ! src/java.desktop/share/classes/javax/swing/text/Document.java ! src/java.desktop/share/classes/javax/swing/text/html/package.html ! src/java.desktop/share/classes/javax/swing/text/html/parser/package.html ! src/java.desktop/share/classes/javax/swing/text/package.html ! src/java.desktop/share/classes/javax/swing/text/rtf/package.html ! src/java.desktop/share/classes/javax/swing/tree/package.html ! src/java.desktop/share/classes/javax/swing/undo/package.html Changeset: eea841d93980 Author: prr Date: 2016-04-29 09:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eea841d93980 8039444: Swing applications not being displayed properly Reviewed-by: serb, vadim ! src/java.desktop/windows/native/libawt/java2d/d3d/D3DBadHardware.h Changeset: 29de7259a224 Author: alexsch Date: 2016-04-29 21:59 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/29de7259a224 8017112: JTabbedPane components have inconsistent accessibility tree Reviewed-by: ptbrunet, serb ! src/java.desktop/share/classes/java/awt/Component.java + test/javax/accessibility/8017112/AccessibleIndexInParentTest.java Changeset: 04b0734e6714 Author: bpb Date: 2016-04-29 11:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/04b0734e6714 8151323: GeoTIFFTagSet#"ModelTiePointTag" name case does not match GeoTIFF specification Summary: Change occurrences of "ModelTiePoint" to "ModelTiepoint." Reviewed-by: prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java Changeset: 179b1e28b42b Author: prr Date: 2016-04-29 11:54 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/179b1e28b42b Merge - make/launcher/Launcher-jdk.jvmstat.rmi.gmk - src/java.base/share/classes/jdk/net/ExtendedSocketOptions.java - src/java.base/share/classes/jdk/net/NetworkPermission.java - src/java.base/share/classes/jdk/net/SocketFlow.java - src/java.base/share/classes/jdk/net/Sockets.java - src/java.base/share/classes/jdk/net/package-info.java - src/java.base/share/classes/sun/net/ExtendedOptionsImpl.java - src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java - src/java.base/unix/native/libnet/ExtendedOptionsImpl.c - src/java.base/windows/native/libnet/ExtendedOptionsImpl.c - src/jdk.jvmstat.rmi/share/classes/module-info.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteHost.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/RemoteVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/monitor/remote/package.html - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostProvider.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/MonitoredHostRmiService.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/PerfDataBuffer.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteMonitoredVm.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/RemoteVmManager.java - src/jdk.jvmstat.rmi/share/classes/sun/jvmstat/perfdata/monitor/protocol/rmi/package.html - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/Jstatd.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteHostImpl.java - src/jdk.jvmstat.rmi/share/classes/sun/tools/jstatd/RemoteVmImpl.java - test/sanity/client/lib/Jemmy2Ext/src/org/jemmy2ext/JemmyExt.java Changeset: 317292ee864e Author: bpb Date: 2016-04-29 14:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/317292ee864e 8149810: TIFFField#getAsLong throws ClassCastException when data is type TIFFTag.TIFF_DOUBLE or TIFFTag.FLOAT Summary: Expand the getAsLong() specification and handle the TIFF_DOUBLE and TIFF_FLOAT cases. Reviewed-by: prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java Changeset: b6e6e3667a77 Author: prr Date: 2016-04-29 16:37 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b6e6e3667a77 8155772: gtk3_interface.c compilation error on Ubuntu 12.10 Reviewed-by: serb, kcr ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: 50c23e46c0f1 Author: serb Date: 2016-05-02 12:01 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/50c23e46c0f1 8154493: AppletViewer should emit its deprecation warning to standard error Reviewed-by: smarks ! src/java.desktop/share/classes/sun/applet/Main.java ! test/sun/applet/DeprecatedAppletViewer/DeprecatedAppletViewer.java Changeset: ab6c0eba9dd4 Author: serb Date: 2016-05-02 12:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ab6c0eba9dd4 8027324: The spec for Toolkit.setDynamicLayout() and Toolkit.isDynamicLayoutActive() needs to be clarified Reviewed-by: alexsch, prr ! src/java.desktop/share/classes/java/awt/Toolkit.java ! test/java/awt/Toolkit/DynamicLayout/bug7172833.java Changeset: 2181e47fdafb Author: bpb Date: 2016-05-03 09:48 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2181e47fdafb 8149560: TIFFField#createFromMetadataNode throws a NullPointerException when the node is set with "tagNumber" attribute Summary: In the specification of createFromMetadataNode() change "tagNumber" to "number" and add two throws clauses which match the behavior. Reviewed-by: prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java Changeset: bd2eb98cc819 Author: prr Date: 2016-05-03 12:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/bd2eb98cc819 Merge - src/java.base/share/classes/jdk/internal/module/Hasher.java - test/javax/transaction/testng/TEST.properties - test/tools/jlink/hashes/HashesTest.java - test/tools/jlink/hashes/newsrc/m2/module-info.java - test/tools/jlink/hashes/newsrc/m2/org/m2/Util.java - test/tools/jlink/hashes/newsrc/not_matched/module-info.java - test/tools/jlink/hashes/newsrc/not_matched/org/not_matched/Name.java - test/tools/jlink/hashes/src/m1/module-info.java - test/tools/jlink/hashes/src/m1/org/m1/Main.java - test/tools/jlink/hashes/src/m2/module-info.java - test/tools/jlink/hashes/src/m2/org/m2/Util.java - test/tools/jlink/hashes/src/not_matched/module-info.java - test/tools/jlink/hashes/src/not_matched/org/not_matched/Name.java - test/tools/launcher/modules/addmods/src/app/Main.java - test/tools/launcher/modules/addmods/src/lib/jdk/lib/Util.java - test/tools/launcher/modules/addmods/src/lib/module-info.java Changeset: 3ec296bfac48 Author: serb Date: 2016-05-04 01:03 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3ec296bfac48 6729836: JavaSound treats large file sizes as negative and cannot read or skip Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/media/sound/AiffFileFormat.java ! src/java.desktop/share/classes/com/sun/media/sound/AiffFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/AuFileFormat.java ! src/java.desktop/share/classes/com/sun/media/sound/AuFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java + src/java.desktop/share/classes/com/sun/media/sound/StandardFileFormat.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveFileFormat.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveFileReader.java ! src/java.desktop/share/classes/com/sun/media/sound/WaveFloatFileReader.java + test/javax/sound/sampled/spi/AudioFileReader/RecognizeHugeAiffFiles.java + test/javax/sound/sampled/spi/AudioFileReader/RecognizeHugeAuFiles.java ! test/javax/sound/sampled/spi/AudioFileReader/RecognizeHugeWaveExtFiles.java + test/javax/sound/sampled/spi/AudioFileReader/RecognizeHugeWaveFiles.java - test/javax/sound/sampled/spi/AudioFileReader/RecognizeHugeWaveFloatFiles.java Changeset: 79e1491172d8 Author: bpb Date: 2016-05-04 10:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79e1491172d8 8149816: TIFFField#getValueAsString result is unexpected for RATIONAL and SRATIONAL types (when modulo is 0) Summary: Add more precision to the specification verbiage of getValueAsString(). Reviewed-by: prr ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/TIFFField.java Changeset: 9a4ad3ce0cc2 Author: serb Date: 2016-05-05 01:30 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9a4ad3ce0cc2 8151786: [TESTBUG] java/beans/XMLEncoder/Test4625418.java timed out intermittently Reviewed-by: alexsch, yan ! test/java/beans/XMLEncoder/Test4625418.java Changeset: cb377ca426ac Author: arapte Date: 2016-05-05 14:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cb377ca426ac 6384991: TrayIcon ActionListener called at wrong time Reviewed-by: rchamyal, serb ! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java ! test/java/awt/TrayIcon/TrayIconMouseTest/TrayIconMouseTest.java Changeset: 80766aba7d32 Author: arapte Date: 2016-05-05 14:56 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/80766aba7d32 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows Reviewed-by: rchamyal, serb ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp ! test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java ! test/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java Changeset: ec2d975eb429 Author: mhalder Date: 2016-05-05 16:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ec2d975eb429 8137137: [macosx] The native dialog doesn't have 'close'(X) button on Mac Reviewed-by: psadhukhan, prr - test/java/awt/print/Dialog/RestoreActiveWindowTest/RestoreActiveWindowTest.html ! test/java/awt/print/Dialog/RestoreActiveWindowTest/RestoreActiveWindowTest.java Changeset: 030b8fcf464f Author: arapte Date: 2016-05-06 17:43 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/030b8fcf464f 8154328: [TEST_BUG] java/awt/TrayIcon/ActionEventTest/ActionEventTest.java Reviewed-by: serb, rchamyal ! test/java/awt/TrayIcon/ActionEventTest/ActionEventTest.java Changeset: f1b8c637b4d5 Author: bpb Date: 2016-05-06 12:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f1b8c637b4d5 8156459: SimpleCMYKColorSpace serialVersionUID is inappropriate Summary: Generate an appropriate value using the 'serialver' command. Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java Changeset: 7f4937b44d50 Author: serb Date: 2016-05-09 12:55 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f4937b44d50 8155071: AppletViewer should print the deprecation warning that the Applet API is deprecated Reviewed-by: prr, smarks ! src/java.desktop/share/classes/sun/applet/resources/MsgAppletViewer.java ! test/sun/applet/DeprecatedAppletViewer/DeprecatedAppletViewer.java Changeset: 1c101d82d192 Author: prr Date: 2016-05-09 08:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1c101d82d192 Merge - make/data/classlist/classlist.aix - make/data/classlist/classlist.linux - make/data/classlist/classlist.macosx - make/data/classlist/classlist.solaris - make/data/classlist/classlist.windows - src/java.base/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java - src/java.base/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m - test/sun/security/provider/SecureRandom/SelfSeed.java Changeset: 93fbec877e52 Author: prr Date: 2016-05-09 09:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/93fbec877e52 8155682: Get rid of legacy Windows Flags for DX Reviewed-by: serb, jgodinez ! src/java.desktop/windows/classes/sun/java2d/windows/WindowsFlags.java ! src/java.desktop/windows/native/libawt/java2d/windows/WindowsFlags.cpp ! src/java.desktop/windows/native/libawt/java2d/windows/WindowsFlags.h Changeset: 43061a625cc6 Author: yan Date: 2016-05-10 12:15 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/43061a625cc6 8156128: Tests for [AWT/Swing] Conditional support for GTK 3 on Linux Reviewed-by: prr + test/javax/swing/LookAndFeel/8145547/DemandGTK.java + test/javax/swing/LookAndFeel/8145547/DemandGTK2.sh + test/javax/swing/LookAndFeel/8145547/DemandGTK2.txt + test/javax/swing/LookAndFeel/8145547/DemandGTK3.sh + test/javax/swing/LookAndFeel/8145547/ProvokeGTK.java Changeset: 597626072716 Author: pkbalakr Date: 2016-05-10 16:08 +0530 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/597626072716 6421058: When calls JSpinner.setEditor() the font in a JSpinner become is a bold. Reviewed-by: serb, alexsch ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/javax/swing/JSpinner/6421058/bug6421058.java Changeset: 7f6e7d69a033 Author: prr Date: 2016-05-12 09:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7f6e7d69a033 8154546: Retire sun.misc.GThreadHelper Reviewed-by: serb, chegar, kcr ! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c - src/jdk.unsupported/unix/classes/sun/misc/GThreadHelper.java Changeset: 7cd62a82f4a6 Author: alexsch Date: 2016-05-12 20:43 +0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7cd62a82f4a6 8154539: Examine the desktop module's use of sun.misc.SoftCache Reviewed-by: prr, chegar, mchung ! src/java.desktop/share/classes/module-info.java + src/java.desktop/share/classes/sun/awt/SoftCache.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/image/MultiResolutionToolkitImage.java - src/jdk.unsupported/share/classes/sun/misc/SoftCache.java ! test/com/sun/jdi/ReferrersTest.java Changeset: 877bccceacb9 Author: prr Date: 2016-05-12 11:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/877bccceacb9 Merge - make/non-build-utils/src/build/tools/makeclasslist/makeClasslist.js - make/src/classes/build/tools/addjsum/AddJsum.java - src/java.base/share/classes/java/util/regex/UnicodeProp.java - src/java.httpclient/share/classes/java/net/http/CharsetToolkit.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/CGIHandler.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpAwareServerSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpReceiveSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendOutputStream.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIDirectSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToCGISocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIHttpToPortSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/RMISocketInfo.java - src/java.rmi/share/classes/sun/rmi/transport/proxy/WrappedSocket.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SortResourcesPlugin.java - test/java/rmi/transport/httpSocket/HttpSocketTest.java - test/java/rmi/transport/httpSocket/HttpSocketTest_Stub.java - test/java/rmi/transport/httpSocket/security.policy - test/java/util/jar/JarFile/MultiReleaseJarAPI.java - test/java/util/jar/JarFile/MultiReleaseJarHttpProperties.java - test/java/util/jar/JarFile/MultiReleaseJarIterators.java - test/java/util/jar/JarFile/MultiReleaseJarProperties.java - test/java/util/jar/JarFile/MultiReleaseJarSecurity.java - test/sun/rmi/transport/proxy/DisableHttpDefaultValue.java - test/sun/rmi/transport/proxy/EagerHttpFallback.java - test/sun/rmi/transport/tcp/blockAccept/BlockAcceptTest.java - test/sun/rmi/transport/tcp/blockAccept/TestIface.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl.java - test/sun/rmi/transport/tcp/blockAccept/TestImpl_Stub.java - test/sun/rmi/transport/tcp/blockAccept/security.policy - test/tools/jlink/plugins/SorterPluginTest.java Changeset: 6968aa3bf5ac Author: vadim Date: 2016-05-13 11:31 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6968aa3bf5ac 8047931: Remove unused medialib code Reviewed-by: bae ! make/lib/Awt2dLibraries.gmk ! src/java.desktop/share/native/libmlib_image/mlib_ImageAffine.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageAffine.h ! src/java.desktop/share/native/libmlib_image/mlib_ImageAffineEdge.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageCheck.h - src/java.desktop/share/native/libmlib_image/mlib_ImageColorTrue2Index.c - src/java.desktop/share/native/libmlib_image/mlib_ImageColormap.h ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv.h - src/java.desktop/share/native/libmlib_image/mlib_ImageConv2x2_f.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16ext.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_32nw.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8ext.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8nw.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_D64nw.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_F32nw.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16ext.c ! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16nw.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageAffineIndex_BC.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageAffineIndex_BL.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageBlendTable.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageBlendTable.h ! src/java.desktop/share/native/libmlib_image/mlib_c_ImageConv.h ! src/java.desktop/share/native/libmlib_image/mlib_c_ImageConv_f.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageThresh1.h - src/java.desktop/share/native/libmlib_image/mlib_c_ImageThresh1_U8.c ! src/java.desktop/share/native/libmlib_image/mlib_image.h - src/java.desktop/share/native/libmlib_image/mlib_image_blend_proto.h ! src/java.desktop/share/native/libmlib_image/mlib_image_proto.h - src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy.c - src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s - src/java.desktop/unix/native/libawt/awt/medialib/vis_asi.h - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffineIndex_BC.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL_S16.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffine_BL_U16.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract.h ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract_1.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract_43.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract_f.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert.h ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert_1.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert_34.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConv.h - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvIndex3_8_16nw.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvIndex3_8_8nw.c ! src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConv_8nw.c Changeset: 4d5055837809 Author: dmarkov Date: 2016-05-13 12:44 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4d5055837809 8155001: SystemTray.remove() leaks GDI Objects in Windows Reviewed-by: serb, alexp ! src/java.desktop/windows/native/libawt/windows/awt_TrayIcon.cpp Changeset: 5ce4dee49b11 Author: prr Date: 2016-05-18 09:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/5ce4dee49b11 Merge ! make/lib/Awt2dLibraries.gmk - src/java.httpclient/share/classes/java/net/http/HttpHeaders1.java - src/jdk.crypto.ucrypto/solaris/native/libj2ucrypto/libsoftcrypto.h - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginContext.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java - test/sun/tools/jinfo/JInfoHelper.java - test/sun/tools/jinfo/JInfoLauncherTest.java - test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java - test/sun/tools/jinfo/JInfoRunningProcessTest.java - test/sun/tools/jinfo/JInfoSanityTest.java - test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java - test/sun/tools/jmap/heapconfig/TmtoolTestScenario.java Changeset: 6b5c8b0f6b74 Author: jlahoda Date: 2016-05-18 21:00 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6b5c8b0f6b74 8133549: Generalize jshell's EditingHistory Summary: Adding a generic EditingHistory to jdk.internal.le, for use by both jjs and jshell Reviewed-by: sundar ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java + src/jdk.internal.le/share/classes/jdk/internal/jline/extra/EditingHistory.java ! src/jdk.internal.le/share/classes/module-info.java + test/jdk/internal/jline/extra/HistoryTest.java Changeset: 13dc4460ec4a Author: xuelei Date: 2016-05-18 22:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/13dc4460ec4a 8151856: Note that disabledAlgorithms override the same algorithms of legacyAlgorithms Reviewed-by: mullan, weijun ! src/java.base/share/conf/security/java.security Changeset: eb272e1c31b7 Author: rhalade Date: 2016-05-18 16:36 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/eb272e1c31b7 8156035: Remove intermittent key from sun/security/rsa/SpecTest.java Reviewed-by: mullan ! test/sun/security/rsa/SpecTest.java Changeset: c7550333c4ba Author: ksrini Date: 2016-05-18 11:31 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c7550333c4ba 8156807: Pack200 must support v53.0 class files Reviewed-by: mchung, shade ! src/java.base/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/jdk.pack200/share/native/common-unpack/constants.h ! test/ProblemList.txt ! test/tools/pack200/TestNormal.java ! test/tools/pack200/Utils.java Changeset: 75472c0614d5 Author: srastogi Date: 2016-05-19 11:13 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/75472c0614d5 8149574: Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass() Reviewed-by: vlivanov, psandoz, sundar, mhaupt ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java Changeset: 798214298782 Author: ssahoo Date: 2016-05-19 04:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/798214298782 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations Reviewed-by: weijun + test/java/security/SecureRandom/ApiTest.java + test/java/security/SecureRandom/EnoughSeedTest.java ! test/java/security/SecureRandom/GetAlgorithm.java + test/java/security/SecureRandom/GetInstanceTest.java + test/java/security/SecureRandom/MultiThreadTest.java + test/java/security/SecureRandom/SerializedSeedTest.java ! test/sun/security/provider/SecureRandom/StrongSecureRandom.java ! test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Changeset: 7af9466123ed Author: alanb Date: 2016-05-19 13:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7af9466123ed 8157290: jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java failing Reviewed-by: chegar ! test/jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java + test/jdk/modules/scenarios/overlappingpackages/src/misc/jdk/internal/misc/Unsafe.java ! test/jdk/modules/scenarios/overlappingpackages/src/misc/module-info.java - test/jdk/modules/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java Changeset: 667006897700 Author: alanb Date: 2016-05-19 13:10 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/667006897700 8148834: Update module-info reader/writer to 53.0 Reviewed-by: sundar, chegar ! src/java.base/share/classes/java/lang/module/ModuleInfo.java ! src/java.base/share/classes/jdk/internal/module/ModuleInfoWriter.java Changeset: 4f217f656946 Author: aefimov Date: 2016-05-19 15:58 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4f217f656946 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg Reviewed-by: shade, joehw ! test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java Changeset: c79af458bd7d Author: aefimov Date: 2016-05-19 16:08 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/c79af458bd7d 8072579: XjcOptionalPropertyTest.java creates files in test.src Reviewed-by: joehw ! test/javax/xml/bind/xjc/8032884/XjcOptionalPropertyTest.java - test/javax/xml/bind/xjc/8032884/compile-schema.sh Changeset: a3f13b375854 Author: shade Date: 2016-05-19 16:59 +0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/a3f13b375854 8148604: JEP 280, Switch to more optimal concatenation strategy Reviewed-by: psandoz, redestad ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Changeset: 099857ef9d0c Author: psandoz Date: 2016-05-19 16:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/099857ef9d0c 8157239: java/lang/invoke/VarHandles/ tests fail by timeout with -Xcomp with lambda form linkage Reviewed-by: vlivanov ! test/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestAccessString.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java ! test/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java ! test/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template ! test/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template Changeset: 123da3a60133 Author: asmotrak Date: 2016-05-19 09:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/123da3a60133 8134267: javax/net/ssl/TLS/TestJSSE.java fails intermittently with BindException: Address already in use Reviewed-by: chegar ! test/javax/net/ssl/TLS/CipherTestUtils.java ! test/javax/net/ssl/TLS/JSSEServer.java ! test/javax/net/ssl/TLS/TestJSSE.java Changeset: e53f8c34880e Author: mchung Date: 2016-05-19 11:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e53f8c34880e 8157068: ExceptionInInitializerError if images build patched to use exploded version of jdk.internal.module.SystemModules Reviewed-by: alanb ! src/java.base/share/classes/java/lang/module/SystemModuleFinder.java ! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java ! src/java.base/share/classes/jdk/internal/module/SystemModules.java - test/tools/launcher/modules/patch/PatchTest.java + test/tools/launcher/modules/patch/basic/PatchTest.java + test/tools/launcher/modules/patch/basic/src/test/jdk/test/Main.java + test/tools/launcher/modules/patch/basic/src/test/module-info.java + test/tools/launcher/modules/patch/basic/src1/java.base/java/text/Annotation.java + test/tools/launcher/modules/patch/basic/src1/java.base/java/text/AnnotationBuddy.java + test/tools/launcher/modules/patch/basic/src1/jdk.compiler/com/sun/tools/javac/Main.java + test/tools/launcher/modules/patch/basic/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java + test/tools/launcher/modules/patch/basic/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java + test/tools/launcher/modules/patch/basic/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java + test/tools/launcher/modules/patch/basic/src2/java.base/java/lang2/Object.java + test/tools/launcher/modules/patch/basic/src2/jdk.compiler/com/sun/tools/javac2/Main.java + test/tools/launcher/modules/patch/basic/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java - test/tools/launcher/modules/patch/src/test/jdk/test/Main.java - test/tools/launcher/modules/patch/src/test/module-info.java - test/tools/launcher/modules/patch/src1/java.base/java/text/Annotation.java - test/tools/launcher/modules/patch/src1/java.base/java/text/AnnotationBuddy.java - test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java - test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java - test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java - test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java - test/tools/launcher/modules/patch/src2/java.base/java/lang2/Object.java - test/tools/launcher/modules/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java - test/tools/launcher/modules/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java + test/tools/launcher/modules/patch/systemmodules/PatchSystemModules.java + test/tools/launcher/modules/patch/systemmodules/src/m1/module-info.java + test/tools/launcher/modules/patch/systemmodules/src/m1/p1/Main.java + test/tools/launcher/modules/patch/systemmodules/src/m2/module-info.java + test/tools/launcher/modules/patch/systemmodules/src/m2/p2/Lib.java + test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java + test/tools/launcher/modules/patch/systemmodules/src1/m2/p2/Lib.java Changeset: 3976fadb091d Author: iris Date: 2016-05-19 12:04 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3976fadb091d 8144062: Move jdk.Version to java.lang.Runtime.Version Reviewed-by: abuckley, alanb, forax, jjg, mchung, psandoz ! src/java.base/share/classes/java/lang/Runtime.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/util/jar/JarFile.java - src/java.base/share/classes/jdk/Version.java ! src/java.base/share/classes/module-info.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/JarFileSystem.java + test/java/lang/Runtime/Version/Basic.java ! test/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java ! test/java/util/jar/JarFile/mrjar/MultiReleaseJarIterators.java ! test/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java ! test/java/util/jar/JarFile/mrjar/MultiReleaseJarSecurity.java - test/jdk/Version/Basic.java ! test/jdk/nio/zipfs/MultiReleaseJarTest.java ! test/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java Changeset: 6efc826d3cd0 Author: lana Date: 2016-05-19 19:46 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/6efc826d3cd0 Merge - src/java.desktop/share/native/libmlib_image/mlib_ImageColorTrue2Index.c - src/java.desktop/share/native/libmlib_image/mlib_ImageColormap.h - src/java.desktop/share/native/libmlib_image/mlib_ImageConv2x2_f.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageAffineIndex_BC.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageAffineIndex_BL.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageBlendTable.c - src/java.desktop/share/native/libmlib_image/mlib_c_ImageBlendTable.h - src/java.desktop/share/native/libmlib_image/mlib_c_ImageThresh1.h - src/java.desktop/share/native/libmlib_image/mlib_c_ImageThresh1_U8.c - src/java.desktop/share/native/libmlib_image/mlib_image_blend_proto.h - src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy.c - src/java.desktop/unix/native/libawt/awt/medialib/mlib_v_ImageCopy_blk.s - src/java.desktop/unix/native/libawt/awt/medialib/vis_asi.h - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageAffineIndex_BC.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelExtract_f.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageChannelInsert_34.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvIndex3_8_16nw.c - src/java.desktop/unix/native/libmlib_image/mlib_v_ImageConvIndex3_8_8nw.c - src/java.httpclient/share/classes/java/net/http/HttpHeaders1.java - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProvider.java - src/jdk.jcmd/share/classes/jdk/internal/vm/agent/spi/ToolProviderFinder.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginContextImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PoolImpl.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/PluginContext.java - src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java - src/jdk.unsupported/share/classes/sun/misc/SoftCache.java - src/jdk.unsupported/unix/classes/sun/misc/GThreadHelper.java - test/java/awt/dnd/Button2DragTest/Button2DragTest.html - test/java/awt/print/Dialog/RestoreActiveWindowTest/RestoreActiveWindowTest.html - test/javax/sound/sampled/spi/AudioFileReader/RecognizeHugeWaveFloatFiles.java - test/javax/xml/bind/xjc/8032884/compile-schema.sh - test/jdk/modules/scenarios/overlappingpackages/src/misc/sun/misc/Unsafe.java - test/sun/tools/jinfo/JInfoHelper.java - test/sun/tools/jinfo/JInfoLauncherTest.java - test/sun/tools/jinfo/JInfoRunningProcessFlagTest.java - test/sun/tools/jinfo/JInfoRunningProcessTest.java - test/sun/tools/jinfo/JInfoSanityTest.java - test/sun/tools/jmap/heapconfig/JMapHeapConfigTest.java - test/sun/tools/jmap/heapconfig/TmtoolTestScenario.java - test/tools/launcher/modules/patch/PatchTest.java - test/tools/launcher/modules/patch/src/test/jdk/test/Main.java - test/tools/launcher/modules/patch/src/test/module-info.java - test/tools/launcher/modules/patch/src1/java.base/java/text/Annotation.java - test/tools/launcher/modules/patch/src1/java.base/java/text/AnnotationBuddy.java - test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/Main.java - test/tools/launcher/modules/patch/src1/jdk.compiler/com/sun/tools/javac/MainBuddy.java - test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClient.java - test/tools/launcher/modules/patch/src1/jdk.naming.dns/com/sun/jndi/dns/DnsClientBuddy.java - test/tools/launcher/modules/patch/src2/java.base/java/lang2/Object.java - test/tools/launcher/modules/patch/src2/jdk.compiler/com/sun/tools/javac2/Main.java - test/tools/launcher/modules/patch/src2/jdk.naming.dns/com/sun/jndi/dns2/Zone.java Changeset: f0c1d4d90df6 Author: lana Date: 2016-05-19 20:14 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f0c1d4d90df6 Merge Changeset: 586ba42ec91d Author: ascarpino Date: 2016-05-19 16:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/586ba42ec91d 8155847: SHA groups needed for jdk.security.provider.preferred Reviewed-by: valeriep, mullan ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/conf/security/java.security ! test/sun/security/jca/PreferredProviderTest.java Changeset: 01a8615439f0 Author: bchristi Date: 2016-05-19 16:25 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/01a8615439f0 8029891: Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java Summary: Properties now stores values in an internal ConcurrentHashMap Reviewed-by: mchung, dholmes, plevart ! src/java.base/share/classes/java/util/Hashtable.java ! src/java.base/share/classes/java/util/Properties.java ! test/ProblemList.txt ! test/java/lang/ClassLoader/deadlock/GetResource.java + test/java/util/Properties/CheckOverrides.java + test/java/util/Properties/CheckUnsynchronized.java + test/java/util/Properties/PropertiesSerialization.java Changeset: 3bcf2d4fdb54 Author: asmotrak Date: 2016-05-19 19:45 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3bcf2d4fdb54 8157344: Multiple test timeouts after push for JDK-8141039 8156606: java/security/SecureRandom/Serialize.java gets time out in Linux Reviewed-by: weijun ! test/ProblemList.txt ! test/java/security/SecureRandom/ApiTest.java ! test/java/security/SecureRandom/EnoughSeedTest.java ! test/java/security/SecureRandom/Serialize.java Changeset: 0e78d0a7a517 Author: weijun Date: 2016-05-20 11:15 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0e78d0a7a517 8149521: automatic discovery of LDAP servers with Kerberos authentication Reviewed-by: vinnie ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java ! test/sun/security/krb5/canonicalize/Test.java Changeset: b244dce93e06 Author: weijun Date: 2016-05-20 11:20 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b244dce93e06 8138766: New default -sigalg for keytool Reviewed-by: mullan ! src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java + test/sun/security/tools/keytool/DefaultSignatureAlgorithm.java Changeset: 1a4e73ae20ce Author: nishjain Date: 2016-05-20 13:48 +0900 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1a4e73ae20ce 7102969: currency.properties supercede not working correctly 8149452: j.t.SimpleDateFormat.getDateFormatSymbols().getZoneStrings() returns incorrect result for some time zones 8157138: Error while fetching currency instance by Currency.getInstance(currencycode) Reviewed-by: naoto, okutsu, peytoia ! make/data/currency/CurrencyData.properties ! make/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java ! src/java.base/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh ! test/java/util/Currency/currency.properties ! test/java/util/Currency/tablea1.txt + test/java/util/TimeZone/Bug8149452.java Changeset: 078eda57a82b Author: henryjen Date: 2016-05-19 21:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/078eda57a82b 8156478: 3 Buffer overrun defect groups in jexec.c Reviewed-by: ksrini ! src/java.base/unix/native/launcher/jexec.c Changeset: 871cb8793270 Author: psandoz Date: 2016-05-20 11:47 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/871cb8793270 8130023: API java.util.stream: explicitly specify guaranteed execution of the pipeline Reviewed-by: briangoetz, redestad ! src/java.base/share/classes/java/util/stream/DoubleStream.java ! src/java.base/share/classes/java/util/stream/IntStream.java ! src/java.base/share/classes/java/util/stream/LongStream.java ! src/java.base/share/classes/java/util/stream/Stream.java ! src/java.base/share/classes/java/util/stream/package-info.java Changeset: b15047a04378 Author: mli Date: 2016-05-20 03:33 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b15047a04378 8157211: Mark tools/launcher/FXLauncherTest.java as intermittently failing Reviewed-by: psandoz ! test/tools/launcher/FXLauncherTest.java Changeset: d9f0d05b7b32 Author: psandoz Date: 2016-05-20 14:07 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d9f0d05b7b32 8157437: Typos in Stream JavaDoc Reviewed-by: shade, alanb, lancea ! src/java.base/share/classes/java/util/stream/AbstractTask.java ! src/java.base/share/classes/java/util/stream/DoubleStream.java ! src/java.base/share/classes/java/util/stream/IntStream.java ! src/java.base/share/classes/java/util/stream/LongStream.java ! src/java.base/share/classes/java/util/stream/Stream.java ! src/java.base/share/classes/java/util/stream/StreamSpliterators.java Changeset: 248c2f34cc1f Author: jlaskey Date: 2016-05-20 11:41 -0300 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/248c2f34cc1f 8156602: javac crashes again on Windows 32-bit with ClosedChannelException Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! test/TEST.groups + test/jdk/internal/jimage/JImageOpenTest.java Changeset: 0fca98a37871 Author: asmotrak Date: 2016-05-20 09:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0fca98a37871 8129389: javax/net/ssl/DTLS tests fail intermittently Reviewed-by: xuelei ! test/javax/net/ssl/DTLS/DTLSOverDatagram.java ! test/javax/net/ssl/DTLS/Reordered.java ! test/javax/net/ssl/DTLS/Retransmission.java Changeset: f08c91aa150d Author: ssahoo Date: 2016-05-20 09:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f08c91aa150d 8157417: Some of SecureRandom test might get timed out in linux Reviewed-by: weijun ! test/java/security/SecureRandom/GetInstanceTest.java ! test/java/security/SecureRandom/MultiThreadTest.java ! test/java/security/SecureRandom/SerializedSeedTest.java ! test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Changeset: 8c75ff8185c6 Author: snikandrova Date: 2016-05-20 11:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8c75ff8185c6 8155575: Provider.java contains very long lines because of lambda Reviewed-by: ascarpino ! src/java.base/share/classes/java/security/Provider.java Changeset: 7edc55ee829c Author: redestad Date: 2016-05-20 20:27 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7edc55ee829c 8157449: Adjust link-time generated Species classes to match JDK-8148604 usage Reviewed-by: shade ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/GenerateJLIClassesPlugin.java Changeset: 326aac1cc313 Author: sherman Date: 2016-05-20 12:47 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/326aac1cc313 8143282: \p{Cn} unassigned code points should be included in \p{C} Summary: to add unassigned cp support into \p{C} Reviewed-by: martin ! src/java.base/share/classes/java/util/regex/CharPredicates.java ! test/java/util/regex/RegExTest.java Changeset: fd6a2591b269 Author: chegar Date: 2016-05-20 21:44 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fd6a2591b269 8157154: jmod jlink properties file need copyright header Reviewed-by: alanb, mchung ! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties ! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties ! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod.properties Changeset: 0a58dc4f8cb4 Author: bpb Date: 2016-05-20 14:41 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a58dc4f8cb4 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently Summary: Add methods multiplyFull() and multiplyHigh() to Math and StrictMath. Reviewed-by: darcy ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java + test/java/lang/Math/MultiplicationTests.java Changeset: 116ec1a1a1ff Author: darcy Date: 2016-05-20 15:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/116ec1a1a1ff 4851777: Add BigDecimal sqrt method Reviewed-by: bpb ! src/java.base/share/classes/java/math/BigDecimal.java + test/java/math/BigDecimal/SquareRootTests.java Changeset: d9c7e8e76afc Author: rhalade Date: 2016-05-20 15:50 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d9c7e8e76afc 8157469: DefaultProviderList.java fails with no provider class apple.security.AppleProvider found Reviewed-by: valeriep ! test/java/security/Provider/DefaultProviderList.java Changeset: 1241537c9721 Author: bpb Date: 2015-09-29 17:28 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/1241537c9721 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math Summary: Add new methods with long, int signatures. Reviewed-by: darcy, scolebourne ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/LocalDate.java ! src/java.base/share/classes/java/time/LocalDateTime.java ! src/java.base/share/classes/java/time/LocalTime.java ! src/java.base/share/classes/java/time/OffsetTime.java ! src/java.base/share/classes/java/time/YearMonth.java ! src/java.base/share/classes/java/time/chrono/HijrahDate.java ! test/java/lang/Math/DivModTests.java ! test/java/lang/Math/ExactArithTests.java Changeset: 4cd0d71cf20e Author: darcy Date: 2016-05-20 16:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4cd0d71cf20e 8157487: Mark ZoneId.java as intermittently failing Reviewed-by: naoto ! test/sun/net/www/protocol/http/ZoneId.java Changeset: 70fb51b05cce Author: alanb Date: 2016-05-21 08:01 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/70fb51b05cce 8152650: ModuleFinder.compose should accept varargs Reviewed-by: mchung ! make/src/classes/build/tools/jigsaw/GenGraphs.java ! make/src/classes/build/tools/jigsaw/ModuleSummary.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleFinder.java ! src/java.base/share/classes/java/lang/reflect/Layer.java ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/jdk.jartool/share/classes/sun/tools/jar/Main.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! test/java/lang/Class/forName/modules/TestLayer.java ! test/java/lang/Class/forName/modules/src/m3/p3/NoAccess.java ! test/java/lang/module/AutomaticModulesTest.java ! test/java/lang/module/ConfigurationTest.java ! test/java/lang/module/ModuleFinderTest.java ! test/java/lang/reflect/Layer/BasicLayerTest.java ! test/java/lang/reflect/Layer/LayerAndLoadersTest.java ! test/java/lang/reflect/Proxy/ProxyClassAccessTest.java ! test/java/lang/reflect/Proxy/ProxyLayerTest.java ! test/java/util/ServiceLoader/modules/ServicesTest.java ! test/jdk/modules/scenarios/container/src/container/container/Main.java Changeset: 997dcff5075f Author: jlahoda Date: 2016-05-21 13:18 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/997dcff5075f 8157502: make docs broken after JDK-5100935 Summary: Correcting reference to Math::multiplyFull. Reviewed-by: alanb ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: 661ab876769e Author: chegar Date: 2016-05-22 19:06 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/661ab876769e 8048518: File Descriptor Leak in src/java.base/unix/native/libnet/net_util_md.c Reviewed-by: alanb, chegar ! src/java.base/unix/native/libnet/net_util_md.c Changeset: ea91cf963514 Author: darcy Date: 2016-05-22 18:23 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ea91cf963514 8157527: Replace @since 1.9 with @since 9 on new math methods Reviewed-by: chegar ! src/java.base/share/classes/java/lang/Math.java ! src/java.base/share/classes/java/lang/StrictMath.java Changeset: ad54181c91ae Author: weijun Date: 2016-05-23 09:31 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ad54181c91ae 8157526: 3KeyTDEA word left in DRBG after JDK-8156213 Reviewed-by: xuelei ! src/java.base/share/classes/java/security/DrbgParameters.java Changeset: 9f8e6c4bc12f Author: weijun Date: 2016-05-23 18:18 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9f8e6c4bc12f 8157544: Typo in CtrDrbg::toString Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/provider/CtrDrbg.java Changeset: 2253b5ac1726 Author: xuelei Date: 2016-05-23 10:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/2253b5ac1726 8046294: Generate the 4-byte timestamp randomly Reviewed-by: jnimeh, weijun ! src/java.base/share/classes/sun/security/ssl/RandomCookie.java ! src/java.base/share/classes/sun/security/ssl/Utilities.java Changeset: 0735c35f15b3 Author: michaelm Date: 2016-05-23 12:38 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0735c35f15b3 8157105: HTTP/2 client hangs in blocking mode if an invalid frame has been received Reviewed-by: rriggs ! src/java.httpclient/share/classes/java/net/http/AsyncSSLDelegate.java ! src/java.httpclient/share/classes/java/net/http/Http2Connection.java ! src/java.httpclient/share/classes/java/net/http/Queue.java ! src/java.httpclient/share/classes/java/net/http/Stream.java ! src/java.httpclient/share/classes/java/net/http/Utils.java + test/java/net/httpclient/http2/ErrorTest.java Changeset: b87b68caed0d Author: michaelm Date: 2016-05-23 12:57 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b87b68caed0d 8153142: Cannot resolve multiple values from one response header Reviewed-by: rriggs ! src/java.httpclient/share/classes/java/net/http/Http1Request.java ! src/java.httpclient/share/classes/java/net/http/ResponseHeaders.java + test/java/net/httpclient/HeadersTest1.java Changeset: 87e8d92a9f6c Author: sherman Date: 2016-05-23 12:53 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/87e8d92a9f6c 8147588: Jar file and Zip file not removed in spite of the OPEN_DELETE flag Reviewed-by: alanb ! src/java.base/share/classes/java/io/RandomAccessFile.java ! src/java.base/share/classes/java/util/zip/ZipFile.java + src/java.base/share/classes/jdk/internal/misc/JavaIORandomAccessFileAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/native/libjava/RandomAccessFile.c Changeset: e93c15465318 Author: martin Date: 2016-05-23 12:44 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/e93c15465318 8157613: Internal documentation improvements to ZipFile.java Reviewed-by: plevart, sherman ! src/java.base/share/classes/java/util/zip/ZipFile.java Changeset: ca392a5bf0ef Author: chegar Date: 2016-05-23 21:28 +0100 URL: http://hg.openjdk.java.net/jigsaw/j