From peter.firmstone at zeus.net.au Wed May 13 06:21:07 2015 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 13 May 2015 06:21:07 -0000 Subject: Policy providers in Java 9 In-Reply-To: <550FF942.9040705@oracle.com> References: <1426939964.1666.8.camel@Nokia-N900> <550E1168.7040203@oracle.com> <550FF942.9040705@oracle.com> Message-ID: <5510120F.9070503@zeus.net.au> A quick update on loading or policy providers with the application classloader on Java 8, until now we have only ever used the extension classloader. The only changes I had to make was to add the policy providers to the classpath, remove code that caused the JVM to exit if a policy provider wasn't loaded by the extension classloader and add some permissions to policy files. I have a total of approximately 2000 tests to run, initial results yielded 4 test failures out of 150, of these simple changes to policy files was all that was necessary for these tests to pass. Many of our tests use multiple jvm's communicating over networks with SecurityManager and Policy providers enabled. Will keep you posted on progress. Regards, Peter. On 23/03/2015 9:30 PM, Alan Bateman wrote: > On 22/03/2015 00:48, Mandy Chung wrote: >> : >> >> There are some SPIs that need adjustment to support loading the >> providers by the application class loader and the policy SPI >> should also be updated in JDK 9. > Right, there are a few areas that need to be updated. In the case of > java.security.Policy then it appears to have never specified how the > policy provider is located. From what I can tell then it used to only > load it via the boot loader but was relaxed later to allow for policy > providers that are "installed" into the run-time image and loaded by > the extension loader. This needs to be re-examined now and also > re-examined to see how it will work with modules going forward. > > -Alan > From javalists at cbfiddle.com Wed May 13 16:11:42 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 13 May 2015 09:11:42 -0700 Subject: internal API usage: sun.awt.CausedFocusEvent Message-ID: <180AF52F-9B82-4B21-8DB5-527953369A2F@cbfiddle.com> I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. Will there be some way of doing this in JDK9? From Alan.Bateman at oracle.com Wed May 13 17:12:26 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 May 2015 18:12:26 +0100 Subject: internal API usage: sun.awt.CausedFocusEvent In-Reply-To: <180AF52F-9B82-4B21-8DB5-527953369A2F@cbfiddle.com> References: <180AF52F-9B82-4B21-8DB5-527953369A2F@cbfiddle.com> Message-ID: <555385FA.4050808@oracle.com> On 13/05/2015 17:11, Alan Snyder wrote: > I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. > > Will there be some way of doing this in JDK9? > I don't know but maybe you could bring this up on the awt-dev list to see if there a way to do what you want with the standard API. -Alan. From javalists at cbfiddle.com Wed May 13 17:51:50 2015 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 13 May 2015 10:51:50 -0700 Subject: internal API usage: sun.awt.CausedFocusEvent In-Reply-To: <555385FA.4050808@oracle.com> References: <180AF52F-9B82-4B21-8DB5-527953369A2F@cbfiddle.com> <555385FA.4050808@oracle.com> Message-ID: <4CEFDD71-A813-455D-BACD-F15F49CDC9E5@cbfiddle.com> I will do that, but a larger question remains: Are any of the AWT classes currently reported by jdeps as ?JDK internal API? going to be accessible in JDK 9? I ask because of this comment by Stuart Marks: Unfortunately, com.sun is a mixture of internal and publicly supported ("exported") APIs. An annotation @jdk.Exported distinguishes the latter from internal APIs. Who decides which APIs get this annotation? Are these annotations in place now? Alan > On May 13, 2015, at 10:12 AM, Alan Bateman wrote: > > On 13/05/2015 17:11, Alan Snyder wrote: >> I have been using sun.awt.CausedFocusEvent to implement special behavior in response to an explicit user-initiated focus traversal to a component. The main point is that I want to inhibit this behavior for all other kinds of focus gained events. >> >> Will there be some way of doing this in JDK9? >> > I don't know but maybe you could bring this up on the awt-dev list to see if there a way to do what you want with the standard API. > > -Alan. From mandy.chung at oracle.com Wed May 13 18:08:12 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 May 2015 11:08:12 -0700 Subject: internal API usage: sun.awt.CausedFocusEvent In-Reply-To: <4CEFDD71-A813-455D-BACD-F15F49CDC9E5@cbfiddle.com> References: <180AF52F-9B82-4B21-8DB5-527953369A2F@cbfiddle.com> <555385FA.4050808@oracle.com> <4CEFDD71-A813-455D-BACD-F15F49CDC9E5@cbfiddle.com> Message-ID: <8BA1B2D1-ECAE-45A1-9A71-5719528DA5AC@oracle.com> > On May 13, 2015, at 10:51 AM, Alan Snyder wrote: > > I will do that, but a larger question remains: > > Are any of the AWT classes currently reported by jdeps as ?JDK internal API? going to be accessible in JDK 9? > No - there is no known RFE that I know of may provide a replacement for sun.awt.* classes except /JDK-8067470 (see [1] for client related internal APIs). The best is to bring up the discussion to awt-dev as Alan suggests. https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool tracks what internal APIs that have known replacement or will have supported APIs in a future release. This is a living document that will be updated if there is any new RFE to provide a replacement to existing internal APIs. > I ask because of this comment by Stuart Marks: > > Unfortunately, com.sun is a mixture of internal and publicly supported ("exported") APIs. An annotation @jdk.Exported distinguishes the latter from internal APIs. > > Who decides which APIs get this annotation? Are these annotations in place now? @jdk.Exported was added in JDK 8. I suggest you look at the exported APIs listed under: http://hg.openjdk.java.net/jdk9/dev/file/tip/modules.xml This is an interim solution to declare what APIs are exported until the module system moves further along and defines a proper module definition. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8065418 From james.laskey at oracle.com Fri May 15 15:45:02 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 15 May 2015 12:45:02 -0300 Subject: RFR: Proposed jimage refresh for JDK9 Message-ID: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. Cheers, ? Jim From Alan.Bateman at oracle.com Mon May 18 14:58:36 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 May 2015 15:58:36 +0100 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> Message-ID: <5559FE1C.1020804@oracle.com> On 15/05/2015 16:45, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ > > There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. > > Just to put a bit more context on this. As Jim says in the subject line, this is refresh of the jimage implementation in JDK 9 (that went in with the initial push of JEP 220). One of the discussion points at the time was making it a bit easier for tools using the jrt file system to locate classes and resources without knowing which module they are in. This is addressed in this update by introducing a top-level /packages directory in the jrt file system. More details in JDK-8066492 [1]. A number of tools already have early support for JDK 9 so they will need some adjustments once these changes get into JDK 9. Another issue addressed in this refresh is the startup performance when first opening the file system. This is something that has been noticeable with javac and javadoc at least. Jim can say more about the architectural changes but at a high level then access goes through a VM interface now whereas previously access from the application and extensions class loaders took different path. Another change is that the jimage file is optionally fully memory-mapped now whereas it was previously only the header. There is a XX option to control this and an open question is whether to do this by default on 32-bit and small devices. For now, there are still 3 jimages file as before but we should eventually be able to move to one once the module system goes in. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8066492 From paul.sandoz at oracle.com Mon May 18 17:07:25 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 18 May 2015 19:07:25 +0200 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> Message-ID: Hi Jim, I reviewed the JDK code. There is quite a lot and i don't understand all the semantics but it generally looks ok. Stuff below is mostly suggested API tweaks. Paul. jdk.internal.jimage.BasicImageReader -- 124 public String[] getEntryNames() { 125 int[] offsets = substrate.attributeOffsets(); 126 List list = new ArrayList<>(); 127 128 for (int offset : offsets) { 129 if (offset != 0) { 130 ImageLocation location = 131 ImageLocation.readFrom(this, offset); 132 list.add(location.getFullNameString()); 133 } 134 } 135 136 String[] array = list.toArray(new String[0]); 137 Arrays.sort(array); 138 139 return array; 140 } You can do this instead: list.sort(null); // more idiomatic for Java 8 return list.toArray(new String[list.size()]); It should be marginally more efficient just because the size information is passed to the array. Alternatively you use a stream too, depending on your perf requirements: return IntStream.of(substrate.attributeOffsets()) .filter(o -> o != 0) .mapToObj(o -> ImageLocation.readFrom(this, o).getFullNameString()) .sorted() .toArray(String[]::new); Same applies to getAllLocations: return IntStream.of(substrate.attributeOffsets()) .filter(o -> o != 0) .mapToObj(o -> ImageLocation.readFrom(this, o)) .sorted(Comparator.comparing(ImageLocation::getFullNameString)) // Use Comparator.comparing in any case for key extraction .toArray(ImageLocation[]::new); jdk.internal.jrtfs.JrtFileSystem.java -- 494 private Iterator nodesToIterator(Path path, String childPrefix, List childNodes) { 495 List childPaths; 496 if (childPrefix == null) { 497 childPaths = childNodes.stream() 498 .map(child -> toJrtPath(child.getNameString())) 499 .collect(Collectors.toCollection(ArrayList::new)); 500 } else { 501 childPaths = childNodes.stream() 502 .map(child -> toJrtPath(childPrefix + child.getNameString().substring(1))) 503 .collect(Collectors.toCollection(ArrayList::new)); 504 } 505 return childPaths.iterator(); 506 } Use Collectors.toList(). Could be marginally simplified as: Function f = childPrefix == null ? child -> toJrtPath(child.getNameString()) : child -> toJrtPath(childPrefix + child.getNameString().substring(1)); return childNodes.stream().map(f).collect(toList()).iterator(); jdk.internal.jimage.ExternalFilesWriter 93 private static String nativeDir(String filename) { 94 if (System.getProperty("os.name").startsWith("Windows")) { 95 if (filename.endsWith(".dll") || filename.endsWith(".diz") 96 || filename.endsWith(".pdb") || filename.endsWith(".map")) { 97 return "bin"; 98 } else { 99 return "lib"; 100 } 101 } else { 102 return "lib"; 103 } 104 } Does that need to be performed in a doPriv block? jdk.internal.jimage.ImageFileCreator -- 108 private void readAllEntries(Map> modulePackagesMap, 109 Set archives) { 110 archives.stream().forEach((archive) -> { 111 List archiveResources = new ArrayList<>(); 112 archive.visitEntries(x-> archiveResources.add(x)); 113 String mn = archive.moduleName(); 114 entriesForModule.put(mn, archiveResources); 115 // Extract package names 116 List classes = archiveResources.stream() 117 .filter(n -> n.type() == EntryType.CLASS_OR_RESOURCE) 118 .collect(Collectors.toList()); 119 Set pkgs = classes.stream().map(Entry::name) 120 .filter(n -> isResourcePackage(n)) 121 .map(ImageFileCreator::toPackage) 122 .collect(Collectors.toSet()); 123 modulePackagesMap.put(mn, pkgs); 124 }); 125 } Do not need to create the intermediate List. If archive.vistEntries was changed instead to: Stream entries(); The code above might flow better and, off the top of my head, you could do something like: archives.stream().forEach((archive) -> { Map> es = archive.entries() .collect(Collectors.partitioningBy(n -> n.type() == EntryType.CLASS_OR_RESOURCE)); String mn = archive.moduleName(); entriesForModule.put(mn, es.get(false)); // Extract package names Set pkgs = es.get(true).stream().map(Entry::name) .filter(n -> isResourcePackage(n)) .map(ImageFileCreator::toPackage) .collect(Collectors.toSet()); modulePackagesMap.put(mn, pkgs); }); For recreateJimage i think you can then do: Map> entriesForModule = archives.stream().collect(Collectors.toMap( Archive::moduleName, a -> a.entries().collect(Collectors.toList()) )); Or derive from Map entriesForModule = nameToArchive.entrySet() .stream() .collect(Collectors.toMap(e -> e.getKey(), e -> e.getValue().entries().collect(Collectors.toList()))); jdk.internal.jimage.ImageModuleDataWriter -- 69 Map> modulePackages = new LinkedHashMap<>(); 70 modules.stream().sorted().forEach((moduleName) -> { 71 List localPackages = modulePackagesMap.get(moduleName).stream() 72 .map(pn -> pn.replace('.', '/')) 73 .sorted() 74 .collect(Collectors.toList()); 75 modulePackages.put(moduleName, localPackages); 76 }); can replace forEach with collect(Collectors.toMap(Functions.identity(), n -> modulePackagesMap.get(n)...)); assuming no duplicate keys? jdk.internal.jimage.ResourcePoolImpl 196 Set pkgs = moduleToPackage.get(res.getModule()); 197 if (pkgs == null) { 198 pkgs = new HashSet<>(); 199 moduleToPackage.put(res.getModule(), pkgs); 200 } use Set pkgs = moduleToPackage.computeIfAbsent(res.getModule(),k -> new HashSet<>()); Paul. On May 15, 2015, at 5:45 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ > > There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. > > Cheers, > > ? Jim > From christian.tornqvist at oracle.com Mon May 18 17:51:33 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 18 May 2015 13:51:33 -0400 Subject: Proposed jimage refresh for JDK9 In-Reply-To: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> Message-ID: <077701d09193$47e11de0$d7a359a0$@oracle.com> Hi Jim, I've looked a bit at the Hotspot test code and here are my initial findings: General things: * Don't print things like "Passed"/"Failed" on stdout, when tests are passing no output is needed, when tests are failing it should throw an exception with a helpful message. "Some cases are failed" is not a helpful message. * Some more comments explaining what the test is trying to do would be useful * Use the asserts available in jdk.test.lib.Asserts, for example you can replace the following code: if (array != null) { System.out.printf("Passed. Offsets\' array retrieved with %s flag", mm); } else { System.out.printf("Failed. Could not retrieve offsets\' array with %s flag", mm); passed = false; } with assertNotNull(array, "Could not retrieve offsets\' array"); * We don't put @author tags in our tests * The test*() methods code should be moved into main hotspot/test/runtime/modules/ImageFile/ImageAttributeOffsetsTest.java * The whole +/-MemoryMapImage can be simplified, simply remove the +/- arguments to the tests and remove all the command line argument parsing code. The .jtr file will tell you what the command line options was when it failed. hotspot/test/runtime/modules/ImageFile/ImageCloseTest.java * How would this test fail? I can't see a way that testImageClose() doesn't return true hotspot/test/runtime/modules/ImageFile/ImageGetDataAddressTest.java * No need to loop through the arguments, simply do 'boolean isMMap = args[0].equals("+");' * No need to print the VM arguments on stdout, jtreg will do that for you hotspot/test/runtime/modules/ImageFile/ImageReadCompressedTest.java * Why is this test in here? It doesn't do anything but seems to be a placeholder, please remove it. hotspot/test/runtime/modules/ImageFile/ImageReadTest.java * No need to loop through the arguments, simply do 'boolean isMMap = args[0].equals("+");' * No need to print the VM arguments on stdout, jtreg will do that for you Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Jim Laskey (Oracle) Sent: Friday, May 15, 2015 11:45 AM To: hotspot-runtime-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net Subject: RFR: Proposed jimage refresh for JDK9 http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. Cheers, ? Jim From paul.sandoz at oracle.com Mon May 18 19:42:40 2015 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 18 May 2015 21:42:40 +0200 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> Message-ID: <818779DB-66A7-42E0-98E0-203CDFB09260@oracle.com> On May 18, 2015, at 7:07 PM, Paul Sandoz wrote: > jdk.internal.jimage.ImageFileCreator > -- > > 108 private void readAllEntries(Map> modulePackagesMap, > 109 Set archives) { > 110 archives.stream().forEach((archive) -> { > 111 List archiveResources = new ArrayList<>(); > 112 archive.visitEntries(x-> archiveResources.add(x)); > 113 String mn = archive.moduleName(); > 114 entriesForModule.put(mn, archiveResources); > 115 // Extract package names > 116 List classes = archiveResources.stream() > 117 .filter(n -> n.type() == EntryType.CLASS_OR_RESOURCE) > 118 .collect(Collectors.toList()); > 119 Set pkgs = classes.stream().map(Entry::name) > 120 .filter(n -> isResourcePackage(n)) > 121 .map(ImageFileCreator::toPackage) > 122 .collect(Collectors.toSet()); > 123 modulePackagesMap.put(mn, pkgs); > 124 }); > 125 } > > Do not need to create the intermediate List. > > If archive.vistEntries was changed instead to: > > Stream entries(); > > The code above might flow better and, off the top of my head, you could do something like: > > archives.stream().forEach((archive) -> { > Map> es = archive.entries() > .collect(Collectors.partitioningBy(n -> n.type() == EntryType.CLASS_OR_RESOURCE)); > I am talking nonsense here, Collectors.partitioningBy cannot be used, but i think the general approach of a stream returning method is still valid. Paul. > String mn = archive.moduleName(); > entriesForModule.put(mn, es.get(false)); > > // Extract package names > Set pkgs = es.get(true).stream().map(Entry::name) > .filter(n -> isResourcePackage(n)) > .map(ImageFileCreator::toPackage) > .collect(Collectors.toSet()); > modulePackagesMap.put(mn, pkgs); > }); > > For recreateJimage i think you can then do: > > Map> entriesForModule = archives.stream().collect(Collectors.toMap( > Archive::moduleName, > a -> a.entries().collect(Collectors.toList()) > )); > > Or derive from Map > > entriesForModule = nameToArchive.entrySet() > .stream() > .collect(Collectors.toMap(e -> e.getKey(), > e -> e.getValue().entries().collect(Collectors.toList()))); > > From forax at univ-mlv.fr Tue May 19 11:03:20 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 19 May 2015 13:03:20 +0200 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> Message-ID: <555B1878.2090607@univ-mlv.fr> As Paul said, it's a big patch ... In ImageBuilder, Option should take the description as 3rd parameter instead of overriding description. Once this is done, Option should not be abstract but takes the processing as an argument too (as a lambda). i.e instead of new Option(true, "--cmds") { @Override void process(ImageBuilder task, String opt, String arg) throws BadArgs { task.options.cmds = splitPath(arg, File.pathSeparator); } @Override String description() { return "Location of native commands"; } } } it's better to write: new Option(true, "--cmds", "Location of native commands", (ImageBuilder task, String opt, String arg) -> { task.options.cmds = splitPath(arg, File.pathSeparator); }) the code is ligther, it uses delegation instead of inheritance and remove a dozen of inner classes on disk. In ModuleArchive, close() should continue to close the opened input streams even if one throw an exception, @Override public void close() throws IOException { IOException e = null; for(InputStream stream : opened) { try { stream.close(); }catch(IOException ex) { if (e == null) { e = ex; } else { e.addSuppressed(ex); } } } if (e != null) { throw e; } } In BasicImageWriter, getString can be simplified to: public String getString(int offset) { UTF8String utf8 = strings.get(offset); if(utf8 != null) { return utf8.toString(); } return null; } also in generatePerfectHash, you don't need to create a Stream to do a forEach on it: input.stream().forEach( you can write input.forEach( ImageReader.LinkNode, instead of @SuppressWarnings("LeakingThisInConstructor"), the constructor should be private and you should add a static factory method that does parent.addChild(linkNode) after calling the constructor. in JrtFileAttributeView.get() that takes a Class, you forget to create the JrtFileAttributeViews with options as 3 parameters (as you do in get that takes a String). in JrtPath, instead of boolean isSame = Arrays.equals(this.getResolvedPath(), ((JrtPath)other).getResolvedPath()); return isSame? isSame : jrtfs.isSameFile(this, (JrtPath)other); the usual code is: JrtPath path = (JrtPath) other; return Arrays.equals(this.getResolvedPath(), path.getResolvedPath()) || jrtfs.isSameFile(this, path); and I fully agree with the review of Paul :) R?mi On 05/15/2015 05:45 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ > http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ > > There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. > > Cheers, > > ? Jim > From Alan.Bateman at oracle.com Tue May 19 11:27:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 May 2015 12:27:10 +0100 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <555B1878.2090607@univ-mlv.fr> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> <555B1878.2090607@univ-mlv.fr> Message-ID: <555B1E0E.4030403@oracle.com> On 19/05/2015 12:03, Remi Forax wrote: > As Paul said, > it's a big patch ... > > In ImageBuilder, Option should take the description as 3rd parameter > instead of overriding description. > Once this is done, Option should not be abstract but takes the > processing as an argument too > Just the say that it's probably not worth spending too much time on the image builder code (in the make tree). The reason is that this is a temporary tool, it should go away once we bring in the linker tool (as part of the module system). -Alan. From james.laskey at oracle.com Tue May 19 16:43:54 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 19 May 2015 13:43:54 -0300 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> Message-ID: <8A4E1C90-1B23-41BB-BD1C-B01AFCE04291@oracle.com> > On May 18, 2015, at 2:07 PM, Paul Sandoz wrote: > > Hi Jim, > > I reviewed the JDK code. There is quite a lot and i don't understand all the semantics but it generally looks ok. > > Stuff below is mostly suggested API tweaks. > > Paul. > > jdk.internal.jimage.BasicImageReader > -- > > 124 public String[] getEntryNames() { > 125 int[] offsets = substrate.attributeOffsets(); > 126 List list = new ArrayList<>(); > 127 > 128 for (int offset : offsets) { > 129 if (offset != 0) { > 130 ImageLocation location = > 131 ImageLocation.readFrom(this, offset); > 132 list.add(location.getFullNameString()); > 133 } > 134 } > 135 > 136 String[] array = list.toArray(new String[0]); > 137 Arrays.sort(array); > 138 > 139 return array; > 140 } > > You can do this instead: > > list.sort(null); // more idiomatic for Java 8 > return list.toArray(new String[list.size()]); > > It should be marginally more efficient just because the size information is passed to the array. > > Alternatively you use a stream too, depending on your perf requirements: > > return IntStream.of(substrate.attributeOffsets()) > .filter(o -> o != 0) > .mapToObj(o -> ImageLocation.readFrom(this, o).getFullNameString()) > .sorted() > .toArray(String[]::new); Done > > Same applies to getAllLocations: > > return IntStream.of(substrate.attributeOffsets()) > .filter(o -> o != 0) > .mapToObj(o -> ImageLocation.readFrom(this, o)) > .sorted(Comparator.comparing(ImageLocation::getFullNameString)) // Use Comparator.comparing in any case for key extraction > .toArray(ImageLocation[]::new); > > Done > jdk.internal.jrtfs.JrtFileSystem.java > -- > > 494 private Iterator nodesToIterator(Path path, String childPrefix, List childNodes) { > 495 List childPaths; > 496 if (childPrefix == null) { > 497 childPaths = childNodes.stream() > 498 .map(child -> toJrtPath(child.getNameString())) > 499 .collect(Collectors.toCollection(ArrayList::new)); > 500 } else { > 501 childPaths = childNodes.stream() > 502 .map(child -> toJrtPath(childPrefix + child.getNameString().substring(1))) > 503 .collect(Collectors.toCollection(ArrayList::new)); > 504 } > 505 return childPaths.iterator(); > 506 } > > Use Collectors.toList(). Could be marginally simplified as: > > Function f = childPrefix == null > ? child -> toJrtPath(child.getNameString()) > : child -> toJrtPath(childPrefix + child.getNameString().substring(1)); > return childNodes.stream().map(f).collect(toList()).iterator(); > > Required: Function f = childPrefix == null ? child -> toJrtPath(child.getNameString()) : child -> toJrtPath(childPrefix + child.getNameString().substring(1)); return childNodes.stream().map(f).collect(toList()).iterator(); > jdk.internal.jimage.ExternalFilesWriter > > 93 private static String nativeDir(String filename) { > 94 if (System.getProperty("os.name").startsWith("Windows")) { > 95 if (filename.endsWith(".dll") || filename.endsWith(".diz") > 96 || filename.endsWith(".pdb") || filename.endsWith(".map")) { > 97 return "bin"; > 98 } else { > 99 return "lib"; > 100 } > 101 } else { > 102 return "lib"; > 103 } > 104 } > > Does that need to be performed in a doPriv block? > > System.getProperty("os.name?) does not appear to be privileged. permission java.util.PropertyPermission "os.name", "read?; in grant { } section > jdk.internal.jimage.ImageFileCreator > -- > > 108 private void readAllEntries(Map> modulePackagesMap, > 109 Set archives) { > 110 archives.stream().forEach((archive) -> { > 111 List archiveResources = new ArrayList<>(); > 112 archive.visitEntries(x-> archiveResources.add(x)); > 113 String mn = archive.moduleName(); > 114 entriesForModule.put(mn, archiveResources); > 115 // Extract package names > 116 List classes = archiveResources.stream() > 117 .filter(n -> n.type() == EntryType.CLASS_OR_RESOURCE) > 118 .collect(Collectors.toList()); > 119 Set pkgs = classes.stream().map(Entry::name) > 120 .filter(n -> isResourcePackage(n)) > 121 .map(ImageFileCreator::toPackage) > 122 .collect(Collectors.toSet()); > 123 modulePackagesMap.put(mn, pkgs); > 124 }); > 125 } > > Do not need to create the intermediate List. > > If archive.vistEntries was changed instead to: > > Stream entries(); > > The code above might flow better and, off the top of my head, you could do something like: > > archives.stream().forEach((archive) -> { > Map> es = archive.entries() > .collect(Collectors.partitioningBy(n -> n.type() == EntryType.CLASS_OR_RESOURCE)); > > String mn = archive.moduleName(); > entriesForModule.put(mn, es.get(false)); > > // Extract package names > Set pkgs = es.get(true).stream().map(Entry::name) > .filter(n -> isResourcePackage(n)) > .map(ImageFileCreator::toPackage) > .collect(Collectors.toSet()); > modulePackagesMap.put(mn, pkgs); > }); > > For recreateJimage i think you can then do: > > Map> entriesForModule = archives.stream().collect(Collectors.toMap( > Archive::moduleName, > a -> a.entries().collect(Collectors.toList()) > )); > > Or derive from Map > > entriesForModule = nameToArchive.entrySet() > .stream() > .collect(Collectors.toMap(e -> e.getKey(), > e -> e.getValue().entries().collect(Collectors.toList()))); Done, modified slightly. > > > jdk.internal.jimage.ImageModuleDataWriter > -- > > 69 Map> modulePackages = new LinkedHashMap<>(); > 70 modules.stream().sorted().forEach((moduleName) -> { > 71 List localPackages = modulePackagesMap.get(moduleName).stream() > 72 .map(pn -> pn.replace('.', '/')) > 73 .sorted() > 74 .collect(Collectors.toList()); > 75 modulePackages.put(moduleName, localPackages); > 76 }); > > can replace forEach with collect(Collectors.toMap(Functions.identity(), n -> modulePackagesMap.get(n)...)); assuming no duplicate keys? > > Done, Functions -> Function > jdk.internal.jimage.ResourcePoolImpl > > 196 Set pkgs = moduleToPackage.get(res.getModule()); > 197 if (pkgs == null) { > 198 pkgs = new HashSet<>(); > 199 moduleToPackage.put(res.getModule(), pkgs); > 200 } > > use > > Set pkgs = moduleToPackage.computeIfAbsent(res.getModule(),k -> new HashSet<>()); > Done. > Paul. > > On May 15, 2015, at 5:45 PM, Jim Laskey (Oracle) wrote: > >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ >> >> There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. >> >> Cheers, >> >> ? Jim >> > From Alan.Bateman at oracle.com Tue May 19 16:50:37 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 May 2015 17:50:37 +0100 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <8A4E1C90-1B23-41BB-BD1C-B01AFCE04291@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> <8A4E1C90-1B23-41BB-BD1C-B01AFCE04291@oracle.com> Message-ID: <555B69DD.3010308@oracle.com> On 19/05/2015 17:43, Jim Laskey (Oracle) wrote: > : >> jdk.internal.jimage.ExternalFilesWriter >> >> 93 private static String nativeDir(String filename) { >> 94 if (System.getProperty("os.name").startsWith("Windows")) { >> 95 if (filename.endsWith(".dll") || filename.endsWith(".diz") >> 96 || filename.endsWith(".pdb") || filename.endsWith(".map")) { >> 97 return "bin"; >> 98 } else { >> 99 return "lib"; >> 100 } >> 101 } else { >> 102 return "lib"; >> 103 } >> 104 } >> >> Does that need to be performed in a doPriv block? >> >> > System.getProperty("os.name?) does not appear to be privileged. > permission java.util.PropertyPermission "os.name", "read?; in grant { } section I think this is the write code so it's only used in the build or jimage recreate, not used at run-time, right? -Alan From james.laskey at oracle.com Tue May 19 16:59:13 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 19 May 2015 13:59:13 -0300 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <555B69DD.3010308@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> <8A4E1C90-1B23-41BB-BD1C-B01AFCE04291@oracle.com> <555B69DD.3010308@oracle.com> Message-ID: <5D669F63-4F9C-4508-9585-F509582BC97E@oracle.com> > On May 19, 2015, at 1:50 PM, Alan Bateman wrote: > > > > On 19/05/2015 17:43, Jim Laskey (Oracle) wrote: >> : >>> jdk.internal.jimage.ExternalFilesWriter >>> >>> 93 private static String nativeDir(String filename) { >>> 94 if (System.getProperty("os.name").startsWith("Windows")) { >>> 95 if (filename.endsWith(".dll") || filename.endsWith(".diz") >>> 96 || filename.endsWith(".pdb") || filename.endsWith(".map")) { >>> 97 return "bin"; >>> 98 } else { >>> 99 return "lib"; >>> 100 } >>> 101 } else { >>> 102 return "lib"; >>> 103 } >>> 104 } >>> >>> Does that need to be performed in a doPriv block? >>> >>> >> System.getProperty("os.name?) does not appear to be privileged. >> permission java.util.PropertyPermission "os.name", "read?; in grant { } section > I think this is the write code so it's only used in the build or jimage recreate, not used at run-time, right? > > -Alan Correct From james.laskey at oracle.com Wed May 20 16:35:44 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 20 May 2015 13:35:44 -0300 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <555B1878.2090607@univ-mlv.fr> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> <555B1878.2090607@univ-mlv.fr> Message-ID: > On May 19, 2015, at 8:03 AM, Remi Forax wrote: > > As Paul said, > it's a big patch ? Agree. > > In ImageBuilder, Option should take the description as 3rd parameter instead of overriding description. > Once this is done, Option should not be abstract but takes the processing as an argument too > (as a lambda). i.e instead of > > new Option(true, "--cmds") { > @Override > void process(ImageBuilder task, String opt, String arg) throws BadArgs { > task.options.cmds = splitPath(arg, File.pathSeparator); > } > @Override > String description() { return "Location of native commands"; } > } > } > > it's better to write: > new Option(true, "--cmds", "Location of native commands", > (ImageBuilder task, String opt, String arg) -> { > task.options.cmds = splitPath(arg, File.pathSeparator); > }) > > the code is ligther, it uses delegation instead of inheritance and remove a dozen of inner classes on disk. Done. > > In ModuleArchive, close() should continue to close the opened input streams even if one throw an exception, > @Override > public void close() throws IOException { > IOException e = null; > for(InputStream stream : opened) { > try { > stream.close(); > }catch(IOException ex) { > if (e == null) { > e = ex; > } else { > e.addSuppressed(ex); > } > } > } > if (e != null) { > throw e; > } > } Done. > > In BasicImageWriter, getString can be simplified to: > public String getString(int offset) { > UTF8String utf8 = strings.get(offset); > if(utf8 != null) { > return utf8.toString(); > } > return null; > } Done. > > also in generatePerfectHash, you don't need to create a Stream to do a forEach on it: > input.stream().forEach( > you can write > input.forEach( Done. > > ImageReader.LinkNode, instead of @SuppressWarnings("LeakingThisInConstructor"), > the constructor should be private and you should add a static factory method that > does parent.addChild(linkNode) after calling the constructor. > Done. > in JrtFileAttributeView.get() that takes a Class, you forget to create the JrtFileAttributeViews > with options as 3 parameters (as you do in get that takes a String). > > in JrtPath, instead of > boolean isSame = Arrays.equals(this.getResolvedPath(), > ((JrtPath)other).getResolvedPath()); > return isSame? isSame : jrtfs.isSameFile(this, (JrtPath)other); > the usual code is: > JrtPath path = (JrtPath) other; > return Arrays.equals(this.getResolvedPath(), path.getResolvedPath()) || > jrtfs.isSameFile(this, path); > Done > and I fully agree with the review of Paul :) > > R?mi > > On 05/15/2015 05:45 PM, Jim Laskey (Oracle) wrote: >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/top/ >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/hotspot/ >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/jdk/ >> http://cr.openjdk.java.net/~jlaskey/jdk9-jimage/langtools/ >> >> There are some issues with regard to the hotspot changes, but I?m working with Coleen and John R. to resolve those. >> >> Cheers, >> >> ? Jim >> > From mandy.chung at oracle.com Mon May 25 19:28:12 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 25 May 2015 12:28:12 -0700 Subject: Review Request 8074432: Move jdeps to jdk.compiler module In-Reply-To: <5562CC61.30603@oracle.com> References: <6C76C1E9-D4C0-4075-AD20-46CF8AAA1925@oracle.com> <5562CC61.30603@oracle.com> Message-ID: Meant to include jigsaw-dev in the initial post. > On May 25, 2015, at 12:16 AM, Alan Bateman wrote: > > On 24/05/2015 05:00, Mandy Chung wrote: >> This will move jdeps to the same module as other langtools javac and javap. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.00/ >> >> This is the final change to resolve the open issue JDK-8072601 (Re-examine jdk.runtime and jdk.dev modules) for JEP 200. >> >> Mandy > I don't see any issues with the patch but I wonder if this is a case where we should introduce jdk.jdeps rather than putting the tool in the jdk.compile module. > serialver and javap are in jdk.compiler that is an appropriate home for jdeps while I don?t particularly like it since it isn?t clear to tell from jdk.compiler module name where jdeps is there. The tool modules have been evolved a bit and some tools are put in its own module such as jdk.pack200, jdk.policytool, jdk.javadoc, jdk.jconsole, jdk.rmic etc. that are organized around its primary tool which is easy to name, document, and understand. Putting jdeps in jdk.jdeps module makes it easy where to find jdeps that is an attractive option. This also opens up the option to move jdeps to jdk repo in the future - it is just a side point and jdeps is currently being used as an interim solution to verify module boundaries until the module system is moving further along. I will post a revised webrev. > A passing comment is that I see we run these tools with -Xms8m, we should re-visit that some day. > Yes - we should re-visit this for the launchers we have. Mandy From mandy.chung at oracle.com Wed May 27 06:00:52 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 May 2015 23:00:52 -0700 Subject: Review Request 8074432: Move jdeps to jdk.compiler module In-Reply-To: References: <6C76C1E9-D4C0-4075-AD20-46CF8AAA1925@oracle.com> <5562CC61.30603@oracle.com> Message-ID: <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. Revised webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ This touches many langtools tests to update @modules but should be easy to review. $ du -s -h jdk.jdeps/com/sun/tools/* 816K jdk.jdeps/com/sun/tools/classfile 468K jdk.jdeps/com/sun/tools/javap 400K jdk.jdeps/com/sun/tools/jdeps $ du -s -h jdk.compiler/ 9.1M jdk.compiler/ Mandy From erik.joelsson at oracle.com Wed May 27 07:48:46 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 May 2015 09:48:46 +0200 Subject: Review Request 8074432: Move jdeps to jdk.compiler module In-Reply-To: <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> References: <6C76C1E9-D4C0-4075-AD20-46CF8AAA1925@oracle.com> <5562CC61.30603@oracle.com> <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> Message-ID: <556576DE.4060806@oracle.com> Hello Mandy, I don't see a Launcher-jdk.jdeps.gmk. Should there be one? /Erik On 2015-05-27 08:00, Mandy Chung wrote: > We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). > > The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. > > Revised webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ > > This touches many langtools tests to update @modules but should be easy to review. > > $ du -s -h jdk.jdeps/com/sun/tools/* > 816K jdk.jdeps/com/sun/tools/classfile > 468K jdk.jdeps/com/sun/tools/javap > 400K jdk.jdeps/com/sun/tools/jdeps > $ du -s -h jdk.compiler/ > 9.1M jdk.compiler/ > > Mandy From james.laskey at oracle.com Wed May 27 12:49:05 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 27 May 2015 09:49:05 -0300 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <5564A76C.5020500@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> <8A4E1C90-1B23-41BB-BD1C-B01AFCE04291@oracle.com> <555B69DD.3010308@oracle.com> <5D669F63-4F9C-4508-9585-F509582BC97E@oracle.com> <8B159D12-1682-42DD-9BF9-5FA218E710FA@oracle.com> <55646CDE.5020106@oracle.com> <5564809D.2050200@oracle.com> <55648254.2060401@oracle.com> <5564A76C.5020500@oracle.com> Message-ID: [Have been OOTO] I have a cunning plan. However, getting this jimage refresh in play has me really bogged down (there is always one more thing -- curse you Jobs.) I do plan on moving the bulk of the jimage JVM_ calls to the JDK. The callbacks into the VM will be reduced to a few calls (open, close, read, read_compressed) and will be VM style correct. Cheers, ? Jim > On May 26, 2015, at 2:03 PM, Coleen Phillimore wrote: > > > > On 5/26/15 10:25 AM, Alan Bateman wrote: >> >> On 26/05/2015 15:18, Coleen Phillimore wrote: >>> : >>> >>>> >>>> In any case, I don't think the JVM functions are a supported interface so we shouldn't need a CCC. >>> >>> We need CCC to remove the JVM functions so I assume we need one to add them. >> Okay although JVM_* functions have never been a supported interface (to my knowledge anyway). >> > These are the current rules, which assume that even though unsupported, these interfaces are known to our customers and licensees. >> >>>> >>>> Also I think we need to see where this is going longer term, my preference would be to move these JVM_* functions out of the VM and put the jimage support in its own libjimage.so. I realize this requires mmap and other support that might be tied a bit to VM options but I think we should at least explore it. >>> >>> I think this functionality should be in Java. >> We might be talking different issues here, I assume you need a minimal native implementation to startup. > > Yes. It seems wasteful to have the JDK code call back to the JVM for this, and then we have new JVM functions to support (and have to file CCC requests if we remove them). > > Thanks, > Coleen > >> >> -Alan > From mandy.chung at oracle.com Wed May 27 13:40:31 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2015 06:40:31 -0700 Subject: Review Request 8074432: Move jdeps to jdk.compiler module In-Reply-To: <556576DE.4060806@oracle.com> References: <6C76C1E9-D4C0-4075-AD20-46CF8AAA1925@oracle.com> <5562CC61.30603@oracle.com> <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> <556576DE.4060806@oracle.com> Message-ID: It?s in my repo but missing from the webrev. diff --git a/make/launcher/Launcher-jdk.jdeps.gmk b/make/launcher/Launcher-jdk.jdeps.gmk new file mode 100644 --- /dev/null +++ b/make/launcher/Launcher-jdk.jdeps.gmk @@ -0,0 +1,36 @@ +# +# Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. +# +# This code is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License version 2 only, as +# published by the Free Software Foundation. Oracle designates this +# particular file as subject to the "Classpath" exception as provided +# by Oracle in the LICENSE file that accompanied this code. +# +# This code is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +# version 2 for more details (a copy is included in the LICENSE file that +# accompanied this code). +# +# You should have received a copy of the GNU General Public License version +# 2 along with this work; if not, write to the Free Software Foundation, +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +# +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA +# or visit www.oracle.com if you need additional information or have any +# questions. +# + +include LauncherCommon.gmk + +$(eval $(call SetupLauncher,javap, \ + -DEXPAND_CLASSPATH_WILDCARDS \ + -DNEVER_ACT_AS_SERVER_CLASS_MACHINE \ + -DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.javap.Main"$(COMMA) }')) + +$(eval $(call SetupLauncher,jdeps, \ + -DEXPAND_CLASSPATH_WILDCARDS \ + -DNEVER_ACT_AS_SERVER_CLASS_MACHINE \ + -DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.jdeps.Main"$(COMMA) }')) > On May 27, 2015, at 12:48 AM, Erik Joelsson wrote: > > Hello Mandy, > > I don't see a Launcher-jdk.jdeps.gmk. Should there be one? > > /Erik > > On 2015-05-27 08:00, Mandy Chung wrote: >> We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). >> >> The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. >> >> Revised webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ >> >> This touches many langtools tests to update @modules but should be easy to review. >> >> $ du -s -h jdk.jdeps/com/sun/tools/* >> 816K jdk.jdeps/com/sun/tools/classfile >> 468K jdk.jdeps/com/sun/tools/javap >> 400K jdk.jdeps/com/sun/tools/jdeps >> $ du -s -h jdk.compiler/ >> 9.1M jdk.compiler/ >> >> Mandy > From erik.joelsson at oracle.com Wed May 27 14:12:44 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 May 2015 16:12:44 +0200 Subject: Review Request 8074432: Move jdeps to jdk.compiler module In-Reply-To: References: <6C76C1E9-D4C0-4075-AD20-46CF8AAA1925@oracle.com> <5562CC61.30603@oracle.com> <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> <556576DE.4060806@oracle.com> Message-ID: <5565D0DC.7080508@oracle.com> Looks good to me. /Erik On 2015-05-27 15:40, Mandy Chung wrote: > It?s in my repo but missing from the webrev. > > diff --git a/make/launcher/Launcher-jdk.jdeps.gmk b/make/launcher/Launcher-jdk.jdeps.gmk > new file mode 100644 > --- /dev/null > +++ b/make/launcher/Launcher-jdk.jdeps.gmk > @@ -0,0 +1,36 @@ > +# > +# Copyright (c) 2015, Oracle and/or its affiliates. All rights reserved. > +# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > +# > +# This code is free software; you can redistribute it and/or modify it > +# under the terms of the GNU General Public License version 2 only, as > +# published by the Free Software Foundation. Oracle designates this > +# particular file as subject to the "Classpath" exception as provided > +# by Oracle in the LICENSE file that accompanied this code. > +# > +# This code is distributed in the hope that it will be useful, but WITHOUT > +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > +# version 2 for more details (a copy is included in the LICENSE file that > +# accompanied this code). > +# > +# You should have received a copy of the GNU General Public License version > +# 2 along with this work; if not, write to the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > +# > +# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > +# or visit www.oracle.com if you need additional information or have any > +# questions. > +# > + > +include LauncherCommon.gmk > + > +$(eval $(call SetupLauncher,javap, \ > + -DEXPAND_CLASSPATH_WILDCARDS \ > + -DNEVER_ACT_AS_SERVER_CLASS_MACHINE \ > + -DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.javap.Main"$(COMMA) }')) > + > +$(eval $(call SetupLauncher,jdeps, \ > + -DEXPAND_CLASSPATH_WILDCARDS \ > + -DNEVER_ACT_AS_SERVER_CLASS_MACHINE \ > + -DJAVA_ARGS='{ "-J-ms8m"$(COMMA) "com.sun.tools.jdeps.Main"$(COMMA) }')) > >> On May 27, 2015, at 12:48 AM, Erik Joelsson wrote: >> >> Hello Mandy, >> >> I don't see a Launcher-jdk.jdeps.gmk. Should there be one? >> >> /Erik >> >> On 2015-05-27 08:00, Mandy Chung wrote: >>> We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). >>> >>> The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. >>> >>> Revised webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ >>> >>> This touches many langtools tests to update @modules but should be easy to review. >>> >>> $ du -s -h jdk.jdeps/com/sun/tools/* >>> 816K jdk.jdeps/com/sun/tools/classfile >>> 468K jdk.jdeps/com/sun/tools/javap >>> 400K jdk.jdeps/com/sun/tools/jdeps >>> $ du -s -h jdk.compiler/ >>> 9.1M jdk.compiler/ >>> >>> Mandy From Alan.Bateman at oracle.com Wed May 27 14:26:55 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 May 2015 15:26:55 +0100 Subject: Review Request 8074432: Move jdeps to jdk.compiler module In-Reply-To: <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> References: <6C76C1E9-D4C0-4075-AD20-46CF8AAA1925@oracle.com> <5562CC61.30603@oracle.com> <15282D68-346E-4569-A356-2266C1A28CD9@oracle.com> Message-ID: <5565D42F.7030009@oracle.com> On 27/05/2015 07:00, Mandy Chung wrote: > We discussed this offline and revised the proposal to group javap and classfile library together with jdeps in jdk.jdeps module for static analysis tools to live. The jdk.compiler module will contain the compiler and a couple of small tools. Moving out javap and classfile library save about 1.2M uncompressed from jdk.compiler (~11%). > > The module is named after the primary tool, jdeps in this case. Tools are in JAVA_HOME/bin directory of idk image and so which module jdeps and javap are transparent in the idk image. > > Revised webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074432/webrev.01/ > > The internal classfile API, javap and jdeps in the jdk.jdeps module looks good to me. -Alan. From coleen.phillimore at oracle.com Tue May 26 12:43:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 May 2015 12:43:35 -0000 Subject: RFR: Proposed jimage refresh for JDK9 In-Reply-To: <5D669F63-4F9C-4508-9585-F509582BC97E@oracle.com> References: <8B2EAD6D-BA19-4C5A-9DD6-15BD00D2191F@oracle.com> <8A4E1C90-1B23-41BB-BD1C-B01AFCE04291@oracle.com> <555B69DD.3010308@oracle.com> <5D669F63-4F9C-4508-9585-F509582BC97E@oracle.com> Message-ID: <8B159D12-1682-42DD-9BF9-5FA218E710FA@oracle.com> Do you need a CCC request to add JVM functions and check with licensee engineering? Coleen Sent from my iPhone > On May 19, 2015, at 12:59 PM, Jim Laskey (Oracle) wrote: > > >> On May 19, 2015, at 1:50 PM, Alan Bateman wrote: >> >> >> >>> On 19/05/2015 17:43, Jim Laskey (Oracle) wrote: >>> : >>>> jdk.internal.jimage.ExternalFilesWriter >>>> >>>> 93 private static String nativeDir(String filename) { >>>> 94 if (System.getProperty("os.name").startsWith("Windows")) { >>>> 95 if (filename.endsWith(".dll") || filename.endsWith(".diz") >>>> 96 || filename.endsWith(".pdb") || filename.endsWith(".map")) { >>>> 97 return "bin"; >>>> 98 } else { >>>> 99 return "lib"; >>>> 100 } >>>> 101 } else { >>>> 102 return "lib"; >>>> 103 } >>>> 104 } >>>> >>>> Does that need to be performed in a doPriv block? >>> System.getProperty("os.name?) does not appear to be privileged. >>> permission java.util.PropertyPermission "os.name", "read?; in grant { } section >> I think this is the write code so it's only used in the build or jimage recreate, not used at run-time, right? >> >> -Alan > > Correct