From Leonid.Mesnik at Sun.COM Tue Jun 1 01:59:02 2010 From: Leonid.Mesnik at Sun.COM (Leonid Mesnik) Date: Tue, 01 Jun 2010 12:59:02 +0400 Subject: The module versioning In-Reply-To: <20100601043127.80456A66@eggemoggin.niobe.net> References: <20100601043127.80456A66@eggemoggin.niobe.net> Message-ID: <4C04CBD6.2000403@sun.com> Mark, Thank you for information. Leonid On 06/01/2010 08:31 AM, Mark Reinhold wrote: >> Date: Mon, 31 May 2010 20:00:22 +0400 >> From: leonid.mesnik at sun.com >> > >> Could you please point me to description of module version format. >> I'm not able to sort out how to compare versions and use VersionQuery >> now. >> > http://cr.openjdk.java.net/~mr/jigsaw/api/org/openjdk/jigsaw/JigsawVersion.html > http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > > - Mark > From sean.mullan at oracle.com Tue Jun 1 06:50:21 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 01 Jun 2010 09:50:21 -0400 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: <4BFD9A8F.5040908@oracle.com> References: <4BFD9A8F.5040908@oracle.com> Message-ID: <4C05101D.8010906@oracle.com> I posted a new webrev addressing the comments I have received so far: http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ If there are no further comments, I plan to putback later today. Thanks, Sean Sean Mullan wrote: > Please review the webrev below which contains code changes that add > support for running signed modules with a SecurityManager. > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.00/ > > > Thanks, > Sean From forax at univ-mlv.fr Tue Jun 1 07:00:52 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 01 Jun 2010 16:00:52 +0200 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: <4C05101D.8010906@oracle.com> References: <4BFD9A8F.5040908@oracle.com> <4C05101D.8010906@oracle.com> Message-ID: <4C051294.6060502@univ-mlv.fr> Le 01/06/2010 15:50, Sean Mullan a ?crit : > I posted a new webrev addressing the comments I have received so far: > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ > > > If there are no further comments, I plan to putback later today. > > Thanks, > Sean > > Sean Mullan wrote: >> Please review the webrev below which contains code changes that add >> support for running signed modules with a SecurityManager. >> >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.00/ >> >> >> Thanks, >> Sean > Some minor nits with the way exception are created: SimpleLibrary.java: throw new InternalError(cnfe.getMessage()); should be throw (InternalError)new InternalError(cnfe.getMessage()).initCause(cnfe Packager.java: - A constructor that takes a String and a cause was added to IOException in 1.6. otherwise I'm okay. R?mi From jonathan.gibbons at oracle.com Tue Jun 1 08:41:29 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 01 Jun 2010 08:41:29 -0700 Subject: jpkg RFE In-Reply-To: <4C0033EC.6030609@sun.com> References: <20100527231533.237FA2AE@eggemoggin.niobe.net> <4C0033EC.6030609@sun.com> Message-ID: <4C052A29.30900@oracle.com> On 05/28/2010 02:21 PM, Dalibor Topic wrote: > Here's a small patch for review: > > http://cr.openjdk.java.net/~robilad/jpkg-resources-default/ > > * jpkg sets resources parameter to module path if no resources path is > explicitly given. > > But of course, that's not enough, so we have to make sure that we only > start writing a resource section if there are actually resources to be > stuffed into a jmod file - i.e. the check whether the resource path is > empty is not sufficient in that case, as the modulepath could be chock > full of class files, with no other file in sight. So ... > > * module file format gets a utility method to check if a path contains > files that are not class files. > > And to make that a bit easier > > * Files gets a few small helper methods to tell if a file name is a > class name. > > Notable differences: this means that *.properties files that were > up until now not necessarily picked up as a resource, if they were only > in the classes/ dirs and not in the resources/ dirs, will now get a > place in the resources section of a jmod file. > > I hope this fits what Jon had in mind, I'd appreciate a review while I > go hack on the tests. > > cheers, > dalibor topic > I haven't reviewed the code, but the functionality seems like what I had in mind. -- Jon From mandy.chung at oracle.com Tue Jun 1 09:19:58 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 01 Jun 2010 09:19:58 -0700 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: <4C05101D.8010906@oracle.com> References: <4BFD9A8F.5040908@oracle.com> <4C05101D.8010906@oracle.com> Message-ID: <4C05332E.5090102@oracle.com> On 06/01/10 06:50, Sean Mullan wrote: > I posted a new webrev addressing the comments I have received so far: > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ > > I agree with Remi's comments of setting the initCause of the InternalError and the use of IOException(String, Throwable). Other than that, looks okay. Thanks Mandy > If there are no further comments, I plan to putback later today. > > Thanks, > Sean > > Sean Mullan wrote: >> Please review the webrev below which contains code changes that add >> support for running signed modules with a SecurityManager. >> >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.00/ >> >> >> Thanks, >> Sean > From jonathan.gibbons at oracle.com Tue Jun 1 14:34:52 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 01 Jun 2010 14:34:52 -0700 Subject: jpkg RFE In-Reply-To: <4C0033EC.6030609@sun.com> References: <20100527231533.237FA2AE@eggemoggin.niobe.net> <4C0033EC.6030609@sun.com> Message-ID: <4C057CFC.2010006@oracle.com> Dalibor, ModuleFileFormat.java, line 487: typo "diectory". line 491, inconsistent indentation, compared to line 478. Is line 529 correct? Before the change, the code allowed for the possibility that the classes directory was empty. Now, what if it is non empty but does not contain class files, and only contains resource files? -- Jon On 05/28/2010 02:21 PM, Dalibor Topic wrote: > Here's a small patch for review: > > http://cr.openjdk.java.net/~robilad/jpkg-resources-default/ > > * jpkg sets resources parameter to module path if no resources path is > explicitly given. > > But of course, that's not enough, so we have to make sure that we only > start writing a resource section if there are actually resources to be > stuffed into a jmod file - i.e. the check whether the resource path is > empty is not sufficient in that case, as the modulepath could be chock > full of class files, with no other file in sight. So ... > > * module file format gets a utility method to check if a path contains > files that are not class files. > > And to make that a bit easier > > * Files gets a few small helper methods to tell if a file name is a > class name. > > Notable differences: this means that *.properties files that were > up until now not necessarily picked up as a resource, if they were only > in the classes/ dirs and not in the resources/ dirs, will now get a > place in the resources section of a jmod file. > > I hope this fits what Jon had in mind, I'd appreciate a review while I > go hack on the tests. > > cheers, > dalibor topic > From Roger.Riggs at Oracle.com Wed Jun 2 05:15:11 2010 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 02 Jun 2010 08:15:11 -0400 Subject: Using modules for applications Message-ID: <4C064B4F.40303@Oracle.com> Hi, Is there a way to determine the module ID that is contained in a .jmod file either before or after installation? The SimpleLibrary.install methods install modules but do not return any indication what was just installed. Even from the command line it would be useful to know what was just installed. Though the module name might be encoded in the file name, I'd rather not be parsing filenames to find the module name. Alternatively, a simple reader of the .jmod file would be simple. Suggestions or workarounds? Thanks, Roger From vincent.x.ryan at oracle.com Wed Jun 2 11:49:31 2010 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 02 Jun 2010 19:49:31 +0100 Subject: jmod enhancements to support signed modules Message-ID: <4C06A7BB.9040008@oracle.com> Hello, Please review these code changes to support the creation of signed modules: http://cr.openjdk.java.net/~vinnie/6957907/webrev.00/ 'jmod install ' now performs certificate path validation of each signer's cert chain when the module file carries a signature. Thanks. From Alan.Bateman at oracle.com Wed Jun 2 12:03:46 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Jun 2010 20:03:46 +0100 Subject: Using modules for applications In-Reply-To: <4C064B4F.40303@Oracle.com> References: <4C064B4F.40303@Oracle.com> Message-ID: <4C06AB12.5070703@oracle.com> Roger Riggs wrote: > Hi, > > Is there a way to determine the module ID that is contained in a .jmod > file > either before or after installation? > > The SimpleLibrary.install methods install modules but do not return > any indication what was just installed. > > Even from the command line it would be useful to know what was just > installed. > > Though the module name might be encoded in the file name, I'd rather not > be parsing filenames to find the module name. Alternatively, a simple > reader > of the .jmod file would be simple. > > Suggestions or workarounds? > > Thanks, Roger > I can't think of a workaround. I suspect this would require a new install method or maybe the existing method should return List. Changing the existing method would probably require changing the parameter type as the input would need to be an ordered collection to match the returned list. -Alan. From mandy.chung at oracle.com Wed Jun 2 13:18:47 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Jun 2010 13:18:47 -0700 Subject: Review request: rebranding jigsaw sources Message-ID: <4C06BCA7.8010508@oracle.com> Alan, Jon, Can you review the rebranding change of the jdk and langtools jigsaw source? Webrev at: http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/jdk http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/langtools Thanks Mandy From Dalibor.Topic at Sun.COM Wed Jun 2 15:34:22 2010 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 03 Jun 2010 00:34:22 +0200 Subject: hello-native.sh test fixlet Message-ID: <4C06DC6E.8060307@sun.com> Hi, in order to make that native test work on a 64 bit Ubuntu 8.10 system, I had to apply this patch: diff -r 43e101bd28c2 test/org/openjdk/jigsaw/hello-native.sh --- a/test/org/openjdk/jigsaw/hello-native.sh Sat May 29 21:19:10 2010 -0700 +++ b/test/org/openjdk/jigsaw/hello-native.sh Wed Jun 02 10:03:44 2010 -0700 @@ -53,7 +53,7 @@ ___ ___ (cd z.test/native/src; - cc -o ../lib/libworld.so -shared org_astro_World.c -static -lc) + cc -o ../lib/libworld.so -shared org_astro_World.c -fPIC) mkdir -p z.test/module-files $BIN/jpkg -d z.test/module-files -m z.test/modules/com.greetings \ OK to push? I tested the patch on Ubuntu 10.04 x86 as well. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: J?rgen Kunz From jonathan.gibbons at oracle.com Wed Jun 2 16:22:32 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 02 Jun 2010 16:22:32 -0700 Subject: jmod question Message-ID: <4C06E7B8.1070809@oracle.com> What's the rationale for the --parent option for jmod, to apply an operation to the parent of the specified library -- shouldn't the user just specify the parent library as the value for -L? The existence of -p/--parent leaves to a potential confusion between -p/--parent and -P/--parent-path. -- Jon From mark.reinhold at oracle.com Wed Jun 2 16:27:44 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Jun 2010 16:27:44 -0700 Subject: hello-native.sh test fixlet In-Reply-To: dalibor.topic@sun.com; Thu, 03 Jun 2010 00:34:22 +0200; <4C06DC6E.8060307@sun.com> Message-ID: <20100602232744.D762E956@eggemoggin.niobe.net> > Date: Thu, 03 Jun 2010 00:34:22 +0200 > From: dalibor.topic at sun.com > in order to make that native test work on a 64 bit Ubuntu 8.10 system, I had to > apply this patch: > > diff -r 43e101bd28c2 test/org/openjdk/jigsaw/hello-native.sh > --- a/test/org/openjdk/jigsaw/hello-native.sh Sat May 29 21:19:10 2010 -0700 > +++ b/test/org/openjdk/jigsaw/hello-native.sh Wed Jun 02 10:03:44 2010 -0700 > @@ -53,7 +53,7 @@ ___ > ___ > > (cd z.test/native/src; > - cc -o ../lib/libworld.so -shared org_astro_World.c -static -lc) > + cc -o ../lib/libworld.so -shared org_astro_World.c -fPIC) > > mkdir -p z.test/module-files > $BIN/jpkg -d z.test/module-files -m z.test/modules/com.greetings \ > > OK to push? Maybe ... > I tested the patch on Ubuntu 10.04 x86 as well. Does it still work on Solaris? - Mark From mandy.chung at oracle.com Wed Jun 2 16:30:18 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Jun 2010 16:30:18 -0700 Subject: Legacy mode, module mode, mixed mode Message-ID: <4C06E98A.8060704@oracle.com> This note attempts to describe the different execution modes for running legacy/modularized applications and how the current and long-term implementation supports them. I'll be sending out the webrev for the legacy mode support and I think this note will help set the basis for the legacy mode support discussion. 0. Module Images A module image consists of the jdk base module and a set of platform modules. The jdk modules are installed in the system module library ($JAVA_HOME/lib/modules). jre-module-image is the full JRE (equivalent the legacy j2re-image). The "jdk.jre" module is the aggregator module representing the entire JRE. jdk-module-image is the full JDK (equivalent to the legacy j2sdk-image). The "jdk" module is the aggregator module representing the entire JDK. rt.jar, tools.jar and other jar files no longer exist in the module image. I. Execution Mode There will be 3 different execution modes. A) Module mode Modularized applications will run in module mode in which classes are loaded from modules installed in module libraries. To run in module mode: $ java -L lib -m foo B) Legacy mode Legacy applications that are pure class-path-based will run on a module image provided that they: * Don't depend upon the internal structure of the JDK/JRE * Only use supported APIs and other interfaces [Tools or applications depending upon files in $JAVA_HOME will require some change.] In the legacy mode, the system classes are loaded from the platform modules installed in the system module library whereas non-system classes are loaded from classpath, extension mechanism or custom class loader as it is today. To run in legacy mode: $ java -cp classes com.foo.Main C) Mixed mode C.a) A legacy application running with classpath and with third-party modules This will be supported to ease migration to enable libraries to migrate to modules which legacy applications can continue to work. This will require some change in the legacy applications to specify its required modules and versions. One option is to extend the manifest of the legacy application jar file: Main-Class: com.greetings.Main Required-Modules: org.astro at 1.2.3 Required-Platform-Modules: jdk.base, jdk.logging C.b) A modularized application to run with jars and classpath This will not be supported. Can be mitigated by creating a tool that can convert simple jar files into modules (to be investigated). II. Bootclasspath A) Module mode Bootclasspath will no longer exist. The -Xbootclasspath{/p,/a} options are not supported. See below III for the current implementation. B) Legacy mode There are various ways to alter the bootclasspath that will continue to work in legacy mode: 1. -Xbootclasspath/p to prepend bootclasspath 2. Endorsed directory to prepend the default bootclasspath via -Djava.endorsed.dirs (one or more directories) and the default $JAVA_HOME/lib/endorsed directory 3. -Xbootclasspath/a to append bootclasspath 4. JVMTI and java.lang.instrument to append the bootclasspath We need a solution to replace "alt-rt.jar" that is prepended in the bootclasspath when -XX:+AggressiveOpts is specified. C) Mixed mode C.a) Same as II.B above C.b) Not supported III. Finding system classes from the platform modules The current implementation leverages the bootclasspath so that the VM built-in class loader can find system classes. Ultimately, we want to eliminate the bootclasspath. The VM will find the primordial classes from the boot module through some jigsaw native interface. A) Module mode 1. Current implementation - The module boot path is passed by the java launcher as a "sun.java.launcher.module.boot" system property and the VM will find the primordial classes from that path. - org.openjdk.jigsaw.BootLoader is the module loader to load system classes. The current implementation extends the bootclasspath at startup time for all platform modules required by the modularized application and delegates to the null loader to define the system classes. 2. Long-term solution The VM needs the ability to find classes from the boot module and the module library to replace the bootclasspath search. In addition, there is an optimization in the VM that during class resolution, if the initiating loader is null, the defining loader has to be null and so the VM can find a class from the bootclasspath and load it directly rather than calling out to Java. The VM may need a way to determine if a class is in a platform context (equivalent to if a class can be found in the bootclasspath). This work is independent to the legacy mode support described below. B) Legacy mode 1. Current implementation - The java launcher constructs the bootclasspath for all modules installed in the system module library and set the -Xbootclasspath/p option before launching the VM. - The default bootclasspath also hardcodes the path of the boot module in the VM for creating the JVM directly from other applications. 2. Long-term solution This will remove the hack in the launcher that constructs the bootclasspath. In legacy mode, it needs to set up the platform contexts from which the VM can find system classes during the startup. Since BootLoader, the module loader for the platform contexts, delegates to the null loader to define the system classes, the current implementation (III.A.1) will continue to use the bootclasspath searching. When III.A.2 is implemented, the VM will use the module library searching. C) Mixed mode C.a) A legacy class-path-based application to run with third-party modules The legacy application will need to specify the required third- party modules and the legacy launcher needs to set up a configuration that resolves the specified dependencies at startup time. In addition, the application can also specify the platform modules it requires to override the default one. A special class loader (say LegacyLoader) will be created for finding classes from the required modules. LegacyLoader will be the parent class loader of the extension class loader so that the required modules will always be searched first. The application class loader and extension class loader will continue to work as it is. Issues: 1. Existing applications may depend on the "sun.boot.class.path" system property. 2. The parent of extension class loader is expected to be null. 3. Should the third-party modules be searched before the extension class path? From mandy.chung at oracle.com Wed Jun 2 16:47:29 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 02 Jun 2010 16:47:29 -0700 Subject: hello-native.sh test fixlet In-Reply-To: <4C06DC6E.8060307@sun.com> References: <4C06DC6E.8060307@sun.com> Message-ID: <4C06ED91.907@oracle.com> Hi Dalibor, This test fails on windows since it needs a different command to build the dll. Do you mind fixing it too? Mandy On 06/02/10 15:34, Dalibor Topic wrote: > Hi, > > in order to make that native test work on a 64 bit Ubuntu 8.10 system, I had to > apply this patch: > > diff -r 43e101bd28c2 test/org/openjdk/jigsaw/hello-native.sh > --- a/test/org/openjdk/jigsaw/hello-native.sh Sat May 29 21:19:10 2010 -0700 > +++ b/test/org/openjdk/jigsaw/hello-native.sh Wed Jun 02 10:03:44 2010 -0700 > @@ -53,7 +53,7 @@ ___ > ___ > > (cd z.test/native/src; > - cc -o ../lib/libworld.so -shared org_astro_World.c -static -lc) > + cc -o ../lib/libworld.so -shared org_astro_World.c -fPIC) > > mkdir -p z.test/module-files > $BIN/jpkg -d z.test/module-files -m z.test/modules/com.greetings \ > > OK to push? > > I tested the patch on Ubuntu 10.04 x86 as well. > > cheers, > dalibor topic > From mark.reinhold at oracle.com Wed Jun 2 20:51:02 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Jun 2010 20:51:02 -0700 Subject: jmod question In-Reply-To: jonathan.gibbons@oracle.com; Wed, 02 Jun 2010 16:22:32 PDT; <4C06E7B8.1070809@oracle.com> Message-ID: <20100603035102.D9F36EAE@eggemoggin.niobe.net> > Date: Wed, 02 Jun 2010 16:22:32 -0700 > From: jonathan.gibbons at oracle.com > What's the rationale for the --parent option for jmod, to apply an operation to > the parent of the specified library -- shouldn't the user just specify the > parent library as the value for -L? > > The existence of -p/--parent leaves to a potential confusion between > -p/--parent and -P/--parent-path. Agreed. The -p option is poorly documented. The intent is that if a subcommand does something with the requested library then -p includes its parent library (and its parent, etc., all the way up the chain). Right now it only applies to the list subcommand, so that "jmod list -p" shows you all modules in the requested library and all of its parents. It probably make sense for -p to apply to a few other subcommands, but I haven't yet thought through the cases. - Mark From mark.reinhold at oracle.com Wed Jun 2 21:34:04 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Jun 2010 21:34:04 -0700 Subject: Issue with detecting if it's a platform context In-Reply-To: mandy.chung@oracle.com; Thu, 20 May 2010 12:40:29 PDT; <4BF5902D.2020907@oracle.com> Message-ID: <20100603043404.A4ACA956@eggemoggin.niobe.net> > Date: Thu, 20 May 2010 12:40:29 -0700 > From: mandy.chung at oracle.com > I made a couple of minor changes in jigsaw for the reorg of the platform > modules [1]. This webrev includes all org.openjdk.jigsaw.* class changes > separating from the classanalyzer and modules.config change. > > http://cr.openjdk.java.net/~mchung/jigsaw/platform-modules/jigsaw/ > > Two problems: > 1. All jdk modules now have the "jdk." and "sun." prefix. Only some of them > need to be loaded by the BootLoader (i.e. classes from rt.jar and those are > connected with the jdk.boot module (i.e. requires local jdk.boot). > > The Platform.isPlatformModuleName method currently uses the prefix of the > module names to determine if it's a platform module and the platform modules > will be loaded by BootLoader. For example, jdk.jps is a tool that requires > jdk.base and jdk.jvmstat and jdk.jps and jdk.jvmstat modules can be loaded by > the module loader. This check should be revised. ... > > I added a Platform.isBootContext method and the LoaderPool will create a > BootLoader only if it's a boot context (yet another temporary solution). > Since this is evolving, we will implement the long-term solution for the > detection if it's a platform context and loading of platform modules. That's fine. > I leave > the isPlatformContext as it is as you probably have made some change in the > config/context. Yes; isPlatformContext is used elsewhere, at least for now. > Does this approach sound reasonable (BootLoader only loads modules that > strongly connected with jdk.boot)? Yes. > 2. The optional modules are not linked and recorded in the config. The fix is > to skip the optional modules in the Resolver only if it doesn't exist. The resolver fix for optional modules needs adjustment. You've got the right idea in moving the Modifier.OPTIONAL test further down in the resolve(int, Choice) method. Placing it at the end of the method, however, means that the resolver will consider remote, not-yet-installed modules as candidates for satisfying optional dependences, and that's not the right thing. The OPTIONAL test should be placed just before the section that checks remote repositories. I'd also change the comment to say "Don't fail; it's just an optional dependence". Oh, and please extend the _Configurator test to check that optional dependences now work correctly. There are a couple of commented-out tests which can serve as a starting point. - Mark From mark.reinhold at oracle.com Wed Jun 2 21:34:50 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Jun 2010 21:34:50 -0700 Subject: Review of platform modules & class analyzer change In-Reply-To: mandy.chung@oracle.com; Tue, 18 May 2010 22:37:05 PDT; <4BF37901.8000306@oracle.com> Message-ID: <20100603043450.DD42A956@eggemoggin.niobe.net> > Date: Tue, 18 May 2010 22:37:05 -0700 > From: mandy.chung at oracle.com > http://cr.openjdk.java.net/~mchung/jigsaw/platform-modules The module-definition changes look good. I haven't reviewed the class-analyzer changes in detail; Alan, could you please take a closer look? I've commented on the resolver fix separately. - Mark From mark.reinhold at oracle.com Wed Jun 2 21:49:51 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Jun 2010 21:49:51 -0700 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: sean.mullan@oracle.com; Fri, 28 May 2010 11:13:27 EDT; <4BFFDD97.6040901@oracle.com> Message-ID: <20100603044951.37F2A956@eggemoggin.niobe.net> > Date: Fri, 28 May 2010 11:13:27 -0400 > From: sean.mullan at oracle.com > On 5/27/10 8:13 PM, R?mi Forax wrote: >>>> In SimpleLibrary.readLocalCodeSigners, >>>> if the file is removed between f.exists() and >>>> new FileInputstream, instead of returning null, you throw an >>>> IOException, >>> >>> Hmm, but there is no way for that to happen unless the library data is >>> being modified maliciously or accidentally. >> >> My question was more, is it the intended behavior ? > > Ok. TBD. I think this needs to be addressed as a more general issue of the > Library implementation and what assumptions can or cannot be made about the > data (integrity, concurrent access, etc). I'll add a comment for now that this > needs to be looked at. Right now the SimpleLibrary implementation is, well, very simple. It doesn't do any locking, nor does it guarantee to clean up properly when something goes wrong. We'll fix it eventually, but let's get all this other stuff working first. - Mark From mark.reinhold at oracle.com Wed Jun 2 21:53:48 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 02 Jun 2010 21:53:48 -0700 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: sean.mullan@oracle.com; Thu, 27 May 2010 11:09:05 EDT; <4BFE8B11.7010209@oracle.com> Message-ID: <20100603045348.38F30956@eggemoggin.niobe.net> > Date: Thu, 27 May 2010 11:09:05 -0400 > From: sean.mullan at oracle.com > On 5/26/10 6:59 PM, R?mi Forax wrote: >> A more general question but perhaps for Mark or Alan, >> why jigsaw codebase use java.io.file and not java.nio.file ? > > I'll defer to Mark or Alan on that question. In early Jigsaw development we wanted to allow for the possibility that the base module might not include java.nio.file, so the SimpleLibrary class was implemented using the sad old java.io.File class. Having gotten much further along in the modularization exercise we now have java.nio.file in the base module, and it's most likely there to stay. So at some point we'll make a pass through all the code and convert uses of the old API to the new one. - Mark From forax at univ-mlv.fr Thu Jun 3 00:48:53 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 03 Jun 2010 09:48:53 +0200 Subject: jmod question In-Reply-To: <20100603035102.D9F36EAE@eggemoggin.niobe.net> References: <20100603035102.D9F36EAE@eggemoggin.niobe.net> Message-ID: <4C075E65.6050609@univ-mlv.fr> Le 03/06/2010 05:51, mark.reinhold at oracle.com a ?crit : >> Date: Wed, 02 Jun 2010 16:22:32 -0700 >> From: jonathan.gibbons at oracle.com >> > >> What's the rationale for the --parent option for jmod, to apply an operation to >> the parent of the specified library -- shouldn't the user just specify the >> parent library as the value for -L? >> >> The existence of -p/--parent leaves to a potential confusion between >> -p/--parent and -P/--parent-path. >> > Agreed. The -p option is poorly documented. > > The intent is that if a subcommand does something with the requested > library then -p includes its parent library (and its parent, etc., all > the way up the chain). > > Right now it only applies to the list subcommand, so that "jmod list -p" > shows you all modules in the requested library and all of its parents. > > It probably make sense for -p to apply to a few other subcommands, but > I haven't yet thought through the cases. > > - Mark > Perhaps -p should be renamed to -r/--recursive. R?mi From Dalibor.Topic at Sun.COM Thu Jun 3 02:06:12 2010 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 03 Jun 2010 11:06:12 +0200 Subject: hello-native.sh test fixlet In-Reply-To: <20100602232744.D762E956@eggemoggin.niobe.net> References: <20100602232744.D762E956@eggemoggin.niobe.net> Message-ID: <4C077084.1080204@sun.com> mark.reinhold at oracle.com wrote: > Does it still work on Solaris? > I assume that means it did work on Solaris. On OpenSolaris, it falls over (with or without the patch) as it can't find cc. I had to use -e to tell jtreg about the /opt/SunStudio/bin path to find CC, but then cc fell over complaining that it can't find jni.h. What's your jtreg command line on Solaris? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: J?rgen Kunz From Dalibor.Topic at Sun.COM Thu Jun 3 02:09:00 2010 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Thu, 03 Jun 2010 11:09:00 +0200 Subject: hello-native.sh test fixlet In-Reply-To: <4C06ED91.907@oracle.com> References: <4C06DC6E.8060307@sun.com> <4C06ED91.907@oracle.com> Message-ID: <4C07712C.8070607@sun.com> Mandy Chung wrote: > Hi Dalibor, > > This test fails on windows since it needs a different command to build > the dll. Do you mind fixing it too? OK, I will. cheers, dalibor topic > > Mandy > > On 06/02/10 15:34, Dalibor Topic wrote: >> Hi, >> >> in order to make that native test work on a 64 bit Ubuntu 8.10 system, >> I had to >> apply this patch: >> >> diff -r 43e101bd28c2 test/org/openjdk/jigsaw/hello-native.sh >> --- a/test/org/openjdk/jigsaw/hello-native.sh Sat May 29 21:19:10 >> 2010 -0700 >> +++ b/test/org/openjdk/jigsaw/hello-native.sh Wed Jun 02 10:03:44 >> 2010 -0700 >> @@ -53,7 +53,7 @@ ___ >> ___ >> >> (cd z.test/native/src; >> - cc -o ../lib/libworld.so -shared org_astro_World.c -static -lc) >> + cc -o ../lib/libworld.so -shared org_astro_World.c -fPIC) >> >> mkdir -p z.test/module-files >> $BIN/jpkg -d z.test/module-files -m z.test/modules/com.greetings \ >> >> OK to push? >> >> I tested the patch on Ubuntu 10.04 x86 as well. >> >> cheers, >> dalibor topic >> > -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: J?rgen Kunz From Alan.Bateman at oracle.com Thu Jun 3 03:57:21 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jun 2010 11:57:21 +0100 Subject: Review request: rebranding jigsaw sources In-Reply-To: <4C06BCA7.8010508@oracle.com> References: <4C06BCA7.8010508@oracle.com> Message-ID: <4C078A91.3040809@oracle.com> Mandy Chung wrote: > Alan, Jon, > > Can you review the rebranding change of the jdk and langtools jigsaw > source? > > Webrev at: > http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/jdk > http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/langtools > > Thanks > Mandy I scanned the patch file and it looks fine. The only thing I notice is that there are a couple of files (src/share/classes/java/lang/ModuleClassLoader.java and ModuleInfoRead.java for example) that have modifications in 2010 but have 2009 rather than a range in the header. -Alan. From Alan.Bateman at oracle.com Thu Jun 3 04:34:49 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jun 2010 12:34:49 +0100 Subject: jmod question In-Reply-To: <20100603035102.D9F36EAE@eggemoggin.niobe.net> References: <20100603035102.D9F36EAE@eggemoggin.niobe.net> Message-ID: <4C079359.8050300@oracle.com> mark.reinhold at oracle.com wrote: > : > Agreed. The -p option is poorly documented. > > The intent is that if a subcommand does something with the requested > library then -p includes its parent library (and its parent, etc., all > the way up the chain). > > Right now it only applies to the list subcommand, so that "jmod list -p" > shows you all modules in the requested library and all of its parents. > > It probably make sense for -p to apply to a few other subcommands, but > I haven't yet thought through the cases. > > - Mark > The refresh and repos subcommands could potentially take this option so that they refresh the catalog or print the associated repositories for all libraries. One suggestion is to switch to --all or -a instead of -p. That is, "jmod list -a" to list all install modules is probably easier to remember. -Alan. From Alan.Bateman at oracle.com Thu Jun 3 05:09:01 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jun 2010 13:09:01 +0100 Subject: Legacy mode, module mode, mixed mode In-Reply-To: <4C06E98A.8060704@oracle.com> References: <4C06E98A.8060704@oracle.com> Message-ID: <4C079B5D.2090500@oracle.com> Mandy - this is good informative write-up. A couple of comments inlined. Mandy Chung wrote: > : > > 0. Module Images > > A module image consists of the jdk base module and a set of platform > modules. The jdk modules are installed in the system module > library ($JAVA_HOME/lib/modules). > > jre-module-image is the full JRE (equivalent the legacy j2re-image). > The "jdk.jre" module is the aggregator module representing the entire > JRE. > > jdk-module-image is the full JDK (equivalent to the legacy > j2sdk-image). > The "jdk" module is the aggregator module representing the entire JDK. > > rt.jar, tools.jar and other jar files no longer exist in the module > image. Should this section include a few words to make it clear that the directory/file layout for the jdk-module-image is the same as the jre-module-image? Just thinking we should make it very obvious to the reader that the jdk image doesn't have the runtime in a "jre" directory as before. > > : > > In the legacy mode, the system classes are loaded from the platform > modules installed in the system module library whereas non-system > classes are loaded from classpath, extension mechanism or custom > class loader as it is today. Should this paragraph make it clear that the "non-platform" modules are ignored (and perhaps reference the migration/mixed-mode support in section C). > > > : > > B) Legacy mode > > There are various ways to alter the bootclasspath that will continue > to work in legacy mode: > > 1. -Xbootclasspath/p to prepend bootclasspath > 2. Endorsed directory to prepend the default bootclasspath > via -Djava.endorsed.dirs (one or more directories) and > the default $JAVA_HOME/lib/endorsed directory > 3. -Xbootclasspath/a to append bootclasspath > 4. JVMTI and java.lang.instrument to append the bootclasspath Should this section mention the extensions mechanism (ext directory where provider implementations and other JAR files are often copied into)? > : > > A) Module mode > > 1. Current implementation > > - The module boot path is passed by the java launcher as a > "sun.java.launcher.module.boot" system property and the > VM will find the primordial classes from that path. Will this be a problem for custom launchers, folks using the JNI invocation API, etc? -Alan. From jonathan.gibbons at oracle.com Thu Jun 3 08:13:43 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 03 Jun 2010 08:13:43 -0700 Subject: jmod RFE Message-ID: <4C07C6A7.5020507@oracle.com> "jmod extract" should provide an option to specify where the files will be extracted to, insteasd of assuming the current directory. -- Jon From mark.reinhold at oracle.com Thu Jun 3 08:33:29 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 03 Jun 2010 08:33:29 -0700 Subject: jmod question In-Reply-To: alan.bateman@oracle.com; Thu, 03 Jun 2010 12:34:49 BST; <4C079359.8050300@oracle.com> Message-ID: <20100603153329.11B1D420@eggemoggin.niobe.net> > Date: Thu, 03 Jun 2010 09:48:53 +0200 > From: R?mi Forax > Perhaps -p should be renamed to -r/--recursive. Hmm. To my eye "-r" suggests downward traversal of a tree rather than upward. > Date: Thu, 03 Jun 2010 12:34:49 +0100 > From: alan.bateman at oracle.com > The refresh and repos subcommands could potentially take this option so that > they refresh the catalog or print the associated repositories for all > libraries. One suggestion is to switch to --all or -a instead of -p. That is, > "jmod list -a" to list all install modules is probably easier to remember. I like it -- I'll change "-p" to "-a". - Mark From Alan.Bateman at oracle.com Thu Jun 3 09:40:35 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jun 2010 17:40:35 +0100 Subject: Review of platform modules & class analyzer change In-Reply-To: <20100603043450.DD42A956@eggemoggin.niobe.net> References: <20100603043450.DD42A956@eggemoggin.niobe.net> Message-ID: <4C07DB03.9040605@oracle.com> mark.reinhold at oracle.com wrote: >> Date: Tue, 18 May 2010 22:37:05 -0700 >> From: mandy.chung at oracle.com >> > > >> http://cr.openjdk.java.net/~mchung/jigsaw/platform-modules >> > > The module-definition changes look good. > > I haven't reviewed the class-analyzer changes in detail; Alan, could you > please take a closer look? > > Mandy - I went through the module changes when you sent this out originally and they also look good to me. I've now gone through the class analyzer changes. One small concern is that the names of the aggregator modules has slipped into Platform.java so it's yet another place that needs to maintained if/when we make changes. The usage of the Platform methods (such as in ClassAnalyzer when printing the module lists for example) also means there are other places that know about the aggregation. Otherwise the changes are fine. At some point it would be good to do a clean-up pass over the class analyzer as it has grown and has been modified many times. Low priority compared to other tasks of course. -Alan. From karen.kinnear at oracle.com Thu Jun 3 10:10:12 2010 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 3 Jun 2010 13:10:12 -0400 Subject: Legacy mode, module mode, mixed mode In-Reply-To: <4C06E98A.8060704@oracle.com> References: <4C06E98A.8060704@oracle.com> Message-ID: Mandy, This is really helpful - thank you for writing this up. A few minor questions/ comments below. On Jun 2, 2010, at 7:30 PM, Mandy Chung wrote: > This note attempts to describe the different execution modes for > running legacy/modularized applications and how the current and > long-term implementation supports them. > > I'll be sending out the webrev for the legacy mode support and > I think this note will help set the basis for the legacy mode > support discussion. > > 0. Module Images > > A module image consists of the jdk base module and a set of platform > modules. The jdk modules are installed in the system module > library ($JAVA_HOME/lib/modules). > > jre-module-image is the full JRE (equivalent the legacy j2re-image). > The "jdk.jre" module is the aggregator module representing the entire > JRE. > > jdk-module-image is the full JDK (equivalent to the legacy j2sdk- > image). > The "jdk" module is the aggregator module representing the entire > JDK. > > rt.jar, tools.jar and other jar files no longer exist in the module > image. > > I. Execution Mode > > There will be 3 different execution modes. > > A) Module mode > > Modularized applications will run in module mode in which classes > are loaded from modules installed in module libraries. > > To run in module mode: > $ java -L lib -m foo > > B) Legacy mode > > Legacy applications that are pure class-path-based will run on > a module image provided that they: > * Don't depend upon the internal structure of the JDK/JRE > * Only use supported APIs and other interfaces > > [Tools or applications depending upon files in $JAVA_HOME will > require some change.] > > In the legacy mode, the system classes are loaded from the platform > modules installed in the system module library whereas non-system > classes are loaded from classpath, extension mechanism or custom > class loader as it is today. > > To run in legacy mode: > $ java -cp classes com.foo.Main > > C) Mixed mode > C.a) A legacy application running with classpath and with third- > party modules > > This will be supported to ease migration to enable libraries to > migrate to modules which legacy applications can continue to work. > > This will require some change in the legacy applications to specify > its > required modules and versions. > > One option is to extend the manifest of the legacy application jar > file: > Main-Class: com.greetings.Main > Required-Modules: org.astro at 1.2.3 > Required-Platform-Modules: jdk.base, jdk.logging Do we also want to outline options for applications that use .jnlp or command-line without a jar file? > > C.b) A modularized application to run with jars and classpath > > This will not be supported. Can be mitigated by creating a tool that > can convert simple jar files into modules (to be investigated). > > II. Bootclasspath > > A) Module mode > Bootclasspath will no longer exist. The -Xbootclasspath{/p,/a} > options are not supported. > > See below III for the current implementation. > > B) Legacy mode > > There are various ways to alter the bootclasspath that will continue > to work in legacy mode: > > 1. -Xbootclasspath/p to prepend bootclasspath > 2. Endorsed directory to prepend the default bootclasspath > via -Djava.endorsed.dirs (one or more directories) and > the default $JAVA_HOME/lib/endorsed directory > 3. -Xbootclasspath/a to append bootclasspath > 4. JVMTI and java.lang.instrument to append the bootclasspath > > We need a solution to replace "alt-rt.jar" that is prepended > in the bootclasspath when -XX:+AggressiveOpts is specified. > > C) Mixed mode > C.a) Same as II.B above > C.b) Not supported > > III. Finding system classes from the platform modules > > The current implementation leverages the bootclasspath so that > the VM built-in class loader can find system classes. Ultimately, > we want to eliminate the bootclasspath. The VM will find the > primordial classes from the boot module through some jigsaw > native interface. > > A) Module mode > > 1. Current implementation > > - The module boot path is passed by the java launcher as a > "sun.java.launcher.module.boot" system property and the > VM will find the primordial classes from that path. > > - org.openjdk.jigsaw.BootLoader is the module loader to > load system classes. The current implementation extends > the bootclasspath at startup time for all platform modules > required by the modularized application and delegates to > the null loader to define the system classes. > > 2. Long-term solution > > The VM needs the ability to find classes from the boot module > and the module library to replace the bootclasspath search. > > In addition, there is an optimization in the VM that during > class resolution, if the initiating loader is null, the > defining loader has to be null and so the VM can find a class > from the bootclasspath and load it directly rather than calling > out to Java. The VM may need a way to determine if a class > is in a platform context (equivalent to if a class can be > found in the bootclasspath). > > This work is independent to the legacy mode support described > below. > > B) Legacy mode > > 1. Current implementation > > - The java launcher constructs the bootclasspath for all modules > installed in the system module library and set the - > Xbootclasspath/p > option before launching the VM. > > - The default bootclasspath also hardcodes the path of the > boot module in the VM for creating the JVM directly from other > applications. > > 2. Long-term solution > > This will remove the hack in the launcher that constructs the > bootclasspath. In legacy mode, it needs to set up the platform > contexts from which the VM can find system classes during the > startup. > > Since BootLoader, the module loader for the platform contexts, > delegates to the null loader to define the system classes, > the current implementation (III.A.1) will continue to use > the bootclasspath searching. When III.A.2 is implemented, > the VM will use the module library searching. > > C) Mixed mode > C.a) A legacy class-path-based application to run with third-party > modules > > The legacy application will need to specify the required third- > party modules and the legacy launcher needs to set up a configuration > that resolves the specified dependencies at startup time. > In addition, the application can also specify the platform modules > it requires to override the default one. How? > > A special class loader (say LegacyLoader) will be created for finding > classes from the required modules. LegacyLoader will be the > parent class loader of the extension class loader so that the > required modules will always be searched first. The application > class loader and extension class loader will continue to work as it > is. I'm not sure I understand the overall search order when we mix legacy apps and modules. > > Issues: > 1. Existing applications may depend on the "sun.boot.class.path" > system property. > 2. The parent of extension class loader is expected to be null. > 3. Should the third-party modules be searched before the extension > class path? > thanks, Karen From mandy.chung at oracle.com Thu Jun 3 10:32:24 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 10:32:24 -0700 Subject: Legacy mode, module mode, mixed mode In-Reply-To: <4C079B5D.2090500@oracle.com> References: <4C06E98A.8060704@oracle.com> <4C079B5D.2090500@oracle.com> Message-ID: <4C07E728.8030309@oracle.com> On 06/03/10 05:09, Alan Bateman wrote: > Mandy - this is good informative write-up. A couple of comments inlined. > > > Mandy Chung wrote: >> : >> >> 0. Module Images >> >> A module image consists of the jdk base module and a set of platform >> modules. The jdk modules are installed in the system module >> library ($JAVA_HOME/lib/modules). >> >> jre-module-image is the full JRE (equivalent the legacy j2re-image). >> The "jdk.jre" module is the aggregator module representing the entire >> JRE. >> >> jdk-module-image is the full JDK (equivalent to the legacy >> j2sdk-image). >> The "jdk" module is the aggregator module representing the entire JDK. >> >> rt.jar, tools.jar and other jar files no longer exist in the module >> image. > Should this section include a few words to make it clear that the > directory/file layout for the jdk-module-image is the same as the > jre-module-image? Just thinking we should make it very obvious to the > reader that the jdk image doesn't have the runtime in a "jre" > directory as before. > Good point. I think this deserves to have its separate document about details of the module images including the layout. We can use this note as the starting point. >> >> : >> >> In the legacy mode, the system classes are loaded from the platform >> modules installed in the system module library whereas non-system >> classes are loaded from classpath, extension mechanism or custom >> class loader as it is today. > Should this paragraph make it clear that the "non-platform" modules > are ignored (and perhaps reference the migration/mixed-mode support in > section C). > Okay. >> >> >> : >> >> B) Legacy mode >> >> There are various ways to alter the bootclasspath that will continue >> to work in legacy mode: >> >> 1. -Xbootclasspath/p to prepend bootclasspath >> 2. Endorsed directory to prepend the default bootclasspath >> via -Djava.endorsed.dirs (one or more directories) and >> the default $JAVA_HOME/lib/endorsed directory >> 3. -Xbootclasspath/a to append bootclasspath >> 4. JVMTI and java.lang.instrument to append the bootclasspath > Should this section mention the extensions mechanism (ext directory > where provider implementations and other JAR files are often copied > into)? Good suggestion. It's useful to include a section describing the extension mechanism in this note. The extension mechanism doesn't extend the bootclasspath and therefore it's not in the above list. > >> : >> >> A) Module mode >> >> 1. Current implementation >> >> - The module boot path is passed by the java launcher as a >> "sun.java.launcher.module.boot" system property and the >> VM will find the primordial classes from that path. > Will this be a problem for custom launchers, folks using the JNI > invocation API, etc? Ah...I forgot to mention this. This will be removed when the VM interfaces with jigsaw to find the boot module. Thanks for the comment. Mandy From mandy.chung at oracle.com Thu Jun 3 10:43:12 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 10:43:12 -0700 Subject: Review of platform modules & class analyzer change In-Reply-To: <4C07DB03.9040605@oracle.com> References: <20100603043450.DD42A956@eggemoggin.niobe.net> <4C07DB03.9040605@oracle.com> Message-ID: <4C07E9B0.4090600@oracle.com> On 06/03/10 09:40, Alan Bateman wrote: > mark.reinhold at oracle.com wrote: >>> Date: Tue, 18 May 2010 22:37:05 -0700 >>> From: mandy.chung at oracle.com >>> >> >> >>> http://cr.openjdk.java.net/~mchung/jigsaw/platform-modules >>> >> >> The module-definition changes look good. >> >> I haven't reviewed the class-analyzer changes in detail; Alan, could you >> please take a closer look? >> >> > Mandy - I went through the module changes when you sent this out > originally and they also look good to me. > > I've now gone through the class analyzer changes. Thanks for the review. > One small concern is that the names of the aggregator modules has > slipped into Platform.java so it's yet another place that needs to > maintained if/when we make changes. The usage of the Platform methods > (such as in ClassAnalyzer when printing the module lists for example) > also means there are other places that know about the aggregation. > Otherwise the changes are fine. At some point it would be good to do a > clean-up pass over the class analyzer as it has grown and has been > modified many times. Low priority compared to other tasks of course. Yeah... I have tried to keep the class analyzer to be less tightly coupled with the module names and the jdk specific. Definitely the class analyzer needs a clean-up pass to make it generic. Mandy From mandy.chung at oracle.com Thu Jun 3 10:54:29 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 10:54:29 -0700 Subject: Review request: rebranding jigsaw sources In-Reply-To: <4C078A91.3040809@oracle.com> References: <4C06BCA7.8010508@oracle.com> <4C078A91.3040809@oracle.com> Message-ID: <4C07EC55.5040102@oracle.com> On 06/03/10 03:57, Alan Bateman wrote: > Mandy Chung wrote: >> Alan, Jon, >> >> Can you review the rebranding change of the jdk and langtools jigsaw >> source? >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/jdk >> http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/langtools >> >> Thanks >> Mandy > I scanned the patch file and it looks fine. The only thing I notice is > that there are a couple of files > (src/share/classes/java/lang/ModuleClassLoader.java and > ModuleInfoRead.java for example) that have modifications in 2010 but > have 2009 rather than a range in the header. I believe Kelly's rebranding script doesn't modify the year in the copyright. It's pure a rebranding change. If we modify a file in 2010 but without updating the copyright header, the year would be 2009 instead of a range. The RE used to run a script to scan the source trees and updates the copyright year if a file has any modification. Kelly is planning to update that script that should take care of these files. Mandy From kelly.ohair at oracle.com Thu Jun 3 11:09:50 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 3 Jun 2010 11:09:50 -0700 Subject: Review request: rebranding jigsaw sources In-Reply-To: <4C07EC55.5040102@oracle.com> References: <4C06BCA7.8010508@oracle.com> <4C078A91.3040809@oracle.com> <4C07EC55.5040102@oracle.com> Message-ID: <6A8F6984-7FBC-4C0C-A3A7-BB8C90F36912@oracle.com> On Jun 3, 2010, at 10:54 AM, Mandy Chung wrote: > On 06/03/10 03:57, Alan Bateman wrote: >> Mandy Chung wrote: >>> Alan, Jon, >>> >>> Can you review the rebranding change of the jdk and langtools >>> jigsaw source? >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/jdk >>> http://cr.openjdk.java.net/~mchung/jigsaw/rebrand/langtools >>> >>> Thanks >>> Mandy >> I scanned the patch file and it looks fine. The only thing I notice >> is that there are a couple of files (src/share/classes/java/lang/ >> ModuleClassLoader.java and ModuleInfoRead.java for example) that >> have modifications in 2010 but have 2009 rather than a range in the >> header. > > I believe Kelly's rebranding script doesn't modify the year in the > copyright. It's pure a rebranding change. If we modify a file in > 2010 but without updating the copyright header, the year would be > 2009 instead of a range. > > The RE used to run a script to scan the source trees and updates the > copyright year if a file has any modification. Kelly is planning > to update that script that should take care of these files. Yeah, don't worry too much about the second year, I'll see about creating a script that RE can run occasionally to update the second years. -kto > Mandy From sean.mullan at oracle.com Thu Jun 3 11:33:35 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 03 Jun 2010 14:33:35 -0400 Subject: jmod enhancements to support signed modules In-Reply-To: <4C06A7BB.9040008@oracle.com> References: <4C06A7BB.9040008@oracle.com> Message-ID: <4C07F57F.8050303@oracle.com> Hi Vinnie, Some comments - * Library - For the install method verifySignature parameter, it should state that the signature verification is performed only if a signature exists - I think that we will need more than the verifySignature flag. There are many settings that one may want control over when validating certificate chains. I would suggest keeping the one-arg install methods (for no signature verification) and adding overloaded install methods that take additional parameters for verifying the signature, ex: public void install(Collection mfs, ModuleFileVerifier.Parameters parameters) However, I don't think this is critical right now. This is something we could do as a follow-on change once we understand the use cases a little better. * Librarian - When we document the -noverify option, we should make it clear that this means the signature is completely ignored and the module will be installed as an unsigned module. * ModuleFileVerifier - The description of verifySignature should also state that the digital signature is verified - I think that we will need an extensible mechanism to allow the caller to decide if it wants to trust each CodeSigner. There also may be cases where the certificate chain validation fails (ex: certificate is expired) but the local policy allows the user to decide if they want to trust the signer. We need some sort of callback mechanism to allow the caller (and/or policy) to decide if it wants to trust each code signer. But this needs more thought, because the callback needs to be supplied with the appropriate level of information to make that decision. Minimally the CodeSigner, but probably also information about the module and where it came from. This is also something I don't think is critical right now, and I think the use cases will become clearer as we do more testing and work on other jigsaw tasks. * ModuleFileFormat - line 1624, 1728, you can just return ModuleFile.SignatureType.PKCS7, enums are constants already - lines 1743-1748, needs to be inside a doPrivileged block, also System.getProperty could be called once, or is java.home cached anywhere else? - line 1747, looks like you never close this file input stream - line 1768-1770, I think a parsing exception should be treated as an error (also see my last comment below) ... - It doesn't look like the PKCS7VerifierParameters class is used, should it be removed? - lines 1810-1812, I think we should throw the CertificateException. Until we have a callback mechanism in place, I think it is better both for debugging and security to treat any certificate validation exception as fatal and by default do not install the module. --Sean On 6/2/10 2:49 PM, Vincent Ryan wrote: > Hello, > > Please review these code changes to support the creation of signed modules: > > http://cr.openjdk.java.net/~vinnie/6957907/webrev.00/ > > 'jmod install' now performs certificate path validation of > each signer's cert chain when the module file carries a signature. > > Thanks. From mandy.chung at oracle.com Thu Jun 3 11:50:45 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 11:50:45 -0700 Subject: Legacy mode to find modules for tools.jar (or other jars not in the bootclasspath) Message-ID: <4C07F985.7070204@oracle.com> I finally get a chance to revise the legacy mode support (III.B.2 as described in [1]) and add the mixed mode legacy application support (III.C.a as in [1]). I wanted to do more extensive testing before requesting a formal code review (the testing I have done so far is good). I'm not surprised if I have some strange unexpected issues. This webrev will give you a better idea how this works as described in [1]. http://cr.openjdk.java.net/~mchung/jigsaw/legacy-mode/webrev.00/ I'd like to start one discussion in this thread: With the tradition legacy image, to compile and run with classes from tools.jar (or other JDK jars that are not part of the default bootclasspath), the -classpath option is required to add it to the classpath. With the new module image, the question is: how should the legacy application find the jdk modules corresponding to tools.jar and other jars? See LegacyLauncher.java line 142. I considered 3 options and propose to use (3a): 1) Default is "jdk.jre" (i.e. entire JRE - see section 0 in [1]) 2) Default is "jdk" (i.e. entire JDK including tools.jar and other) 3) Default is "jdk.legacy" that is an aggregator module that optionally requires all jdk modules. a) install jdk.legacy in jre-module-image and jdk-module-image (i.e. legacy mode is only supported in jre-module-image and jdk-module-image.) b) install jdk.legacy with the base image (i.e. legacy mode is supported in any module image provided that the classes the app depends on exist) 1) Default is "jdk.jre" We could extend this to check if $JAVA_HOME/lib/tools.jar is added in the classpath; if so, it will use "jdk" module. Pros: - No change is required in the command to compile or run java application - Legacy applications will run on jre-module-image or jdk-module-image Cons: - Require to continue to use -cp tools.jar even if tools.jar doesn't exist in the module image - Legacy applications will not run on jre-base-image (or with some other modules installed) (2) Default is "jdk" Pros: - No change in the command to compile or run java application Cons: - Legacy app must run on jdk-module-image (not jre-module-image in which "jdk" module is not installed) (3) Default is "jdk.legacy" (or call it "jdk.any") Pros: - No change is required in the command to compile or run java application - Legacy apps will run on jre-module-image or jdk-module-image Cons: - One additional aggregator module Comment, thoughts? Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-June/001039.html [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000563.html From mandy.chung at oracle.com Thu Jun 3 12:50:13 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 12:50:13 -0700 Subject: Legacy mode, module mode, mixed mode In-Reply-To: References: <4C06E98A.8060704@oracle.com> Message-ID: <4C080775.6000400@oracle.com> On 06/03/10 10:10, Karen Kinnear wrote: >> >> >> C) Mixed mode >> C.a) A legacy application running with classpath and with third-party >> modules >> >> This will be supported to ease migration to enable libraries to >> migrate to modules which legacy applications can continue to work. >> >> This will require some change in the legacy applications to specify its >> required modules and versions. >> >> One option is to extend the manifest of the legacy application jar >> file: >> Main-Class: com.greetings.Main >> Required-Modules: org.astro at 1.2.3 >> Required-Platform-Modules: jdk.base, jdk.logging > > Do we also want to outline options for applications that use .jnlp or > command-line without a jar file? The jnlp applications are packaged as jar file. I can add a note. The jnlp launcher would need to get the required modules from the manifest before launching the jnlp application. For launching a class (rather than from -jar option), it will become clear when we define the interface for the custom launcher to use (currently I use the "sun.java.launcher.*" system properties). >> >> C) Mixed mode >> C.a) A legacy class-path-based application to run with third-party >> modules >> >> The legacy application will need to specify the required third- >> party modules and the legacy launcher needs to set up a configuration >> that resolves the specified dependencies at startup time. >> In addition, the application can also specify the platform modules >> it requires to override the default one. > How? As described above, add Required-Platform-Modules in the manifest. >> >> A special class loader (say LegacyLoader) will be created for finding >> classes from the required modules. LegacyLoader will be the >> parent class loader of the extension class loader so that the >> required modules will always be searched first. The application >> class loader and extension class loader will continue to work as it is. > I'm not sure I understand the overall search order when we mix > legacy apps and modules. > My current thinking is to always search the modules first before the extension and application class loader. The webrev in [1] should give you a better idea. I still need to consider if the third-party modules be searched after the extension class path. [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-June/001061.html From sean.mullan at oracle.com Thu Jun 3 13:52:03 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 03 Jun 2010 16:52:03 -0400 Subject: Incremental jdk development In-Reply-To: <4BFC33C8.80101@oracle.com> References: <4BFC33C8.80101@oracle.com> Message-ID: <4C0815F3.5060300@oracle.com> When you do a build from the jigsaw/jdk/make directory, what do you set your ALT_HOTSPOT properties to? I tried setting them to the following: ALT_HOTSPOT_IMPORT_PATH = /home/mullan/hg/jigsaw/build/linux-i586 ALT_HOTSPOT_CLIENT_PATH = /home/mullan/hg/jigsaw/build/linux-i586/lib/i386/client ALT_HOTSPOT_SERVER_PATH = /home/mullan/hg/jigsaw/build/linux-i586/lib/i386/server but I'm getting the following error: make[3]: Entering directory `/home/mullan/hg/jigsaw/jdk/make/java/redist/sajdi' make[3]: *** No rule to make target `/home/mullan/hg/jigsaw/build/linux-i586/jre/lib/i386/libsaproc.so', needed by `../../../../build/linux-i586/lib/i386/libsaproc.so'. Stop. make[3]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java/redist/sajdi' make[2]: *** [all] Error 1 make[2]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java/redist' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java' make: *** [all] Error 1 something is still expecting the old jre/lib directory structure ... Thanks, Sean On 5/25/10 4:32 PM, Mandy Chung wrote: > In the jigsaw repo, the makefile to modularize the jdk > (make/modules/Makefile) is not optimized and it will reinstall all jdk > modules in a module library every time it is made. Some of us have our > own script to update the module library rather than remaking > make/modules/Makefile. > > I include such script in the jigsaw/jdk repo for the incremental jdk > development as an interim solution: > http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/335e3289aba7/make/modules/update_module.sh > > > For example, after you recompile classes in some directory, > $ cd make/java/java ; make all > > you can use the script to update the module library: > $ make/modules/update_module.sh jdk.boot > > Please refer to the script for different options. Hope this helps. > > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-May/000960.html From Alan.Bateman at oracle.com Thu Jun 3 14:21:04 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 03 Jun 2010 22:21:04 +0100 Subject: Incremental jdk development In-Reply-To: <4C0815F3.5060300@oracle.com> References: <4BFC33C8.80101@oracle.com> <4C0815F3.5060300@oracle.com> Message-ID: <4C081CC0.4020404@oracle.com> Sean Mullan wrote: > When you do a build from the jigsaw/jdk/make directory, what do you > set your ALT_HOTSPOT properties to? I tried setting them to the > following: > > ALT_HOTSPOT_IMPORT_PATH = /home/mullan/hg/jigsaw/build/linux-i586 > ALT_HOTSPOT_CLIENT_PATH = > /home/mullan/hg/jigsaw/build/linux-i586/lib/i386/client > ALT_HOTSPOT_SERVER_PATH = > /home/mullan/hg/jigsaw/build/linux-i586/lib/i386/server > > but I'm getting the following error: > > make[3]: Entering directory > `/home/mullan/hg/jigsaw/jdk/make/java/redist/sajdi' > make[3]: *** No rule to make target > `/home/mullan/hg/jigsaw/build/linux-i586/jre/lib/i386/libsaproc.so', > needed by `../../../../build/linux-i586/lib/i386/libsaproc.so'. Stop. > make[3]: Leaving directory > `/home/mullan/hg/jigsaw/jdk/make/java/redist/sajdi' > make[2]: *** [all] Error 1 > make[2]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java/redist' > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java' > make: *** [all] Error 1 > > something is still expecting the old jre/lib directory structure ... > > Thanks, > Sean It might be easier to start with a build of the entire forest and then do your incremental builds in the jdk repo with ALT_OUTPUTDIR set appropriately. If you are doing partial builds like the above then you might be best to build the "all_product" target so that you have the complete export tree. That way you just need to set ALT_HOTSPOT_IMPORT_PATH (to build/linux-i586/export-linux-i586 in your case) -- ie: no need to set the ALT_HOTSPOT_{CLIENT,SERVER}_PATH variables. -Alan. From mandy.chung at oracle.com Thu Jun 3 14:22:31 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 14:22:31 -0700 Subject: Incremental jdk development In-Reply-To: <4C0815F3.5060300@oracle.com> References: <4BFC33C8.80101@oracle.com> <4C0815F3.5060300@oracle.com> Message-ID: <4C081D17.40305@oracle.com> On 06/03/10 13:52, Sean Mullan wrote: > When you do a build from the jigsaw/jdk/make directory, what do you > set your ALT_HOTSPOT properties to? I tried setting them to the > following: > > ALT_HOTSPOT_IMPORT_PATH = /home/mullan/hg/jigsaw/build/linux-i586 > ALT_HOTSPOT_CLIENT_PATH = > /home/mullan/hg/jigsaw/build/linux-i586/lib/i386/client > ALT_HOTSPOT_SERVER_PATH = > /home/mullan/hg/jigsaw/build/linux-i586/lib/i386/server > > but I'm getting the following error: > > make[3]: Entering directory > `/home/mullan/hg/jigsaw/jdk/make/java/redist/sajdi' > make[3]: *** No rule to make target > `/home/mullan/hg/jigsaw/build/linux-i586/jre/lib/i386/libsaproc.so', > needed by `../../../../build/linux-i586/lib/i386/libsaproc.so'. Stop. > make[3]: Leaving directory > `/home/mullan/hg/jigsaw/jdk/make/java/redist/sajdi' > make[2]: *** [all] Error 1 > make[2]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java/redist' > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/home/mullan/hg/jigsaw/jdk/make/java' > make: *** [all] Error 1 > I didn't run into it yet since I build langtools, jdk, and hotspot all together as they all contain jigsaw changes. > something is still expecting the old jre/lib directory structure ... > I will fix it. HOTSPOT_SALIB_PATH = $(HOTSPOT_IMPORT_PATH)/jre/lib/$(LIBARCH) If you build jigsaw/hotspot before, you can set ALT_HOTSPOT_IMPORT_PATH=<..>/build/linux-i586/hotspot/import to workaround the problem. Mandy > Thanks, > Sean > > On 5/25/10 4:32 PM, Mandy Chung wrote: >> In the jigsaw repo, the makefile to modularize the jdk >> (make/modules/Makefile) is not optimized and it will reinstall all jdk >> modules in a module library every time it is made. Some of us have our >> own script to update the module library rather than remaking >> make/modules/Makefile. >> >> I include such script in the jigsaw/jdk repo for the incremental jdk >> development as an interim solution: >> http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/file/335e3289aba7/make/modules/update_module.sh >> >> >> >> For example, after you recompile classes in some directory, >> $ cd make/java/java ; make all >> >> you can use the script to update the module library: >> $ make/modules/update_module.sh jdk.boot >> >> Please refer to the script for different options. Hope this helps. >> >> Mandy >> [1] >> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-May/000960.html From mandy.chung at oracle.com Thu Jun 3 15:34:43 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 03 Jun 2010 15:34:43 -0700 Subject: Issue with detecting if it's a platform context In-Reply-To: <20100603043404.A4ACA956@eggemoggin.niobe.net> References: <20100603043404.A4ACA956@eggemoggin.niobe.net> Message-ID: <4C082E03.5000106@oracle.com> On 06/02/10 21:34, mark.reinhold at oracle.com wrote: >> 2. The optional modules are not linked and recorded in the config. The fix is >> to skip the optional modules in the Resolver only if it doesn't exist. >> > > The resolver fix for optional modules needs adjustment. You've got > the right idea in moving the Modifier.OPTIONAL test further down in > the resolve(int, Choice) method. Placing it at the end of the method, > however, means that the resolver will consider remote, not-yet-installed > modules as candidates for satisfying optional dependences, and that's > not the right thing. The OPTIONAL test should be placed just before the > section that checks remote repositories. I'd also change the comment to > say "Don't fail; it's just an optional dependence". > Thanks for catching it. Here is the diff: diff --git a/src/share/classes/org/openjdk/jigsaw/Resolver.java b/src/share/classes/org/openjdk/jigsaw/Resolver.java --- a/src/share/classes/org/openjdk/jigsaw/Resolver.java +++ b/src/share/classes/org/openjdk/jigsaw/Resolver.java @@ -48,7 +48,6 @@ import static org.openjdk.jigsaw.Trace.* // of the dependence graph since different versions of the same module can // have completely different dependences. -// ## TODO: Implement optional dependences // ## TODO: Implement provides // ## TODO: Improve error messages @@ -176,6 +175,11 @@ final class Resolver { return true; } + if (dep.modifiers().contains(Modifier.OPTIONAL)) { + // Don't fail; it's just an optional dependence + return resolve(depth + 1, choice.next); + } + // No local module found, so if this catalog is a library then // consider its remote repositories, if any // @@ -199,11 +203,6 @@ final class Resolver { return true; } } - } - - if (dep.modifiers().contains(Modifier.OPTIONAL)) { - // Skip for now; we'll handle these later - return resolve(depth + 1, choice.next); } if (tracing) > Oh, and please extend the _Configurator test to check that optional > dependences now work correctly. There are a couple of commented-out > tests which can serve as a starting point. > > Will do that. Thanks for the review. Mandy From Alan.Bateman at oracle.com Fri Jun 4 02:05:24 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 04 Jun 2010 10:05:24 +0100 Subject: Review request: jdk jtreg testing with jdk-module-image In-Reply-To: <4C007D6C.7070107@oracle.com> References: <4C007D6C.7070107@oracle.com> Message-ID: <4C08C1D4.7060802@oracle.com> Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jigsaw/jprt-jigsaw-tests/forest > http://cr.openjdk.java.net/~mchung/jigsaw/jprt-jigsaw-tests/jdk/ > > With this fix, we can run the jdk test targets with the > jdk-module-image from making jdk/test/Makefile or in a jprt job. > This also adds a new jdk_jigsaw test target for testing module image. > > I add a new "modules" keyword and the test/Makefile will set the > keyword to exclude modules tests if testing a legacy image. The > java/lang/module and java/lang/reflect/Module jtreg tests are tagged > with the new "modules" keyword since these tests are included in > jdk_lang target and also jdk_jigsaw is included in the jprt test targets. > > test/ModulesProblemList.txt is intended for temporarily use. Some of > the failures are known issues that should be fixed soon. I did a pass over this. It mostly looks good to me. In test/Makefile would it be more readable/consistent to use MODULE_BUILD instead of TEST_MODULES to indicate that it's a modules build? Minor nit is that a spurious blank line is added at line 347. In jprt.properties I see you've removed the fastdebug build from the list of flavors. Is that intended? Finally, did you mean to include the new tests and fixes to the other tests in this webrev? I look through them and they look good. -Alan. From vincent.x.ryan at oracle.com Fri Jun 4 06:47:01 2010 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 04 Jun 2010 14:47:01 +0100 Subject: jmod enhancements to support signed modules In-Reply-To: <4C07F57F.8050303@oracle.com> References: <4C06A7BB.9040008@oracle.com> <4C07F57F.8050303@oracle.com> Message-ID: <4C0903D5.7000906@oracle.com> Thanks for your comments Sean. I've made the changes you suggest except for removing PKCS7VerifierParameters class because it is used by the ModuleFormatTest01 unit test. An updated webrev is available at: http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ On 03/06/2010 19:33, Sean Mullan wrote: > Hi Vinnie, > > Some comments - > > * Library > > - For the install method verifySignature parameter, it should state that > the signature verification is performed only if a signature exists > > - I think that we will need more than the verifySignature flag. There > are many settings that one may want control over when validating > certificate chains. I would suggest keeping the one-arg install methods > (for no signature verification) and adding overloaded install methods > that take additional parameters for verifying the signature, ex: > > public void install(Collection mfs, > ModuleFileVerifier.Parameters parameters) > > However, I don't think this is critical right now. This is something we > could do as a follow-on change once we understand the use cases a little > better. > > * Librarian > > - When we document the -noverify option, we should make it clear that > this means the signature is completely ignored and the module will be > installed as an unsigned module. > > * ModuleFileVerifier > > - The description of verifySignature should also state that the digital > signature is verified > > - I think that we will need an extensible mechanism to allow the caller > to decide if it wants to trust each CodeSigner. There also may be cases > where the certificate chain validation fails (ex: certificate is > expired) but the local policy allows the user to decide if they want to > trust the signer. > > We need some sort of callback mechanism to allow the caller (and/or > policy) to decide if it wants to trust each code signer. But this needs > more thought, because the callback needs to be supplied with the > appropriate level of information to make that decision. Minimally the > CodeSigner, but probably also information about the module and where it > came from. > > This is also something I don't think is critical right now, and I think > the use cases will become clearer as we do more testing and work on > other jigsaw tasks. > > * ModuleFileFormat > > - line 1624, 1728, you can just return ModuleFile.SignatureType.PKCS7, > enums are constants already > > - lines 1743-1748, needs to be inside a doPrivileged block, also > System.getProperty could be called once, or is java.home cached anywhere > else? > > - line 1747, looks like you never close this file input stream > > - line 1768-1770, I think a parsing exception should be treated as an > error (also see my last comment below) ... > > - It doesn't look like the PKCS7VerifierParameters class is used, should > it be removed? > > - lines 1810-1812, I think we should throw the CertificateException. > Until we have a callback mechanism in place, I think it is better both > for debugging and security to treat any certificate validation exception > as fatal and by default do not install the module. > > > --Sean > > On 6/2/10 2:49 PM, Vincent Ryan wrote: >> Hello, >> >> Please review these code changes to support the creation of signed >> modules: >> >> http://cr.openjdk.java.net/~vinnie/6957907/webrev.00/ >> >> 'jmod install' now performs certificate path validation of >> each signer's cert chain when the module file carries a signature. >> >> Thanks. From mandy.chung at oracle.com Fri Jun 4 08:26:41 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 04 Jun 2010 08:26:41 -0700 Subject: Review request: jdk jtreg testing with jdk-module-image In-Reply-To: <4C08C1D4.7060802@oracle.com> References: <4C007D6C.7070107@oracle.com> <4C08C1D4.7060802@oracle.com> Message-ID: <4C091B31.4010100@oracle.com> Alan Bateman wrote: > Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jigsaw/jprt-jigsaw-tests/forest >> http://cr.openjdk.java.net/~mchung/jigsaw/jprt-jigsaw-tests/jdk/ >> >> With this fix, we can run the jdk test targets with the >> jdk-module-image from making jdk/test/Makefile or in a jprt job. >> This also adds a new jdk_jigsaw test target for testing module image. >> >> I add a new "modules" keyword and the test/Makefile will set the >> keyword to exclude modules tests if testing a legacy image. The >> java/lang/module and java/lang/reflect/Module jtreg tests are tagged >> with the new "modules" keyword since these tests are included in >> jdk_lang target and also jdk_jigsaw is included in the jprt test >> targets. >> >> test/ModulesProblemList.txt is intended for temporarily use. Some of >> the failures are known issues that should be fixed soon. > I did a pass over this. It mostly looks good to me. > > In test/Makefile would it be more readable/consistent to use > MODULE_BUILD instead of TEST_MODULES to indicate that it's a modules > build? Minor nit is that a spurious blank line is added at line 347. > ok. Will update that. > In jprt.properties I see you've removed the fastdebug build from the > list of flavors. Is that intended? > This is not intended. I'll revert that line's change. > Finally, did you mean to include the new tests and fixes to the other > tests in this webrev? I look through them and they look good. > Thanks for reviewing the tests. This webrev includes the test fixes and new tests for review as well. Mandy From sean.mullan at oracle.com Fri Jun 4 10:22:01 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 04 Jun 2010 13:22:01 -0400 Subject: jmod enhancements to support signed modules In-Reply-To: <4C0903D5.7000906@oracle.com> References: <4C06A7BB.9040008@oracle.com> <4C07F57F.8050303@oracle.com> <4C0903D5.7000906@oracle.com> Message-ID: <4C093639.9080903@oracle.com> * SimpleLibrary - lines 821-822: you should cache/reuse this object per install in order to avoid redundant loading of the cacerts file when you are installing more than one signed module --Sean On 6/4/10 9:47 AM, Vincent Ryan wrote: > Thanks for your comments Sean. > > I've made the changes you suggest except for removing PKCS7VerifierParameters > class because it is used by the ModuleFormatTest01 unit test. > > An updated webrev is available at: > > http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ > > > > On 03/06/2010 19:33, Sean Mullan wrote: >> Hi Vinnie, >> >> Some comments - >> >> * Library >> >> - For the install method verifySignature parameter, it should state that >> the signature verification is performed only if a signature exists >> >> - I think that we will need more than the verifySignature flag. There >> are many settings that one may want control over when validating >> certificate chains. I would suggest keeping the one-arg install methods >> (for no signature verification) and adding overloaded install methods >> that take additional parameters for verifying the signature, ex: >> >> public void install(Collection mfs, >> ModuleFileVerifier.Parameters parameters) >> >> However, I don't think this is critical right now. This is something we >> could do as a follow-on change once we understand the use cases a little >> better. >> >> * Librarian >> >> - When we document the -noverify option, we should make it clear that >> this means the signature is completely ignored and the module will be >> installed as an unsigned module. >> >> * ModuleFileVerifier >> >> - The description of verifySignature should also state that the digital >> signature is verified >> >> - I think that we will need an extensible mechanism to allow the caller >> to decide if it wants to trust each CodeSigner. There also may be cases >> where the certificate chain validation fails (ex: certificate is >> expired) but the local policy allows the user to decide if they want to >> trust the signer. >> >> We need some sort of callback mechanism to allow the caller (and/or >> policy) to decide if it wants to trust each code signer. But this needs >> more thought, because the callback needs to be supplied with the >> appropriate level of information to make that decision. Minimally the >> CodeSigner, but probably also information about the module and where it >> came from. >> >> This is also something I don't think is critical right now, and I think >> the use cases will become clearer as we do more testing and work on >> other jigsaw tasks. >> >> * ModuleFileFormat >> >> - line 1624, 1728, you can just return ModuleFile.SignatureType.PKCS7, >> enums are constants already >> >> - lines 1743-1748, needs to be inside a doPrivileged block, also >> System.getProperty could be called once, or is java.home cached anywhere >> else? >> >> - line 1747, looks like you never close this file input stream >> >> - line 1768-1770, I think a parsing exception should be treated as an >> error (also see my last comment below) ... >> >> - It doesn't look like the PKCS7VerifierParameters class is used, should >> it be removed? >> >> - lines 1810-1812, I think we should throw the CertificateException. >> Until we have a callback mechanism in place, I think it is better both >> for debugging and security to treat any certificate validation exception >> as fatal and by default do not install the module. >> >> >> --Sean >> >> On 6/2/10 2:49 PM, Vincent Ryan wrote: >>> Hello, >>> >>> Please review these code changes to support the creation of signed >>> modules: >>> >>> http://cr.openjdk.java.net/~vinnie/6957907/webrev.00/ >>> >>> 'jmod install' now performs certificate path validation of >>> each signer's cert chain when the module file carries a signature. >>> >>> Thanks. > From mark.reinhold at oracle.com Fri Jun 4 11:31:48 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 04 Jun 2010 11:31:48 -0700 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: sean.mullan@oracle.com; Tue, 01 Jun 2010 09:50:21 EDT; <4C05101D.8010906@oracle.com> Message-ID: <20100604183148.2DB619DF@eggemoggin.niobe.net> > Date: Tue, 01 Jun 2010 09:50:21 -0400 > From: sean.mullan at oracle.com > I posted a new webrev addressing the comments I have received so far: > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ Mostly looks good, but I'd like to see a few changes before you push. SimpleLibrary.java [55] Is there a reason to put signer.ser in its own subdirectory? If not, please change that. Also, please name it "signer", without the extension. [522] Serialization is a pretty heavyweight (and brittle) solution here. I can live with it for now, but in a future changeset please modify this code to store and load CodeSigners using the existing conventions for metadata files. [540] Casts should not be separated from the expression being cast, i.e., (CodeSigner)ois.readObject(), not (CodeSigner) ois.readObject() . Loader.java The codeSourceForName map is awkward. Please add a codeSource property to java.lang.reflect.Module instead. That will obviate the need for this map and also make the CodeSource available for other uses. [196] If there's no CodeSigner then shouldn't you pass null as the last argument to defineModule, rather than new CodeSource(null, null)? ModuleFileFormat.java [831] Knowledge of the format of the signer file should be encapsulated in one place. When installing a module file the SimpleLibrary.install method already gets the signers, by invoking Reader.verifySignature, so it'd be better to store the signers at that point rather than in the module-file reader. Moving this code now will also make it possible to eliminate serialization later. - Mark From mark.reinhold at oracle.com Fri Jun 4 12:05:14 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 04 Jun 2010 12:05:14 -0700 Subject: jmod enhancements to support signed modules In-Reply-To: vincent.x.ryan@oracle.com; Fri, 04 Jun 2010 14:47:01 BST; <4C0903D5.7000906@oracle.com> Message-ID: <20100604190514.527449DF@eggemoggin.niobe.net> > Date: Fri, 04 Jun 2010 14:47:01 +0100 > From: vincent.x.ryan at oracle.com > http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ These changes look good. Just a couple of comments on jmod-basic.sh: It'd be better to put the signed-module tests in a separate file, so that the "basic" tests remain basic. Can you create keystore.jks in the test script? That'd be preferable to checking in a binary file. Dalibor -- Could you please review this also? There are some nontrivial changes to the packaging code. - Mark From jonathan.gibbons at oracle.com Fri Jun 4 12:11:27 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Jun 2010 12:11:27 -0700 Subject: jmod enhancements to support signed modules In-Reply-To: <20100604190514.527449DF@eggemoggin.niobe.net> References: <20100604190514.527449DF@eggemoggin.niobe.net> Message-ID: <4C094FDF.4070404@oracle.com> On 06/04/2010 12:05 PM, mark.reinhold at oracle.com wrote: >> Date: Fri, 04 Jun 2010 14:47:01 +0100 >> From: vincent.x.ryan at oracle.com >> > >> http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ >> > These changes look good. Just a couple of comments on jmod-basic.sh: > > It'd be better to put the signed-module tests in a separate file, so > that the "basic" tests remain basic. > > Can you create keystore.jks in the test script? That'd be preferable > to checking in a binary file. > > Dalibor -- Could you please review this also? There are some nontrivial > changes to the packaging code. > > - Mark > The test contains a comment about jtreg and symlinks -- the issues with symlinks should have been fixed a while back in jtreg 4.0. If you believe jtreg is still broken w.r.t. symlinks, please let me know. -- Jon From sean.mullan at oracle.com Fri Jun 4 12:22:46 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 04 Jun 2010 15:22:46 -0400 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: <20100604183148.2DB619DF@eggemoggin.niobe.net> References: <20100604183148.2DB619DF@eggemoggin.niobe.net> Message-ID: <4C095286.2090609@oracle.com> On 6/4/10 2:31 PM, mark.reinhold at oracle.com wrote: >> Date: Tue, 01 Jun 2010 09:50:21 -0400 >> From: sean.mullan at oracle.com > >> I posted a new webrev addressing the comments I have received so far: >> >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ > > Mostly looks good, but I'd like to see a few changes before you push. > > SimpleLibrary.java > > [55] Is there a reason to put signer.ser in its own subdirectory? Just trying to think ahead - we'll likely want to store additional security information such as the module's granted permissions, and potentially other certificate related information such as CRLs. > If not, please change that. Also, please name it "signer", without the > extension. Ok. > [522] Serialization is a pretty heavyweight (and brittle) solution > here. I can live with it for now, but in a future changeset please > modify this code to store and load CodeSigners using the existing > conventions for metadata files. Ok, I will address this in a subsequent changeset. > > [540] Casts should not be separated from the expression being cast, > i.e., (CodeSigner)ois.readObject(), not (CodeSigner) ois.readObject() . Ok. > Loader.java > > The codeSourceForName map is awkward. Please add a codeSource property > to java.lang.reflect.Module instead. That will obviate the need for > this map and also make the CodeSource available for other uses. Sounds good. > [196] If there's no CodeSigner then shouldn't you pass null as the last > argument to defineModule, rather than new CodeSource(null, null)? No, I don't believe so. There is a subtle difference. A CodeSource of (null, null) will still be granted permissions where the URL/certs don't matter, ex the permissions of the sandbox policy. But a null CodeSource won't be granted any permissions. > ModuleFileFormat.java > > [831] Knowledge of the format of the signer file should be encapsulated > in one place. When installing a module file the SimpleLibrary.install > method already gets the signers, by invoking Reader.verifySignature, > so it'd be better to store the signers at that point rather than in the > module-file reader. Moving this code now will also make it possible to > eliminate serialization later. Yes, good point. I'll try to post an updated webrev later today. Thanks, Sean From mark.reinhold at oracle.com Fri Jun 4 13:19:35 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 04 Jun 2010 13:19:35 -0700 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: sean.mullan@oracle.com; Fri, 04 Jun 2010 15:22:46 EDT; <4C095286.2090609@oracle.com> Message-ID: <20100604201935.983E31044@eggemoggin.niobe.net> > Date: Fri, 04 Jun 2010 15:22:46 -0400 > From: sean.mullan at oracle.com > On 6/4/10 2:31 PM, mark.reinhold at oracle.com wrote: >> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ >> ... >> >> SimpleLibrary.java >> >> [55] Is there a reason to put signer.ser in its own subdirectory? > > Just trying to think ahead - we'll likely want to store additional security > information such as the module's granted permissions, and potentially other > certificate related information such as CRLs. Even then I don't expect there will ever be very many files in an installed-module directory, so I doubt a subdirectory would be needed. > ... >> Loader.java >> ... >> >> [196] If there's no CodeSigner then shouldn't you pass null as the last >> argument to defineModule, rather than new CodeSource(null, null)? > > No, I don't believe so. There is a subtle difference. A CodeSource of (null, > null) will still be granted permissions where the URL/certs don't matter, ex > the permissions of the sandbox policy. But a null CodeSource won't be granted > any permissions. Hmm. That's okay for now, I guess. - Mark From sean.mullan at oracle.com Fri Jun 4 15:27:14 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 04 Jun 2010 18:27:14 -0400 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: <20100604201935.983E31044@eggemoggin.niobe.net> References: <20100604201935.983E31044@eggemoggin.niobe.net> Message-ID: <4C097DC2.6080804@oracle.com> On 6/4/10 4:19 PM, mark.reinhold at oracle.com wrote: >> Date: Fri, 04 Jun 2010 15:22:46 -0400 >> From: sean.mullan at oracle.com > >> On 6/4/10 2:31 PM, mark.reinhold at oracle.com wrote: >>> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.01/ >>> ... >>> >>> SimpleLibrary.java >>> >>> [55] Is there a reason to put signer.ser in its own subdirectory? >> >> Just trying to think ahead - we'll likely want to store additional security >> information such as the module's granted permissions, and potentially other >> certificate related information such as CRLs. > > Even then I don't expect there will ever be very many files in an > installed-module directory, so I doubt a subdirectory would be needed. No problem, I removed it. Updated webrev: http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.02/ Let me know if I missed anything. Thanks, Sean From mandy.chung at oracle.com Fri Jun 4 15:42:42 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 04 Jun 2010 22:42:42 +0000 Subject: hg: jigsaw/jigsaw/jdk: Fix update_module.sh to zip file module content Message-ID: <20100604224255.C61F046F8D@hg.openjdk.java.net> Changeset: 0cb842a91e74 Author: mchung Date: 2010-06-04 03:39 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/0cb842a91e74 Fix update_module.sh to zip file module content ! make/modules/update_module.sh From mark.reinhold at oracle.com Fri Jun 4 16:03:37 2010 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 04 Jun 2010 16:03:37 -0700 Subject: Code Review Request: running signed modules with SecurityManager In-Reply-To: sean.mullan@oracle.com; Fri, 04 Jun 2010 18:27:14 EDT; <4C097DC2.6080804@oracle.com> Message-ID: <20100604230337.4DC7D1044@eggemoggin.niobe.net> > Date: Fri, 04 Jun 2010 18:27:14 -0400 > From: sean.mullan at oracle.com > ... Updated webrev: > > http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/SecurityManager2/webrev.02/ > > Let me know if I missed anything. Looks good -- ship it! - Mark From jonathan.gibbons at oracle.com Fri Jun 4 17:51:34 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 05 Jun 2010 00:51:34 +0000 Subject: hg: jigsaw/jigsaw/langtools: cleanup and doc langtools build.xml file Message-ID: <20100605005135.EE49A46F94@hg.openjdk.java.net> Changeset: 2c30424a8283 Author: jjg Date: 2010-06-04 17:46 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/2c30424a8283 cleanup and doc langtools build.xml file ! make/build.properties ! make/build.xml From sean.mullan at oracle.com Sat Jun 5 16:49:12 2010 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Sat, 05 Jun 2010 23:49:12 +0000 Subject: hg: jigsaw/jigsaw/jdk: 2 new changesets Message-ID: <20100605234953.009C446FC4@hg.openjdk.java.net> Changeset: c05b7deb6450 Author: mullan Date: 2010-06-05 19:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c05b7deb6450 Support for running signed modules with a SecurityManager Reviewed-by: mchung, forax, mr ! src/share/classes/java/lang/module/ModuleClassLoader.java ! src/share/classes/java/lang/reflect/Module.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/org/openjdk/jigsaw/Files.java ! src/share/classes/org/openjdk/jigsaw/Library.java ! src/share/classes/org/openjdk/jigsaw/Loader.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Packager.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! test/org/openjdk/jigsaw/MockLibrary.java + test/org/openjdk/jigsaw/cli/signed-module.policy + test/org/openjdk/jigsaw/cli/signed-module.sh Changeset: 5b3b8fd670fe Author: mullan Date: 2010-06-05 19:32 -0400 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5b3b8fd670fe Branch merge. From Dalibor.Topic at Sun.COM Mon Jun 7 09:01:20 2010 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 07 Jun 2010 18:01:20 +0200 Subject: jmod enhancements to support signed modules In-Reply-To: <4C0903D5.7000906@oracle.com> References: <4C06A7BB.9040008@oracle.com> <4C07F57F.8050303@oracle.com> <4C0903D5.7000906@oracle.com> Message-ID: <4C0D17D0.6080501@sun.com> Vincent Ryan wrote: > Thanks for your comments Sean. > > I've made the changes you suggest except for removing PKCS7VerifierParameters > class because it is used by the ModuleFormatTest01 unit test. > > An updated webrev is available at: > > http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ Looks good to me, small nits: ModuleFileFormat: * import cleanup: I guess the import java.security.cert.Certificate; could go away, too? * loadCACertsStore: Not sure about the unix file separators and the file location on windows - if the file name is used across tests & further code, it may make sense to add it to Files.java. * SimpleLibrary indentation : + if (doVerify) { mr.verifyHashes(); + } cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: J?rgen Kunz From vincent.x.ryan at oracle.com Mon Jun 7 09:14:20 2010 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 07 Jun 2010 17:14:20 +0100 Subject: jmod enhancements to support signed modules In-Reply-To: <20100604190514.527449DF@eggemoggin.niobe.net> References: <20100604190514.527449DF@eggemoggin.niobe.net> Message-ID: <4C0D1ADC.2090401@oracle.com> Thanks for the review. I'll move the signed tests out of jmod-basic.sh and I'll prepare a Java program to generate the keystore file. On 04/06/2010 20:05, mark.reinhold at oracle.com wrote: >> Date: Fri, 04 Jun 2010 14:47:01 +0100 >> From: vincent.x.ryan at oracle.com > >> http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ > > These changes look good. Just a couple of comments on jmod-basic.sh: > > It'd be better to put the signed-module tests in a separate file, so > that the "basic" tests remain basic. > > Can you create keystore.jks in the test script? That'd be preferable > to checking in a binary file. > > Dalibor -- Could you please review this also? There are some nontrivial > changes to the packaging code. > > - Mark From vincent.x.ryan at oracle.com Mon Jun 7 09:16:44 2010 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 07 Jun 2010 17:16:44 +0100 Subject: jmod enhancements to support signed modules In-Reply-To: <4C0D17D0.6080501@sun.com> References: <4C06A7BB.9040008@oracle.com> <4C07F57F.8050303@oracle.com> <4C0903D5.7000906@oracle.com> <4C0D17D0.6080501@sun.com> Message-ID: <4C0D1B6C.8070403@oracle.com> Thanks for the quick turnaround Dalibor. I've a few responses below. On 07/06/2010 17:01, Dalibor Topic wrote: > Vincent Ryan wrote: >> Thanks for your comments Sean. >> >> I've made the changes you suggest except for removing PKCS7VerifierParameters >> class because it is used by the ModuleFormatTest01 unit test. >> >> An updated webrev is available at: >> >> http://cr.openjdk.java.net/~vinnie/6957907/webrev.01/ > > Looks good to me, small nits: > > ModuleFileFormat: > > * import cleanup: > > I guess the import java.security.cert.Certificate; could go away, too? java.security.Certificate (deprecated) obscures java.security.cert.Certificate when package wildcards are used so I normally import it explicitly. > > * loadCACertsStore: > > Not sure about the unix file separators and the file location on windows > - if the file name is used across tests& further code, it may make sense > to add it to Files.java. Slash separator works on Windows too. > > * SimpleLibrary > > indentation : > + if (doVerify) { > mr.verifyHashes(); > + } Fixed > > cheers, > dalibor topic > From sean.mullan at oracle.com Mon Jun 7 10:57:04 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 07 Jun 2010 13:57:04 -0400 Subject: Legacy mode, module mode, mixed mode In-Reply-To: <4C06E98A.8060704@oracle.com> References: <4C06E98A.8060704@oracle.com> Message-ID: <4C0D32F0.7080209@oracle.com> On 6/2/10 7:30 PM, Mandy Chung wrote: > C) Mixed mode > C.a) A legacy application running with classpath and with third-party > modules > > This will be supported to ease migration to enable libraries to > migrate to modules which legacy applications can continue to work. > > This will require some change in the legacy applications to specify its > required modules and versions. > > One option is to extend the manifest of the legacy application jar file: > Main-Class: com.greetings.Main > Required-Modules: org.astro at 1.2.3 > Required-Platform-Modules: jdk.base, jdk.logging Note that if the legacy application is signed, this will break the signature so you will need to re-sign it. --Sean From mandy.chung at oracle.com Mon Jun 7 11:36:43 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Jun 2010 11:36:43 -0700 Subject: Legacy mode, module mode, mixed mode In-Reply-To: <4C0D32F0.7080209@oracle.com> References: <4C06E98A.8060704@oracle.com> <4C0D32F0.7080209@oracle.com> Message-ID: <4C0D3C3B.402@oracle.com> On 06/07/10 10:57, Sean Mullan wrote: > On 6/2/10 7:30 PM, Mandy Chung wrote: >> C) Mixed mode >> C.a) A legacy application running with classpath and with third-party >> modules >> >> This will be supported to ease migration to enable libraries to >> migrate to modules which legacy applications can continue to work. >> >> This will require some change in the legacy applications to specify its >> required modules and versions. >> >> One option is to extend the manifest of the legacy application jar file: >> Main-Class: com.greetings.Main >> Required-Modules: org.astro at 1.2.3 >> Required-Platform-Modules: jdk.base, jdk.logging > > Note that if the legacy application is signed, this will break the > signature so you will need to re-sign it. > Thanks for pointing this out. I'll make a note of it and include that in the discussion of the mixed mode support. Mandy From mike.duigou at oracle.com Mon Jun 7 12:43:50 2010 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 7 Jun 2010 12:43:50 -0700 Subject: Comments on format and type of path in Module File Format Specification Message-ID: The description for SubSectionFileHeader::path in the current module file format [1] seems fairly close to URI Relative Reference [2] but the typing description for path somewhat ambiguous. Declaring the path to be a URI may offer benefits for more predictable resolution as well as specified forms for normalization/canonicalization. Additionally the path is in currently declared as "modified Java UTF-8" but no normalization/canonicalization is discussed. The use of modified UTF-8 seems unnecessary since a length is provided. I understand that it is likely modified UTF-8 because it's convenient for String written with DataOutputStream and because other Java formats (notably the class file format) also use the modified variant of UTF-8. None of this would be relevant if path is an encoded URI as the charset would be US-ASCII. Mike [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/module-file-format/ [2] http://tools.ietf.org/html/rfc3986#section-4.2 From vincent.x.ryan at oracle.com Mon Jun 7 12:47:06 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 07 Jun 2010 19:47:06 +0000 Subject: hg: jigsaw/jigsaw/jdk: 6957907: (jmod) Enhance Librarian to handle signed modules Message-ID: <20100607194720.C56D34701F@hg.openjdk.java.net> Changeset: 59fccedf56e7 Author: vinnie Date: 2010-06-07 20:47 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/59fccedf56e7 6957907: (jmod) Enhance Librarian to handle signed modules Reviewed-by: jigsaw-dev ! src/share/classes/org/openjdk/jigsaw/Library.java ! src/share/classes/org/openjdk/jigsaw/ModuleFileFormat.java ! src/share/classes/org/openjdk/jigsaw/ModuleFileSigner.java ! src/share/classes/org/openjdk/jigsaw/ModuleFileVerifier.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java ! src/share/classes/org/openjdk/jigsaw/cli/Packager.java ! test/org/openjdk/jigsaw/InstallFromRepo.java ! test/org/openjdk/jigsaw/MockLibrary.java + test/org/openjdk/jigsaw/cli/ImportPrivateKey.java ! test/org/openjdk/jigsaw/cli/ModuleFormatTest01.java ! test/org/openjdk/jigsaw/cli/ModuleFormatTest01.sh + test/org/openjdk/jigsaw/cli/ca-cert.pem + test/org/openjdk/jigsaw/cli/ee-cert.pem ! test/org/openjdk/jigsaw/cli/jmod-basic.sh + test/org/openjdk/jigsaw/cli/jmod-signed.sh - test/org/openjdk/jigsaw/cli/keystore.jks + test/org/openjdk/jigsaw/cli/prikey.pem From vincent.x.ryan at oracle.com Mon Jun 7 12:51:35 2010 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 07 Jun 2010 19:51:35 +0000 Subject: hg: jigsaw/jigsaw/jdk: Updated testcase to generate the required keystore file Message-ID: <20100607195148.76B3E47020@hg.openjdk.java.net> Changeset: 281bb4fece82 Author: vinnie Date: 2010-06-07 20:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/281bb4fece82 Updated testcase to generate the required keystore file ! test/org/openjdk/jigsaw/cli/signed-module.sh From mandy.chung at oracle.com Mon Jun 7 18:01:16 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 07 Jun 2010 18:01:16 -0700 Subject: jdk example that uses one module's loader to load a resource file in another module Message-ID: <4C0D965C.7070201@oracle.com> I find an example in the jdk that one module (javac) attempts to load a resource file in another module (apt) using its module loader. Since apt is not required by javac, it fails to find the apt's resource bundle. This indicates that there likely exists legacy applications that may do the same thing. It works fine in the legacy app. When migrating legacy apps to modules, the legacy app may require changes like this javac / apt case. Details: com.sun.tools.javac.util.JavacMessages class is in the javac module while it is also used by the apt tool (apt module) for apt diagnostic. In com.sun.tools.apt.util.Bark constructor: // register additional resource bundle for APT messages. JavacMessages aptMessages = JavacMessages.instance(context); aptMessages.add("com.sun.tools.apt.resources.apt"); aptDiags = new JCDiagnostic.Factory(aptMessages, "apt"); The com.sun.tools.javac.util.JavacMessages.getBundles() implementation loads a resource bundle with its own class loader (by calling java.util.ResourceBundle.getBundle(String). In the legacy world, it has no problem finding "com.sun.tools.apt.resources.apt" resource bundle since com.sun.tools.javac.util.JavacMessages class and apt's resource files are on the class path. In the module world, javac and apt are two separate modules loaded by two different module loader. So com.sun.tools.javac.util.JavacMessages class fails to find the "com.sun.tools.apt.resources.apt" resource bundle that is in the apt module. As discussed with Jon, to fix this specific javac/apt resource file issue, the loader of the apt module should be included as part of the apt context when passing to JavacMessages. Mandy From vincent.x.ryan at oracle.com Tue Jun 8 08:56:35 2010 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 08 Jun 2010 16:56:35 +0100 Subject: jigsaw system property names Message-ID: <4C0E6833.8000003@oracle.com> During testing and deployment it is sometimes necessary to override the system cacerts file (in ${java.home}/lib/security/cacerts). Especially in the case of jigsaw as it is an OPENJDK repository so it builds an empty cacerts file, by default. I'd like to propose a new system property that specifies the file path to an alternative cacerts file. For example, org.openjdk.system.security.cacerts Is there an existing naming convention for system properties in jigsaw? From mandy.chung at oracle.com Tue Jun 8 09:24:46 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:24:46 +0000 Subject: hg: jigsaw/jigsaw: Added tag jigsaw-b06 for changeset ea7bd43ecda5 Message-ID: <20100608162447.1732C47056@hg.openjdk.java.net> Changeset: 788b63e053de Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/rev/788b63e053de Added tag jigsaw-b06 for changeset ea7bd43ecda5 ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:25:19 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:25:19 +0000 Subject: hg: jigsaw/jigsaw/corba: Added tag jigsaw-b06 for changeset 8dec33cd256e Message-ID: <20100608162521.83D6F47057@hg.openjdk.java.net> Changeset: 7d8a515f7b6b Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/corba/rev/7d8a515f7b6b Added tag jigsaw-b06 for changeset 8dec33cd256e ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:25:54 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:25:54 +0000 Subject: hg: jigsaw/jigsaw/hotspot: Added tag jigsaw-b06 for changeset 10399ce71866 Message-ID: <20100608162601.6BD7647058@hg.openjdk.java.net> Changeset: 44130d67346f Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/44130d67346f Added tag jigsaw-b06 for changeset 10399ce71866 ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:26:34 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:26:34 +0000 Subject: hg: jigsaw/jigsaw/jaxp: Added tag jigsaw-b06 for changeset 8e549baa9d5d Message-ID: <20100608162634.1240F47059@hg.openjdk.java.net> Changeset: dca3e44833a7 Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxp/rev/dca3e44833a7 Added tag jigsaw-b06 for changeset 8e549baa9d5d ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:27:06 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:27:06 +0000 Subject: hg: jigsaw/jigsaw/jaxws: Added tag jigsaw-b06 for changeset 2addcb5741c7 Message-ID: <20100608162706.8B48E4705A@hg.openjdk.java.net> Changeset: 7432941eadad Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jaxws/rev/7432941eadad Added tag jigsaw-b06 for changeset 2addcb5741c7 ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:27:39 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:27:39 +0000 Subject: hg: jigsaw/jigsaw/jdk: Added tag jigsaw-b06 for changeset 281bb4fece82 Message-ID: <20100608162816.5F3784705B@hg.openjdk.java.net> Changeset: c8b8de798884 Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/c8b8de798884 Added tag jigsaw-b06 for changeset 281bb4fece82 ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:28:49 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:28:49 +0000 Subject: hg: jigsaw/jigsaw/langtools: Added tag jigsaw-b06 for changeset 2c30424a8283 Message-ID: <20100608162853.AC5964705C@hg.openjdk.java.net> Changeset: a1c17a221326 Author: mchung Date: 2010-06-07 21:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a1c17a221326 Added tag jigsaw-b06 for changeset 2c30424a8283 ! .hgtags From mandy.chung at oracle.com Tue Jun 8 09:41:02 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 16:41:02 +0000 Subject: hg: jigsaw/jigsaw/jdk: Implement optional dependence Message-ID: <20100608164114.D84274705E@hg.openjdk.java.net> Changeset: 2b3cc0508c55 Author: mchung Date: 2010-06-07 21:38 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2b3cc0508c55 Implement optional dependence Reviewed-by: mr ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! test/org/openjdk/jigsaw/_Configurator.java + test/org/openjdk/jigsaw/optional-deps.sh From mandy.chung at oracle.com Tue Jun 8 12:56:17 2010 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Tue, 08 Jun 2010 19:56:17 +0000 Subject: hg: jigsaw/jigsaw/jdk: 13 new changesets Message-ID: <20100608195901.BF19447066@hg.openjdk.java.net> Changeset: 88864cea9611 Author: mchung Date: 2010-05-25 15:01 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/88864cea9611 Renaming of platform modules and add optional dependences Reviewed-by: alanb ! make/Makefile ! make/com/sun/Makefile ! make/common/Defs-modules.gmk ! make/common/Defs.gmk ! make/common/internal/Defs-corba.gmk ! make/common/internal/Defs-jaxp.gmk ! make/common/internal/Defs-jaxws.gmk ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/launchers/Makefile ! make/modules/Makefile ! make/modules/jdk7.depconfig ! make/modules/modules.config ! make/modules/modules.group + make/modules/modules.properties - make/modules/tools/Makefile - make/modules/tools/build.xml - make/modules/tools/nbproject/project.properties - make/modules/tools/nbproject/project.xml - make/modules/tools/src/com/sun/classanalyzer/AnnotatedDependency.java - make/modules/tools/src/com/sun/classanalyzer/AnnotationParser.java - make/modules/tools/src/com/sun/classanalyzer/BootAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/CheckDeps.java - make/modules/tools/src/com/sun/classanalyzer/ClassAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ClassFileParser.java - make/modules/tools/src/com/sun/classanalyzer/ClassPath.java - make/modules/tools/src/com/sun/classanalyzer/CodeAttributeParser.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java - make/modules/tools/src/com/sun/classanalyzer/ConstantPoolParser.java - make/modules/tools/src/com/sun/classanalyzer/DependencyConfig.java - make/modules/tools/src/com/sun/classanalyzer/Klass.java - make/modules/tools/src/com/sun/classanalyzer/Module.java - make/modules/tools/src/com/sun/classanalyzer/ModuleConfig.java - make/modules/tools/src/com/sun/classanalyzer/ResolutionInfo.java - make/modules/tools/src/com/sun/classanalyzer/ResourceFile.java - make/modules/tools/src/com/sun/classanalyzer/ShowDeps.java ! make/sun/security/tools/Makefile + make/tools/classanalyzer/Makefile + make/tools/classanalyzer/build.xml + make/tools/classanalyzer/nbproject/project.properties + make/tools/classanalyzer/nbproject/project.xml + make/tools/classanalyzer/src/com/sun/classanalyzer/AnnotatedDependency.java + make/tools/classanalyzer/src/com/sun/classanalyzer/AnnotationParser.java + make/tools/classanalyzer/src/com/sun/classanalyzer/BootAnalyzer.java + make/tools/classanalyzer/src/com/sun/classanalyzer/CheckDeps.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ClassAnalyzer.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ClassFileParser.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ClassPath.java + make/tools/classanalyzer/src/com/sun/classanalyzer/CodeAttributeParser.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ConstantPoolAnalyzer.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ConstantPoolParser.java + make/tools/classanalyzer/src/com/sun/classanalyzer/DependencyConfig.java + make/tools/classanalyzer/src/com/sun/classanalyzer/Klass.java + make/tools/classanalyzer/src/com/sun/classanalyzer/Module.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleConfig.java + make/tools/classanalyzer/src/com/sun/classanalyzer/Platform.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ResolutionInfo.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ResourceFile.java + make/tools/classanalyzer/src/com/sun/classanalyzer/ShowDeps.java + make/tools/classanalyzer/src/com/sun/classanalyzer/Trace.java ! src/share/classes/org/openjdk/jigsaw/LoaderPool.java ! src/share/classes/org/openjdk/jigsaw/Platform.java ! src/share/classes/org/openjdk/jigsaw/Resolver.java Changeset: 639fe2e51aea Author: mchung Date: 2010-05-28 13:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/639fe2e51aea Added xmltransform aggregator module to load SAX parser. ! make/common/Defs-modules.gmk ! make/common/Defs.gmk ! make/modules/modules.config ! make/modules/modules.group ! make/modules/modules.properties Changeset: 3fbe1d73d222 Author: mchung Date: 2010-05-28 13:11 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3fbe1d73d222 cp classes to modules after untar sa-jdi.jar ! make/modules/Makefile Changeset: 3c575d06fc02 Author: mchung Date: 2010-05-28 13:12 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/3c575d06fc02 Copy US_export_policy.jar and local_policy.jar to the base module Reviewed-by: mullan ! make/javax/crypto/Makefile Changeset: 7dfab44394bf Author: mchung Date: 2010-06-01 09:06 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7dfab44394bf Add jdk_jigsaw test target and modules keyword ! test/Makefile + test/ModulesProblemList.txt ! test/TEST.ROOT ! test/java/lang/module/_ModuleId.java ! test/java/lang/module/module-info-annotation.sh ! test/java/lang/module/module-info-reader.sh ! test/java/lang/reflect/Module/module-annotation.sh + test/org/openjdk/jigsaw/circular-deps.sh + test/org/openjdk/jigsaw/optional-deps.sh Changeset: f35f12dfb560 Author: mchung Date: 2010-06-01 11:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f35f12dfb560 Merge Changeset: 5678ef9499cf Author: mchung Date: 2010-06-04 11:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5678ef9499cf Update tests to use sh instead of /bin/sh ! test/org/openjdk/jigsaw/hello-native.sh ! test/org/openjdk/jigsaw/hello.sh ! test/org/openjdk/jigsaw/maze.sh ! test/org/openjdk/jigsaw/package.sh ! test/org/openjdk/jigsaw/resolver.sh ! test/org/openjdk/jigsaw/resource.sh ! test/org/openjdk/jigsaw/security.sh Changeset: 7cd72d2ca533 Author: mchung Date: 2010-06-04 11:02 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/7cd72d2ca533 Rename TEST_MODULES to MODULE_BUILD ! test/Makefile Changeset: 5314db30ef52 Author: mchung Date: 2010-06-04 11:32 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/5314db30ef52 Not to resolve optional dependence from remote repo ! src/share/classes/org/openjdk/jigsaw/Resolver.java Changeset: b28edede09ed Author: mchung Date: 2010-06-04 15:16 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b28edede09ed Update tests to use sh instead of /bin/sh ! test/org/openjdk/jigsaw/install-files.sh ! test/org/openjdk/jigsaw/install-repo.sh ! test/org/openjdk/jigsaw/preinstall.sh ! test/org/openjdk/jigsaw/pubrepo.sh ! test/org/openjdk/jigsaw/repolist.sh Changeset: 4d6ee85dfff9 Author: mchung Date: 2010-06-04 15:17 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/4d6ee85dfff9 Add tests for optional dependencies ! test/org/openjdk/jigsaw/_Configurator.java Changeset: 010ca680e9dd Author: mchung Date: 2010-06-07 21:15 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/010ca680e9dd Added SUN_XERCES_MODULE variable in Defs-modules.gmk ! make/common/Defs-modules.gmk Changeset: 2a1b142ebf22 Author: mchung Date: 2010-06-08 12:55 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2a1b142ebf22 Merge ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! test/org/openjdk/jigsaw/_Configurator.java - test/org/openjdk/jigsaw/cli/keystore.jks From mandy.chung at oracle.com Tue Jun 8 13:11:46 2010 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 08 Jun 2010 13:11:46 -0700 Subject: Legacy mode to find modules for tools.jar (or other jars not in the bootclasspath) In-Reply-To: <4C07F985.7070204@oracle.com> References: <4C07F985.7070204@oracle.com> Message-ID: <4C0EA402.6090809@oracle.com> Latest webrev: http://cr.openjdk.java.net/~mchung/jigsaw/legacy-mode/webrev.01/ I'm happy that the legacy mode support now passes the SKIP_BOOT_CYCLE=false build and it gets rid of the java launcher bootclasspath hack. It also includes the mixed mode support that needs further testing. Mandy On 06/03/10 11:50, Mandy Chung wrote: > I finally get a chance to revise the legacy mode support (III.B.2 as > described in [1]) and add the mixed mode legacy application support > (III.C.a as in [1]). I wanted to do more extensive testing before > requesting a formal code review (the testing I have done so far is > good). I'm not surprised if I have some strange unexpected issues. > > This webrev will give you a better idea how this works as described in > [1]. > http://cr.openjdk.java.net/~mchung/jigsaw/legacy-mode/webrev.00/ > > I'd like to start one discussion in this thread: > > With the tradition legacy image, to compile and run with classes from > tools.jar (or other JDK jars that are not part of the default > bootclasspath), the -classpath option is required to add it to the > classpath. > > With the new module image, the question is: how should the legacy > application find the jdk modules corresponding to tools.jar and other > jars? See LegacyLauncher.java line 142. > > I considered 3 options and propose to use (3a): > 1) Default is "jdk.jre" (i.e. entire JRE - see section 0 in [1]) > 2) Default is "jdk" (i.e. entire JDK including tools.jar and other) > 3) Default is "jdk.legacy" that is an aggregator module that > optionally requires all jdk modules. > a) install jdk.legacy in jre-module-image and jdk-module-image (i.e. > legacy mode is only supported in jre-module-image and jdk-module-image.) > b) install jdk.legacy with the base image (i.e. legacy mode is > supported in any module image provided that the classes the app > depends on exist) > > 1) Default is "jdk.jre" > We could extend this to check if $JAVA_HOME/lib/tools.jar is added in > the classpath; if so, it will use "jdk" module. > > Pros: > - No change is required in the command to compile or run java application > - Legacy applications will run on jre-module-image or jdk-module-image > Cons: > - Require to continue to use -cp tools.jar even if tools.jar doesn't > exist in the module image > - Legacy applications will not run on jre-base-image (or with some > other modules installed) > > (2) Default is "jdk" > > Pros: > - No change in the command to compile or run java application > Cons: > - Legacy app must run on jdk-module-image (not jre-module-image in > which "jdk" module is not installed) > > (3) Default is "jdk.legacy" (or call it "jdk.any") > > Pros: > - No change is required in the command to compile or run java application > - Legacy apps will run on jre-module-image or jdk-module-image > Cons: > - One additional aggregator module > > Comment, thoughts? > > Mandy > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-June/001039.html > [2] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000563.html > From jonathan.gibbons at oracle.com Tue Jun 8 17:27:16 2010 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Jun 2010 00:27:16 +0000 Subject: hg: jigsaw/jigsaw/langtools: 8 new changesets Message-ID: <20100609002731.7291F47070@hg.openjdk.java.net> Changeset: a8ec9e42bedc Author: jjg Date: 2010-05-27 08:29 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a8ec9e42bedc First pass at module library for target java ! make/build.properties ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 080d4b2961af Author: jjg Date: 2010-05-27 12:07 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/080d4b2961af add rules for building bootstrap modules ! make/build.xml Changeset: 0316258534fe Author: jjg Date: 2010-06-01 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/0316258534fe build changes to build modules ! make/build.properties ! make/build.xml Changeset: e9c482afeb04 Author: jjg Date: 2010-06-01 13:59 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/e9c482afeb04 Merge Changeset: 97b0d24cea7b Author: jjg Date: 2010-06-04 18:05 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/97b0d24cea7b build changes to build and use modules instead of bootclasspath ! make/build.properties ! make/build.xml + make/tools/Jigsaw/FpkgTask.java + make/tools/Jigsaw/JmodTask.java Changeset: 1915e9e82215 Author: jjg Date: 2010-06-08 15:18 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1915e9e82215 build modular javac ! make/build.properties ! make/build.xml Changeset: ad056b1f0618 Author: jjg Date: 2010-06-08 15:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ad056b1f0618 Merge Changeset: 19cf0f0f0dda Author: jjg Date: 2010-06-08 16:40 -0700 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/19cf0f0f0dda adapt to module name changes/reorg ! make/build.properties ! make/build.xml From klaus.teller at gmx.net Mon Jun 28 16:15:51 2010 From: klaus.teller at gmx.net (Klaus Teller) Date: Tue, 29 Jun 2010 01:15:51 +0200 Subject: Trying Jigsaw Message-ID: <20100628231551.176280@gmx.net> Hi Folks, Is it possible to give Jigsaw a try? When exactly should I do? I couldn't find any usage manual, so please bear with me and would very much appreciate any hint. Klaus. -- GRATIS f?r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01