From andreas.sterbenz at sun.com Mon Oct 1 06:00:08 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Mon, 1 Oct 2007 06:00:08 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710011300.l91D080f025723@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071001/a4a7d4ae/attachment.html From andreas.sterbenz at sun.com Tue Oct 2 06:00:04 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Tue, 2 Oct 2007 06:00:04 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710021300.l92D04f0012076@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071002/0905b62f/attachment.html From andreas.sterbenz at sun.com Wed Oct 3 06:00:05 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Wed, 3 Oct 2007 06:00:05 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710031300.l93D05cK004461@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071003/ad3eb7ac/attachment.html From andreas.sterbenz at sun.com Thu Oct 4 06:00:06 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Thu, 4 Oct 2007 06:00:06 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710041300.l94D06hH029215@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071004/058685ab/attachment.html From andreas.sterbenz at sun.com Fri Oct 5 06:00:06 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Fri, 5 Oct 2007 06:00:06 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710051300.l95D06N5013947@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071005/10a86573/attachment.html From David.Bristor at Sun.COM Fri Oct 5 15:55:54 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Fri, 05 Oct 2007 15:55:54 -0700 Subject: [modules-dev] Review request for 6559067, 6559086, and 6605100 Message-ID: <4706C0FA.4000703@sun.com> Hi folks, This fixes 3 bugs: (repo) implement LocalRepository.shutdown() and reload() http://monaco.sfbay/detail.jsp?cr=6559067 (repo) URLRepository.shutdown() and reload() http://monaco.sfbay/detail.jsp?cr=6559086 (repo) Allow factories in repository configuration http://monaco.sfbay/detail.jsp?cr=6605100 The webrev is at: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6559067+6559086+6605100/ There are lots of changes, so a description of them is in order: * LocalRepository and URLRepository suffered from entropy, so I moved code around and brought them up to coding standards (I'm sure some things are still missed in that regard). * In discussion, Kumar, Stanley, and I decided that the configuration of those 2 repositories should be via system properties and the Map given when they're constructed. The repository-specific system propertes are read once, when the class is loaded. Their values *override* any that could be given at construction. BasicLauncherTests was changed to use overrides via system properties; Local and URL repository tests use overrides via the Map. * When one of those repositories is created, it is OK if its source location does not exist. In this case, when find() or list() operations are performed, they'll return empty lists. If reload() is performed, and at that time the source location *does* exist, then subsequent find() or list() operations will return modules now available. This is verified in the Local and URL repository tests. Checks for the prior, opposite behavior were removed from these and from RepositoryTest. * However, we provide a system property for each of these repository types that can cause construction/initialization to require that the source location *does* exist at that time; if not an IOException gets thrown. LocalRepositoryTest verifies this. * shutdown() and reload() are implemented for both repositories, and are verified in Local and URL repository tests. * For these repository implementations: once an instance has been initialized, subsequent initialize() invocations are a no-op. Once an instance has been initialized and then shutdown, subsequent shutdown() invocations are a no-op. But if an instance is initialized, then shutdown, a subsequent initialize() invocation throws IllegalStateException. Local and URL repository tests were updated to check this. * RepositoryConfig now supports configuration via RepositoryFactory objects. See src/share/lib/module/repository.properties and src/share/classes/sun/module/repository/ExtensionRepositoryFactory for an example. A new test was added for factories. Thanks, Dave From andreas.sterbenz at sun.com Mon Oct 8 06:00:07 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Mon, 8 Oct 2007 06:00:07 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710081300.l98D07PU011077@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071008/abc7a345/attachment.html From andreas.sterbenz at sun.com Tue Oct 9 06:00:04 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Tue, 9 Oct 2007 06:00:04 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710091300.l99D04ql009768@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071009/30f1e5cd/attachment.html From David.Bristor at Sun.COM Tue Oct 9 13:28:47 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 09 Oct 2007 13:28:47 -0700 Subject: [modules-dev] Review request for 6578988 Message-ID: <470BE47F.7020009@sun.com> Hi folks, This fix for (repo) Implement Repository.shutdownOnExit builds on top of my previous request (attached); it has build atop that because the changes here for shutdownOnExit() rely on the changes to shutdown() in the prior request. This is a *lot* shorter than my previous request. It includes some javadoc fixes in JamUtils. You'll see in the change that when shutdownOnExit is invoked with false, that any previously-created shutdownThread is made available to GC. I didn't see any reason to retain the reference if the likelihood is that it won't be used. It might be better to keep it once created. Space v. time! bugster: http://monaco.sfbay/detail.jsp?cr=6578988 webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6578988 I submitted a JPRT run that has changes for this fix plus the others. Thanks! Dave -------------- next part -------------- An embedded message was scrubbed... From: Dave Bristor Subject: Review request for 6559067, 6559086, and 6605100 Date: Fri, 05 Oct 2007 15:55:54 -0700 Size: 3205 Url: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071009/f2e03877/attachment.mht From Stanley.Ho at Sun.COM Tue Oct 9 19:23:15 2007 From: Stanley.Ho at Sun.COM (Stanley M. Ho) Date: Tue, 09 Oct 2007 19:23:15 -0700 Subject: [modules-dev] Review request for 6559067, 6559086, and 6605100 In-Reply-To: <4706C0FA.4000703@sun.com> References: <4706C0FA.4000703@sun.com> Message-ID: <470C3793.8080401@sun.com> Hi Dave, Looks good. Several comments: - src/share/classes/sun/module/repository/LocalRepository.java 253 public synchronized ModuleArchiveInfo install(URL u) throws IOException { Should check if repository is read-only. Local repository is read-only if the source location is not writable by the user. 260 throw new IOException( 261 "Cannot overwrite " + f.getName() + " in repository directory " + sourceDir); Should throw IllegalStateException instead because a module definition with the same name, version, and platform binding has already been installed. 261 "Cannot overwrite " + f.getName() + " in repository directory " + sourceDir); "in repository's source directory" instead of "in repository directory". 278 public synchronized boolean uninstall(ModuleArchiveInfo m) throws IOException { Should check if repository is read-only. 287 if (!f.exists()) { 288 throw new IOException("Could not find module file for " + m.getName() 289 + "in the repository"); 290 } If module does not exist, should simply return false. See spec. 295 if (f2.isDirectory()) { What happens if f2 is a file? 328 ArrayList rc = new ArrayList(); 329 if (constraint == Query.ANY) { 330 for (ModuleDefinition md : contents.getModuleDefinitions()) { 331 rc.add(md); 332 } 333 } else { 334 for (ModuleDefinition md : contents.getModuleDefinitions()) { 335 if (constraint.match(md)) { 336 rc.add(md); 337 } 338 } 339 } The result should be read-only, and it could also be cached for subsequent query as an optimization. List rc; if (constraint == Query.ANY) { rc = Collections.unmodifiableList(contents.getModuleDefinitions()); } else { rc = new ArrayList(); for (ModuleDefinition md : contents.getModuleDefinitions()) { if (constraint.match(md)) { rc.add(md); } } rc = Collections.unmodifiableList(rc); } 444 throw new NullPointerException("LocalRepository: config cannot be null."); 582 "LocalRepository: specified " + type + " directory " I notice that some exceptions' messages are prefixed with "LocalRespository:" while some aren't. Should be consistent. 496 if (expansionDirName != null) { 497 expansionDir = new File(expansionDirName, 498 "expansion" + "-" + timestamp); 499 expansionDir.mkdir(); 500 } else { 501 File tmp = File.createTempFile("jamtmp" + System.currentTimeMillis(), "tmp"); 502 expansionDir = new File(tmp.getParent(), 503 "LocalRepositoryExpansion-" 504 + getName() + "-" + timestamp); 505 tmp.delete(); 506 expansionDir.mkdirs(); 507 } Could be simplified somewhat: if (expansionDirName == null) { File tmp = File.createTempFile("jamtmp", System.currentTimeMillis(), "tmp"); expansionDirName = tmp.getParent().getCanonicalPath(); tmp.delete(); } expansionDir = new File(expansionDirName, "LocalRepositoryExpansion-" + getName() + "-" + timestamp); expansionDir.mkdirs(); 495 private void initializeDirs() throws IOException { Perhaps "constructDirs", "constructCache", or "initializeCache". 517 private void resetDirs() throws IOException { Perhaps "cleanupDirs" or "cleanupCache", or "removeCache". 547 private void uninstallJams() throws IOException { I don't seem to find where this method get used. Could it be removed? - src/share/classes/sun/module/repository/RepositoryConfig.java 489 + ": " + msg); Missing "'" before ": ". - src/share/classes/sun/module/repository/URLRepository.java 675 public synchronized List findModuleDefinitions(Query constraint) { Same comment as in LocalRepository. 774 String getSourcePath() { Don't see it being used. Can it be removed? 812 throw new NullPointerException("URLRepository: config cannot be null."); 846 "URLRepository: In repository " + getSourceLocation() 877 throw new IOException("URLRepository: Cannot open connection to " + moduleMD, ex); 885 throw new IOException("URLRepository: Cannot load MODULE.METADATA for " + moduleMD, ex); Prefix issue in exception's message. 1087 private void initializeDirs() throws IOException { 1111 private void resetDirs() throws IOException { See above. 1122 metadataDir = null; 1123 downloadDir = null; Shouldn't baseDir also be reset to null? - src/share/classes/sun/module/repository/ExtensionRepositoryFactory.java I think you might mean global repository instead of extension repository. 54 locations.put("linux", "/usr/jdk/packages/lib/ext"); 55 locations.put("solaris", "/usr/java/packages/lib/ext"); 56 locations.put("windows", "%SystemRoot%\\Sun\\Java\\lib\\ext"); These locations are where the global legacy extension JARs are stored, but they're not for modules. For the extension repository, the location should be {java.home}/lib/module/ext on all platforms. If you want to add the support for the global repository, the location would be the following for now: Linux: /usr/jdk/packages/lib/module Solaris: /usr/java/packages/lib/module Windows: %SystemRoot%\\Sun\\Java\\lib\\module That said, the location should be specified in the repository.properties rather than hardcoded. See below. 71 return Modules.newLocalRepository( The extension repository should be a file-based URL repository for performance reason, while the global repository should be a local repository. - src/share/lib/module/repository.properties 32 extension.parent=bootstrap 33 extension.factoryname=sun.module.repository.ExtensionRepositoryFactory 34 35 user.parent=extension 36 user.factoryname=sun.module.repository.UserRepositoryFactory extension.parent=bootstrap extension.factoryname=sun.module.repository.ExtensionRepositoryFactory extension.source.location=file:///{java.home}/lib/module/ext global.parent=extension global.factoryname=sun.module.repository.GlobalRepositoryFactory global.source.location=/usr/jdk/packages/lib/module (note: varies between platforms) user.parent=global user.factoryname=sun.module.repository.UserRepositoryFactory user.source.location=file:///{user.home}/.java/module That's it for now. - Stanley Dave Bristor wrote: > Hi folks, > > This fixes 3 bugs: > (repo) implement LocalRepository.shutdown() and reload() > http://monaco.sfbay/detail.jsp?cr=6559067 > > (repo) URLRepository.shutdown() and reload() > http://monaco.sfbay/detail.jsp?cr=6559086 > > (repo) Allow factories in repository configuration > http://monaco.sfbay/detail.jsp?cr=6605100 > > The webrev is at: > > http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6559067+6559086+6605100/ > > There are lots of changes, so a description of them is in order: > > * LocalRepository and URLRepository suffered from entropy, so I moved code > around and brought them up to coding standards (I'm sure some things are still > missed in that regard). > > * In discussion, Kumar, Stanley, and I decided that the configuration of those > 2 repositories should be via system properties and the Map > given when they're constructed. The repository-specific system propertes are > read once, when the class is loaded. Their values *override* any that could > be given at construction. BasicLauncherTests was changed to use overrides via > system properties; Local and URL repository tests use overrides via the > Map. > > * When one of those repositories is created, it is OK if its source location > does not exist. In this case, when find() or list() operations are performed, > they'll return empty lists. If reload() is performed, and at that time the > source location *does* exist, then subsequent find() or list() operations will > return modules now available. This is verified in the Local and URL > repository tests. Checks for the prior, opposite behavior were removed from > these and from RepositoryTest. > > * However, we provide a system property for each of these repository types > that can cause construction/initialization to require that the source location > *does* exist at that time; if not an IOException gets thrown. > LocalRepositoryTest verifies this. > > * shutdown() and reload() are implemented for both repositories, and are > verified in Local and URL repository tests. > > * For these repository implementations: once an instance has been initialized, > subsequent initialize() invocations are a no-op. Once an instance has been > initialized and then shutdown, subsequent shutdown() invocations are a no-op. > But if an instance is initialized, then shutdown, a subsequent initialize() > invocation throws IllegalStateException. Local and URL repository tests were > updated to check this. > > * RepositoryConfig now supports configuration via RepositoryFactory objects. > See src/share/lib/module/repository.properties and > src/share/classes/sun/module/repository/ExtensionRepositoryFactory for an > example. A new test was added for factories. > > Thanks, > Dave > _______________________________________________ > modules-dev mailing list > modules-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-dev From Stanley.Ho at Sun.COM Tue Oct 9 19:36:24 2007 From: Stanley.Ho at Sun.COM (Stanley M. Ho) Date: Tue, 09 Oct 2007 19:36:24 -0700 Subject: [modules-dev] Review request for 6578988 In-Reply-To: <470BE47F.7020009@sun.com> References: <470BE47F.7020009@sun.com> Message-ID: <470C3AA8.6030702@sun.com> Hi Dave, Looks good. One comment: - src/share/classes/java/module/Repository.java 244 shutdownThread = new Thread() { The issue is that this shutdownThread is not created until the first shutdownOnExit() is called. However, this could happen in any thread group. In the sandbox, thread groups easily come and go as applications are loaded, and shutdown, and this shutdown hook might not be executed properly if the associated thread group has been destroyed before the end of the JVM session. The proper way to fix this is to obtain the main thread group when the module system is started, and make sure this shutdown thread is created in the main thread group. - Stanley Dave Bristor wrote: > Hi folks, > > This fix for > (repo) Implement Repository.shutdownOnExit > > builds on top of my previous request (attached); it has build atop that > because the changes here for shutdownOnExit() rely on the changes to > shutdown() in the prior request. > > This is a *lot* shorter than my previous request. It includes some > javadoc fixes in JamUtils. > > You'll see in the change that when shutdownOnExit is invoked with false, > that any previously-created shutdownThread is made available to GC. I > didn't see any reason to retain the reference if the likelihood is that > it won't be used. It might be better to keep it once created. Space v. > time! > > bugster: http://monaco.sfbay/detail.jsp?cr=6578988 > webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6578988 > > I submitted a JPRT run that has changes for this fix plus the others. > > Thanks! > Dave > > ------------------------------------------------------------------------ > > Subject: > Review request for 6559067, 6559086, and 6605100 > From: > Dave Bristor > Date: > Fri, 05 Oct 2007 15:55:54 -0700 > To: > modules-dev at openjdk.java.net > > To: > modules-dev at openjdk.java.net > > > Hi folks, > > This fixes 3 bugs: > (repo) implement LocalRepository.shutdown() and reload() > http://monaco.sfbay/detail.jsp?cr=6559067 > > (repo) URLRepository.shutdown() and reload() > http://monaco.sfbay/detail.jsp?cr=6559086 > > (repo) Allow factories in repository configuration > http://monaco.sfbay/detail.jsp?cr=6605100 > > The webrev is at: > > http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6559067+6559086+6605100/ > > There are lots of changes, so a description of them is in order: > > * LocalRepository and URLRepository suffered from entropy, so I moved > code around and brought them up to coding standards (I'm sure some > things are still missed in that regard). > > * In discussion, Kumar, Stanley, and I decided that the configuration of > those 2 repositories should be via system properties and the Map String> given when they're constructed. The repository-specific system > propertes are read once, when the class is loaded. Their values > *override* any that could be given at construction. BasicLauncherTests > was changed to use overrides via system properties; Local and URL > repository tests use overrides via the Map. > > * When one of those repositories is created, it is OK if its source > location does not exist. In this case, when find() or list() operations > are performed, they'll return empty lists. If reload() is performed, > and at that time the source location *does* exist, then subsequent > find() or list() operations will return modules now available. This is > verified in the Local and URL repository tests. Checks for the prior, > opposite behavior were removed from these and from RepositoryTest. > > * However, we provide a system property for each of these repository > types that can cause construction/initialization to require that the > source location *does* exist at that time; if not an IOException gets > thrown. LocalRepositoryTest verifies this. > > * shutdown() and reload() are implemented for both repositories, and are > verified in Local and URL repository tests. > > * For these repository implementations: once an instance has been > initialized, subsequent initialize() invocations are a no-op. Once an > instance has been initialized and then shutdown, subsequent shutdown() > invocations are a no-op. But if an instance is initialized, then > shutdown, a subsequent initialize() invocation throws > IllegalStateException. Local and URL repository tests were updated to > check this. > > * RepositoryConfig now supports configuration via RepositoryFactory > objects. See src/share/lib/module/repository.properties and > src/share/classes/sun/module/repository/ExtensionRepositoryFactory for > an example. A new test was added for factories. > > Thanks, > Dave > > > ------------------------------------------------------------------------ > > _______________________________________________ > modules-dev mailing list > modules-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-dev From andreas.sterbenz at sun.com Wed Oct 10 06:00:07 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Wed, 10 Oct 2007 06:00:07 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710101300.l9AD07jx007868@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071010/94bddfc2/attachment.html From David.Bristor at Sun.COM Wed Oct 10 12:08:34 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Wed, 10 Oct 2007 12:08:34 -0700 Subject: [modules-dev] Review request for 6578988 In-Reply-To: <470C3AA8.6030702@sun.com> References: <470BE47F.7020009@sun.com> <470C3AA8.6030702@sun.com> Message-ID: <470D2332.4060207@sun.com> Thanks Stanley. It'll take a bit longer to address comments in the other review, so I figured on taking care of this first. I moved all field declarations to be at the top of the class declaration. I did this after noticing them placed throughout the class, and in particular seeing ThreadFactory, which is now used to create the shutdownThread. I also added isReloadSupported(), as per the spec. Rather than make it abstract, I have it returning false by default; subclasses can override this. Webrev updated: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6578988 Thanks, Dave Stanley M. Ho wrote: > Hi Dave, > > Looks good. One comment: > > - src/share/classes/java/module/Repository.java > > 244 shutdownThread = new Thread() { > > The issue is that this shutdownThread is not created until the first > shutdownOnExit() is called. However, this could happen in any thread > group. In the sandbox, thread groups easily come and go as applications > are loaded, and shutdown, and this shutdown hook might not be executed > properly if the associated thread group has been destroyed before the > end of the JVM session. > > The proper way to fix this is to obtain the main thread group when the > module system is started, and make sure this shutdown thread is created > in the main thread group. > > - Stanley > > > Dave Bristor wrote: >> Hi folks, >> >> This fix for >> (repo) Implement Repository.shutdownOnExit >> >> builds on top of my previous request (attached); it has build atop >> that because the changes here for shutdownOnExit() rely on the changes >> to shutdown() in the prior request. >> >> This is a *lot* shorter than my previous request. It includes some >> javadoc fixes in JamUtils. >> >> You'll see in the change that when shutdownOnExit is invoked with >> false, that any previously-created shutdownThread is made available to >> GC. I didn't see any reason to retain the reference if the likelihood >> is that it won't be used. It might be better to keep it once >> created. Space v. time! >> >> bugster: http://monaco.sfbay/detail.jsp?cr=6578988 >> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6578988 >> >> I submitted a JPRT run that has changes for this fix plus the others. >> >> Thanks! >> Dave >> >> ------------------------------------------------------------------------ >> >> Subject: >> Review request for 6559067, 6559086, and 6605100 >> From: >> Dave Bristor >> Date: >> Fri, 05 Oct 2007 15:55:54 -0700 >> To: >> modules-dev at openjdk.java.net >> >> To: >> modules-dev at openjdk.java.net >> >> >> Hi folks, >> >> This fixes 3 bugs: >> (repo) implement LocalRepository.shutdown() and reload() >> http://monaco.sfbay/detail.jsp?cr=6559067 >> >> (repo) URLRepository.shutdown() and reload() >> http://monaco.sfbay/detail.jsp?cr=6559086 >> >> (repo) Allow factories in repository configuration >> http://monaco.sfbay/detail.jsp?cr=6605100 >> >> The webrev is at: >> >> http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6559067+6559086+6605100/ >> >> >> There are lots of changes, so a description of them is in order: >> >> * LocalRepository and URLRepository suffered from entropy, so I moved >> code around and brought them up to coding standards (I'm sure some >> things are still missed in that regard). >> >> * In discussion, Kumar, Stanley, and I decided that the configuration >> of those 2 repositories should be via system properties and the >> Map given when they're constructed. The >> repository-specific system propertes are read once, when the class is >> loaded. Their values *override* any that could be given at >> construction. BasicLauncherTests was changed to use overrides via >> system properties; Local and URL repository tests use overrides via >> the Map. >> >> * When one of those repositories is created, it is OK if its source >> location does not exist. In this case, when find() or list() >> operations are performed, they'll return empty lists. If reload() is >> performed, and at that time the source location *does* exist, then >> subsequent find() or list() operations will return modules now >> available. This is verified in the Local and URL repository tests. >> Checks for the prior, opposite behavior were removed from these and >> from RepositoryTest. >> >> * However, we provide a system property for each of these repository >> types that can cause construction/initialization to require that the >> source location *does* exist at that time; if not an IOException gets >> thrown. LocalRepositoryTest verifies this. >> >> * shutdown() and reload() are implemented for both repositories, and >> are verified in Local and URL repository tests. >> >> * For these repository implementations: once an instance has been >> initialized, subsequent initialize() invocations are a no-op. Once an >> instance has been initialized and then shutdown, subsequent shutdown() >> invocations are a no-op. But if an instance is initialized, then >> shutdown, a subsequent initialize() invocation throws >> IllegalStateException. Local and URL repository tests were updated to >> check this. >> >> * RepositoryConfig now supports configuration via RepositoryFactory >> objects. See src/share/lib/module/repository.properties and >> src/share/classes/sun/module/repository/ExtensionRepositoryFactory for >> an example. A new test was added for factories. >> >> Thanks, >> Dave >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> modules-dev mailing list >> modules-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/modules-dev From andreas.sterbenz at sun.com Thu Oct 11 06:00:05 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Thu, 11 Oct 2007 06:00:05 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710111300.l9BD05N5018382@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071011/47cc9bb9/attachment.html From David.Bristor at Sun.COM Thu Oct 11 14:58:06 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Thu, 11 Oct 2007 14:58:06 -0700 Subject: [modules-dev] Review request for 6559067, 6559086, and 6605100 In-Reply-To: <470C3793.8080401@sun.com> References: <4706C0FA.4000703@sun.com> <470C3793.8080401@sun.com> Message-ID: <470E9C6E.6010605@sun.com> Hi Stanley, thanks for all the feedback...it was a lot to review! Comments inline. Stanley M. Ho wrote: > Hi Dave, > > Looks good. Several comments: > > - src/share/classes/sun/module/repository/LocalRepository.java > > 253 public synchronized ModuleArchiveInfo install(URL u) throws > IOException { > > Should check if repository is read-only. Local repository is read-only > if the source location is not writable by the user. Fixed. See also changes to isReadOnly(). > 260 throw new IOException( > 261 "Cannot overwrite " + f.getName() + " in repository > directory " + sourceDir); > > Should throw IllegalStateException instead because a module definition > with the same name, version, and platform binding has already been > installed. Fixed. > 261 "Cannot overwrite " + f.getName() + " in repository > directory " + sourceDir); > > "in repository's source directory" instead of "in repository directory". Fixed. > 278 public synchronized boolean uninstall(ModuleArchiveInfo m) > throws IOException { > > Should check if repository is read-only. Fixed; FWIW I don't see it as a requirement in the spec nor javadoc (not to discount it as a good idea!). I changed install() and uninstall(). I also added a check to disallow installation of modules whose names begin with "java." (No test for this latter, though.) > 287 if (!f.exists()) { > 288 throw new IOException("Could not find module file for " > + m.getName() > 289 + "in the repository"); > 290 } > > If module does not exist, should simply return false. See spec. Fixed. > 295 if (f2.isDirectory()) { > > What happens if f2 is a file? Then somehow a file of that name got created, perhaps by a user; we shouldn't do anything with it. The non-directory situation now throws IllegalStateException. > > 328 ArrayList rc = new > ArrayList(); > 329 if (constraint == Query.ANY) { > 330 for (ModuleDefinition md : > contents.getModuleDefinitions()) { > 331 rc.add(md); > 332 } > 333 } else { > 334 for (ModuleDefinition md : > contents.getModuleDefinitions()) { > 335 if (constraint.match(md)) { > 336 rc.add(md); > 337 } > 338 } > 339 } > > The result should be read-only, and it could also be cached for > subsequent query as an optimization. > > List rc; > if (constraint == Query.ANY) { > rc = Collections.unmodifiableList(contents.getModuleDefinitions()); > } else { > rc = new ArrayList(); > for (ModuleDefinition md : contents.getModuleDefinitions()) { > if (constraint.match(md)) { > rc.add(md); > } > } > rc = Collections.unmodifiableList(rc); > } I made the result unmodifiable, and introduced some caching; see modDefCache. As an aside: findModuleDefinitions has to take the platform binding into account, so I fixed this too; see platformMatches(). For now that returns true but that will change once platform binding support gets added (see 6601899). > > 444 throw new NullPointerException("LocalRepository: config > cannot be null."); > 582 "LocalRepository: specified " + type + " directory " > > I notice that some exceptions' messages are prefixed with > "LocalRespository:" while some aren't. Should be consistent. Fixed by introducing new method msg(String) which returns given String arg with a prefix. I changed all (hopefully!) throws to use this. > 496 if (expansionDirName != null) { > 497 expansionDir = new File(expansionDirName, > 498 "expansion" + "-" + timestamp); > 499 expansionDir.mkdir(); > 500 } else { > 501 File tmp = File.createTempFile("jamtmp" + > System.currentTimeMillis(), "tmp"); > 502 expansionDir = new File(tmp.getParent(), > 503 "LocalRepositoryExpansion-" > 504 + getName() + "-" + timestamp); > 505 tmp.delete(); > 506 expansionDir.mkdirs(); > 507 } > > Could be simplified somewhat: > > if (expansionDirName == null) { > File tmp = File.createTempFile("jamtmp", System.currentTimeMillis(), > "tmp"); > expansionDirName = tmp.getParent().getCanonicalPath(); > tmp.delete(); > } > expansionDir = new File(expansionDirName, "LocalRepositoryExpansion-" + > getName() + "-" + timestamp); > expansionDir.mkdirs(); Done! > 495 private void initializeDirs() throws IOException { > > Perhaps "constructDirs", "constructCache", or "initializeCache". Now called initializeCache(). > 517 private void resetDirs() throws IOException { > > Perhaps "cleanupDirs" or "cleanupCache", or "removeCache". Now called removeCache(). > 547 private void uninstallJams() throws IOException { > > I don't seem to find where this method get used. Could it be removed? Definitely! It was used at one point, and I forgot to remove it. Done. > - src/share/classes/sun/module/repository/RepositoryConfig.java > > 489 + ": " + msg); > > Missing "'" before ": ". You're eyesight is much better than mine: Fixed. > - src/share/classes/sun/module/repository/URLRepository.java > > 675 public synchronized List > findModuleDefinitions(Query constraint) { > > Same comment as in LocalRepository. > > 774 String getSourcePath() { > > Don't see it being used. Can it be removed? It's used in URLModuleDefinitionContent. > 812 throw new NullPointerException("URLRepository: config > cannot be null."); > 846 "URLRepository: In repository " + getSourceLocation() > 877 throw new IOException("URLRepository: Cannot open > connection to " + moduleMD, ex); > 885 throw new IOException("URLRepository: Cannot load > MODULE.METADATA for " + moduleMD, ex); > > Prefix issue in exception's message. Fixed similarly to LocalRepository. > 1087 private void initializeDirs() throws IOException { > 1111 private void resetDirs() throws IOException { > > See above. Fixed as in LocalRepository. > 1122 metadataDir = null; > 1123 downloadDir = null; > > Shouldn't baseDir also be reset to null? Fixed. > - src/share/classes/sun/module/repository/ExtensionRepositoryFactory.java > > I think you might mean global repository instead of extension repository. > > 54 locations.put("linux", "/usr/jdk/packages/lib/ext"); > 55 locations.put("solaris", "/usr/java/packages/lib/ext"); > 56 locations.put("windows", "%SystemRoot%\\Sun\\Java\\lib\\ext"); > > These locations are where the global legacy extension JARs are stored, > but they're not for modules. For the extension repository, the location > should be {java.home}/lib/module/ext on all platforms. I changed repository.properties to accomplish this. > If you want to add the support for the global repository, the location > would be the following for now: > > Linux: /usr/jdk/packages/lib/module > Solaris: /usr/java/packages/lib/module > Windows: %SystemRoot%\\Sun\\Java\\lib\\module > > That said, the location should be specified in the repository.properties > rather than hardcoded. See below. I have the locations both hardcoded and in repository.properties; the latter take precedence over the former. > 71 return Modules.newLocalRepository( > > The extension repository should be a file-based URL repository for > performance reason, while the global repository should be a local > repository. Done, via classname in repository.properties > - src/share/lib/module/repository.properties > > 32 extension.parent=bootstrap > 33 extension.factoryname=sun.module.repository.ExtensionRepositoryFactory > > 34 > 35 user.parent=extension > 36 user.factoryname=sun.module.repository.UserRepositoryFactory > > extension.parent=bootstrap > extension.factoryname=sun.module.repository.ExtensionRepositoryFactory > extension.source.location=file:///{java.home}/lib/module/ext > global.parent=extension > global.factoryname=sun.module.repository.GlobalRepositoryFactory > global.source.location=/usr/jdk/packages/lib/module (note: varies > between platforms) > user.parent=global > user.factoryname=sun.module.repository.UserRepositoryFactory > user.source.location=file:///{user.home}/.java/module Fixed in principle, though the result is a little different. We explicitly don't use the form of the source given for the user repository because that results in the error situation we discussed with Alan a while back. Webrev is updated: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6559067+6559086+6605100/ Thanks again for the extensive feedback, Dave > That's it for now. > > - Stanley > > > Dave Bristor wrote: >> Hi folks, >> >> This fixes 3 bugs: >> (repo) implement LocalRepository.shutdown() and reload() >> http://monaco.sfbay/detail.jsp?cr=6559067 >> >> (repo) URLRepository.shutdown() and reload() >> http://monaco.sfbay/detail.jsp?cr=6559086 >> >> (repo) Allow factories in repository configuration >> http://monaco.sfbay/detail.jsp?cr=6605100 >> >> The webrev is at: >> >> http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6559067+6559086+6605100/ >> >> >> There are lots of changes, so a description of them is in order: >> >> * LocalRepository and URLRepository suffered from entropy, so I moved >> code around and brought them up to coding standards (I'm sure some >> things are still missed in that regard). >> >> * In discussion, Kumar, Stanley, and I decided that the configuration >> of those 2 repositories should be via system properties and the >> Map given when they're constructed. The >> repository-specific system propertes are read once, when the class is >> loaded. Their values *override* any that could be given at >> construction. BasicLauncherTests was changed to use overrides via >> system properties; Local and URL repository tests use overrides via >> the Map. >> >> * When one of those repositories is created, it is OK if its source >> location does not exist. In this case, when find() or list() >> operations are performed, they'll return empty lists. If reload() is >> performed, and at that time the source location *does* exist, then >> subsequent find() or list() operations will return modules now >> available. This is verified in the Local and URL repository tests. >> Checks for the prior, opposite behavior were removed from these and >> from RepositoryTest. >> >> * However, we provide a system property for each of these repository >> types that can cause construction/initialization to require that the >> source location *does* exist at that time; if not an IOException gets >> thrown. LocalRepositoryTest verifies this. >> >> * shutdown() and reload() are implemented for both repositories, and >> are verified in Local and URL repository tests. >> >> * For these repository implementations: once an instance has been >> initialized, subsequent initialize() invocations are a no-op. Once an >> instance has been initialized and then shutdown, subsequent shutdown() >> invocations are a no-op. But if an instance is initialized, then >> shutdown, a subsequent initialize() invocation throws >> IllegalStateException. Local and URL repository tests were updated to >> check this. >> >> * RepositoryConfig now supports configuration via RepositoryFactory >> objects. See src/share/lib/module/repository.properties and >> src/share/classes/sun/module/repository/ExtensionRepositoryFactory for >> an example. A new test was added for factories. >> >> Thanks, >> Dave >> _______________________________________________ >> modules-dev mailing list >> modules-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/modules-dev From andreas.sterbenz at sun.com Fri Oct 12 06:00:03 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Fri, 12 Oct 2007 06:00:03 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710121300.l9CD03CL000452@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071012/2a717fd2/attachment.html From db13166 at pasilla.SFBay.Sun.COM Fri Oct 12 17:20:19 2007 From: db13166 at pasilla.SFBay.Sun.COM (David Bristor) Date: Fri, 12 Oct 2007 17:20:19 -0700 (PDT) Subject: [modules-dev] Code Manager notification (putback-to) Message-ID: <200710130020.l9D0KJqg020815@pasilla.SFBay.Sun.COM> Event: putback-to Parent workspace: /net/shimmer.sfbay/export/home/jsr277/ws (shimmer.sfbay:/export/home/jsr277/ws) Child workspace: /data/ws/db-jam (pasilla:/data/ws/db-jam) User: db13166 Comment: 6559067 (repo) implement LocalRepository.shutdown() and reload() 6559086 (repo) URLRepository.shutdown() and reload() 6605100 (repo) Allow factories in repository configuration 6578988 (repo) Implement Repository.shutdownOnExit [stanley.ho] Files: update: src/share/classes/sun/module/repository/LocalRepository.java update: src/share/classes/sun/module/repository/RepositoryConfig.java update: src/share/classes/sun/module/repository/RepositoryContents.java update: src/share/classes/sun/module/repository/URLRepository.java update: src/share/lib/module/repository.properties update: test/java/module/repository/LocalRepositoryTest.java update: test/java/module/repository/URLRepositoryTest.java update: test/sun/module/repository/RepositoryTest.java update: src/share/classes/java/module/Repository.java update: src/share/classes/sun/module/JamUtils.java create: src/share/classes/sun/module/repository/RepositoryFactory.java create: src/share/classes/sun/module/repository/GlobalRepositoryFactory.java create: src/share/classes/sun/module/repository/UserRepositoryFactory.java create: test/sun/module/repository/RepositoryFactoryTest.java create: test/sun/module/repository/RepositoryFactoryTest.properties create: test/java/module/repository/ShutdownOnExitTest.java Examined files: 16 Contents Summary: 6 create 10 update Names Summary: 6 update parent's name history 6 update children's name history From andreas.sterbenz at sun.com Mon Oct 15 06:00:03 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Mon, 15 Oct 2007 06:00:03 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710151300.l9FD03av003774@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071015/a69db25d/attachment.html From andreas.sterbenz at sun.com Tue Oct 16 06:00:06 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Tue, 16 Oct 2007 06:00:06 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710161300.l9GD06eX025999@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071016/f156626a/attachment.html From David.Bristor at Sun.COM Tue Oct 16 15:42:10 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 16 Oct 2007 15:42:10 -0700 Subject: [modules-dev] Review request for 6560271 (embedded JAR files) Message-ID: <47153E42.2010103@sun.com> Hi folks, This set of changes lets embedded legacy JAR files work, including with the JarLibraryPath annotation. I plan to build on this in making changes to support native libraries. Comments welcome! bugster: http://monaco.sfbay/detail.jsp?cr=6560271 webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 Description of changes: Several bits of cleanup, such as for javadoc, consistency, etc. JamUtils: Added copyFile() which is therefore removed from URLRepository. LocalRepository: Improve location of expansionDir. URLRepository: Just cleanup. LocalJamDefinitionContent: Support for legacy/embedded JAR files. Code cleanup to make it more consistent with URLModuleDefinitionContent. I think this should be renamed to LocalModuleDefinitionContent for consistency (or rename the other class); opinions? URLModuleDefinitionContent: Support for legacy/embedded JAR files. RepositoryUtils: This new class has static methods which were formerly duplicated in others, especially {Local,URL}Repository. In theory, this could be a pair of base classes, one for the *Repository implementations, and one for the *ModuleDefinition implementations. The former is particularly likely. JamBuilder: now public constructor and can add annotations to the JAM that's to be built. LegacyJarTest: makes sure the above works ;-) Thanks, Dave From David.Bristor at Sun.COM Tue Oct 16 17:25:13 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 16 Oct 2007 17:25:13 -0700 Subject: [modules-dev] Validiating JAM files Message-ID: <47155669.6050205@sun.com> Hi folks, In yesterday's meeting, I offered that while adding support for embedded JAR files, it might be reasonable to also fix 6571510 (repo) Throw error if a JAM file contains a JAM file Stanley suggested that it would be a Good Thing if all kinds of JAM validation were done only once and ideally at the same time. Section 5.7 mentions checks that "can" be used: are they required to be done, i.e, "must" instead of "can"? Anyway, below is the list from the spec section 5.7, and my impressions on each. * The filename of the module archive must have .jam, .jam.pack.gz, or .jar extension. Not checked during LocalRepository.install() nor URLRepository.initialize(), but otherwise OK w/ those repositories. * The module archive must be in the JAM file format. i.e. a jar file with the MODULE.METADATA file under the MODULE-INF directory. Checked via RepositoryUtils.getMetadata(). * If the module archive is signed, its entries must be consistently signed by same set of signers. Not checked AFAIK. * The metadata of the module definition must follow the file format of the .spkg file. Not checked AFAIK. * The module name must be present in the metadata of the module definition. Not checked AFAIK. * If the module version is specified in the metadata of the module definition, it must follow the versioning scheme. Checked in Version.valueOf() * If version constraints are specified with the imports in the metadata of the module definition, they must follow the versioning scheme. Checked via Version.valueOf() * If the main class is specified in the metadata of the module definition or in the manifest of the module archive, the class must be present in the module archive. For URLRepository, we want to defer this check until the JAM is actually downloaded. For LocalRepository, we can check earlier. * If the import policy class is specified in the metadata of the module definition, the class must be present in the module archive. Ditto the previous. I plan to file bugs on the above late this week, unless there are objections or, even better, you let me know that one/more of the above are already implemented ;-) Thanks, Dave From Kumar.Srinivasan at Sun.COM Tue Oct 16 17:28:08 2007 From: Kumar.Srinivasan at Sun.COM (Kumar Srinivasan) Date: Tue, 16 Oct 2007 17:28:08 -0700 Subject: [modules-dev] Review request for 6560271 (embedded JAR files) In-Reply-To: <47153E42.2010103@sun.com> References: <47153E42.2010103@sun.com> Message-ID: <47155718.4010706@Sun.COM> Hi Dave, Generally looks good. I am quite sure Stanley will do a more thorough review, here are some comments: 1. I noticed you were using buffers of 4096 and other places 8192, I think we should put a static in JamUtils.BUFFER_SIZE = 8192 and simply use this everywhere or if we want different sizes for whatever reason we could do this: JamUtils.LARGE_BUFFER_SIZE = 8192 JamUtils.MEDIUM_BUFFER_SIZE = 4096 JamUtils.SMALL_BUFFER_SIZE = 2048 2. LocalJamDefinitionContent.java s/cpde/code/g > Hi folks, > > This set of changes lets embedded legacy JAR files work, including with the > JarLibraryPath annotation. I plan to build on this in making changes to > support native libraries. Comments welcome! > > bugster: http://monaco.sfbay/detail.jsp?cr=6560271 > webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 > > Description of changes: > > Several bits of cleanup, such as for javadoc, consistency, etc. > > JamUtils: Added copyFile() which is therefore removed from URLRepository. > > LocalRepository: Improve location of expansionDir. > > URLRepository: Just cleanup. > > LocalJamDefinitionContent: Support for legacy/embedded JAR files. Code > cleanup to make it more consistent with URLModuleDefinitionContent. I think > this should be renamed to LocalModuleDefinitionContent for consistency (or > rename the other class); opinions? > > URLModuleDefinitionContent: Support for legacy/embedded JAR files. > > RepositoryUtils: This new class has static methods which were formerly > duplicated in others, especially {Local,URL}Repository. In theory, this could > be a pair of base classes, one for the *Repository implementations, and one > for the *ModuleDefinition implementations. The former is particularly likely. > > JamBuilder: now public constructor and can add annotations to the JAM that's > to be built. > > LegacyJarTest: makes sure the above works ;-) > > Thanks, > Dave > _______________________________________________ > modules-dev mailing list > modules-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-dev > -- Kumar Srinivasan Sun Microsystems, Java Software. 408-276-7586 From David.Bristor at Sun.COM Tue Oct 16 18:08:43 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 16 Oct 2007 18:08:43 -0700 Subject: [modules-dev] Review request for 6560271 (embedded JAR files) In-Reply-To: <47155718.4010706@Sun.COM> References: <47153E42.2010103@sun.com> <47155718.4010706@Sun.COM> Message-ID: <4715609B.4090005@sun.com> Thanks for the feedback, my followup inline. Kumar Srinivasan wrote: > Hi Dave, > > Generally looks good. I am quite sure Stanley will do a more > thorough review, here are some comments: > > 1. I noticed you were using buffers of 4096 and other places > 8192, I think we should put a static in JamUtils.BUFFER_SIZE = 8192 > and simply use this everywhere or if we want different sizes for > whatever reason we could do this: > JamUtils.LARGE_BUFFER_SIZE = 8192 > JamUtils.MEDIUM_BUFFER_SIZE = 4096 > JamUtils.SMALL_BUFFER_SIZE = 2048 I added a single BUFFER_SIZE = 8192 in JamUtils, and made use of it in files that are already part of this webrev. I updated 6566724 to explicitly mention this for other code too: 6566724 Add constants for oft-used strings such as MODULE.METADATA That'll make a nice cleanup task for a rainy day ;-) > 2. LocalJamDefinitionContent.java s/cpde/code/g Webrev updated: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 Fixed, thanks. Dave > > > > >> Hi folks, >> >> This set of changes lets embedded legacy JAR files work, including with the >> JarLibraryPath annotation. I plan to build on this in making changes to >> support native libraries. Comments welcome! >> >> bugster: http://monaco.sfbay/detail.jsp?cr=6560271 >> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 >> >> Description of changes: >> >> Several bits of cleanup, such as for javadoc, consistency, etc. >> >> JamUtils: Added copyFile() which is therefore removed from URLRepository. >> >> LocalRepository: Improve location of expansionDir. >> >> URLRepository: Just cleanup. >> >> LocalJamDefinitionContent: Support for legacy/embedded JAR files. Code >> cleanup to make it more consistent with URLModuleDefinitionContent. I think >> this should be renamed to LocalModuleDefinitionContent for consistency (or >> rename the other class); opinions? >> >> URLModuleDefinitionContent: Support for legacy/embedded JAR files. >> >> RepositoryUtils: This new class has static methods which were formerly >> duplicated in others, especially {Local,URL}Repository. In theory, this could >> be a pair of base classes, one for the *Repository implementations, and one >> for the *ModuleDefinition implementations. The former is particularly likely. >> >> JamBuilder: now public constructor and can add annotations to the JAM that's >> to be built. >> >> LegacyJarTest: makes sure the above works ;-) >> >> Thanks, >> Dave >> _______________________________________________ >> modules-dev mailing list >> modules-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/modules-dev >> > > From David.Bristor at Sun.COM Tue Oct 16 18:19:33 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 16 Oct 2007 18:19:33 -0700 Subject: [modules-dev] Review request for 6560271 (embedded JAR files) In-Reply-To: <4715609B.4090005@sun.com> References: <47153E42.2010103@sun.com> <47155718.4010706@Sun.COM> <4715609B.4090005@sun.com> Message-ID: <47156325.9080101@sun.com> Even more followup: I just noticed in issue regarding uninstallation of legacy jars: please hold off on any review until I get to look at it tomorrow morning... Dave Dave Bristor wrote: > Thanks for the feedback, my followup inline. > > Kumar Srinivasan wrote: >> Hi Dave, >> >> Generally looks good. I am quite sure Stanley will do a more >> thorough review, here are some comments: >> >> 1. I noticed you were using buffers of 4096 and other places >> 8192, I think we should put a static in JamUtils.BUFFER_SIZE = 8192 >> and simply use this everywhere or if we want different sizes for >> whatever reason we could do this: >> JamUtils.LARGE_BUFFER_SIZE = 8192 >> JamUtils.MEDIUM_BUFFER_SIZE = 4096 >> JamUtils.SMALL_BUFFER_SIZE = 2048 > > I added a single BUFFER_SIZE = 8192 in JamUtils, and made use of it in files > that are already part of this webrev. I updated 6566724 to explicitly mention > this for other code too: > > 6566724 Add constants for oft-used strings such as MODULE.METADATA > > That'll make a nice cleanup task for a rainy day ;-) > >> 2. LocalJamDefinitionContent.java s/cpde/code/g > > Webrev updated: > http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 > > Fixed, thanks. > > Dave >> >> >> >>> Hi folks, >>> >>> This set of changes lets embedded legacy JAR files work, including with the >>> JarLibraryPath annotation. I plan to build on this in making changes to >>> support native libraries. Comments welcome! >>> >>> bugster: http://monaco.sfbay/detail.jsp?cr=6560271 >>> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 >>> >>> Description of changes: >>> >>> Several bits of cleanup, such as for javadoc, consistency, etc. >>> >>> JamUtils: Added copyFile() which is therefore removed from URLRepository. >>> >>> LocalRepository: Improve location of expansionDir. >>> >>> URLRepository: Just cleanup. >>> >>> LocalJamDefinitionContent: Support for legacy/embedded JAR files. Code >>> cleanup to make it more consistent with URLModuleDefinitionContent. I think >>> this should be renamed to LocalModuleDefinitionContent for consistency (or >>> rename the other class); opinions? >>> >>> URLModuleDefinitionContent: Support for legacy/embedded JAR files. >>> >>> RepositoryUtils: This new class has static methods which were formerly >>> duplicated in others, especially {Local,URL}Repository. In theory, this could >>> be a pair of base classes, one for the *Repository implementations, and one >>> for the *ModuleDefinition implementations. The former is particularly likely. >>> >>> JamBuilder: now public constructor and can add annotations to the JAM that's >>> to be built. >>> >>> LegacyJarTest: makes sure the above works ;-) >>> >>> Thanks, >>> Dave >>> _______________________________________________ >>> modules-dev mailing list >>> modules-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/modules-dev >>> >> > _______________________________________________ > modules-dev mailing list > modules-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-dev From andreas.sterbenz at sun.com Wed Oct 17 06:00:20 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Wed, 17 Oct 2007 06:00:20 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710171300.l9HD0Kqx004169@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071017/ca043c69/attachment.html From andreas.sterbenz at sun.com Thu Oct 18 06:00:04 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Thu, 18 Oct 2007 06:00:04 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710181300.l9ID047l000599@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071018/e45ec633/attachment.html From David.Bristor at Sun.COM Thu Oct 18 14:48:04 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Thu, 18 Oct 2007 14:48:04 -0700 Subject: [modules-dev] Review request for 6560271 (embedded JAR files) In-Reply-To: <47156325.9080101@sun.com> References: <47153E42.2010103@sun.com> <47155718.4010706@Sun.COM> <4715609B.4090005@sun.com> <47156325.9080101@sun.com> Message-ID: <4717D494.1070601@sun.com> I fixed the issues w.r.t. uninstallation, and updated the webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271/ For the curious, these changes have to do with making the location of legacy jars be consistent between Local and URL repositories, and ensuring that uninstall() removes only those for the particular module being uninstalled. Also, expansion directories are now not created unless required. A minor downside of these changes is that ShutdownOnExitTest doesn't work on Windows, so it's been changed to pass on that platform. We can't do better until disableModuleDefinition is implemented. Thanks, Dave Dave Bristor wrote: > Even more followup: I just noticed in issue regarding uninstallation of > legacy jars: please hold off on any review until I get to look at it > tomorrow morning... > Dave > > Dave Bristor wrote: >> Thanks for the feedback, my followup inline. >> >> Kumar Srinivasan wrote: >>> Hi Dave, >>> >>> Generally looks good. I am quite sure Stanley will do a more >>> thorough review, here are some comments: >>> >>> 1. I noticed you were using buffers of 4096 and other places >>> 8192, I think we should put a static in JamUtils.BUFFER_SIZE = 8192 >>> and simply use this everywhere or if we want different sizes for >>> whatever reason we could do this: >>> JamUtils.LARGE_BUFFER_SIZE = 8192 >>> JamUtils.MEDIUM_BUFFER_SIZE = 4096 >>> JamUtils.SMALL_BUFFER_SIZE = 2048 >> >> I added a single BUFFER_SIZE = 8192 in JamUtils, and made use of it in >> files that are already part of this webrev. I updated 6566724 to >> explicitly mention this for other code too: >> >> 6566724 Add constants for oft-used strings such as MODULE.METADATA >> >> That'll make a nice cleanup task for a rainy day ;-) >> >>> 2. LocalJamDefinitionContent.java s/cpde/code/g >> >> Webrev updated: >> http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 >> >> Fixed, thanks. >> >> Dave >>> >>> >>> >>>> Hi folks, >>>> >>>> This set of changes lets embedded legacy JAR files work, including >>>> with the JarLibraryPath annotation. I plan to build on this in >>>> making changes to support native libraries. Comments welcome! >>>> >>>> bugster: http://monaco.sfbay/detail.jsp?cr=6560271 >>>> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 >>>> >>>> Description of changes: >>>> >>>> Several bits of cleanup, such as for javadoc, consistency, etc. >>>> >>>> JamUtils: Added copyFile() which is therefore removed from >>>> URLRepository. >>>> >>>> LocalRepository: Improve location of expansionDir. >>>> >>>> URLRepository: Just cleanup. >>>> >>>> LocalJamDefinitionContent: Support for legacy/embedded JAR files. >>>> Code cleanup to make it more consistent with >>>> URLModuleDefinitionContent. I think this should be renamed to >>>> LocalModuleDefinitionContent for consistency (or rename the other >>>> class); opinions? >>>> >>>> URLModuleDefinitionContent: Support for legacy/embedded JAR files. >>>> >>>> RepositoryUtils: This new class has static methods which were >>>> formerly duplicated in others, especially {Local,URL}Repository. In >>>> theory, this could be a pair of base classes, one for the >>>> *Repository implementations, and one for the *ModuleDefinition >>>> implementations. The former is particularly likely. >>>> >>>> JamBuilder: now public constructor and can add annotations to the >>>> JAM that's to be built. >>>> >>>> LegacyJarTest: makes sure the above works ;-) >>>> >>>> Thanks, >>>> Dave >>>> _______________________________________________ >>>> modules-dev mailing list >>>> modules-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/modules-dev >>>> >>> >> _______________________________________________ >> modules-dev mailing list >> modules-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/modules-dev > From ksrini at baggy.SFBay.Sun.COM Thu Oct 18 16:01:03 2007 From: ksrini at baggy.SFBay.Sun.COM (Kumar Srinivasan - Java Software) Date: Thu, 18 Oct 2007 16:01:03 -0700 (PDT) Subject: [modules-dev] Code Manager notification (putback-to) Message-ID: <200710182301.l9IN1331024849@baggy.SFBay.Sun.COM> Event: putback-to Parent workspace: /net/shimmer.sfbay/export/home/jsr277/ws (shimmer.sfbay:/export/home/jsr277/ws) Child workspace: /net/baggy.sfbay/allmine/ws-277/j2se (baggy:/net/baggy.sfbay/allmine/ws-277/j2se) User: ksrini Comment: 6559097:(cl) set the system classloader to the module classloader[stanley.ho at Sun.COM, dave.bristor at Sun.COM, andreas.sterbenz at Sun.com] 6604523:(launcher) tests should use the new jam tools[stanley.ho at Sun.COM, dave.bristor at Sun.COM, andreas.sterbenz at Sun.com] Webrev: http://javaweb.sfbay/~ksrini/webrevs/j2se-tools/jsr277-11.2 Testing: * jtreg on solaris, windows * jprt all platforms Files: update: src/share/bin/java.c update: src/share/classes/java/lang/ClassLoader.java update: src/share/classes/java/module/ModuleSystem.java update: src/share/classes/sun/module/ModuleLauncher.java update: src/share/classes/sun/module/bootstrap/ClasspathModule.java update: src/share/classes/sun/module/config/DefaultImportOverridePolicy.java update: src/share/classes/sun/module/core/ModuleLoader.java update: test/java/module/basic/BasicLauncherTests.java update: test/java/module/basic/Utils.java create: src/share/classes/sun/module/core/ProxyModuleLoader.java Examined files: 10 Contents Summary: 1 create 9 update Names Summary: 1 update parent's name history 1 update children's name history From jprtadm at jprt-web.SFBay.Sun.COM Thu Oct 18 16:52:33 2007 From: jprtadm at jprt-web.SFBay.Sun.COM (JPRT Administrator) Date: Thu, 18 Oct 2007 16:52:33 -0700 (PDT) Subject: [modules-dev] JPRT: [sfbay] job notification - success with job 2007-10-18-230145.daemon.jsr277-putback Message-ID: <200710182352.l9INqXrI007786@jprt-web.SFBay.Sun.COM> JPRT: [sfbay] job notification - success with job 2007-10-18-230145.daemon.jsr277-putback JPRT Job ID: 2007-10-18-230145.daemon.jsr277-putback JPRT System Used: sfbay JPRT Version Used: 28 Sep 2007 - Ask a Stupid Question Day Job URL: http://javaweb.sfbay/jdk/jprt/archive/2007/10/2007-10-18-230145.daemon.jsr277-putback Job ARCHIVE: /net/prt-archiver.sfbay/data/jprt/archive/2007/10/2007-10-18-230145.daemon.jsr277-putback User: daemon Email: modules-dev at openjdk.java.net Release: jdk1.7.0 Job Source: Source Tree: /net/shimmer.sfbay/export/home/jsr277/ws/{make,src} File List: {.} Exclude List: {build} Command Line: jprt submit -stree ../ws -ot '.*linux_i586.*product.*' -noquickabort -email modules-dev at openjdk.java.net -id jsr277-putback -rtests '*-*-c2-java/module' -rtests '*-*-c2-sun/module' Job submitted at: Thu-23:01:46-GMT Total time in queue: 50m 47s Job started at: Thu-23:34:49-GMT Job finished at: Thu-23:52:33-GMT Job run time: 17m 44s Job state: success Job flags: Bundles: USE: jprt install 2007-10-18-230145.daemon.jsr277-putback HINT: Use 'jprt rerun -comment -retest 2007-10-18-230145.daemon.jsr277-putback' to rerun the tests for this job (you can also add tests with 'jprt rerun'). NOTE: Zip files containing exe or dll files on windows have had problems with execute permissions. You may need to 'chmod a+x' the windows exe and dll files. User Comments: null Build (Release:jdk1.7.0 Boot: Import:): linux_i586_2.4-product success(13m 45s elapsed) Tests: linux_i586-product-c1-jvm98 success(02m 21s elapsed) linux_i586-product-c2-jvm98 success(02m 08s elapsed) linux_i586-product-c2-java/module success(02m 31s elapsed) linux_i586-product-c2-sun/module success(02m 00s elapsed) For announcements on downtime and availability join the alias 'jprt-announce at sun.com'. You can see the latest announcements at http://archives.central/tm/browse?jprt-announce. For suspected system problems, send mail to 'jprt-admin at sun.com'. The jprt how to document is available at http://javaweb.sfbay/jdk/jprt/dist/javadoc/jprt/doc-files/how-to.html. From andreas.sterbenz at sun.com Fri Oct 19 06:00:29 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Fri, 19 Oct 2007 06:00:29 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710191300.l9JD0TcE014379@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071019/3e0cb352/attachment.html From jprtadm at jprt-web.SFBay.Sun.COM Fri Oct 19 16:10:10 2007 From: jprtadm at jprt-web.SFBay.Sun.COM (JPRT Administrator) Date: Fri, 19 Oct 2007 16:10:10 -0700 (PDT) Subject: [modules-dev] JPRT: [sfbay] job notification - success with job 2007-10-19-111319.as130790.jsr277-nightly Message-ID: <200710192310.l9JNAAc1016555@jprt-web.SFBay.Sun.COM> JPRT: [sfbay] job notification - success with job 2007-10-19-111319.as130790.jsr277-nightly JPRT Job ID: 2007-10-19-111319.as130790.jsr277-nightly JPRT System Used: sfbay JPRT Version Used: 28 Sep 2007 - Ask a Stupid Question Day Job URL: http://javaweb.sfbay/jdk/jprt/archive/2007/10/2007-10-19-111319.as130790.jsr277-nightly Job ARCHIVE: /net/prt-archiver.sfbay/data/jprt/archive/2007/10/2007-10-19-111319.as130790.jsr277-nightly User: as130790 Email: modules-dev at openjdk.java.net Release: jdk1.7.0 Job Source: Source Tree: /net/shimmer.sfbay/export/home/jsr277/ws/{make,src} File List: {.} Exclude List: {build} Command Line: jprt submit -stree ../ws -ot '.*product.*' -noquickabort -email modules-dev at openjdk.java.net -id jsr277-nightly -rtests '*-*-c2-java/module' -rtests '*-*-c2-sun/module' Job submitted at: Fri-11:13:21-GMT Total time in queue: 11h 56m 49s Job started at: Fri-22:06:07-GMT Job finished at: Fri-23:10:10-GMT Job run time: 1h 04m 03s Job state: success Job flags: Bundles: USE: jprt install 2007-10-19-111319.as130790.jsr277-nightly HINT: Use 'jprt rerun -comment -retest 2007-10-19-111319.as130790.jsr277-nightly' to rerun the tests for this job (you can also add tests with 'jprt rerun'). NOTE: Zip files containing exe or dll files on windows have had problems with execute permissions. You may need to 'chmod a+x' the windows exe and dll files. User Comments: null Build (Release:jdk1.7.0 Boot: Import:): solaris_sparc_5.10-product success(25m 09s elapsed) solaris_sparcv9_5.10-product success(14m 31s elapsed) solaris_i586_5.10-product success(13m 10s elapsed) solaris_x64_5.10-product success(07m 51s elapsed) linux_i586_2.4-product success(14m 43s elapsed) linux_x64_2.4-product success(16m 31s elapsed) windows_i586_5-product success(48m 07s elapsed) windows_x64_5.2-product success(49m 04s elapsed) Tests: solaris_sparc-product-c1-jvm98 success(03m 39s elapsed) solaris_sparc-product-c2-jvm98 success(02m 43s elapsed) solaris_sparcv9-product-c2-jvm98 success(03m 02s elapsed) solaris_i586-product-c1-jvm98 success(02m 19s elapsed) solaris_i586-product-c2-jvm98 success(02m 05s elapsed) solaris_x64-product-c2-jvm98 success(02m 01s elapsed) linux_i586-product-c1-jvm98 success(02m 25s elapsed) linux_i586-product-c2-jvm98 success(02m 15s elapsed) linux_x64-product-c2-jvm98 success(01m 49s elapsed) windows_i586-product-c1-jvm98 success(05m 47s elapsed) windows_i586-product-c2-jvm98 success(05m 31s elapsed) windows_x64-product-c2-jvm98 success(02m 40s elapsed) solaris_sparc-product-c2-java/module success(01m 51s elapsed) solaris_sparcv9-product-c2-java/module success(02m 00s elapsed) solaris_i586-product-c2-java/module success(01m 14s elapsed) solaris_x64-product-c2-java/module success(01m 24s elapsed) linux_i586-product-c2-java/module success(02m 27s elapsed) linux_x64-product-c2-java/module success(01m 15s elapsed) windows_i586-product-c2-java/module success(06m 41s elapsed) windows_x64-product-c2-java/module success(03m 54s elapsed) solaris_sparc-product-c2-sun/module success( 56s elapsed) solaris_sparcv9-product-c2-sun/module success(01m 01s elapsed) solaris_i586-product-c2-sun/module success( 41s elapsed) solaris_x64-product-c2-sun/module success( 38s elapsed) linux_i586-product-c2-sun/module success(01m 49s elapsed) linux_x64-product-c2-sun/module success( 58s elapsed) windows_i586-product-c2-sun/module success(04m 17s elapsed) windows_x64-product-c2-sun/module success(03m 30s elapsed) For announcements on downtime and availability join the alias 'jprt-announce at sun.com'. You can see the latest announcements at http://archives.central/tm/browse?jprt-announce. For suspected system problems, send mail to 'jprt-admin at sun.com'. The jprt how to document is available at http://javaweb.sfbay/jdk/jprt/dist/javadoc/jprt/doc-files/how-to.html. From andreas.sterbenz at sun.com Mon Oct 22 06:00:04 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Mon, 22 Oct 2007 06:00:04 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710221300.l9MD0493002048@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071022/15ab103f/attachment.html From mcconnell at dpml.net Mon Oct 22 15:29:05 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Tue, 23 Oct 2007 07:59:05 +0930 Subject: [modules-dev] java.module.ModuleArchiveInfo comments Message-ID: <1193092145.6362.25.camel@gloria> Apologies for the noise if the following has already been addressed ... While browsing through module sources I noticed that the ModuleArchiveInfo sources from the b22 (12-OCT) contains some inconsistencies between the javadoc and implementation as related to exception handling - specifically, the constructor documents that a NullPointerException will be thrown for a select number of cases, however, the implementation throws an IllegalArgumentException. In addition the constructor documentation asserts that a NPE will be thrown if the lastModified argument is less than 0. Seems to me that the source and javadoc should be update such that: 1. Null values throw NPE relative to the repository, name and version parameter tests 2. The inconsistent platform/architecture combinations and the negative lastModified validation should be handled though appropriate IllegalArgumentExceptions Cheers, Steve. P.S. Can anyone provide a public SVN url for the modules codebase? -- Stephen J. McConnell mailto:mcconnell at dpml.net http://www.dpml.net From Andreas.Sterbenz at Sun.COM Mon Oct 22 15:53:20 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Mon, 22 Oct 2007 15:53:20 -0700 Subject: [modules-dev] java.module.ModuleArchiveInfo comments In-Reply-To: <1193092145.6362.25.camel@gloria> References: <1193092145.6362.25.camel@gloria> Message-ID: <471D29E0.9030509@sun.com> Stephen J. McConnell wrote: > > Seems to me that the source and javadoc should be update such that: > > 1. Null values throw NPE relative to the repository, name > and version parameter tests > 2. The inconsistent platform/architecture combinations and > the negative lastModified validation should be handled > though appropriate IllegalArgumentExceptions I am not fully up-to-date on that class, but this sounds reasonable. I expect Stanley will want to comment once he is back online. > P.S. Can anyone provide a public SVN url for the modules codebase? No, but with any luck within the next few weeks (or so) there will be a Mercurial [1] repository for the Modules project on OpenJDK. That means people outside Sun will see exactly the same sources at the same time in the same way as people inside Sun. [1] http://www.selenic.com/mercurial/wiki/ Andreas. From andreas.sterbenz at sun.com Tue Oct 23 06:00:06 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Tue, 23 Oct 2007 06:00:06 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710231300.l9ND06PM023381@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071023/2938b5a4/attachment.html From David.Bristor at Sun.COM Tue Oct 23 16:44:40 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 23 Oct 2007 16:44:40 -0700 Subject: [modules-dev] [Fwd: Re: Review request for 6560271 (embedded JAR files)] Message-ID: <471E8768.8090907@sun.com> Hi folks, Any further feedback on 6560271? bugster: http://monaco.sfbay/detail.jsp?cr=6560271 webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271/ I heard from Kumar earlier that it was OK. I ask because, in a separate workspace, I have changes for 6601899: URLRepository.find*() must not return modules for other than the appropriate platform/arch which take care of using platform/arch. Presuming that the changes for 6560271 are "roughly correct", I've made these more recent changes essentially on top of those for 6560271. Since webrev diffs against checked-in files, I don't think it's possible to generate one between these two changes. I'll make one for 6601899 once I've checked in 6560271. But I won't check that in, until I hear that it's OK. Any takers? Thanks, Dave -------- Original Message -------- Subject: Re: [modules-dev] Review request for 6560271 (embedded JAR files) Date: Thu, 18 Oct 2007 14:48:04 -0700 From: Dave Bristor To: Dave Bristor CC: Kumar Srinivasan , modules-dev at openjdk.java.net References: <47153E42.2010103 at sun.com> <47155718.4010706 at Sun.COM> <4715609B.4090005 at sun.com> <47156325.9080101 at sun.com> I fixed the issues w.r.t. uninstallation, and updated the webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271/ For the curious, these changes have to do with making the location of legacy jars be consistent between Local and URL repositories, and ensuring that uninstall() removes only those for the particular module being uninstalled. Also, expansion directories are now not created unless required. A minor downside of these changes is that ShutdownOnExitTest doesn't work on Windows, so it's been changed to pass on that platform. We can't do better until disableModuleDefinition is implemented. Thanks, Dave Dave Bristor wrote: > Even more followup: I just noticed in issue regarding uninstallation of > legacy jars: please hold off on any review until I get to look at it > tomorrow morning... > Dave > > Dave Bristor wrote: >> Thanks for the feedback, my followup inline. >> >> Kumar Srinivasan wrote: >>> Hi Dave, >>> >>> Generally looks good. I am quite sure Stanley will do a more >>> thorough review, here are some comments: >>> >>> 1. I noticed you were using buffers of 4096 and other places >>> 8192, I think we should put a static in JamUtils.BUFFER_SIZE = 8192 >>> and simply use this everywhere or if we want different sizes for >>> whatever reason we could do this: >>> JamUtils.LARGE_BUFFER_SIZE = 8192 >>> JamUtils.MEDIUM_BUFFER_SIZE = 4096 >>> JamUtils.SMALL_BUFFER_SIZE = 2048 >> >> I added a single BUFFER_SIZE = 8192 in JamUtils, and made use of it in >> files that are already part of this webrev. I updated 6566724 to >> explicitly mention this for other code too: >> >> 6566724 Add constants for oft-used strings such as MODULE.METADATA >> >> That'll make a nice cleanup task for a rainy day ;-) >> >>> 2. LocalJamDefinitionContent.java s/cpde/code/g >> >> Webrev updated: >> http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 >> >> Fixed, thanks. >> >> Dave >>> >>> >>> >>>> Hi folks, >>>> >>>> This set of changes lets embedded legacy JAR files work, including >>>> with the JarLibraryPath annotation. I plan to build on this in >>>> making changes to support native libraries. Comments welcome! >>>> >>>> bugster: http://monaco.sfbay/detail.jsp?cr=6560271 >>>> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271 >>>> >>>> Description of changes: >>>> >>>> Several bits of cleanup, such as for javadoc, consistency, etc. >>>> >>>> JamUtils: Added copyFile() which is therefore removed from >>>> URLRepository. >>>> >>>> LocalRepository: Improve location of expansionDir. >>>> >>>> URLRepository: Just cleanup. >>>> >>>> LocalJamDefinitionContent: Support for legacy/embedded JAR files. >>>> Code cleanup to make it more consistent with >>>> URLModuleDefinitionContent. I think this should be renamed to >>>> LocalModuleDefinitionContent for consistency (or rename the other >>>> class); opinions? >>>> >>>> URLModuleDefinitionContent: Support for legacy/embedded JAR files. >>>> >>>> RepositoryUtils: This new class has static methods which were >>>> formerly duplicated in others, especially {Local,URL}Repository. In >>>> theory, this could be a pair of base classes, one for the >>>> *Repository implementations, and one for the *ModuleDefinition >>>> implementations. The former is particularly likely. >>>> >>>> JamBuilder: now public constructor and can add annotations to the >>>> JAM that's to be built. >>>> >>>> LegacyJarTest: makes sure the above works ;-) >>>> >>>> Thanks, >>>> Dave >>>> _______________________________________________ >>>> modules-dev mailing list >>>> modules-dev at openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/modules-dev >>>> >>> >> _______________________________________________ >> modules-dev mailing list >> modules-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/modules-dev > From andreas.sterbenz at sun.com Wed Oct 24 06:00:09 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Wed, 24 Oct 2007 06:00:09 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710241300.l9OD09Dq005355@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071024/1be8ae15/attachment.html From Andreas.Sterbenz at Sun.COM Wed Oct 24 18:06:55 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Wed, 24 Oct 2007 18:06:55 -0700 Subject: [modules-dev] [Fwd: Re: Review request for 6560271 (embedded JAR files)] In-Reply-To: <471E8768.8090907@sun.com> References: <471E8768.8090907@sun.com> Message-ID: <471FEC2F.3030707@sun.com> Dave Bristor wrote: > > bugster: http://monaco.sfbay/detail.jsp?cr=6560271 > webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271/ Looks fine, some minor comments: . JamUtils.copyFile(): creating a BufferedInputStream is not really useful here since the reads are all done in BUFFER_SIZEd blocks anyway . LocalRepository.installJams(): not sure why you deleted the comment about .pack.gz here, but if you don't need it, that is fine with me . LocalRepository.assertValidDirs(): why did you change !isDirectory() to isFile() ? . LocalJamDefinitionContent.createModuleDefinition(): is that string really intended to be "URLModuleDefinitionContent" ? . RepositoryUtils.extractJarFiles(): is that always "URLModuleDefinitionContent" ? . RepositoryUtils.extractJarFiles:223: I may be missing something, but are you creating a file and then immediately deleting it in some cases? Andreas. From andreas.sterbenz at sun.com Thu Oct 25 06:00:08 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Thu, 25 Oct 2007 06:00:08 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710251300.l9PD083u008270@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071025/b61686da/attachment.html From mcconnell at dpml.net Thu Oct 25 12:46:24 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Fri, 26 Oct 2007 05:16:24 +0930 Subject: [modules-dev] B22 modules project build failure Message-ID: <1193341584.12052.9.camel@gloria> When attempting to build the modules b22 distribution (from published sources) I'm getting an error related to an attempt to build something that references a non-existent resources in the binary plugs. The version of the binary plugs that I'm using is also the B22 release (however - the b22 general source release and the b22 modules release are not really in sync and I suspect that a different version of the binary plugs may be required). I would be really interested in knowing if anyone has successfully built the modules B22 distribution. Cheers, Steve. P.S. Here is the end of my build process: $ cd module/make $ make sanity $ make ... >>>Recursively making redist all @ Fri Oct 26 05:04:13 CST 2007 ... make[2]: Entering directory `/home/foo/jdk/modules/make/java/redist' BinaryPlugs import started: Fri Oct 26 05:04:13 CST 2007 BINARY_PLUGS_PATH=/home/foo/jdk/openjdk-binary-plugs make[2]: *** No rule to make target `/home/foo/jdk/openjdk-binary-plugs/jre/lib/i386/libdcpr.so', needed by `../../../build/linux-i586/lib/i386/libdcpr.so'. Stop. make[2]: Leaving directory `/home/foo/jdk/modules/make/java/redist' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/foo/jdk/modules/make/java' make: *** [all] Error 1 -- Stephen J. McConnell mailto:mcconnell at dpml.net http://www.dpml.net From David.Bristor at Sun.COM Thu Oct 25 15:28:05 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Thu, 25 Oct 2007 15:28:05 -0700 Subject: [modules-dev] [Fwd: Re: Review request for 6560271 (embedded JAR files)] In-Reply-To: <471FEC2F.3030707@sun.com> References: <471E8768.8090907@sun.com> <471FEC2F.3030707@sun.com> Message-ID: <47211875.2050702@sun.com> Thanks for the feedback; all fixed. Andreas Sterbenz wrote: > Dave Bristor wrote: >> >> bugster: http://monaco.sfbay/detail.jsp?cr=6560271 >> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271/ > > Looks fine, some minor comments: > > . JamUtils.copyFile(): creating a BufferedInputStream is not really > useful here since the reads are all done in BUFFER_SIZEd blocks anyway I removed the BufferedInputStream. > . LocalRepository.installJams(): not sure why you deleted the comment > about .pack.gz here, but if you don't need it, that is fine with me I wanted to clean out the XXX commentary where we have bugs filed, and in this case we've got 6566022. > . LocalRepository.assertValidDirs(): why did you change !isDirectory() > to isFile() ? I'd changed the use of expansionDir such that it isn't created in the filesystem unless there are any actual legacy JAR files; if it is not null but it's a plain file that would be bad. But your comment prompted this clarification/improvement: if (expansionDir != null && (expansionDir.exists() && !expansionDir.isDirectory())) { > . LocalJamDefinitionContent.createModuleDefinition(): is that string > really intended to be "URLModuleDefinitionContent" ? Whoops; changed to LocalJamDefinitionContent and another similar URL* mention in a comment. > . RepositoryUtils.extractJarFiles(): is that always > "URLModuleDefinitionContent" ? Whoops again. I added a private static final String NAME to {URLModule,LocalJam}DefinitionContent, and pass that where appropriate. > . RepositoryUtils.extractJarFiles:223: I may be missing something, but > are you creating a file and then immediately deleting it in some cases? Unfortunately so. Section 5.2.4 is explicit that legacy JARs must not contain MODULE.METADATA. The only way I know to determine that is to examine the embedded JAR's contents, and to do that we (currently) have to extract the JAR into its own file. I updated the webrev after seeing all tests pass. http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6560271/ Thanks, Dave > > > Andreas. > From andreas.sterbenz at sun.com Fri Oct 26 06:00:10 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Fri, 26 Oct 2007 06:00:10 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710261300.l9QD0AtC002473@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071026/8a464675/attachment.html From db13166 at pasilla.SFBay.Sun.COM Fri Oct 26 13:41:23 2007 From: db13166 at pasilla.SFBay.Sun.COM (David Bristor) Date: Fri, 26 Oct 2007 13:41:23 -0700 (PDT) Subject: [modules-dev] Code Manager notification (putback-to) Message-ID: <200710262041.l9QKfN8i004016@pasilla.SFBay.Sun.COM> Event: putback-to Parent workspace: /net/shimmer.sfbay/export/home/jsr277/ws (shimmer.sfbay:/export/home/jsr277/ws) Child workspace: /data/ws/db-repo (pasilla:/data/ws/db-repo) User: db13166 Comment: 6560271 (repo) Support for embedded JAR files [andreas.sterbenz, kumar.srinivasan] Files: update: src/share/classes/sun/module/JamUtils.java update: src/share/classes/sun/module/repository/LocalRepository.java update: src/share/classes/sun/module/repository/LocalJamDefinitionContent.java update: src/share/classes/sun/module/repository/URLModuleDefinitionContent.java update: src/share/classes/sun/module/repository/URLRepository.java update: src/share/classes/sun/module/tools/JRepo.java update: test/java/module/repository/ShutdownOnExitTest.java update: test/sun/module/tools/JamBuilder.java create: test/java/module/repository/LegacyJarTest.java Examined files: 9 Contents Summary: 1 create 8 update Names Summary: 1 update parent's name history 1 update children's name history From db13166 at pasilla.SFBay.Sun.COM Fri Oct 26 13:44:27 2007 From: db13166 at pasilla.SFBay.Sun.COM (David Bristor) Date: Fri, 26 Oct 2007 13:44:27 -0700 (PDT) Subject: [modules-dev] Code Manager notification (putback-to) Message-ID: <200710262044.l9QKiRWm007235@pasilla.SFBay.Sun.COM> Event: putback-to Parent workspace: /net/shimmer.sfbay/export/home/jsr277/ws (shimmer.sfbay:/export/home/jsr277/ws) Child workspace: /data/ws/db-repo (pasilla:/data/ws/db-repo) User: db13166 Comment: 6560271 (repo) Support for embedded JAR files [andreas.sterbenz, kumar.srinivasan] Files: create: src/share/classes/sun/module/repository/RepositoryUtils.java Examined files: 1 Contents Summary: 1 create Names Summary: 1 update parent's name history 1 update children's name history From jprtadm at jprt-web.SFBay.Sun.COM Fri Oct 26 14:16:42 2007 From: jprtadm at jprt-web.SFBay.Sun.COM (JPRT Administrator) Date: Fri, 26 Oct 2007 14:16:42 -0700 (PDT) Subject: [modules-dev] JPRT: [sfbay] job notification - FAILED with job 2007-10-26-204129.daemon.jsr277-putback Message-ID: <200710262116.l9QLGg5U009661@jprt-web.SFBay.Sun.COM> JPRT: [sfbay] job notification - FAILED with job 2007-10-26-204129.daemon.jsr277-putback Failure reason: Build target failure: linux_i586_2.4-product JPRT Job ID: 2007-10-26-204129.daemon.jsr277-putback JPRT System Used: sfbay JPRT Version Used: 28 Sep 2007 - Ask a Stupid Question Day Job URL: http://javaweb.sfbay/jdk/jprt/archive/2007/10/2007-10-26-204129.daemon.jsr277-putback Job ARCHIVE: /net/prt-archiver.sfbay/data/jprt/archive/2007/10/2007-10-26-204129.daemon.jsr277-putback User: daemon Email: modules-dev at openjdk.java.net Release: jdk1.7.0 Job Source: Source Tree: /net/shimmer.sfbay/export/home/jsr277/ws/{make,src} File List: {.} Exclude List: {build} Command Line: jprt submit -stree ../ws -ot '.*linux_i586.*product.*' -noquickabort -email modules-dev at openjdk.java.net -id jsr277-putback -rtests '*-*-c2-java/module' -rtests '*-*-c2-sun/module' Job submitted at: Fri-20:41:31-GMT Total time in queue: 35m 11s Job started at: Fri-21:14:41-GMT Job finished at: Fri-21:16:42-GMT Job run time: 02m 01s Job state: FAILED Job fail/kill comment: Build target failure: linux_i586_2.4-product Job flags: Bundles: USE: jprt install 2007-10-26-204129.daemon.jsr277-putback HINT: Use 'jprt rerun -comment 2007-10-26-204129.daemon.jsr277-putback' to rerun this job if you suspect bogus results. User Comments: null Build (Release:jdk1.7.0 Boot: Import:): linux_i586_2.4-product FAILED(01m 16s elapsed) ------------------------------------------------------------------------------ linux_i586_2.4-product (details from log file) /net/prt-archiver.sfbay/data/jprt/archive/2007/10/2007-10-26-204129.daemon.jsr277-putback/logs/linux_i586_2.4-product-build.log http://javaweb.sfbay/jdk/jprt/archive/2007/10/2007-10-26-204129.daemon.jsr277-putback//logs/linux_i586_2.4-product-build.log symbol : variable RepositoryUtils location: class sun.module.repository.URLModuleDefinitionContent byte[] moduleMetadata = RepositoryUtils.getMetadata(jamFile, IDENT); ^ ../../../src/share/classes/sun/module/repository/URLModuleDefinitionContent.java:302: cannot find symbol symbol : variable RepositoryUtils location: class sun.module.repository.URLModuleDefinitionContent File[] jarFiles = RepositoryUtils.getLegacyJars( ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 12 errors make[2]: *** [.compile.classlist] Error 1 make[2]: Leaving directory `/tmp/jprt/temp/P1/B/204129.daemon/source/make/java/java' make[1]: *** [all] Error 1 make[1]: Leaving directory `/tmp/jprt/temp/P1/B/204129.daemon/source/make/java' make: *** [all] Error 1 ########################################################### # # Finished: Fri Oct 26 14:16:23 PDT 2007 # # Disk Space: # Filesystem 1k-blocks Used Available Use% Mounted on # /dev/sda2 66357620 17166332 45820452 28% / # # Stats for ccache: # cache directory /opt/jprt/ccache_data/usr_bin # cache hit 89 # cache miss 5 # called for link 3 # no input file 111 # files in cache 35835 # cache size 850.0 Mbytes # max cache size 976.6 Mbytes # # returned exit code 2 # ########################################################### ------------------------------------------------------------------------------ Tests: linux_i586-product-c1-jvm98 not_started( 00s elapsed) linux_i586-product-c2-jvm98 not_started( 00s elapsed) linux_i586-product-c2-java/module not_started( 00s elapsed) linux_i586-product-c2-sun/module not_started( 00s elapsed) For announcements on downtime and availability join the alias 'jprt-announce at sun.com'. You can see the latest announcements at http://archives.central/tm/browse?jprt-announce. For suspected system problems, send mail to 'jprt-admin at sun.com'. The jprt how to document is available at http://javaweb.sfbay/jdk/jprt/dist/javadoc/jprt/doc-files/how-to.html. From jprtadm at jprt-web.SFBay.Sun.COM Fri Oct 26 14:36:45 2007 From: jprtadm at jprt-web.SFBay.Sun.COM (JPRT Administrator) Date: Fri, 26 Oct 2007 14:36:45 -0700 (PDT) Subject: [modules-dev] JPRT: [sfbay] job notification - success with job 2007-10-26-204434.daemon.jsr277-putback Message-ID: <200710262136.l9QLajNx009680@jprt-web.SFBay.Sun.COM> JPRT: [sfbay] job notification - success with job 2007-10-26-204434.daemon.jsr277-putback JPRT Job ID: 2007-10-26-204434.daemon.jsr277-putback JPRT System Used: sfbay JPRT Version Used: 28 Sep 2007 - Ask a Stupid Question Day Job URL: http://javaweb.sfbay/jdk/jprt/archive/2007/10/2007-10-26-204434.daemon.jsr277-putback Job ARCHIVE: /net/prt-archiver.sfbay/data/jprt/archive/2007/10/2007-10-26-204434.daemon.jsr277-putback User: daemon Email: modules-dev at openjdk.java.net Release: jdk1.7.0 Job Source: Source Tree: /net/shimmer.sfbay/export/home/jsr277/ws/{make,src} File List: {.} Exclude List: {build} Command Line: jprt submit -stree ../ws -ot '.*linux_i586.*product.*' -noquickabort -email modules-dev at openjdk.java.net -id jsr277-putback -rtests '*-*-c2-java/module' -rtests '*-*-c2-sun/module' Job submitted at: Fri-20:44:36-GMT Total time in queue: 52m 09s Job started at: Fri-21:16:55-GMT Job finished at: Fri-21:36:45-GMT Job run time: 19m 50s Job state: success Job flags: Bundles: USE: jprt install 2007-10-26-204434.daemon.jsr277-putback HINT: Use 'jprt rerun -comment -retest 2007-10-26-204434.daemon.jsr277-putback' to rerun the tests for this job (you can also add tests with 'jprt rerun'). NOTE: Zip files containing exe or dll files on windows have had problems with execute permissions. You may need to 'chmod a+x' the windows exe and dll files. User Comments: null Build (Release:jdk1.7.0 Boot: Import:): linux_i586_2.4-product success(11m 56s elapsed) Tests: linux_i586-product-c1-jvm98 success(06m 34s elapsed) linux_i586-product-c2-jvm98 success(06m 24s elapsed) linux_i586-product-c2-java/module success(06m 24s elapsed) linux_i586-product-c2-sun/module success(06m 15s elapsed) For announcements on downtime and availability join the alias 'jprt-announce at sun.com'. You can see the latest announcements at http://archives.central/tm/browse?jprt-announce. For suspected system problems, send mail to 'jprt-admin at sun.com'. The jprt how to document is available at http://javaweb.sfbay/jdk/jprt/dist/javadoc/jprt/doc-files/how-to.html. From David.Bristor at Sun.COM Fri Oct 26 17:45:55 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Fri, 26 Oct 2007 17:45:55 -0700 Subject: [modules-dev] Review request for 6601899 Message-ID: <47228A43.8010708@sun.com> Hi folks, This is to fix 6601899 (repo) URLRepository.find*() must not return modules for other than the appropriate platform/arch bugster: http://monaco.sfbay/detail.jsp?cr=6601899 webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6601899/ The bulk of the work involves taking into account platform & arch when installing, finding, and listing modules. There are several simplifications & cleanups. The "interesting" changes are in LocalRepository ModuleInfoXMLReader URLRepository Changes in those (and to a lesser extent other files) are based on additions to RepositoryUtils. LocalRepositoryTest and URLRepositoryTest were updated to take into account platform/arch specifics. There currently aren't any tests which look for the (IMHO unlikely) case of having specified platform but not arch or vice versa. Nor are there (yet) any tests which take into account a user-specified path. The changes also include a fix to Jam.java so that temp files are deleted on exit. Ditto for JamBuilder.java (only used as part of tests, but equally good for it to clean up after itself). Thanks, Dave From mcconnell at dpml.net Fri Oct 26 19:51:11 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Sat, 27 Oct 2007 12:21:11 +0930 Subject: [modules-dev] Review request for 6601899 In-Reply-To: <47228A43.8010708@sun.com> References: <47228A43.8010708@sun.com> Message-ID: <1193453471.14440.5.camel@gloria> On Fri, 2007-10-26 at 17:45 -0700, Dave Bristor wrote: > Hi folks, > > This is to fix > > 6601899 (repo) URLRepository.find*() must not return modules for other than > the appropriate platform/arch > > bugster: http://monaco.sfbay/detail.jsp?cr=6601899 > webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6601899/ > > The bulk of the work involves taking into account platform & arch when > installing, finding, and listing modules. There are several simplifications & > cleanups. The "interesting" changes are in > > LocalRepository > ModuleInfoXMLReader > URLRepository > > Changes in those (and to a lesser extent other files) are based on additions > to RepositoryUtils. > > LocalRepositoryTest and URLRepositoryTest were updated to take into account > platform/arch specifics. There currently aren't any tests which look for the > (IMHO unlikely) case of having specified platform but not arch or vice versa. According to javadoc that I've reading though recently (and supporting implementation code), the scenario you describe cannot exist. Either both architecture and platform are specified as non-null OR both attributes are null. Cheers, Steve. From jprtadm at jprt-web.SFBay.Sun.COM Sat Oct 27 05:27:48 2007 From: jprtadm at jprt-web.SFBay.Sun.COM (JPRT Administrator) Date: Sat, 27 Oct 2007 05:27:48 -0700 (PDT) Subject: [modules-dev] JPRT: [sfbay] job notification - success with job 2007-10-27-111310.as130790.jsr277-nightly Message-ID: <200710271227.l9RCRmk3015952@jprt-web.SFBay.Sun.COM> JPRT: [sfbay] job notification - success with job 2007-10-27-111310.as130790.jsr277-nightly JPRT Job ID: 2007-10-27-111310.as130790.jsr277-nightly JPRT System Used: sfbay JPRT Version Used: 28 Sep 2007 - Ask a Stupid Question Day Job URL: http://javaweb.sfbay/jdk/jprt/archive/2007/10/2007-10-27-111310.as130790.jsr277-nightly Job ARCHIVE: /net/prt-archiver.sfbay/data/jprt/archive/2007/10/2007-10-27-111310.as130790.jsr277-nightly User: as130790 Email: modules-dev at openjdk.java.net Release: jdk1.7.0 Job Source: Source Tree: /net/shimmer.sfbay/export/home/jsr277/ws/{make,src} File List: {.} Exclude List: {build} Command Line: jprt submit -stree ../ws -ot '.*product.*' -noquickabort -email modules-dev at openjdk.java.net -id jsr277-nightly -rtests '*-*-c2-java/module' -rtests '*-*-c2-sun/module' Job submitted at: Sat-11:13:11-GMT Total time in queue: 1h 14m 36s Job started at: Sat-11:19:24-GMT Job finished at: Sat-12:27:47-GMT Job run time: 1h 08m 23s Job state: success Job flags: Bundles: USE: jprt install 2007-10-27-111310.as130790.jsr277-nightly HINT: Use 'jprt rerun -comment -retest 2007-10-27-111310.as130790.jsr277-nightly' to rerun the tests for this job (you can also add tests with 'jprt rerun'). NOTE: Zip files containing exe or dll files on windows have had problems with execute permissions. You may need to 'chmod a+x' the windows exe and dll files. User Comments: null Build (Release:jdk1.7.0 Boot: Import:): solaris_sparc_5.10-product success(24m 44s elapsed) solaris_sparcv9_5.10-product success(14m 21s elapsed) solaris_i586_5.10-product success(13m 33s elapsed) solaris_x64_5.10-product success(07m 34s elapsed) linux_i586_2.4-product success(11m 21s elapsed) linux_x64_2.4-product success(16m 43s elapsed) windows_i586_5-product success(45m 19s elapsed) windows_x64_5.2-product success(48m 02s elapsed) Tests: solaris_sparc-product-c1-jvm98 success(03m 40s elapsed) solaris_sparc-product-c2-jvm98 success(02m 39s elapsed) solaris_sparcv9-product-c2-jvm98 success(03m 04s elapsed) solaris_i586-product-c1-jvm98 success(02m 19s elapsed) solaris_i586-product-c2-jvm98 success(02m 02s elapsed) solaris_x64-product-c2-jvm98 success(01m 59s elapsed) linux_i586-product-c1-jvm98 success(02m 14s elapsed) linux_i586-product-c2-jvm98 success(02m 14s elapsed) linux_x64-product-c2-jvm98 success(01m 41s elapsed) windows_i586-product-c1-jvm98 success(06m 07s elapsed) windows_i586-product-c2-jvm98 success(05m 52s elapsed) windows_x64-product-c2-jvm98 success(01m 57s elapsed) solaris_sparc-product-c2-java/module success(01m 58s elapsed) solaris_sparcv9-product-c2-java/module success(02m 01s elapsed) solaris_i586-product-c2-java/module success(01m 18s elapsed) solaris_x64-product-c2-java/module success(01m 28s elapsed) linux_i586-product-c2-java/module success(02m 31s elapsed) linux_x64-product-c2-java/module success(01m 43s elapsed) windows_i586-product-c2-java/module success(19m 21s elapsed) windows_x64-product-c2-java/module success(06m 11s elapsed) solaris_sparc-product-c2-sun/module success( 52s elapsed) solaris_sparcv9-product-c2-sun/module success(01m 00s elapsed) solaris_i586-product-c2-sun/module success( 41s elapsed) solaris_x64-product-c2-sun/module success( 38s elapsed) linux_i586-product-c2-sun/module success(01m 49s elapsed) linux_x64-product-c2-sun/module success(01m 07s elapsed) windows_i586-product-c2-sun/module success(19m 11s elapsed) windows_x64-product-c2-sun/module success(03m 35s elapsed) For announcements on downtime and availability join the alias 'jprt-announce at sun.com'. You can see the latest announcements at http://archives.central/tm/browse?jprt-announce. For suspected system problems, send mail to 'jprt-admin at sun.com'. The jprt how to document is available at http://javaweb.sfbay/jdk/jprt/dist/javadoc/jprt/doc-files/how-to.html. From Andreas.Sterbenz at Sun.COM Sun Oct 28 23:35:16 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Sun, 28 Oct 2007 23:35:16 -0700 Subject: [modules-dev] B22 modules project build failure In-Reply-To: <1193341584.12052.9.camel@gloria> References: <1193341584.12052.9.camel@gloria> Message-ID: <47257F24.1060704@sun.com> Stephen J. McConnell wrote: > When attempting to build the modules b22 distribution (from published > sources) I'm getting an error related to an attempt to build something > that references a non-existent resources in the binary plugs. The > version of the binary plugs that I'm using is also the B22 release > (however - the b22 general source release and the b22 modules release > are not really in sync and I suspect that a different version of the > binary plugs may be required). Sorry about that. To build the 12_oct_2007 modules drop, please try the binary plugs for b21. They are available at http://download.java.net/openjdk/jdk7/promoted/b21/ . I did an OpenJDK test build on Solaris x86 and it worked fine for me with those. Background: the build reorganization (langtools) caused some problems for our parent workspace, so we currently cannot sync up with the most recent changes. That means we are out of date wrt code changes elsewhere in the JDK, which happened to affect the binary plugs. This may get resolved in time for the imminent build 23, but that is uncertain at this point. So if you don't see a big bringover that changes some 10000 files prior to b23 getting posted in a few days, please continue to use the b21 plugs for that Modules drop as well. Andreas. From andreas.sterbenz at sun.com Mon Oct 29 06:00:06 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Mon, 29 Oct 2007 06:00:06 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710291300.l9TD063n008135@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071029/8a6a85dd/attachment.html From andreas.sterbenz at sun.com Tue Oct 30 06:00:03 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Tue, 30 Oct 2007 06:00:03 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710301300.l9UD03iQ013952@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071030/53a3cfdf/attachment.html From David.Bristor at Sun.COM Tue Oct 30 10:51:46 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 30 Oct 2007 10:51:46 -0700 Subject: [modules-dev] Review request for 6601899 In-Reply-To: <1193453471.14440.5.camel@gloria> References: <47228A43.8010708@sun.com> <1193453471.14440.5.camel@gloria> Message-ID: <47276F32.2060407@sun.com> Stephen J. McConnell wrote: > On Fri, 2007-10-26 at 17:45 -0700, Dave Bristor wrote: >> Hi folks, >> >> This is to fix >> >> 6601899 (repo) URLRepository.find*() must not return modules for other than >> the appropriate platform/arch >> >> bugster: http://monaco.sfbay/detail.jsp?cr=6601899 >> webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6601899/ >> >> The bulk of the work involves taking into account platform & arch when >> installing, finding, and listing modules. There are several simplifications & >> cleanups. The "interesting" changes are in >> >> LocalRepository >> ModuleInfoXMLReader >> URLRepository >> >> Changes in those (and to a lesser extent other files) are based on additions >> to RepositoryUtils. >> >> LocalRepositoryTest and URLRepositoryTest were updated to take into account >> platform/arch specifics. There currently aren't any tests which look for the >> (IMHO unlikely) case of having specified platform but not arch or vice versa. > > According to javadoc that I've reading though recently (and supporting > implementation code), the scenario you describe cannot exist. Either > both architecture and platform are specified as non-null OR both > attributes are null. If the javadoc says an invariant X should hold, then I hope that the code enforces X. And then, it's reasonable to have a test for X, to see if it really does hold. OTOH, upon your email's prodding, I looked at java.module.annotation.PlatformBinding and at RepositoryMetadata.xml: those APIs do indeed prevent having only one of platform/arch set. Would you agree that no further test is necessary? Thanks, Dave > > Cheers, Steve. > > > > _______________________________________________ > modules-dev mailing list > modules-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-dev From David.Bristor at Sun.COM Tue Oct 30 11:25:54 2007 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 30 Oct 2007 11:25:54 -0700 Subject: [modules-dev] Review request for 6601899 In-Reply-To: <47228A43.8010708@sun.com> References: <47228A43.8010708@sun.com> Message-ID: <47277732.1070603@sun.com> Brief update: I noticed that URLModuleDefinitionContent.getData() is superfluous, given JamUtils.readFile(); the former is removed and prior uses of it now use the latter. Webrev updated. Thanks, Dave Dave Bristor wrote: > Hi folks, > > This is to fix > > 6601899 (repo) URLRepository.find*() must not return modules for other than > the appropriate platform/arch > > bugster: http://monaco.sfbay/detail.jsp?cr=6601899 > webrev: http://analemma.sfbay.sun.com/java/jdk/ws/libs/rev/6601899/ > > The bulk of the work involves taking into account platform & arch when > installing, finding, and listing modules. There are several simplifications & > cleanups. The "interesting" changes are in > > LocalRepository > ModuleInfoXMLReader > URLRepository > > Changes in those (and to a lesser extent other files) are based on additions > to RepositoryUtils. > > LocalRepositoryTest and URLRepositoryTest were updated to take into account > platform/arch specifics. There currently aren't any tests which look for the > (IMHO unlikely) case of having specified platform but not arch or vice versa. > Nor are there (yet) any tests which take into account a user-specified path. > > The changes also include a fix to Jam.java so that temp files are deleted on > exit. Ditto for JamBuilder.java (only used as part of tests, but equally good > for it to clean up after itself). > > Thanks, > Dave > _______________________________________________ > modules-dev mailing list > modules-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/modules-dev From mcconnell at dpml.net Wed Oct 31 00:27:21 2007 From: mcconnell at dpml.net (Stephen J. McConnell) Date: Wed, 31 Oct 2007 17:57:21 +1030 Subject: [modules-dev] B22 modules project build failure In-Reply-To: <47257F24.1060704@sun.com> References: <1193341584.12052.9.camel@gloria> <47257F24.1060704@sun.com> Message-ID: <1193815641.15067.95.camel@gloria> Following the update of the binary plugs to the B21 version the build goes a lot further. I'm now failing somewhere a long way into the build with the following: Rebuilding ../../../build/linux-i586/lib/i386/xawt/libmawt.so because of ../../../build/linux-i586/tmp/sun/sun.awt.X11/xawt/obj/.files_compiled mapfile-vers [snip-very-long-command] /usr/bin/ld: cannot find -lXtst collect2: ld returned 1 exit status make[2]: *** [../../../build/linux-i586/lib/i386/xawt/libmawt.so] Error 1 make[2]: Leaving directory `/home/foo/jdk/modules/make/sun/xawt' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/foor/jdk/modules/make/sun' make: *** [all] Error 1 I'm guessing this may be because I'm building with the bootstrap JDK pointing to the latest iced-tea distribution. I'll try again with SE6 and see if this delivers anything different. Cheers, Steve. On Sun, 2007-10-28 at 23:35 -0700, Andreas Sterbenz wrote: > Stephen J. McConnell wrote: > > When attempting to build the modules b22 distribution (from published > > sources) I'm getting an error related to an attempt to build something > > that references a non-existent resources in the binary plugs. The > > version of the binary plugs that I'm using is also the B22 release > > (however - the b22 general source release and the b22 modules release > > are not really in sync and I suspect that a different version of the > > binary plugs may be required). > > Sorry about that. To build the 12_oct_2007 modules drop, please try the > binary plugs for b21. They are available at > http://download.java.net/openjdk/jdk7/promoted/b21/ . I did an OpenJDK > test build on Solaris x86 and it worked fine for me with those. > > Background: the build reorganization (langtools) caused some problems for > our parent workspace, so we currently cannot sync up with the most recent > changes. That means we are out of date wrt code changes elsewhere in the > JDK, which happened to affect the binary plugs. > > This may get resolved in time for the imminent build 23, but that is > uncertain at this point. So if you don't see a big bringover that changes > some 10000 files prior to b23 getting posted in a few days, please > continue to use the b21 plugs for that Modules drop as well. > > Andreas. > From Andreas.Sterbenz at Sun.COM Wed Oct 31 00:42:11 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Wed, 31 Oct 2007 00:42:11 -0700 Subject: [modules-dev] B22 modules project build failure In-Reply-To: <1193815641.15067.95.camel@gloria> References: <1193341584.12052.9.camel@gloria> <47257F24.1060704@sun.com> <1193815641.15067.95.camel@gloria> Message-ID: <472831D3.6080304@sun.com> Stephen J. McConnell wrote: > > /usr/bin/ld: cannot find -lXtst > collect2: ld returned 1 exit status > make[2]: *** [../../../build/linux-i586/lib/i386/xawt/libmawt.so] Error 1 > make[2]: Leaving directory `/home/foo/jdk/modules/make/sun/xawt' > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/home/foor/jdk/modules/make/sun' > make: *** [all] Error 1 That's a linker error. Apparently AWT requires various X libraries, including libXtst, to be installed on the system. You should try installing it on your system. There are some hints for Ubuntu in the build README: https://openjdk.dev.java.net/source/browse/*checkout*/openjdk/jdk/trunk/README-builds.html#SDBE Hope that helps. Andreas. From andreas.sterbenz at sun.com Wed Oct 31 06:00:03 2007 From: andreas.sterbenz at sun.com (andreas.sterbenz at sun.com) Date: Wed, 31 Oct 2007 06:00:03 -0700 (PDT) Subject: [modules-dev] Open Bugs/RFEs in java/module Message-ID: <200710311300.l9VD03Ri005564@shimmer.sfbay.sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/modules-dev/attachments/20071031/5cb80479/attachment.html