From Alan.Bateman at oracle.com Wed Feb 1 01:30:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Feb 2012 09:30:38 +0000 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F287DEE.20505@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> Message-ID: <4F29063E.6050601@oracle.com> On 31/01/2012 23:49, Mandy Chung wrote: > > This depends on the services support that Alan is working on [1]. > The service loader is not yet module-aware. Prior to the module views > and exports change, all public types including > sun.java2d.jules.JulesRenderingEngine are exported and that's why it > was working previously. > > sun.java2d.pipe.RenderingEngine calls ServiceLoader.loadInstalled > method to create a new service loader using the extension class > loader. In module mode, there isn't any extension class loader but > instead it should use the caller's module loader. > > Alan, what do you think to integrate the change you have in the > ServiceLoader class that uses the proper module loader in module mode > first? I think that can be separated from the services work. I re-based the services patch after the views+exports work was pushed and just checked that it has the right declarations: $ jmod ls -v : jdk.desktop at 8-ea : requires service sun.java2d.pipe.RenderingEngine : provides service sun.java2d.pipe.RenderingEngine with sun.java2d.jules.JulesRenderingEngine provides service sun.java2d.pipe.RenderingEngine with sun.java2d.pisces.PiscesRenderingEngine I don't think the ServiceLoader changes on their own will fix this as it requires the services changes in the runtime. As many things are currently broken then I think I should just get the first version in. I have a second patch to it in the works that re-works the Resolver code to handle services dependencies properly (the first version was to get things working). -Alan From Alan.Bateman at oracle.com Wed Feb 1 10:41:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Feb 2012 18:41:32 +0000 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F29063E.6050601@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> <4F29063E.6050601@oracle.com> Message-ID: <4F29875C.5010903@oracle.com> On 01/02/2012 09:30, Alan Bateman wrote: > I re-based the services patch after the views+exports work was pushed > and just checked that it has the right declarations: > > $ jmod ls -v > : > jdk.desktop at 8-ea > : > requires service sun.java2d.pipe.RenderingEngine > : > provides service sun.java2d.pipe.RenderingEngine with > sun.java2d.jules.JulesRenderingEngine > provides service sun.java2d.pipe.RenderingEngine with > sun.java2d.pisces.PiscesRenderingEngine > > I don't think the ServiceLoader changes on their own will fix this as > it requires the services changes in the runtime. As many things are > currently broken then I think I should just get the first version in. > I have a second patch to it in the works that re-works the Resolver > code to handle services dependencies properly (the first version was > to get things working). > > -Alan Actually I think you're right, we can take some of the SL changes to get a bit further but we run into another issue with a Class.forName usage in sun.font.FontManagerFactory. Here's the webrev the patch to get it going: http://cr.openjdk.java.net/~alanb/fmf-patch/webrev/ -Alan. From mandy.chung at oracle.com Wed Feb 1 11:47:37 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 01 Feb 2012 11:47:37 -0800 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F29875C.5010903@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> <4F29063E.6050601@oracle.com> <4F29875C.5010903@oracle.com> Message-ID: <4F2996D9.1030302@oracle.com> On 2/1/2012 10:41 AM, Alan Bateman wrote: > Actually I think you're right, we can take some of the SL changes to > get a bit further but we run into another issue with a Class.forName > usage in sun.font.FontManagerFactory. Thanks for getting the fix for it. I missed this issue when testing the module views work. Oh yeah, this is one of those in the jdk implementation that depends on the tradition class loading delegation model. At some point, we'll look at all class-loader related usage. > Here's the webrev the patch to get it going: > > http://cr.openjdk.java.net/~alanb/fmf-patch/webrev/ FontManagerFactory.java L78: It's fine to call BootLoader.getSystemLoader() as a workaround for now. This assumes that the class is visible to the BootLoader and it works in the current prototype since jdk.desktop requires local jdk.base.internal. It'll fail if an alternate class specified through the property is in another module. I think it would use the module loader loading this FontManagerFactory class. I have a patch that adds the Class.getModuleClassLoader method but it's coupled with the legacy mode support. I can modify this FontManagerFactory class in the legacy mode support work. ServiceLoader.java L482, 515, 548: seems like it's time to add a convenient method to determine if it's in module mode or legacy mode. In the current prototype, BootLoader only gets created in module mode but it may also be created with the legacy mode support. If it gets changed, this would be isolated in this single method. (sorry I should have added that convenient method in my last changeset). L483: if loader == null, should it use BootLoader.getSystemLoader() instead? Mandy From Alan.Bateman at oracle.com Wed Feb 1 12:01:02 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Feb 2012 20:01:02 +0000 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F2996D9.1030302@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> <4F29063E.6050601@oracle.com> <4F29875C.5010903@oracle.com> <4F2996D9.1030302@oracle.com> Message-ID: <4F2999FE.6080902@oracle.com> On 01/02/2012 19:47, Mandy Chung wrote: > > Thanks for getting the fix for it. I missed this issue when testing > the module views work. > > Oh yeah, this is one of those in the jdk implementation that depends > on the tradition class loading delegation model. At some point, we'll > look at all class-loader related usage. Right, and I'll sure we will have many of these. > > FontManagerFactory.java > L78: It's fine to call BootLoader.getSystemLoader() as a > workaround for now. > This assumes that the class is visible to the BootLoader and it > works in > the current prototype since jdk.desktop requires local > jdk.base.internal. > It'll fail if an alternate class specified through the property is in > another module. I think it would use the module loader loading this > FontManagerFactory class. I have a patch that adds the > Class.getModuleClassLoader method but it's coupled with the legacy > mode support. I can modify this FontManagerFactory class in the > legacy > mode support work. In legacy mode it should work the way it has always worked and find the font manager on the system class path. Not clear how it should work in module mode so I decided that BootLoader would be the most sensible for now. I think this will need to be changed (several other places too) once we are further along. > > ServiceLoader.java > L482, 515, 548: seems like it's time to add a convenient method to > determine > if it's in module mode or legacy mode. In the current prototype, > BootLoader > only gets created in module mode but it may also be created with the > legacy mode support. If it gets changed, this would be isolated > in this > single method. (sorry I should have added that convenient method in my > last changeset). > > L483: if loader == null, should it use BootLoader.getSystemLoader() > instead? I don't think so because in module mode we want existing code that calls it with null to use the caller's class loader. I agree we need to add a method to indicate if are in module mode. -Alan. From mandy.chung at oracle.com Wed Feb 1 13:06:58 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 01 Feb 2012 13:06:58 -0800 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F2999FE.6080902@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> <4F29063E.6050601@oracle.com> <4F29875C.5010903@oracle.com> <4F2996D9.1030302@oracle.com> <4F2999FE.6080902@oracle.com> Message-ID: <4F29A972.1010609@oracle.com> On 2/1/2012 12:01 PM, Alan Bateman wrote: >> L483: if loader == null, should it use >> BootLoader.getSystemLoader() instead? > I don't think so because in module mode we want existing code that > calls it with null to use the caller's class loader. I agree we need > to add a method to indicate if are in module mode. Actually I wonder if the module-aware service loader should not accept null loader in module mode as the service dependences are declared in the module-info. I know you are thinking about adding new API for modules to use. Since there are existing code that calls ServiceLoader.load with a null loader, using caller's loader is fine for now and the services work will revisit this. Mandy From alan.bateman at oracle.com Thu Feb 2 07:43:10 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 02 Feb 2012 15:43:10 +0000 Subject: hg: jigsaw/jigsaw/jdk: Temporary fix to ServiceLoader to work in module mode Message-ID: <20120202154338.5EEAD47310@hg.openjdk.java.net> Changeset: b3b9bb762fbd Author: alanb Date: 2012-02-02 15:42 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/b3b9bb762fbd Temporary fix to ServiceLoader to work in module mode Temporary fix to FontManagerFactory to work in module mode Reviewed-by: mchung ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/font/FontManagerFactory.java From lhochet at gmail.com Thu Feb 2 14:46:16 2012 From: lhochet at gmail.com (Ludovic HOCHET) Date: Thu, 2 Feb 2012 23:46:16 +0100 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F287DEE.20505@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> Message-ID: Today's change fixed that issue, thanks, so I went on rechecking my Worldclock toy application [1] and got: Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/Object at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:791) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.lang.module.ModuleClassLoader.defineClass(ModuleClassLoader.java:49) at org.openjdk.jigsaw.Loader.finishFindingClass(Loader.java:240) at org.openjdk.jigsaw.Loader.findClass(Loader.java:184) at org.openjdk.jigsaw.Loader.loadClass(Loader.java:115) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482) Caused by: java.lang.ClassNotFoundException: java.lang.Object : requested by +lh.worldclock.application at org.openjdk.jigsaw.Loader.loadClass(Loader.java:113) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 9 more This seemed to call for a missing jdk.base, and indeed adding it fixed the issue (along with doing the same in the panel as well as exporting the required package). Is it now necessary to explicitely require jdk.base? Ludovic [1]: http://lhochet.blogspot.com/2012/01/jigsaw-worldclock-with-maven-plugin.html On Wed, Feb 1, 2012 at 00:49, Mandy Chung wrote: > On 1/31/2012 2:07 PM, Ludovic HOCHET wrote: > >> Hello, >> I tried building the latest source, but I'm having the following when >> trying to launch jconsole: >> >> > Thanks for reporting it. > > ludovic at jigsaw-vm:~/dev/**jigsaw$ export >> JIG=~/dev/jigsaw/build/linux-**i586/jdk-module-image >> ludovic at jigsaw-vm:~/dev/**jigsaw$ $JIG/bin/java -m jdk.jconsole >> Exception in thread "main" java.util.**ServiceConfigurationError: >> sun.java2d.pipe.**RenderingEngine: Provider >> sun.java2d.jules.**JulesRenderingEngine not found >> > > This depends on the services support that Alan is working on [1]. The > service loader is not yet module-aware. Prior to the module views and > exports change, all public types including sun.java2d.jules.**JulesRenderingEngine > are exported and that's why it was working previously. > > sun.java2d.pipe.**RenderingEngine calls ServiceLoader.loadInstalled > method to create a new service loader using the extension class loader. In > module mode, there isn't any extension class loader but instead it should > use the caller's module loader. > > Alan, what do you think to integrate the change you have in the > ServiceLoader class that uses the proper module loader in module mode > first? I think that can be separated from the services work. > > Mandy > [1] http://mail.openjdk.java.net/**pipermail/jigsaw-dev/2011-** > December/001819.html > -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From mandy.chung at oracle.com Thu Feb 2 15:22:26 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 02 Feb 2012 15:22:26 -0800 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> Message-ID: <4F2B1AB2.4000704@oracle.com> Ludovic, If I understand correctly, you get the NoClassDefFoundError if you have this module-info.java (that doesn't have "requires jdk.base"): module lh.worldclock.application @ 0.7 { requires jdk.desktop; requires lh.worldclock.panel @ 0.7; class lh.worldclock.WorldClock; } There are two things on our todo list that are relevant to this known issue. 1) jdk.desktop should re-export jdk.base so that your app only needs to say "requires jdk.desktop". 2) requires jdk.base will be synthesized by javac if not specifed in the module-info.java file [1]. Jon already has the javac change. Once we get the jigsaw runtime change ready, we will push it to jigsaw forest and that will address this issue. So for now, you would need to workaround it by specifying "requires jdk.base" as you have done. Thanks Mandy [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01 On 2/2/2012 2:46 PM, Ludovic HOCHET wrote: > Today's change fixed that issue, thanks, so I went on rechecking my > Worldclock toy application [1] and got: > Exception in thread "main" java.lang.NoClassDefFoundError: > java/lang/Object > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:791) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at > java.lang.module.ModuleClassLoader.defineClass(ModuleClassLoader.java:49) > at org.openjdk.jigsaw.Loader.finishFindingClass(Loader.java:240) > at org.openjdk.jigsaw.Loader.findClass(Loader.java:184) > at org.openjdk.jigsaw.Loader.loadClass(Loader.java:115) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > at > sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482) > Caused by: java.lang.ClassNotFoundException: java.lang.Object : > requested by +lh.worldclock.application > at org.openjdk.jigsaw.Loader.loadClass(Loader.java:113) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > ... 9 more > > This seemed to call for a missing jdk.base, and indeed adding it fixed > the issue (along with doing the same in the panel as well as exporting > the required package). > > Is it now necessary to explicitely require jdk.base? > > Ludovic > > [1]: > http://lhochet.blogspot.com/2012/01/jigsaw-worldclock-with-maven-plugin.html > > On Wed, Feb 1, 2012 at 00:49, Mandy Chung > wrote: > > On 1/31/2012 2:07 PM, Ludovic HOCHET wrote: > > Hello, > I tried building the latest source, but I'm having the > following when > trying to launch jconsole: > > > Thanks for reporting it. > > ludovic at jigsaw-vm:~/dev/jigsaw$ export > JIG=~/dev/jigsaw/build/linux-i586/jdk-module-image > ludovic at jigsaw-vm:~/dev/jigsaw$ $JIG/bin/java -m jdk.jconsole > Exception in thread "main" java.util.ServiceConfigurationError: > sun.java2d.pipe.RenderingEngine: Provider > sun.java2d.jules.JulesRenderingEngine not found > > > This depends on the services support that Alan is working on [1]. > The service loader is not yet module-aware. Prior to the module > views and exports change, all public types including > sun.java2d.jules.JulesRenderingEngine are exported and that's why > it was working previously. > > sun.java2d.pipe.RenderingEngine calls ServiceLoader.loadInstalled > method to create a new service loader using the extension class > loader. In module mode, there isn't any extension class loader > but instead it should use the caller's module loader. > > Alan, what do you think to integrate the change you have in the > ServiceLoader class that uses the proper module loader in module > mode first? I think that can be separated from the services work. > > Mandy > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-December/001819.html > > > > > -- > Ludovic > ----------------------------------------- > > "Les formes qui differencient les etres importent peu > si leur pensees s'unissent pour batir un univers..." > Yoko Tsuno (in 'Les titans' by Roger Leloup) > [The shapes that differenciate beings are not important > if their thoughts unite to build a universe] > From mandy.chung at oracle.com Fri Feb 3 12:52:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 03 Feb 2012 12:52:48 -0800 Subject: Review request: module-info class file update Message-ID: <4F2C4920.9050900@oracle.com> Jon and I are working together to update javac and runtime per the latest language and class file specification for module declaration [1]. Key changes include: 1. ModuleRequires attribute and ModuleProvides attribute - use u4 flags and add SYNTHESIZED flag 2. new CONSTANT_ModuleQuery_info 3. exports 4. default platform module is "jdk.base" - will switch to "java.base" when the alias support is implemented 5. The jar tool synthesizes "requires jdk.jre" in the generated module-info that is the entire JRE. If the legacy jar requires other modules, it requires to define its dependences properly. Webrev at: http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jvms-update.00/ Thanks Mandy [1] http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html P.S. There is one javac failure we are currently diagnosing. I will send a separate review for that issue once we resolve it as I believe it's fairly isolated one. From lhochet at gmail.com Sat Feb 4 14:07:30 2012 From: lhochet at gmail.com (Ludovic HOCHET) Date: Sat, 4 Feb 2012 23:07:30 +0100 Subject: jigsaw now sync'ed with jdk8-b23 In-Reply-To: <4F2B1AB2.4000704@oracle.com> References: <20120131051342.01D9A47299@hg.openjdk.java.net> <4F2782FA.5040406@oracle.com> <4F287DEE.20505@oracle.com> <4F2B1AB2.4000704@oracle.com> Message-ID: Hello Mandy, You understood correctly. This was the module-info.java that I had when I published the post. Ludovic On Fri, Feb 3, 2012 at 00:22, Mandy Chung wrote: > Ludovic, > > If I understand correctly, you get the NoClassDefFoundError > if you have this module-info.java (that doesn't have > "requires jdk.base"): > > module lh.worldclock.application @ 0.7 > { > requires jdk.desktop; > requires lh.worldclock.panel @ 0.7; > class lh.worldclock.WorldClock; > } > > There are two things on our todo list that are relevant > to this known issue. > 1) jdk.desktop should re-export jdk.base so that > your app only needs to say "requires jdk.desktop". > 2) requires jdk.base will be synthesized by javac if not > specifed in the module-info.java file [1]. Jon already > has the javac change. Once we get the jigsaw runtime > change ready, we will push it to jigsaw forest and that > will address this issue. > > So for now, you would need to workaround it by specifying > "requires jdk.base" as you have done. > > Thanks > Mandy > [1] http://cr.openjdk.java.net/~**mr/jigsaw/notes/jigsaw-big-**picture-01 > > > > On 2/2/2012 2:46 PM, Ludovic HOCHET wrote: > >> Today's change fixed that issue, thanks, so I went on rechecking my >> Worldclock toy application [1] and got: >> Exception in thread "main" java.lang.**NoClassDefFoundError: >> java/lang/Object >> at java.lang.ClassLoader.**defineClass1(Native Method) >> at java.lang.ClassLoader.**defineClass(ClassLoader.java:**791) >> at java.security.**SecureClassLoader.defineClass(** >> SecureClassLoader.java:142) >> at java.lang.module.**ModuleClassLoader.defineClass(** >> ModuleClassLoader.java:49) >> at org.openjdk.jigsaw.Loader.**finishFindingClass(Loader.**java:240) >> at org.openjdk.jigsaw.Loader.**findClass(Loader.java:184) >> at org.openjdk.jigsaw.Loader.**loadClass(Loader.java:115) >> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**356) >> at sun.launcher.LauncherHelper.**checkAndLoadMain(** >> LauncherHelper.java:482) >> Caused by: java.lang.**ClassNotFoundException: java.lang.Object : >> requested by +lh.worldclock.application >> at org.openjdk.jigsaw.Loader.**loadClass(Loader.java:113) >> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**356) >> ... 9 more >> >> This seemed to call for a missing jdk.base, and indeed adding it fixed >> the issue (along with doing the same in the panel as well as exporting the >> required package). >> >> Is it now necessary to explicitely require jdk.base? >> >> Ludovic >> >> [1]: http://lhochet.blogspot.com/**2012/01/jigsaw-worldclock-** >> with-maven-plugin.html >> >> On Wed, Feb 1, 2012 at 00:49, Mandy Chung > mandy.chung at oracle.com**>> wrote: >> >> On 1/31/2012 2:07 PM, Ludovic HOCHET wrote: >> >> Hello, >> I tried building the latest source, but I'm having the >> following when >> trying to launch jconsole: >> >> >> Thanks for reporting it. >> >> ludovic at jigsaw-vm:~/dev/**jigsaw$ export >> JIG=~/dev/jigsaw/build/linux-**i586/jdk-module-image >> ludovic at jigsaw-vm:~/dev/**jigsaw$ $JIG/bin/java -m jdk.jconsole >> Exception in thread "main" java.util.**ServiceConfigurationError: >> sun.java2d.pipe.**RenderingEngine: Provider >> sun.java2d.jules.**JulesRenderingEngine not found >> >> >> This depends on the services support that Alan is working on [1]. >> The service loader is not yet module-aware. Prior to the module >> views and exports change, all public types including >> sun.java2d.jules.**JulesRenderingEngine are exported and that's why >> it was working previously. >> >> sun.java2d.pipe.**RenderingEngine calls ServiceLoader.loadInstalled >> method to create a new service loader using the extension class >> loader. In module mode, there isn't any extension class loader >> but instead it should use the caller's module loader. >> >> Alan, what do you think to integrate the change you have in the >> ServiceLoader class that uses the proper module loader in module >> mode first? I think that can be separated from the services work. >> >> Mandy >> [1] >> http://mail.openjdk.java.net/**pipermail/jigsaw-dev/2011-** >> December/001819.html >> >> >> >> >> -- >> Ludovic >> ------------------------------**----------- >> >> "Les formes qui differencient les etres importent peu >> si leur pensees s'unissent pour batir un univers..." >> Yoko Tsuno (in 'Les titans' by Roger Leloup) >> [The shapes that differenciate beings are not important >> if their thoughts unite to build a universe] >> >> -- Ludovic ----------------------------------------- "Les formes qui differencient les etres importent peu si leur pensees s'unissent pour batir un univers..." Yoko Tsuno (in 'Les titans' by Roger Leloup) [The shapes that differenciate beings are not important if their thoughts unite to build a universe] From andrii.rodionov at gmail.com Sun Feb 5 01:50:00 2012 From: andrii.rodionov at gmail.com (Andrii Rodionov) Date: Sun, 05 Feb 2012 11:50:00 +0200 Subject: Jigsaw Quick Start - question Message-ID: <4F2E50C8.7080204@gmail.com> Hello! I am trying to implement an example from Jigsaw Quick Start (http://openjdk.java.net/projects/jigsaw/doc/quickstart.html). Modules were compiled and installed successfully. But when I try to execute the com.greetings , I get an exception: $ /opt/jdk/bin/java -L mlib -m com.greetings Exception in thread "main" java.lang.NoClassDefFoundError: org/astro/World at com.greetings.Hello.main(Hello.java:6) Caused by: java.lang.ClassNotFoundException: org.astro.World : requested by +com.greetings at org.openjdk.jigsaw.Loader.loadClass(Loader.java:113) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 1 more In Jigsaw Quick Start module-info.java is next: $ cat src/modules/org.astro/module-info.java module org.astro @ 1.2 { } After I?ve added line ?exports org.astro? to this module: module org.astro @ 1.2 { exports org.astro; } com.greetings run successfully. May there be an error in example? With best regards, Andrii Rodionov From Alan.Bateman at oracle.com Sun Feb 5 04:12:49 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 05 Feb 2012 12:12:49 +0000 Subject: Jigsaw Quick Start - question In-Reply-To: <4F2E50C8.7080204@gmail.com> References: <4F2E50C8.7080204@gmail.com> Message-ID: <4F2E7241.8080708@oracle.com> On 05/02/2012 09:50, Andrii Rodionov wrote: > Hello! > > I am trying to implement an example from Jigsaw Quick Start > (http://openjdk.java.net/projects/jigsaw/doc/quickstart.html). > Modules were compiled and installed successfully. But when I try to > execute the com.greetings , I get an exception: > $ /opt/jdk/bin/java -L mlib -m com.greetings > Exception in thread "main" java.lang.NoClassDefFoundError: > org/astro/World > at com.greetings.Hello.main(Hello.java:6) > Caused by: java.lang.ClassNotFoundException: org.astro.World : > requested by +com.greetings > at org.openjdk.jigsaw.Loader.loadClass(Loader.java:113) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > ... 1 more > > > In Jigsaw Quick Start module-info.java is next: > $ cat src/modules/org.astro/module-info.java > module org.astro @ 1.2 { > } > > After I?ve added line ?exports org.astro? to this module: > module org.astro @ 1.2 { > exports org.astro; > } > > com.greetings run successfully. > > May there be an error in example? Yes, the quick start guide needs to be updated since the exports implementation was pushed. We'll get this done soon. -Alan From alexey.x.fedorov at oracle.com Mon Feb 6 09:27:29 2012 From: alexey.x.fedorov at oracle.com (Alexey Fedorov) Date: Mon, 06 Feb 2012 21:27:29 +0400 Subject: Small question about Dependence.Modifier.SYNTHETIC Message-ID: <4F300D81.7090406@oracle.com> Hello! I am playing with Jigsaw and met the following strange behavior. As I understand, java.lang.module.Dependence.Modifier.SYNTHETIC was created in modular JDK for underlining that the corresponding dependency was added by the system, not by user. Consider the following code example: /module-info.java:/ module my.module @ 1.0 { class mypackage.MyClass; } /MyClass.java:/ package mypackage; public class MyClass { public static void main(String[] args) throws IOException { ModuleInfo moduleInfo = MyClass.class.getModule().getModuleInfo(); for (ViewDependence viewDependence : moduleInfo.requiresModules()) { System.out.println(viewDependence); } } } In the middle of January output was: >> requires*synthetic*jdk@=8-ea But actual output is: >> requires jdk@=8-ea Here dependency "jdk@=8-ea" is not marked as*synthetic*. Is it an expected behavior or regression? -- Thank you, Alexey From jonathan.gibbons at oracle.com Mon Feb 6 09:40:17 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 06 Feb 2012 09:40:17 -0800 Subject: Small question about Dependence.Modifier.SYNTHETIC In-Reply-To: <4F300D81.7090406@oracle.com> References: <4F300D81.7090406@oracle.com> Message-ID: <4F301081.2040401@oracle.com> There are two flags, ACC_SYNTHETIC and ACC_SYNTHESIZED. According to the latest spec, you should be getting ACC_SYNTHESIZED. But, that change may not have made it to the main repos yet. -- Jon On 02/06/2012 09:27 AM, Alexey Fedorov wrote: > Hello! > > I am playing with Jigsaw and met the following strange behavior. As I > understand, java.lang.module.Dependence.Modifier.SYNTHETIC was created > in modular JDK for underlining that the corresponding dependency was > added by the system, not by user. Consider the following code example: > > > /module-info.java:/ > > module my.module @ 1.0 { > class mypackage.MyClass; > } > > > /MyClass.java:/ > > package mypackage; > > public class MyClass { > > public static void main(String[] args) throws IOException { > ModuleInfo moduleInfo = > MyClass.class.getModule().getModuleInfo(); > for (ViewDependence viewDependence : > moduleInfo.requiresModules()) { > System.out.println(viewDependence); > } > } > > } > > > In the middle of January output was: > >>> requires*synthetic*jdk@=8-ea > > > But actual output is: > >>> requires jdk@=8-ea > > > > Here dependency "jdk@=8-ea" is not marked as*synthetic*. Is it an > expected behavior or regression? > > > -- > Thank you, > Alexey > From Alan.Bateman at oracle.com Mon Feb 6 10:19:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 06 Feb 2012 18:19:38 +0000 Subject: Allow remote repository to be located via non-http URI Message-ID: <4F3019BA.9070000@oracle.com> The remote repository is currently limited to http. I've changed the implementation so that other URIs can now be used, in particular file URIs where the repository is on the file system. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/jigsaw-localrepos/webrev/ Thanks, Alan. From alex.buckley at oracle.com Mon Feb 6 11:54:36 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 06 Feb 2012 11:54:36 -0800 Subject: Small question about Dependence.Modifier.SYNTHETIC In-Reply-To: <4F301081.2040401@oracle.com> References: <4F300D81.7090406@oracle.com> <4F301081.2040401@oracle.com> Message-ID: <4F302FFC.8050402@oracle.com> On 2/6/2012 9:40 AM, Jonathan Gibbons wrote: > There are two flags, ACC_SYNTHETIC and ACC_SYNTHESIZED. According to the > latest spec, you should be getting ACC_SYNTHESIZED. But, that change may > not have made it to the main repos yet. Good time to explain these modifiers. Historically, too many class file artifacts have been marked synthetic, and thus hidden from reflection, when in fact they represent "user-land" constructs which the Java SE specification (notably the Java Language Spec) defines as present in classes. The canonical example is Enum.values(), which is mandated by the JLS to exist in enum types as a completely ordinary method. It can only be generated by a compiler but it should not be marked synthetic because it is not javac-specific and must be exposed via reflection. So, the Java team has been aware for some time of the need to distinguish "synthesized" content (compiler-generated but user-visible and in some sense "standardized") from "synthetic" content (compiler-generated but invisible and implementation-specific). In neither case does the content map to constructs that were physically present in source. Synthesized content maps to constructs that were logically present in source. The Jigsaw class file structures are the first to introduce a first-class ACC_SYNTHESIZED flag to complement ACC_SYNTHETIC, but I expect other structures will adopt it over time. The JVM Spec will say something like: - If an entity has the synthetic flag, then the entity represents a source-level artifact that is specific to the implementation of the host system which generated the class file. The entity may not exist in all class files generated from the same source code, and should not appear in language-level models of reflection. - If an entity has the synthesized flag, then the entity represents a source-level artifact that is defined by the Java SE platform despite not appearing in source code. The entity is not specific to the implementation of the host system which generated the class file. The entity must exist in all class files generated from the same code, and should appear in language-level models of reflection. To clarify, http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html#jigsaw-1.2 ought to mandate a _synthesized_ dependency: "If a module declaration does not express a dependency on the java.base module, and the module declaration is not of java.base itself, then the module declaration automatically has a _synthesized_ dependency on a version of the java.base module chosen by the host system." Alex From mandy.chung at oracle.com Mon Feb 6 15:16:37 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 06 Feb 2012 15:16:37 -0800 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F3019BA.9070000@oracle.com> References: <4F3019BA.9070000@oracle.com> Message-ID: <4F305F55.3020207@oracle.com> On 2/6/2012 10:19 AM, Alan Bateman wrote: > > The remote repository is currently limited to http. I've changed the > implementation so that other URIs can now be used, in particular file > URIs where the repository is on the file system. The webrev with the > changes is here: > > http://cr.openjdk.java.net/~alanb/jigsaw-localrepos/webrev/ > Looks okay. It would be good to add a test to verify the repository API before and after adding jmod files (something like _RemoteRepository.java but specific for file-system based repository) Mandy From chris.hegarty at oracle.com Tue Feb 7 03:05:52 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 Feb 2012 11:05:52 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F3019BA.9070000@oracle.com> References: <4F3019BA.9070000@oracle.com> Message-ID: <4F310590.3040806@oracle.com> This looks good. One minor comment; Should the arg passed to add-repo, if the scheme is unspecified, be checked to see if it is a directory? Or maybe this isn't all that useful ( it may be a dir, but not a valid repository ). The error handling in SimpleLibrary$RepoList.add could be more robust to handle this by removing the repoDir ( and its contents ) and possibly decrementing the count? Also (related) what is the point of appending the '/' in canonicalize? If the file url points to a file then it will not end in a '/', therefore it cannot be a valid repo, right? Should this be an error, or just handled as above? -Chris. On 02/ 6/12 06:19 PM, Alan Bateman wrote: > > The remote repository is currently limited to http. I've changed the > implementation so that other URIs can now be used, in particular file > URIs where the repository is on the file system. The webrev with the > changes is here: > > http://cr.openjdk.java.net/~alanb/jigsaw-localrepos/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Tue Feb 7 03:30:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Feb 2012 11:30:08 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F310590.3040806@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> Message-ID: <4F310B40.20906@oracle.com> On 07/02/2012 11:05, Chris Hegarty wrote: > This looks good. > > One minor comment; Should the arg passed to add-repo, if the scheme is > unspecified, be checked to see if it is a directory? Or maybe this > isn't all that useful ( it may be a dir, but not a valid repository ). When you add a repository then its catalog is fetched so it will fail if it's not a valid repository. > The error handling in SimpleLibrary$RepoList.add could be more robust > to handle this by removing the repoDir ( and its contents ) and > possibly decrementing the count? I agree the error handling should be more robust and it should rollback the changes but this is an existing problem. I'd prefer to separate it from this patch. I also think there is a lot more than could be done with the repository support, it's very much a prototype implementation at present. > > Also (related) what is the point of appending the '/' in canonicalize? > If the file url points to a file then it will not end in a '/', > therefore it cannot be a valid repo, right? Should this be an error, > or just handled as above? A trailing slash is required as otherwise the URI resolution will not work as expected (remember that URI resolution will concatenate all but the last segment of the URI's path). You are right that if a file path is specified and we convert it to a URI and so will have a trailing slash if a directory but this code has to work with other URI schemes too. -Alan From chris.hegarty at oracle.com Tue Feb 7 03:48:40 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 07 Feb 2012 11:48:40 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F310B40.20906@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> <4F310B40.20906@oracle.com> Message-ID: <4F310F98.4010207@oracle.com> Thanks for the explanations, these were just some minor observations, what you have in the webrev looks good to me. -Chris. On 02/ 7/12 11:30 AM, Alan Bateman wrote: > On 07/02/2012 11:05, Chris Hegarty wrote: >> This looks good. >> >> One minor comment; Should the arg passed to add-repo, if the scheme is >> unspecified, be checked to see if it is a directory? Or maybe this >> isn't all that useful ( it may be a dir, but not a valid repository ). > When you add a repository then its catalog is fetched so it will fail if > it's not a valid repository. > >> The error handling in SimpleLibrary$RepoList.add could be more robust >> to handle this by removing the repoDir ( and its contents ) and >> possibly decrementing the count? > I agree the error handling should be more robust and it should rollback > the changes but this is an existing problem. I'd prefer to separate it > from this patch. I also think there is a lot more than could be done > with the repository support, it's very much a prototype implementation > at present. > >> >> Also (related) what is the point of appending the '/' in canonicalize? >> If the file url points to a file then it will not end in a '/', >> therefore it cannot be a valid repo, right? Should this be an error, >> or just handled as above? > A trailing slash is required as otherwise the URI resolution will not > work as expected (remember that URI resolution will concatenate all but > the last segment of the URI's path). You are right that if a file path > is specified and we convert it to a URI and so will have a trailing > slash if a directory but this code has to work with other URI schemes too. > > -Alan From Alan.Bateman at oracle.com Tue Feb 7 08:51:49 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Feb 2012 16:51:49 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F305F55.3020207@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F305F55.3020207@oracle.com> Message-ID: <4F3156A5.9000703@oracle.com> On 06/02/2012 23:16, Mandy Chung wrote: > > Looks okay. It would be good to add a test to verify the repository > API before and after adding jmod files (something like > _RemoteRepository.java but specific for file-system based repository) > There's a test in the patch that installs modules from a file based repository but I agreed we could do more. If it's okay with you I push the current patch and put it on my ToDo list to change the repository tests to exercise both file and http repositories. -Alan. From mandy.chung at oracle.com Tue Feb 7 08:57:39 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 07 Feb 2012 08:57:39 -0800 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F3156A5.9000703@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F305F55.3020207@oracle.com> <4F3156A5.9000703@oracle.com> Message-ID: <4F315803.9090608@oracle.com> On 2/7/2012 8:51 AM, Alan Bateman wrote: > On 06/02/2012 23:16, Mandy Chung wrote: >> >> Looks okay. It would be good to add a test to verify the repository >> API before and after adding jmod files (something like >> _RemoteRepository.java but specific for file-system based repository) >> > There's a test in the patch that installs modules from a file based > repository but I agreed we could do more. If it's okay with you I push > the current patch and put it on my ToDo list to change the repository > tests to exercise both file and http repositories. That's okay with me. Mandy From alan.bateman at oracle.com Tue Feb 7 08:57:39 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Feb 2012 16:57:39 +0000 Subject: hg: jigsaw/jigsaw/jdk: Allow remote repository to be located via non-http URI Message-ID: <20120207165800.18F9C473BE@hg.openjdk.java.net> Changeset: d2aa5e849fe5 Author: alanb Date: 2012-02-07 16:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/d2aa5e849fe5 Allow remote repository to be located via non-http URI Reviewed-by: chegar, mchung ! src/share/classes/org/openjdk/jigsaw/RemoteRepository.java ! src/share/classes/org/openjdk/jigsaw/Resolution.java ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! src/share/classes/org/openjdk/jigsaw/cli/Librarian.java + test/org/openjdk/jigsaw/hello-repo.sh From Alan.Bateman at oracle.com Wed Feb 8 06:43:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Feb 2012 14:43:30 +0000 Subject: Review request: module-info class file update In-Reply-To: <4F2C4920.9050900@oracle.com> References: <4F2C4920.9050900@oracle.com> Message-ID: <4F328A12.9050608@oracle.com> On 03/02/2012 20:52, Mandy Chung wrote: > Jon and I are working together to update javac and runtime per the > latest language and class file specification for module declaration > [1]. Key changes include: > > 1. ModuleRequires attribute and ModuleProvides attribute > - use u4 flags and add SYNTHESIZED flag > 2. new CONSTANT_ModuleQuery_info > 3. exports > 4. default platform module is "jdk.base" > - will switch to "java.base" when the alias support is implemented > 5. The jar tool synthesizes "requires jdk.jre" in the generated > module-info > that is the entire JRE. If the legacy jar requires other modules, > it requires > to define its dependences properly. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/jvms-update.00/ > > Thanks > Mandy > [1] http://openjdk.java.net/projects/jigsaw/doc/lang-vm.html > > P.S. There is one javac failure we are currently diagnosing. I will > send a separate review for that issue once we resolve it as I believe > it's fairly isolated one. I went through the changes and they look fine to me. It's good to get the implementation sync'ed up. -Alan From Alan.Bateman at oracle.com Thu Feb 9 09:06:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Feb 2012 17:06:08 +0000 Subject: runtime changes for services In-Reply-To: <4EEB6998.6070005@oracle.com> References: <4EEB6998.6070005@oracle.com> Message-ID: <4F33FD00.20900@oracle.com> I'd like to get a first implementation of the runtime changes to support services in so that the API and other dependent changes can be worked on. The changes are relatively simple: 1. The class analyzer is updated to emit the requires/provides service declarations in the generated module-info files (see [1] for the output). The generation of module-info sources is of course short term as the module-info sources will ultimately be checked in with the source. 2. The resolver synthesizes an optional dependency on all modules that that suppliers of services. The dependency is optional to work with permits and also cases where a module has several versions installed and some, but not all, provide an implementation of the service. The linker is updated so that contexts that provide a service become service suppliers to modules that require the service. The set of service suppliers is separate to the normal set of supplying contexts and so requires additional maps in the configuration. 3. The ServiceLoader changes that were pushed a few days work with this patch. In module mode then calls to ServiceLoader.load and loadInstalled use the caller's module to determine the services to return. For now if invoked from a module that doesn't require the service then a ServiceLoader with an empty iterator is returned. 4. The jar tool has been updated so that when it is generates a module-info for a JAR file that contains META-INF/services then the module-info's provides attribute will declare the services. That's mostly it, there is clearly lots more to do (on the API in particular) but this is a first installation. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/index.html Thanks, Alan. [1] http://cr.openjdk.java.net/~alanb/jigsaw-services/moduleinfos.txt From jesse.glick at oracle.com Thu Feb 9 17:28:51 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 09 Feb 2012 20:28:51 -0500 Subject: Java platform imports not limited to declared dependencies Message-ID: <4F3472D3.3050405@oracle.com> As of my build of Jan 27, given ---%<--- src/org/hello/Main.java package org.hello; public class Main { public static void main(String[] args) { System.out.println(javax.xml.parsers.SAXParserFactory.newInstance()); } } ---%<--- src/module-info.java module org.hello @ 1 { requires jdk.base; class org.hello.Main; } ---%<--- if I run $ mkdir classes && javac -d classes src/org/hello/Main.java src/module-info.java it succeeds without complaint. My understanding was that this should be rejected unless I also said "requires jdk.jaxp;". Am I missing something? From jonathan.gibbons at oracle.com Thu Feb 9 17:53:10 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 09 Feb 2012 17:53:10 -0800 Subject: Java platform imports not limited to declared dependencies In-Reply-To: <4F3472D3.3050405@oracle.com> References: <4F3472D3.3050405@oracle.com> Message-ID: <4F347886.7030304@oracle.com> Jesse, javac makes no claim right now to enforce rules of accessibility and visibility, since the details are still being worked out. -- Jon On 02/09/2012 05:28 PM, Jesse Glick wrote: > As of my build of Jan 27, given > > ---%<--- src/org/hello/Main.java > package org.hello; > public class Main { > public static void main(String[] args) { > > System.out.println(javax.xml.parsers.SAXParserFactory.newInstance()); > } > } > ---%<--- src/module-info.java > module org.hello @ 1 { > requires jdk.base; > class org.hello.Main; > } > ---%<--- > > if I run > > $ mkdir classes && javac -d classes src/org/hello/Main.java > src/module-info.java > > it succeeds without complaint. My understanding was that this should > be rejected unless I also said "requires jdk.jaxp;". Am I missing > something? From jesse.glick at oracle.com Fri Feb 10 07:52:01 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 10 Feb 2012 10:52:01 -0500 Subject: Java platform imports not limited to declared dependencies In-Reply-To: <4F347886.7030304@oracle.com> References: <4F3472D3.3050405@oracle.com> <4F347886.7030304@oracle.com> Message-ID: <4F353D21.6050601@oracle.com> On 02/09/2012 08:53 PM, Jonathan Gibbons wrote: > javac makes no claim right now to enforce rules of accessibility and visibility OK. Is there some sort of status page where you can get a quick overview of what major features are planned and for each whether it is already implemented in jigsaw/jigsaw/* repos, in progress in a webrev, or not yet started? From Alan.Bateman at oracle.com Mon Feb 13 05:10:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2012 13:10:48 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F310B40.20906@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> <4F310B40.20906@oracle.com> Message-ID: <4F390BD8.1020405@oracle.com> On 07/02/2012 11:30, Alan Bateman wrote: > On 07/02/2012 11:05, Chris Hegarty wrote: > >> The error handling in SimpleLibrary$RepoList.add could be more robust >> to handle this by removing the repoDir ( and its contents ) and >> possibly decrementing the count? > I agree the error handling should be more robust and it should > rollback the changes but this is an existing problem. I'd prefer to > separate it from this patch. I also think there is a lot more than > could be done with the repository support, it's very much a prototype > implementation at present. > Just to follow up this discussion. The issue with not cleaning up after a failed attempt to add a remote repository is annoying so I've put a patch to fix it here: http://cr.openjdk.java.net/~alanb/jigsaw-reporollback/webrev/ I'll add tests to cover this and other scenarios where expanding the tests for this area (as per the discussion with Mandy). -Alan. From chris.hegarty at oracle.com Mon Feb 13 05:52:11 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Feb 2012 13:52:11 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F390BD8.1020405@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> <4F310B40.20906@oracle.com> <4F390BD8.1020405@oracle.com> Message-ID: <4F39158B.30107@oracle.com> This looks fine to me. Trivially, can the Files.move (RR.java L166 of new file) be moved into the first try-catch? I just can't see that the separate try-catch is necessary. -Chris. On 13/02/2012 13:10, Alan Bateman wrote: > On 07/02/2012 11:30, Alan Bateman wrote: >> On 07/02/2012 11:05, Chris Hegarty wrote: >> >>> The error handling in SimpleLibrary$RepoList.add could be more robust >>> to handle this by removing the repoDir ( and its contents ) and >>> possibly decrementing the count? >> I agree the error handling should be more robust and it should >> rollback the changes but this is an existing problem. I'd prefer to >> separate it from this patch. I also think there is a lot more than >> could be done with the repository support, it's very much a prototype >> implementation at present. >> > Just to follow up this discussion. The issue with not cleaning up after > a failed attempt to add a remote repository is annoying so I've put a > patch to fix it here: > > http://cr.openjdk.java.net/~alanb/jigsaw-reporollback/webrev/ > > I'll add tests to cover this and other scenarios where expanding the > tests for this area (as per the discussion with Mandy). > > -Alan. > > From Alan.Bateman at oracle.com Mon Feb 13 06:37:18 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Feb 2012 14:37:18 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F39158B.30107@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> <4F310B40.20906@oracle.com> <4F390BD8.1020405@oracle.com> <4F39158B.30107@oracle.com> Message-ID: <4F39201E.1000004@oracle.com> On 13/02/2012 13:52, Chris Hegarty wrote: > This looks fine to me. > > Trivially, can the Files.move (RR.java L166 of new file) be moved into > the first try-catch? I just can't see that the separate try-catch is > necessary. > > -Chris. The file needs to be closed before moving it into place. It could be done with an outer try-catch that does the recovery but instead it will require the try-with-resources to ensure that the file is closed before the move. -Alan From chris.hegarty at oracle.com Mon Feb 13 06:42:01 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 13 Feb 2012 14:42:01 +0000 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F39201E.1000004@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> <4F310B40.20906@oracle.com> <4F390BD8.1020405@oracle.com> <4F39158B.30107@oracle.com> <4F39201E.1000004@oracle.com> Message-ID: <4F392139.1000206@oracle.com> On 13/02/2012 14:37, Alan Bateman wrote: > On 13/02/2012 13:52, Chris Hegarty wrote: >> This looks fine to me. >> >> Trivially, can the Files.move (RR.java L166 of new file) be moved into >> the first try-catch? I just can't see that the separate try-catch is >> necessary. >> >> -Chris. > The file needs to be closed before moving it into place. It could be D'oh! I knew there was a reason, just couldn't see it. In which case, the change looks fine to me. -Chris. > done with an outer try-catch that does the recovery but instead it will > require the try-with-resources to ensure that the file is closed before > the move. > > -Alan From mandy.chung at oracle.com Mon Feb 13 12:16:23 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 13 Feb 2012 12:16:23 -0800 Subject: Allow remote repository to be located via non-http URI In-Reply-To: <4F390BD8.1020405@oracle.com> References: <4F3019BA.9070000@oracle.com> <4F310590.3040806@oracle.com> <4F310B40.20906@oracle.com> <4F390BD8.1020405@oracle.com> Message-ID: <4F396F97.1070400@oracle.com> On 2/13/2012 5:10 AM, Alan Bateman wrote: > Just to follow up this discussion. The issue with not cleaning up > after a failed attempt to add a remote repository is annoying so I've > put a patch to fix it here: > > http://cr.openjdk.java.net/~alanb/jigsaw-reporollback/webrev/ > Looks good. > > The file needs to be closed before moving it into place. It could be > done with an outer try-catch that does the recovery but instead it > will require the try-with-resources to ensure that the file is closed > before the move. Is it worth adding a comment in L166 to make this clear in the source? Thanks Mandy From mandy.chung at oracle.com Mon Feb 13 13:30:25 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 13 Feb 2012 21:30:25 +0000 Subject: hg: jigsaw/jigsaw/jdk: Runtime change for module-info.class spec update Message-ID: <20120213213105.A7934474B2@hg.openjdk.java.net> Changeset: 131130c69575 Author: mchung Date: 2012-02-13 12:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/131130c69575 Runtime change for module-info.class spec update Reviewed-by: alanb Spec update includes: 1. ModuleRequires attribute and ModuleProvides attribute - use u4 flags and add SYNTHESIZED flag 2. new CONSTANT_ModuleQuery_info 3. exports 4. default platform module is "jdk.base" - will switch to "java.base" when the alias support is implemented 5. The jar tool synthesizes "requires jdk.jre" in the generated module-info that is the entire JRE. If the legacy jar requires other modules, it requires to define its dependences properly. ! make/modules/modules.group ! make/tools/classanalyzer/classanalyzer.html ! make/tools/classanalyzer/src/com/sun/classanalyzer/BootAnalyzer.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ClassAnalyzer.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ConstantPoolParser.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/Module.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleBuilder.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleConfig.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleInfo.java ! src/share/classes/java/lang/module/Dependence.java ! src/share/classes/java/lang/module/ModuleInfoReader.java ! src/share/classes/java/lang/module/ServiceDependence.java ! src/share/classes/org/openjdk/jigsaw/ClassInfo.java ! src/share/classes/org/openjdk/jigsaw/Platform.java ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! src/share/classes/org/openjdk/jigsaw/cli/Commands.java ! src/share/classes/sun/tools/jar/ModuleInfo.java ! test/java/lang/module/_ModuleInfoReader.java ! test/java/lang/module/module-info-reader.sh ! test/org/openjdk/jigsaw/_Library.java ! test/org/openjdk/jigsaw/circular-deps.sh ! test/org/openjdk/jigsaw/hello-jar.sh ! test/org/openjdk/jigsaw/hello-native.sh ! test/org/openjdk/jigsaw/hello-optional.sh ! test/org/openjdk/jigsaw/hello-view.sh ! test/org/openjdk/jigsaw/hello.sh ! test/org/openjdk/jigsaw/library.sh ! test/org/openjdk/jigsaw/maze.sh ! test/org/openjdk/jigsaw/optional-base.sh ! test/org/openjdk/jigsaw/optional-deps.sh ! test/org/openjdk/jigsaw/optional-jaxp.sh ! test/org/openjdk/jigsaw/optional-reexport.sh ! test/org/openjdk/jigsaw/preinstall.sh ! test/org/openjdk/jigsaw/resolver.sh From mandy.chung at oracle.com Mon Feb 13 13:30:27 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Mon, 13 Feb 2012 21:30:27 +0000 Subject: hg: jigsaw/jigsaw/langtools: 32 new changesets Message-ID: <20120213213138.5FB68474B3@hg.openjdk.java.net> Changeset: 4e089d47de08 Author: jjg Date: 2012-01-10 13:57 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4e089d47de08 Convert to using new constant pool entry CONSTANT_ModuleQuery_info ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java Changeset: 47a73fdd0b86 Author: jjg Date: 2012-01-10 15:53 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/47a73fdd0b86 Convert to using java.base bade module ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/javax/lang/model/util/ModuleResolver.java Changeset: 3163ec6ee9d5 Author: jjg Date: 2012-01-12 14:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3163ec6ee9d5 fixes for base module and ModuleId ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/javax/lang/model/util/ModuleResolver.java Changeset: 1e684519d1f4 Author: jjg Date: 2012-01-12 19:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1e684519d1f4 converge on latest JVMS spec ! src/share/classes/com/sun/source/tree/RequiresFlag.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java ! src/share/classes/com/sun/tools/classfile/ModuleRequires_attribute.java ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 3b7197fe9d65 Author: jjg Date: 2012-01-14 11:41 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/3b7197fe9d65 write inherited exports in view ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java Changeset: 0c082bf0868a Author: jjg Date: 2012-01-15 11:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/0c082bf0868a fix order of directives ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: 6374e1768234 Author: jjg Date: 2012-01-19 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/6374e1768234 Rename ModuleIdQuery to ModuleQuery - src/share/classes/com/sun/source/tree/ModuleIdQueryTree.java + src/share/classes/com/sun/source/tree/ModuleQueryTree.java ! src/share/classes/com/sun/source/tree/RequiresModuleDirectiveTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Directive.java ! src/share/classes/com/sun/tools/javac/code/ModuleId.java - src/share/classes/com/sun/tools/javac/code/ModuleIdQuery.java + src/share/classes/com/sun/tools/javac/code/ModuleQuery.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawModuleResolver.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/javax/lang/model/element/ModuleElement.java Changeset: 0ec6fbf091f1 Author: jjg Date: 2012-01-19 15:48 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/0ec6fbf091f1 Merge ! src/share/classes/com/sun/tools/classfile/ModuleProvides_attribute.java Changeset: 79f268e1e047 Author: jjg Date: 2012-01-21 16:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/79f268e1e047 Rebuilding tests ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javac/modules/EntrypointTest01.java + test/tools/javac/modules/ExportTest01.java - test/tools/javac/modules/ModuleAccessTest01.java - test/tools/javac/modules/ModuleAnnotsTest01.java - test/tools/javac/modules/ModuleAttributeTest01.java - test/tools/javac/modules/ModuleClassAttributeTest01.java - test/tools/javac/modules/ModuleModeTests/DerbyTest.java - test/tools/javac/modules/ModuleModeTests/HelloAWTTest.java - test/tools/javac/modules/ModuleModeTests/HelloWorldTest.java - test/tools/javac/modules/ModuleModeTests/TestRunner.java - test/tools/javac/modules/ModuleModifierTest01.java - test/tools/javac/modules/ModulePathTest01.java - test/tools/javac/modules/ModulePathTest02.java - test/tools/javac/modules/ModulePermitsAttributeTest01.java - test/tools/javac/modules/ModuleProvidesAttributeTest01.java - test/tools/javac/modules/ModuleRequiresAttributeTest01.java - test/tools/javac/modules/ModuleResolverTest01.java - test/tools/javac/modules/ModuleResolverTest02.java - test/tools/javac/modules/ModuleResolverTest03.java - test/tools/javac/modules/ModuleResolverTest04.java - test/tools/javac/modules/ModuleResolverTest05.java - test/tools/javac/modules/ModuleVersionQueryTest01.java - test/tools/javac/modules/ModuleVersionTest01.java + test/tools/javac/modules/PermitsTest01.java + test/tools/javac/modules/ProvidesModuleTest01.java + test/tools/javac/modules/ProvidesServiceTest01.java + test/tools/javac/modules/RequiresModuleTest01.java + test/tools/javac/modules/RequiresServiceTest01.java Changeset: 4b4365ef7d35 Author: jjg Date: 2012-01-23 11:13 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/4b4365ef7d35 Mising file + src/share/classes/com/sun/tools/javac/comp/ModuleContext.java Changeset: b0bffeef4aef Author: jjg Date: 2012-01-23 19:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b0bffeef4aef add and consolidate tests ! src/share/classes/com/sun/tools/classfile/ModuleData_attribute.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/ModuleContext.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/modules/DirectiveTest.java ! test/tools/javac/modules/EntrypointTest01.java - test/tools/javac/modules/ExportTest01.java + test/tools/javac/modules/ExportsTest01.java ! test/tools/javac/modules/PermitsTest01.java ! test/tools/javac/modules/ProvidesModuleTest01.java ! test/tools/javac/modules/ProvidesServiceTest01.java ! test/tools/javac/modules/RequiresModuleTest01.java ! test/tools/javac/modules/RequiresServiceTest01.java + test/tools/javac/modules/ViewTest01.java Changeset: b42a126d943b Author: jjg Date: 2012-01-23 22:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b42a126d943b new test + test/tools/javac/modules/ModuleDataTest01.java Changeset: a960e0b6b464 Author: jjg Date: 2012-01-23 22:21 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/a960e0b6b464 clean up diagnostics, provide missing diagnostics ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/modules/ProvidesServiceTest01.java Changeset: 26d795d3ad30 Author: jjg Date: 2012-01-24 08:16 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/26d795d3ad30 test updates ! test/tools/javac/modules/DirectiveTest.java ! test/tools/javac/modules/RequiresServiceTest01.java ! test/tools/javac/modules/ViewTest01.java Changeset: 70a9a5da93ad Author: jjg Date: 2012-01-25 14:50 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/70a9a5da93ad More work on tests ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/modules/DirectiveTest.java ! test/tools/javac/modules/EntrypointTest01.java ! test/tools/javac/modules/ExportsTest01.java ! test/tools/javac/modules/ModuleDataTest01.java ! test/tools/javac/modules/PermitsTest01.java ! test/tools/javac/modules/ProvidesModuleTest01.java ! test/tools/javac/modules/ProvidesServiceTest01.java ! test/tools/javac/modules/RequiresModuleTest01.java ! test/tools/javac/modules/RequiresServiceTest01.java ! test/tools/javac/modules/ViewTest01.java Changeset: 7f728718a51b Author: mchung Date: 2012-01-25 14:10 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/7f728718a51b Merge with jigsaw-views ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java Changeset: 9dfe9d11fd65 Author: mchung Date: 2012-01-25 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/9dfe9d11fd65 support SYNTHETIC and SYNTHESIZED modifier ! src/share/classes/com/sun/tools/javac/jigsaw/JavacCatalog.java Changeset: 8dd76d134965 Author: mchung Date: 2012-01-25 15:45 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/8dd76d134965 Merge Changeset: df8e7bb69873 Author: jjg Date: 2012-01-25 18:01 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/df8e7bb69873 more checks, more diagnostcs, more tests ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java ! test/tools/javac/modules/DirectiveTest.java ! test/tools/javac/modules/EntrypointTest01.java ! test/tools/javac/modules/ProvidesServiceTest01.java Changeset: 1bf314a8162f Author: jjg Date: 2012-01-26 13:32 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/1bf314a8162f Temp. patch to use jdk.base instead of java.base until alias support is available ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: c71578e47a67 Author: jjg Date: 2012-01-26 16:18 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/c71578e47a67 make ClientCodeWrapper.wrap tolerant of null ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java Changeset: ab5a8f1c0b81 Author: jjg Date: 2012-01-26 17:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ab5a8f1c0b81 bug fix for entrypoint class check ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Modules.java Changeset: b9abee860658 Author: jjg Date: 2012-01-27 14:55 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/b9abee860658 add support for jdk.legacy, to be used when no module-info is available ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 51fb17abfc32 Author: mcimadamore Date: 2012-01-24 17:52 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/51fb17abfc32 7129801: Merge the two method applicability routines Summary: Resolve.java and Infer.java should reuse the same method applicability check routine Reviewed-by: dlsmith, jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java Changeset: ac36176b7de0 Author: jjh Date: 2012-01-24 15:51 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ac36176b7de0 7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/main/Main.java + test/tools/javah/T7126832/T7126832.java + test/tools/javah/T7126832/java.java Changeset: d16b464e742c Author: jjh Date: 2012-01-24 16:31 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d16b464e742c 7129225: javac fails to run annotation processors when star import of package of gensrc Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/7129225/Anno.java + test/tools/javac/7129225/AnnoProcessor.java + test/tools/javac/7129225/NegTest.ref + test/tools/javac/7129225/TestImportStar.java + test/tools/javac/7129225/TestImportStar.ref Changeset: 332dfa0f91df Author: jjh Date: 2012-01-25 12:20 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/332dfa0f91df 7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm Reviewed-by: jjg ! test/tools/javac/7129225/AnnoProcessor.java ! test/tools/javac/7129225/NegTest.ref ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref Changeset: f1201c124de0 Author: jjg Date: 2012-01-27 15:47 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f1201c124de0 Merge with TL ! .hgtags ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/javax/lang/model/element/Element.java Changeset: d46c6d0d9f80 Author: jjg Date: 2012-02-11 12:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/d46c6d0d9f80 fixes for full skip boot cycle build ! src/share/classes/com/sun/tools/javac/comp/Modules.java ! src/share/classes/com/sun/tools/javac/jigsaw/JigsawLibraryLocation.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/util/Debug.java Changeset: ebb12f0ae70f Author: jjg Date: 2012-02-11 12:09 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/ebb12f0ae70f fix javadoc errors ! src/share/classes/javax/tools/ExtendedLocation.java Changeset: abc83e4b419e Author: jjg Date: 2012-02-11 16:30 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/abc83e4b419e fix java.lang.UnsupportedOperationException from List ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java Changeset: 532038c25d55 Author: mchung Date: 2012-02-13 12:29 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/532038c25d55 Merge ! .hgtags - src/share/classes/com/sun/source/tree/ModuleIdQueryTree.java + src/share/classes/com/sun/source/tree/ModuleQueryTree.java - src/share/classes/com/sun/tools/javac/code/ModuleIdQuery.java + src/share/classes/com/sun/tools/javac/code/ModuleQuery.java From alan.bateman at oracle.com Tue Feb 14 03:48:03 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 14 Feb 2012 11:48:03 +0000 Subject: hg: jigsaw/jigsaw/jdk: Clean-up/recover when attempt to add remote repository fails Message-ID: <20120214114854.F239C474C1@hg.openjdk.java.net> Changeset: 115b3bb6de96 Author: alanb Date: 2012-02-14 11:47 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/115b3bb6de96 Clean-up/recover when attempt to add remote repository fails Reviewed-by: chegar, mchung ! src/share/classes/org/openjdk/jigsaw/RemoteRepository.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java From mandy.chung at oracle.com Tue Feb 14 11:31:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 14 Feb 2012 11:31:48 -0800 Subject: on the white board Message-ID: <4F3AB6A4.3090501@oracle.com> jdk.base exports java.util; exports java.util.PropertyChangeListener as java.beans.PropertyChangeListener; jdk.desktop (ghost) exports java.beans; requires public jdk.base; app (user) requires jdk.desktop; From david.holmes at oracle.com Tue Feb 14 18:45:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Feb 2012 12:45:46 +1000 Subject: on the white board In-Reply-To: <4F3AB6A4.3090501@oracle.com> References: <4F3AB6A4.3090501@oracle.com> Message-ID: <4F3B1C5A.8020802@oracle.com> On 15/02/2012 5:31 AM, Mandy Chung wrote: > jdk.base > exports java.util; > exports java.util.PropertyChangeListener as > java.beans.PropertyChangeListener; I hadn't seen a spec for schizophrenic types ;-) How do these work and why are they needed? Cheers, David > jdk.desktop (ghost) > exports java.beans; > requires public jdk.base; > > app (user) > requires jdk.desktop; > From mandy.chung at oracle.com Tue Feb 14 19:29:00 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 15 Feb 2012 03:29:00 +0000 Subject: hg: jigsaw/jigsaw/langtools: Delete old modules tests in changeset 1282: mismerge Message-ID: <20120215032904.9F068474DF@hg.openjdk.java.net> Changeset: f5edb3b919f0 Author: mchung Date: 2012-02-14 19:28 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/f5edb3b919f0 Delete old modules tests in changeset 1282: mismerge - test/tools/javac/modules/ModuleAccessTest01.java - test/tools/javac/modules/ModuleAnnotsTest01.java - test/tools/javac/modules/ModuleAttributeTest01.java - test/tools/javac/modules/ModuleClassAttributeTest01.java - test/tools/javac/modules/ModuleModeTests/DerbyTest.java - test/tools/javac/modules/ModuleModeTests/HelloAWTTest.java - test/tools/javac/modules/ModuleModeTests/HelloWorldTest.java - test/tools/javac/modules/ModuleModeTests/TestRunner.java - test/tools/javac/modules/ModuleModifierTest01.java - test/tools/javac/modules/ModulePathTest01.java - test/tools/javac/modules/ModulePathTest02.java - test/tools/javac/modules/ModulePermitsAttributeTest01.java - test/tools/javac/modules/ModuleProvidesAttributeTest01.java - test/tools/javac/modules/ModuleRequiresAttributeTest01.java - test/tools/javac/modules/ModuleResolverTest01.java - test/tools/javac/modules/ModuleResolverTest02.java - test/tools/javac/modules/ModuleResolverTest03.java - test/tools/javac/modules/ModuleResolverTest04.java - test/tools/javac/modules/ModuleResolverTest05.java - test/tools/javac/modules/ModuleVersionQueryTest01.java - test/tools/javac/modules/ModuleVersionTest01.java From chris.hegarty at oracle.com Wed Feb 15 03:49:36 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Feb 2012 11:49:36 +0000 Subject: RFR: Superfluous classes archive created for modules with no files Message-ID: <4F3B9BD0.1020109@oracle.com> Hi, There is an incorrect assertion in the SimpleLibrary resource location code, loadContent(). Essentially it expects an installed module to always have a 'classes' archive. This may not always be the case, e.g. 'jdk' & 'jdk.jre'. This wasn't noticed before, at least in the system library, as modules installed using 'jmod install -L classes' actually creates an empty classes jar archive. Example, >: ../bin/jmod create -L m.lib >: ../bin/jmod install -L m.lib ../modules/jdk/classes jdk >: ls m.lib/jdk/8-ea . .. classes index info >: unzip -l m.lib/jdk/8-ea/classes Archive: m.lib/jdk/8-ea/classes warning [m.lib/jdk/8-ea/classes]: zipfile is empty This is not the case when the module is install from the jmod file, i.e. no 'classes' archive is created if there are no classes or resources in the jmod file. Example, >: ../bin/jmod create -L m.lib >: ../bin/jmod install -L m.lib ../jigsaw-pkgs/jmod/jdk at 8-ea.jmod >: ls m.lib/jdk/8-ea . .. index info The solution is to simply remove the incorrect assertion and change the installer so that it only creates a 'classes' archive if it is needed. http://cr.openjdk.java.net/~chegar/jigsaw/classless_webrev.00/webrev/ Thanks, -Chris. From Alan.Bateman at oracle.com Wed Feb 15 04:23:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 12:23:44 +0000 Subject: RFR: Superfluous classes archive created for modules with no files In-Reply-To: <4F3B9BD0.1020109@oracle.com> References: <4F3B9BD0.1020109@oracle.com> Message-ID: <4F3BA3D0.7070406@oracle.com> On 15/02/2012 11:49, Chris Hegarty wrote: > Hi, > > There is an incorrect assertion in the SimpleLibrary resource location > code, loadContent(). Essentially it expects an installed module to > always have a 'classes' archive. This may not always be the case, e.g. > 'jdk' & 'jdk.jre'. > > This wasn't noticed before, at least in the system library, as modules > installed using 'jmod install -L classes' actually creates an > empty classes jar archive. Example, > >: ../bin/jmod create -L m.lib > >: ../bin/jmod install -L m.lib ../modules/jdk/classes jdk > >: ls m.lib/jdk/8-ea > . .. classes index info > >: unzip -l m.lib/jdk/8-ea/classes > Archive: m.lib/jdk/8-ea/classes > warning [m.lib/jdk/8-ea/classes]: zipfile is empty > > This is not the case when the module is install from the jmod file, > i.e. no 'classes' archive is created if there are no classes or > resources in the jmod file. Example, > >: ../bin/jmod create -L m.lib > >: ../bin/jmod install -L m.lib ../jigsaw-pkgs/jmod/jdk at 8-ea.jmod > >: ls m.lib/jdk/8-ea > . .. index info > > The solution is to simply remove the incorrect assertion and change > the installer so that it only creates a 'classes' archive if it is > needed. > > http://cr.openjdk.java.net/~chegar/jigsaw/classless_webrev.00/webrev/ Is this causing a problem or is it just the warning from unzip? I remember Dave Bristor pushed several changes to ensure that the empty zip case was handled and I'm just wondering if something was missed. As regards the change then I think listFiles would be nicer if it returned a List rather than populated the given collection, ie: List files = listAll(src.toPath()); What would you about removing Files.copy(File,OutputStream) from org.openjdk.jigsaw.Files and using java.nio.file.Files.copy(Path,OutputStream). That would avoid some of the conversion in this case. One difference to be aware of is that Files.copy(Path,OutputStream) does not close the output stream. The rational for this is for the "cat f1 f2 f2 > out" type case. Minor comment is just to check that the style is consistent (indentation of "throws IOException" and use of curly braces with single statements). -Alan. From chris.hegarty at oracle.com Wed Feb 15 06:09:59 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Feb 2012 14:09:59 +0000 Subject: RFR: Superfluous classes archive created for modules with no files In-Reply-To: <4F3BA3D0.7070406@oracle.com> References: <4F3B9BD0.1020109@oracle.com> <4F3BA3D0.7070406@oracle.com> Message-ID: <4F3BBCB7.5070604@oracle.com> On 15/02/2012 12:23, Alan Bateman wrote: > ... > Is this causing a problem or is it just the warning from unzip? I > remember Dave Bristor pushed several changes to ensure that the empty > zip case was handled and I'm just wondering if something was missed. This causes a problem. The assert is fired. I noticed this issue while working on creating the module images from jmod files ( I hope to publish a webrev for this later in the week ). It is an obvious difference between the images created by installing from "classes", rather than jmod files, and causes the resource test to fail (since jdk and jdk.jre will not have a classes archive when installed from jmod file). > As regards the change then I think listFiles would be nicer if it > returned a List rather than populated the given collection, ie: > List files = listAll(src.toPath()); > > What would you about removing Files.copy(File,OutputStream) from > org.openjdk.jigsaw.Files and using > java.nio.file.Files.copy(Path,OutputStream). That would avoid some of > the conversion in this case. One difference to be aware of is that > Files.copy(Path,OutputStream) does not close the output stream. The > rational for this is for the "cat f1 f2 f2 > out" type case. > > Minor comment is just to check that the style is consistent (indentation > of "throws IOException" and use of curly braces with single statements). Updated webrev incorporating the above comments: http://cr.openjdk.java.net/~chegar/jigsaw/classless_webrev.01/webrev/ -Chris. > > -Alan. > > > > > > > > > From Alan.Bateman at oracle.com Wed Feb 15 07:41:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 15:41:38 +0000 Subject: RFR: Superfluous classes archive created for modules with no files In-Reply-To: <4F3BBCB7.5070604@oracle.com> References: <4F3B9BD0.1020109@oracle.com> <4F3BA3D0.7070406@oracle.com> <4F3BBCB7.5070604@oracle.com> Message-ID: <4F3BD232.8000905@oracle.com> On 15/02/2012 14:09, Chris Hegarty wrote: > : > > Updated webrev incorporating the above comments: > > http://cr.openjdk.java.net/~chegar/jigsaw/classless_webrev.01/webrev/ > The updated webrev looks fine to me. I assume I need to push this for you. -Alan From chris.hegarty at oracle.com Wed Feb 15 07:45:44 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Feb 2012 15:45:44 +0000 Subject: RFR: Superfluous classes archive created for modules with no files In-Reply-To: <4F3BD232.8000905@oracle.com> References: <4F3B9BD0.1020109@oracle.com> <4F3BA3D0.7070406@oracle.com> <4F3BBCB7.5070604@oracle.com> <4F3BD232.8000905@oracle.com> Message-ID: <4F3BD328.6010305@oracle.com> On 15/02/2012 15:41, Alan Bateman wrote: > On 15/02/2012 14:09, Chris Hegarty wrote: >> : >> >> Updated webrev incorporating the above comments: >> >> http://cr.openjdk.java.net/~chegar/jigsaw/classless_webrev.01/webrev/ >> > The updated webrev looks fine to me. I assume I need to push this for you. Thanks Alan, this would be great. -Chris. > > -Alan > From jonathan.gibbons at oracle.com Wed Feb 15 11:58:44 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 15 Feb 2012 19:58:44 +0000 Subject: hg: jigsaw/jigsaw/langtools: new ClassReaderTest01.java Message-ID: <20120215195850.4417F474FB@hg.openjdk.java.net> Changeset: 02c4a813fe26 Author: jjg Date: 2012-02-15 11:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/02c4a813fe26 new ClassReaderTest01.java + test/tools/javac/modules/ClassReaderTest01.java From alexey.x.fedorov at oracle.com Wed Feb 15 11:59:30 2012 From: alexey.x.fedorov at oracle.com (Alexey Fedorov) Date: Wed, 15 Feb 2012 23:59:30 +0400 Subject: Spacebars are missed in ServiceDependence.toString() Message-ID: <4F3C0EA2.6050406@oracle.com> Hi all, I am playing with Jigsaw and found the following small bug: method ServiceDependence.toString() contains modifier without any spacebars between them. Set modifiers = new HashSet<>(Arrays.asList(OPTIONAL, PUBLIC)); ServiceDependence sd = new ServiceDependence(modifiers, "my.service"); sd.toString returns: > requires serviceoptionalpublic my.service but expected something like: > requires service optional public my.service Seems like small bug :) -- Thank you, Alexey From Alan.Bateman at oracle.com Wed Feb 15 12:05:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 Feb 2012 20:05:11 +0000 Subject: Spacebars are missed in ServiceDependence.toString() In-Reply-To: <4F3C0EA2.6050406@oracle.com> References: <4F3C0EA2.6050406@oracle.com> Message-ID: <4F3C0FF7.9000103@oracle.com> On 15/02/2012 19:59, Alexey Fedorov wrote: > Hi all, > > I am playing with Jigsaw and found the following small bug: method > ServiceDependence.toString() contains modifier without any spacebars > between them. > > Set modifiers = new > HashSet<>(Arrays.asList(OPTIONAL, PUBLIC)); > ServiceDependence sd = new ServiceDependence(modifiers, "my.service"); > > sd.toString returns: > >> requires serviceoptionalpublic my.service > > but expected something like: > >> requires service optional public my.service > > Seems like small bug :) I noticed this too and it's fixed in the services implementation [1], just not pushed yet. -Alan. [1] http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/ From alan.bateman at oracle.com Wed Feb 15 12:07:44 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 15 Feb 2012 20:07:44 +0000 Subject: hg: jigsaw/jigsaw/jdk: Superfluous classes archive created for modules with no files Message-ID: <20120215200819.94141474FC@hg.openjdk.java.net> Changeset: 2c2b55c87c8c Author: chegar Date: 2012-02-15 20:07 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/2c2b55c87c8c Superfluous classes archive created for modules with no files Reviewed-by: alanb ! src/share/classes/org/openjdk/jigsaw/Files.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! test/org/openjdk/jigsaw/resource.sh From alexey.x.fedorov at oracle.com Wed Feb 15 12:22:09 2012 From: alexey.x.fedorov at oracle.com (Alexey Fedorov) Date: Thu, 16 Feb 2012 00:22:09 +0400 Subject: Spacebars are missed in ServiceDependence.toString() In-Reply-To: <4F3C0FF7.9000103@oracle.com> References: <4F3C0EA2.6050406@oracle.com> <4F3C0FF7.9000103@oracle.com> Message-ID: <4F3C13F1.2070600@oracle.com> Thank you, Alan! http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/src/share/classes/java/lang/module/ServiceDependence.java.udiff.html - that's exactly what I meant! -- Have a good day, Alexey On 16-Feb-12 0:05, Alan Bateman wrote: > On 15/02/2012 19:59, Alexey Fedorov wrote: >> Hi all, >> >> I am playing with Jigsaw and found the following small bug: method >> ServiceDependence.toString() contains modifier without any spacebars >> between them. >> >> Set modifiers = new >> HashSet<>(Arrays.asList(OPTIONAL, PUBLIC)); >> ServiceDependence sd = new ServiceDependence(modifiers, "my.service"); >> >> sd.toString returns: >> >>> requires serviceoptionalpublic my.service >> >> but expected something like: >> >>> requires service optional public my.service >> >> Seems like small bug :) > I noticed this too and it's fixed in the services implementation [1], > just not pushed yet. > > -Alan. > > [1] http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/ From mandy.chung at oracle.com Wed Feb 15 15:04:04 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2012 15:04:04 -0800 Subject: runtime changes for services In-Reply-To: <4F33FD00.20900@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> Message-ID: <4F3C39E4.6030701@oracle.com> Alan, The new module-info.java files with services look good. This changeset looks good as the first installation. I view "requires service S" as expanded to a set of requires clauses on the module view that provides S at install time. For example, module M { requires service S; } If there are 3 different modules PS1, PS2, PS3 providing the implementation of service S, it'd be like: module M { requires PS1; requires PS2; requires PS3; } assuming there is no conflict among these dependencies. Synthesizing view dependencies makes sense to me. The synthesized dependency with no version query (Resolver.java L327) leads me to rethink and wonder if the resolver has to take services as a constraint. module M { requires MS; requires service S; } module MS @ 2.0 { // no provides service S } module MS @ 1.0 { provides service S with Impl; } The synthesized dependency is "requires MS" with no version query. What would happen in this case? I suspect the resolver will fail as it chooses MS at 2.0 but it doesn't provide service S. As sthe ensureServicesPresent() method will catch if there is any service dependency not satisfied, this might be adequate. This seems to be a discussion point for later. On 2/9/2012 9:06 AM, Alan Bateman wrote: > http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/index.html com/sun/classanalyzer/ModuleInfo.java L46: you're right that it needs to make a defensive copy of services and providers. L45 makes a copy of the requires and put it in a TreeSet so that ModuleInfo.getRequires() returns an ordered set for writing to module-info.java. L155-172: would it be better to sort the list before printing the "requires services" statements? I believe the ordering of "provides service" statements matters and so it should keep it the same order as specified in the META-INF/services files. java/util/ServiceLoader.java L357-359: for maintainability, would it be better to replace these lines with if (!hasNext()) { throw new NoSuchElementException(); } org/openjdk/jigsaw/Context.java L173, 203: I assume you want to fix these methods to return a unmodifiable map, right? I don't see the code that expects them to be modifiable (maybe I miss something)? org/openjdk/jigsaw/Linker.java L296: extra blank line org/openjdk/jigsaw/Loader.java L286-289: can these lines be replaced with: Set remotes = context.serviceSuppliers().get(cn); L278: I wonder if this should return a map of ModuleClassLoader rather than ClassLoader just be explicit. L291: this causes the module loader for the service implementation class be instantiated. I presume we want the loader be instantiated lazily when it's loaded. On the other hand, the instantiation cost doesn't look like too high. It's fine for the initial implementation but we should look into this open issue. org/openjdk/jigsaw/Resolver.java L320,322,323, 338: a space below ":" There are other places missing the space in the foreach statements needed fixing too. sun/tools/jar/Main.java L785: would you suggest to replace Charset.forName("UTF-8") with StandardCharsets.UTF_8 (no real difference though)? L989: This is not really a question for this change but you may have the answer. I have seen some copy of readAllBytes in other places. Have we considered adding this support to the platform? new services tests Looks good. The copyright start year should be 2012 :) I notice that some tests turn on assertion but some don't. It might be good to set -esa -ea on all tests I think. Mandy From david.holmes at oracle.com Wed Feb 15 21:42:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Feb 2012 15:42:49 +1000 Subject: runtime changes for services In-Reply-To: <4F3C39E4.6030701@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> Message-ID: <4F3C9759.9010903@oracle.com> On 16/02/2012 9:04 AM, Mandy Chung wrote: > The new module-info.java files with services look good. This > changeset looks good as the first installation. > > I view "requires service S" as expanded to a set of requires > clauses on the module view that provides S at install time. > For example, > module M { > requires service S; > } > > If there are 3 different modules PS1, PS2, PS3 providing the > implementation of service S, it'd be like: > module M { > requires PS1; > requires PS2; > requires PS3; > } Do you mean that PS1, PS2 and PS3 all combine to provide service S? Or that they each provide service S? David ----- > assuming there is no conflict among these dependencies. > Synthesizing view dependencies makes sense to me. > > The synthesized dependency with no version query (Resolver.java > L327) leads me to rethink and wonder if the resolver has to take > services as a constraint. > > module M { > requires MS; > requires service S; > } > > module MS @ 2.0 { > // no provides service S > } > module MS @ 1.0 { > provides service S with Impl; > } > > The synthesized dependency is "requires MS" with no version > query. What would happen in this case? I suspect the resolver > will fail as it chooses MS at 2.0 but it doesn't provide service S. > As sthe ensureServicesPresent() method will catch if there is > any service dependency not satisfied, this might be adequate. > This seems to be a discussion point for later. > > On 2/9/2012 9:06 AM, Alan Bateman wrote: >> http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/index.html > com/sun/classanalyzer/ModuleInfo.java > L46: you're right that it needs to make a defensive copy > of services and providers. L45 makes a copy of the requires > and put it in a TreeSet so that ModuleInfo.getRequires() > returns an ordered set for writing to module-info.java. > > L155-172: would it be better to sort the list before printing > the "requires services" statements? I believe the ordering of > "provides service" statements matters and so it should keep > it the same order as specified in the META-INF/services files. > > java/util/ServiceLoader.java > L357-359: for maintainability, would it be better to replace > these lines with > if (!hasNext()) { > throw new NoSuchElementException(); > } > > org/openjdk/jigsaw/Context.java > L173, 203: I assume you want to fix these methods to return a > unmodifiable map, right? I don't see the code that expects > them to be modifiable (maybe I miss something)? > > org/openjdk/jigsaw/Linker.java > L296: extra blank line > > org/openjdk/jigsaw/Loader.java > L286-289: can these lines be replaced with: > Set remotes = context.serviceSuppliers().get(cn); > > L278: I wonder if this should return a map of ModuleClassLoader > rather than ClassLoader just be explicit. > > L291: this causes the module loader for the service > implementation class be instantiated. I presume we want > the loader be instantiated lazily when it's loaded. On > the other hand, the instantiation cost doesn't look like > too high. It's fine for the initial implementation but > we should look into this open issue. > > org/openjdk/jigsaw/Resolver.java > L320,322,323, 338: a space below ":" > There are other places missing the space in the foreach > statements needed fixing too. > > sun/tools/jar/Main.java > L785: would you suggest to replace Charset.forName("UTF-8") > with StandardCharsets.UTF_8 (no real difference though)? > L989: This is not really a question for this change but > you may have the answer. I have seen some copy of readAllBytes > in other places. Have we considered adding this support > to the platform? > > new services tests > Looks good. The copyright start year should be 2012 :) > I notice that some tests turn on assertion but some don't. > It might be good to set -esa -ea on all tests I think. > > Mandy > From mandy.chung at oracle.com Wed Feb 15 21:52:34 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 15 Feb 2012 21:52:34 -0800 Subject: runtime changes for services In-Reply-To: <4F3C9759.9010903@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> Message-ID: <4F3C99A2.9040907@oracle.com> On 2/15/2012 9:42 PM, David Holmes wrote: >> >> If there are 3 different modules PS1, PS2, PS3 providing the >> implementation of service S, it'd be like: >> module M { >> requires PS1; >> requires PS2; >> requires PS3; >> } > > Do you mean that PS1, PS2 and PS3 all combine to provide service S? Or > that they each provide service S? The latter. Mandy From david.holmes at oracle.com Wed Feb 15 22:10:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Feb 2012 16:10:04 +1000 Subject: runtime changes for services In-Reply-To: <4F3C99A2.9040907@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> <4F3C99A2.9040907@oracle.com> Message-ID: <4F3C9DBC.3030709@oracle.com> On 16/02/2012 3:52 PM, Mandy Chung wrote: > On 2/15/2012 9:42 PM, David Holmes wrote: >>> >>> If there are 3 different modules PS1, PS2, PS3 providing the >>> implementation of service S, it'd be like: >>> module M { >>> requires PS1; >>> requires PS2; >>> requires PS3; >>> } >> >> Do you mean that PS1, PS2 and PS3 all combine to provide service S? Or >> that they each provide service S? > > The latter. Then in that case don't you want those requires clauses to be a disjunction rather than a conjunction? Else it appears M requires all three implementations of service S. David > Mandy From Alan.Bateman at oracle.com Thu Feb 16 02:21:35 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Feb 2012 10:21:35 +0000 Subject: runtime changes for services In-Reply-To: <4F3C9DBC.3030709@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> <4F3C99A2.9040907@oracle.com> <4F3C9DBC.3030709@oracle.com> Message-ID: <4F3CD8AF.2020709@oracle.com> On 16/02/2012 06:10, David Holmes wrote: > On 16/02/2012 3:52 PM, Mandy Chung wrote: >> On 2/15/2012 9:42 PM, David Holmes wrote: >>>> >>>> If there are 3 different modules PS1, PS2, PS3 providing the >>>> implementation of service S, it'd be like: >>>> module M { >>>> requires PS1; >>>> requires PS2; >>>> requires PS3; >>>> } >>> >>> Do you mean that PS1, PS2 and PS3 all combine to provide service S? Or >>> that they each provide service S? >> >> The latter. > > Then in that case don't you want those requires clauses to be a > disjunction rather than a conjunction? Else it appears M requires all > three implementations of service S. In this first version then "requires service S" is essentially treated by the resolver as: requires optional S1; requires optional S2; requires optional S3; where at least one version of S1, S2, and S3 provide one or more implementation of S. It's done this way for now solely for performance reasons. I've gone through several iterations where providing the service was an additional constraint but the performance wasn't satisfactory. It needs further work and I think should be done in conjunction with more extensive work on the resolver. The reason it's optional is because there may not be a version of S1 that can be used (because of "permits" or because of other constraints that involve module that provide implementations of service types). Anyway, to your question, it may be that only a version of S2 and S3 are chosen and the implementations of S that they provide will be returned by the ServiceLoader's iterator. -Alan. From jesse.glick at oracle.com Thu Feb 16 07:07:16 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 16 Feb 2012 10:07:16 -0500 Subject: Mandatory service requirement (was: runtime changes for services) In-Reply-To: <4F3CD8AF.2020709@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> <4F3C99A2.9040907@oracle.com> <4F3C9DBC.3030709@oracle.com> <4F3CD8AF.2020709@oracle.com> Message-ID: <4F3D1BA4.5020407@oracle.com> On 02/16/2012 05:21 AM, Alan Bateman wrote: > "requires service S" is essentially treated by the resolver as: > > requires optional S1; > requires optional S2; > requires optional S3; Consider just dropping mandatory service requirement, i.e. let a module which declares that it requires a particular service just load whatever providers happen to be available for other reasons, such as because an overarching "application" module required the providing module directly (I suppose like what "requires optional service" would do). The NetBeans module system permits modules to declare that they provide and require named tokens, where the token is often by convention a service class name. Initially it seemed like a good idea for a module which loads a service to declare that it requires that some provider of this service be present. In practice this has proven to be more harmful than helpful, leading us to start removing these require clauses: 1. The section of a module which loads the service might never actually be called for a given use case. For example, one package might use a service but the application only uses another package which does not. Or the module might be referenced merely for some utility method. 2. It is generally just as easy to write the module to behave gracefully when no provider is found (and you may need to do this anyway for the benefit of tests). If all providers of a given service are iterated, an empty loop usually has sane semantics. If just the first one (*) is used, the calling module can often substitute a skeletal no-op implementation; or at worst throw a documented error or exception. 3. A given application probably does not need every provider of a service to be loaded; there is likely to be a set of known and tested providers. The decoupling at the module level is beneficial as it makes the modules reusable, and it ought to be easy for an app developer or user to add a module with an extra provider, but mere presence in the repository should not magically trigger this. 4. Token-based dependencies like this can be difficult to translate into other module or packaging or repository systems. 5. Disjunctive dependencies complicate resolver semantics. In the NetBeans module system if there are several providers of a token and a module requires it, all the providers which _could_ be loaded _are_ loaded (together with their own dependencies), and then the requirer is loaded so long as at least one provider was as well. This behavior has been responsible for a lot of bugs and corner cases when combined with other constraints. 6. Token requirements will often lead to cycles in the dependency graph, as a module defining an SPI and matching API declares that it requires some provider of the SPI. In NetBeans module enablement order follows a topological sort and cycles are forbidden, leading to the introduction of an alternate form of the require clause ("needs") which does not affect order (and more complexity in the resolver). Jigsaw permits cycles but this ought to be limited to modularization of legacy code; if you ever want to support things like dynamically unloading modules it is much easier if there are no cycles. For that matter, you could probably drop the need to declare that a service is used at all: if and when ServiceLoader is called, determine the providers - if not precomputed in the repository - and load them. Of course you cannot compatibly reverse this decision, since older modules might "unexpectedly" load a service and there is no way of upgrading them except to grep the sources for calls to ServiceLoader.load(Literal.class) under the assumption that this is the only calling pattern. (*) Though ServiceLoader has no means of imposing an ordering on services. You can add a method returning a sort key to the service interface itself if you do not mind eagerly loading all implementations. The NetBeans equivalent (MetaInfServicesLookup) supports a static sort key to avoid this. From david.lloyd at redhat.com Thu Feb 16 09:33:56 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 16 Feb 2012 11:33:56 -0600 Subject: on the white board In-Reply-To: <4F3B1C5A.8020802@oracle.com> References: <4F3AB6A4.3090501@oracle.com> <4F3B1C5A.8020802@oracle.com> Message-ID: <4F3D3E04.6050305@redhat.com> On 02/14/2012 08:45 PM, David Holmes wrote: > On 15/02/2012 5:31 AM, Mandy Chung wrote: >> jdk.base >> exports java.util; >> exports java.util.PropertyChangeListener as >> java.beans.PropertyChangeListener; > > I hadn't seen a spec for schizophrenic types ;-) How do these work and > why are they needed? I too am interested in an explanation of what this is. -- - DML From mark.reinhold at oracle.com Thu Feb 16 13:30:13 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Feb 2012 13:30:13 -0800 Subject: on the white board In-Reply-To: david.lloyd@redhat.com; Thu, 16 Feb 2012 11:33:56 CST; <4F3D3E04.6050305@redhat.com> Message-ID: <20120216213013.A0547DC0@eggemoggin.niobe.net> 2012/2/16 9:33 -0800, david.lloyd at redhat.com: > On 02/14/2012 08:45 PM, David Holmes wrote: >> On 15/02/2012 5:31 AM, Mandy Chung wrote: >>> jdk.base >>> exports java.util; >>> exports java.util.PropertyChangeListener as >>> java.beans.PropertyChangeListener; >> >> I hadn't seen a spec for schizophrenic types ;-) How do these work and >> why are they needed? > > I too am interested in an explanation of what this is. A few of us were having an informal conversation about whether it'd be worth having a way to declare that one class is an alias for another, as a way to allow for existing APIs to be refactored without breaking old code. It turns out to get very complicated very quickly, so I doubt we'll pursue anything like this in the near future. - Mark From jesse.glick at oracle.com Thu Feb 16 14:41:33 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Thu, 16 Feb 2012 17:41:33 -0500 Subject: API refactoring (was: on the white board) In-Reply-To: <20120216213013.A0547DC0@eggemoggin.niobe.net> References: <20120216213013.A0547DC0@eggemoggin.niobe.net> Message-ID: <4F3D861D.5090303@oracle.com> On 02/16/2012 04:30 PM, mark.reinhold at oracle.com wrote: > It turns out to get very complicated very quickly Perhaps this kind of thing could be delegated to libraries rather than baked into the module system, as way to manage the complexity. An API-exporting module could declare a class implementing java.lang.instrument.ClassFileTransformer which would be given a chance to fix up classes in modules depending on it. A helper library based on something like ASM could offer convenient transformations such as renaming a class, rewriting usages of a method, etc. In fact the same system would be very useful for libraries which require bytecode transformation for reasons other than backward compatibility, such as JMockit or AspectJ or RIFE/Continuations, which currently require you to either manually specify -agent when running or perform a build-time transformation. From mandy.chung at oracle.com Thu Feb 16 17:17:54 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 17 Feb 2012 01:17:54 +0000 Subject: hg: jigsaw/jigsaw/jdk: jdk.ucrypto should be required Message-ID: <20120217011835.AB17047530@hg.openjdk.java.net> Changeset: 1c3bbdc93d5d Author: chegar Date: 2012-02-16 21:56 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/1c3bbdc93d5d jdk.ucrypto should be required ! make/com/oracle/security/ucrypto/Makefile ! make/modules/modules.group From chris.hegarty at oracle.com Fri Feb 17 01:35:56 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Feb 2012 09:35:56 +0000 Subject: RFR: Building jre/jdk images from jmod files Message-ID: <4F3E1F7C.9040601@oracle.com> This is a follow up to the work for supporting native libraries and commands outside the module library. The issue is that we previously could not (reasonably) create the module images from jmod files. The reason is that the native libraries and config files were not being put into the correct section of the jmod files. For example, on Windows the dll's and exe's were put into the NATIVE_CMDS section. Setting --natlib on Windows and installing would not effect where the dll's get installed. Since the post processing construction of the modules will eventually be replaced, I didn't want to spend too much time rewriting much of the makefile, instead I guess you could say this is a little bit of a cheat! Unix, Basically, anything put into the build lib/(LIBARCH) directory can be considered a native library, or jvm.cfg/Xusage.txt/debuginfo which are closely related and therefore packaged with NATIVE_LIBS. Everything else in the build lib directory, *.properties, *.data, *.policy, tz data, fonts, go into the CONFIG section. Native commands go into NATIVE_CMDS. Windows Since the dll's and exe's are created and put in the build bin directory, I simply modified the makefiles to know they are dealing with a native command and put it into the modules bin dir, then everything else in the build bin directory must be a native lib ( or closely related pdb/map/etc). Now the contents of the build lib directory are simply *.properties, *.data, *.policy, tz data, fonts, go into the CONFIG section. I verified that module images built with the changes are the same as without. Additionally, BUILD_PACKAGES=false still works ( for faster builds ). http://cr.openjdk.java.net/~chegar/jigsaw/jmods_webrev.00/webrev/ Thanks, -Chris. From Alan.Bateman at oracle.com Fri Feb 17 07:23:33 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Feb 2012 15:23:33 +0000 Subject: Mandatory service requirement In-Reply-To: <4F3D1BA4.5020407@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> <4F3C99A2.9040907@oracle.com> <4F3C9DBC.3030709@oracle.com> <4F3CD8AF.2020709@oracle.com> <4F3D1BA4.5020407@oracle.com> Message-ID: <4F3E70F5.2060302@oracle.com> On 16/02/2012 15:07, Jesse Glick wrote: > > Consider just dropping mandatory service requirement, i.e. let a > module which declares that it requires a particular service just load > whatever providers happen to be available for other reasons, such as > because an overarching "application" module required the providing > module directly (I suppose like what "requires optional service" would > do). For cases where there isn't a default/fallback implementation and where any provider implementation will suffice, then I think it would be preferable to catch such issues at install time rather than failing at runtime. > : > > For that matter, you could probably drop the need to declare that a > service is used at all: if and when ServiceLoader is called, determine > the providers - if not precomputed in the repository - and load them. > Of course you cannot compatibly reverse this decision, since older > modules might "unexpectedly" load a service and there is no way of > upgrading them except to grep the sources for calls to > ServiceLoader.load(Literal.class) under the assumption that this is > the only calling pattern. > I'm not following here, this is a static module system and so the modules that are providing the service need to involved when generating the configuration. -Alan. From alexey.x.fedorov at oracle.com Fri Feb 17 07:45:58 2012 From: alexey.x.fedorov at oracle.com (Alexey Fedorov) Date: Fri, 17 Feb 2012 19:45:58 +0400 Subject: Re-export and isModulePresent Message-ID: <4F3E7636.2080302@oracle.com> Hello! Suppose we have the following module structure: module A @ 1.0 { ... } module B @ 1.0 { ... requires public A; } module C @ 1.0 { ... requires B; } the following call in any class from module C returns *false*: getClass().getModule().isModulePresent("A") Is this behavior correct? In other words, "requires public A" directive re-exports *only A's types*, not *module *A? -- Thank you, Alexey From jesse.glick at oracle.com Fri Feb 17 08:15:50 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Fri, 17 Feb 2012 11:15:50 -0500 Subject: Mandatory service requirement In-Reply-To: <4F3E70F5.2060302@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> <4F3C99A2.9040907@oracle.com> <4F3C9DBC.3030709@oracle.com> <4F3CD8AF.2020709@oracle.com> <4F3D1BA4.5020407@oracle.com> <4F3E70F5.2060302@oracle.com> Message-ID: <4F3E7D36.1060301@oracle.com> On 02/17/2012 10:23 AM, Alan Bateman wrote: > For cases where there isn't a default/fallback implementation and where any provider implementation will suffice Probably the minority case as I argued before. > it would be preferable to catch such issues at install time rather than failing at runtime. It would be preferable, yes - the question is whether this minor bit of safety is worth the added conceptual & implementation complexity. >> drop the need to declare that a service is used at all: if and when ServiceLoader is called, determine the providers > > the modules that are providing the service need to involved when generating the configuration. My point is that the providing modules could be added to the configuration in other ways. For example: module jaxp { exports javax.xml.parsers; } module xerces { requires jaxp; provides service javax.xml.parsers.SAXParserFactory with ...; } module saxon { requires jaxp; provides service javax.xml.parsers.SAXParserFactory with ...; } module my.corp.wsparser { requires jaxp; } package my.corp.wsparser; class Parser { void parse(my.corp.WebServiceInput input) { SAXParser = SAXParserFactory.newInstance().newSAXParser(); // ... } } module my.corp.app { requires my.corp.wsparser; requires saxon; // I have tested with this } Here the call to SAXParserFactory.newInstance() would succeed so long as the application ultimately includes some XML parser, without the need for any "requires service javax.xml.parsers.SAXParserFactory" declaration. If you forgot to include one, this would probably be obvious (unless the parsing were on a rare and untested code path). The application module hardcodes a particular parser implementation which is known to work well, but this does not seem onerous: the wsparser module could be reused with other parsers, and offering a version of the app based on Xerces would be trivial. Conversely, quietly substituting Xerces at installation time might well lead to a host of subtle bugs. Even if you wanted to support "requires service javax.xml.parsers.SAXParserFactory" for the hypothetical case of an application whose author optimistically believes that any XML parser would work equally well, there is no obvious reason why this declaration must be in the wsparser module and not in the app module - or should it be in the jaxp module which would actually be calling ServiceLoader? So long as the xerces and/or saxon modules are *somewhere* in the configuration, it should not matter which module(s) requested the service: the "provides service ..." declarations suffice for the module system to create an index of service -> providers, maintained during installation. From mandy.chung at oracle.com Fri Feb 17 12:06:51 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Feb 2012 12:06:51 -0800 Subject: Re-export and isModulePresent In-Reply-To: <4F3E7636.2080302@oracle.com> References: <4F3E7636.2080302@oracle.com> Message-ID: <4F3EB35B.80402@oracle.com> On 2/17/2012 7:45 AM, Alexey Fedorov wrote: > Hello! > > Suppose we have the following module structure: > > module A @ 1.0 { > ... > } > > module B @ 1.0 { > ... > requires public A; > } > > module C @ 1.0 { > ... > requires B; > } > > the following call in any class from module C returns *false*: > > getClass().getModule().isModulePresent("A") > > Is this behavior correct? In other words, "requires public A" > directive re-exports *only A's types*, not *module *A? It's a bug. One use case of the isModulePresent() method is for testing if an optional module exists so that the a caller can conditionally reference the exported types from that module. In your example, module C should be able to access types in A that are re-exported from B if A is installed and linked with C. So the isModulePresent("A") method should return true in this case and we will fix it. Mandy From alexey.x.fedorov at oracle.com Fri Feb 17 12:27:43 2012 From: alexey.x.fedorov at oracle.com (Alexey Fedorov) Date: Sat, 18 Feb 2012 00:27:43 +0400 Subject: Re-export and isModulePresent In-Reply-To: <4F3EB35B.80402@oracle.com> References: <4F3E7636.2080302@oracle.com> <4F3EB35B.80402@oracle.com> Message-ID: <4F3EB83F.5060200@oracle.com> Mandy, thank you! -- Have a good weekend, Alexey On 02/18/2012 12:06 AM, Mandy Chung wrote: > On 2/17/2012 7:45 AM, Alexey Fedorov wrote: >> Hello! >> >> Suppose we have the following module structure: >> >> module A @ 1.0 { >> ... >> } >> >> module B @ 1.0 { >> ... >> requires public A; >> } >> >> module C @ 1.0 { >> ... >> requires B; >> } >> >> the following call in any class from module C returns *false*: >> >> getClass().getModule().isModulePresent("A") >> >> Is this behavior correct? In other words, "requires public A" >> directive re-exports *only A's types*, not *module *A? > > It's a bug. One use case of the isModulePresent() method is for > testing if an optional module exists so that the a caller can > conditionally reference the exported types from that module. In your > example, module C should be able to access types in A that are > re-exported from B if A is installed and linked with C. So the > isModulePresent("A") method should return true in this case and we > will fix it. > > Mandy From mandy.chung at oracle.com Fri Feb 17 16:35:57 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 17 Feb 2012 16:35:57 -0800 Subject: RFR: Building jre/jdk images from jmod files In-Reply-To: <4F3E1F7C.9040601@oracle.com> References: <4F3E1F7C.9040601@oracle.com> Message-ID: <4F3EF26D.5090007@oracle.com> Chris, I like your idea separating the native cmds, native libs, and config files during the jdk build so that they can be added in the proper section of the jmod file. Setting --natlib of the system module library to "bin" on Windows will keep the jigsaw module image working and allows the necessary changes in the jdk implementation to happen later. I'm amazed that you can find a way to do this cleanly hacking the makefiles for jdk modularization. > http://cr.openjdk.java.net/~chegar/jigsaw/jmods_webrev.00/webrev/ Your patch looks good. One thing to note: debug libraries is on the list for investigation. make/modules/Makefile currently filters out *.map and *.pdb files from the modules it create. This was done before the introduction of debuginfo files and we wanted to be able to measure the module size without debug libs. Just to mention it since you may try to find *.map and *.pdb on windows build and don't see them there. For testing - the default test set should cover many areas. I generally would also run jdk_beans* jdk_management*, jdk_security*, and jdk_tools1 test targets. The ModuleProblemList.txt is due for update but the failures should just be a few. Thanks Mandy On 2/17/2012 1:35 AM, Chris Hegarty wrote: > This is a follow up to the work for supporting native libraries and > commands outside the module library. > > The issue is that we previously could not (reasonably) create the > module images from jmod files. The reason is that the native libraries > and config files were not being put into the correct section of the > jmod files. For example, on Windows the dll's and exe's were put into > the NATIVE_CMDS section. Setting --natlib on Windows and installing > would not effect where the dll's get installed. > > Since the post processing construction of the modules will eventually > be replaced, I didn't want to spend too much time rewriting much of > the makefile, instead I guess you could say this is a little bit of a > cheat! > > Unix, > Basically, anything put into the build lib/(LIBARCH) directory can > be considered a native library, or jvm.cfg/Xusage.txt/debuginfo which > are closely related and therefore packaged with NATIVE_LIBS. > Everything else in the build lib directory, *.properties, *.data, > *.policy, tz data, fonts, go into the CONFIG section. Native commands > go into NATIVE_CMDS. > > Windows > Since the dll's and exe's are created and put in the build bin > directory, I simply modified the makefiles to know they are dealing > with a native command and put it into the modules bin dir, then > everything else in the build bin directory must be a native lib ( or > closely related pdb/map/etc). Now the contents of the build lib > directory are simply *.properties, *.data, *.policy, tz data, fonts, > go into the CONFIG section. > > I verified that module images built with the changes are the same as > without. Additionally, BUILD_PACKAGES=false still works ( for faster > builds ). > > http://cr.openjdk.java.net/~chegar/jigsaw/jmods_webrev.00/webrev/ > > Thanks, > -Chris. From jonathan.gibbons at oracle.com Sat Feb 18 09:05:54 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 18 Feb 2012 17:05:54 +0000 Subject: hg: jigsaw/jigsaw/langtools: fix NPE for Attr.visitProvidesService Message-ID: <20120218170559.84AC44757F@hg.openjdk.java.net> Changeset: 083b1c682a32 Author: jjg Date: 2012-02-18 09:04 -0800 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/083b1c682a32 fix NPE for Attr.visitProvidesService ! src/share/classes/com/sun/tools/javac/comp/Attr.java From Alan.Bateman at oracle.com Sun Feb 19 08:31:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Feb 2012 16:31:07 +0000 Subject: Mandatory service requirement In-Reply-To: <4F3E7D36.1060301@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F3C9759.9010903@oracle.com> <4F3C99A2.9040907@oracle.com> <4F3C9DBC.3030709@oracle.com> <4F3CD8AF.2020709@oracle.com> <4F3D1BA4.5020407@oracle.com> <4F3E70F5.2060302@oracle.com> <4F3E7D36.1060301@oracle.com> Message-ID: <4F4123CB.1090209@oracle.com> On 17/02/2012 16:15, Jesse Glick wrote: > : > >> it would be preferable to catch such issues at install time rather >> than failing at runtime. > > It would be preferable, yes - the question is whether this minor bit > of safety is worth the added conceptual & implementation complexity. "requires service S" means >= 1 implementations of S required. "requires optional service S" means >= 0 implementations of S required. I don't think it's too hard from a conceptual point of view. I do agree than in many cases it will be the latter usage but, at least for the JDK, that is because there is a default implementation. > > My point is that the providing modules could be added to the > configuration in other ways. For example: > > module jaxp { > exports javax.xml.parsers; > } > module xerces { > requires jaxp; > provides service javax.xml.parsers.SAXParserFactory with ...; > } > module saxon { > requires jaxp; > provides service javax.xml.parsers.SAXParserFactory with ...; > } > module my.corp.wsparser { > requires jaxp; > } > package my.corp.wsparser; > class Parser { > void parse(my.corp.WebServiceInput input) { > SAXParser = SAXParserFactory.newInstance().newSAXParser(); > // ... > } > } > module my.corp.app { > requires my.corp.wsparser; > requires saxon; // I have tested with this > } > > Here the call to SAXParserFactory.newInstance() would succeed so long > as the application ultimately includes some XML parser, without the > need for any "requires service javax.xml.parsers.SAXParserFactory" > declaration. If you forgot to include one, this would probably be > obvious (unless the parsing were on a rare and untested code path). > The application module hardcodes a particular parser implementation > which is known to work well, but this does not seem onerous: the > wsparser module could be reused with other parsers, and offering a > version of the app based on Xerces would be trivial. Conversely, > quietly substituting Xerces at installation time might well lead to a > host of subtle bugs. > > Even if you wanted to support "requires service > javax.xml.parsers.SAXParserFactory" for the hypothetical case of an > application whose author optimistically believes that any XML parser > would work equally well, there is no obvious reason why this > declaration must be in the wsparser module and not in the app module - > or should it be in the jaxp module which would actually be calling > ServiceLoader? So long as the xerces and/or saxon modules are > *somewhere* in the configuration, it should not matter which module(s) > requested the service: the "provides service ..." declarations suffice > for the module system to create an index of service -> providers, > maintained during installation. I'm not sure that this will scale as my.corp.app may not know about all usages of ServiceLoader. However I do agree that a preferred implementation, or "I have tested with this" as you put it, it worth discussion from a predictability point of view. There isn't anything in Jigsaw for this at present although in the JDK we have examples where there is a means to override or specify the provider implementation to use. -Alan From alan.bateman at oracle.com Sun Feb 19 08:44:20 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Feb 2012 16:44:20 +0000 Subject: hg: jigsaw/jigsaw/langtools: Another NPE in Attr.visitProvidesService Message-ID: <20120219164426.236014758A@hg.openjdk.java.net> Changeset: 0e11747978c5 Author: jjg Date: 2012-02-19 16:35 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/langtools/rev/0e11747978c5 Another NPE in Attr.visitProvidesService ! src/share/classes/com/sun/tools/javac/comp/ModuleContext.java From jaroslav.tulach at oracle.com Mon Feb 20 01:49:42 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 20 Feb 2012 10:49:42 +0100 Subject: Eliminate silent dependencies was: Mandatory service requirement In-Reply-To: <4F3E7D36.1060301@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F3E70F5.2060302@oracle.com> <4F3E7D36.1060301@oracle.com> Message-ID: <201202201049.42860.jaroslav.tulach@oracle.com> Jesse, is your suggestion to force the my.corp.app module to always have a direct dependency on explicit implementation of a parser (e.g. saxon)? If so, I believe it would be unfortunate. It may be valid for my.corp.app to select and prefer one implementation of a parser. If the whole application is tested with saxon parser, it is perfectly OK, to request that the saxon parser is used when my.corp.wsparser needs SAX. However it is important for jaxp module or my.corp.wsparser module (as a reusable units) to properly indicate the need for implementation of a SAX parser too. Otherwise others, reusing jaxp or my.corp.wsparser will find out only during runtime that the execution environment is insufficient. Dependencies are here to statically describe the runtime environment of a module. When turning my.corp.wsparser on, the system needs to realize some SAX parser needs to be around (but it is OK, if my.corp.app narrows the selection or even changes it[1]). Services often act like singletons. Properly used singletons need to be "inherently initialized" (discussed at [2] and [3]). As such the jaxp module either: - needs to declare that it requires service implementation of its parser(s) - it can "requires service optional" and provide default fallback implementation(s) Letting the jaxp module be silent about its dependencies is the worst solution. It sort of reminds me the time when every user of NetBeans org.netbeans.projectuiapi module had to also declare a requires dependency on its implementation module org.netbeans.projectui. It was a mess and we simplified the usage of that API a lot by replacing this with module org.netbeans.projectuiapi { requires service optional org.netbeans.project.uiapi.ActionsFactory; requires service optional org.netbeans.project.uiapi.OpenProjectsTrampoline; requires service optional org.netbeans.project.uiapi.ProjectChooserFactory; } In the NetBeans case the "requires service optional" style is more unit test friendly. But with a little tweaks mandatory "requires service" would work well too. The only wrong case is when the API module (jaxp or org.netbeans.projectuiapi) is silent about its dependencies. -jt [1] my.corp.app could somehow express that the DOM parser is not need, but that gets too complicated and if that is a frequent situation then there should be independent module for SAX and for DOM parser API anyway... [2] http://wiki.apidesign.org/wiki/Singleton [3] http://wiki.apidesign.org/wiki/Injectable_Singleton >## 17.?2.?2012 17:15:50 ##< > On 02/17/2012 10:23 AM, Alan Bateman wrote: > >> drop the need to declare that a service is used at all: if and when > >> ServiceLoader is called, determine the providers > > > > the modules that are providing the service need to involved when > > generating the configuration. > > My point is that the providing modules could be added to the configuration > in other ways. For example: > > module jaxp { > exports javax.xml.parsers; > } > module xerces { > requires jaxp; > provides service javax.xml.parsers.SAXParserFactory with ...; > } > module saxon { > requires jaxp; > provides service javax.xml.parsers.SAXParserFactory with ...; > } > module my.corp.wsparser { > requires jaxp; > } > package my.corp.wsparser; > class Parser { > void parse(my.corp.WebServiceInput input) { > SAXParser = SAXParserFactory.newInstance().newSAXParser(); > // ... > } > } > module my.corp.app { > requires my.corp.wsparser; > requires saxon; // I have tested with this > } > > Here the call to SAXParserFactory.newInstance() would succeed so long as > the application ultimately includes some XML parser, without the need for > any "requires service javax.xml.parsers.SAXParserFactory" declaration. If > you forgot to include one, this would probably be obvious (unless the > parsing were on a rare and untested code path). The application module > hardcodes a particular parser implementation which is known to work well, > but this does not seem onerous: the wsparser module could be reused with > other parsers, and offering a version of the app based on Xerces would be > trivial. Conversely, quietly substituting Xerces at installation time > might well lead to a host of subtle bugs. > > Even if you wanted to support "requires service > javax.xml.parsers.SAXParserFactory" for the hypothetical case of an > application whose author optimistically believes that any XML parser would > work equally well, there is no obvious reason why this declaration must be > in the wsparser module and not in the app module - or should it be in the > jaxp module which would actually be calling ServiceLoader? So long as the > xerces and/or saxon modules are *somewhere* in the configuration, it > should not matter which module(s) requested the service: the "provides > service ..." declarations suffice for the module system to create an index > of service -> providers, maintained during installation. From david.lloyd at redhat.com Mon Feb 20 06:06:19 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 20 Feb 2012 08:06:19 -0600 Subject: Eliminate silent dependencies was: Mandatory service requirement In-Reply-To: <201202201049.42860.jaroslav.tulach@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F3E70F5.2060302@oracle.com> <4F3E7D36.1060301@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> Message-ID: <4F42535B.7050800@redhat.com> On 02/20/2012 03:49 AM, Jaroslav Tulach wrote: > Jesse, > is your suggestion to force the my.corp.app module to always have a direct > dependency on explicit implementation of a parser (e.g. saxon)? If so, I > believe it would be unfortunate. > > It may be valid for my.corp.app to select and prefer one implementation of a > parser. If the whole application is tested with saxon parser, it is perfectly > OK, to request that the saxon parser is used when my.corp.wsparser needs SAX. > > However it is important for jaxp module or my.corp.wsparser module (as a > reusable units) to properly indicate the need for implementation of a SAX > parser too. Otherwise others, reusing jaxp or my.corp.wsparser will find out > only during runtime that the execution environment is insufficient. I understand this and sympathize however I believe this doesn't actually work in reality. Implementing our latest app server release as a fully modular run-time environment has given us some insight into the realities of this problem. You have essentially these scenarios when it comes to implementation discovery: 1) There is only one implementation which is used system-wide (this is your "services as singletons" scenario). 2) There are multiple implementations, however normally only one implementation is selected for the entire application. 3) There are multiple implementations, but each module may need to choose a different implementation. 4) There are multiple implementations, however implementations carry semantic meaning and generally must therefore be selected by some identifier. The ServiceLoader API (or its moral equivalent) is pretty widely used today for all four scenarios. However I do not believe that there is a single declarative construct which adequately solves all these cases. Of these scenarios, only #1 is adequately solved by declaring a that a module requires some unspecified implementation of a given API. I think instead that these cases can and should be solved by the existing dependency mechanism. If a service is indeed a true singleton in every sense (which corresponds to case #1), then the simplest solution is to have the API import its implementation (or at least import its services resources in order to be able to locate it) and use its own class loader to locate it. If a service is application-wide (case #2), the API would search the boot module's class loader or TCCL (there are pros and cons of each), which would express the dependency. A good example which fits for both #1 and #2 is NIO, where multiple implementations (per system) are certainly possible but also somewhat unlikely. If a service is typically per-module (case #3) then each module would import (at run time) its preferred implementation and use its own class loader to search for it. If a service's behavior varies by implementation (case #4), as is the case for cryptographic, digest, and other security APIs (where the algorithm is significant to determining the behavior of the implementation) and several third-party APIs, then the application must import the implementations which it uses (granted the security APIs already have an alternative global registry based method, however this is not an ideal solution for this problem). In this case, the API would generally use the caller's class loader or TCCL to search for an implementation with a matching "type". Note that this case is unique in that the conceptual service dependency is not just a base type to be implemented, but it also has a "flavor" component to specify behavior characteristics. All of these solutions have in common that the API to locate the implementation requires some notion of what class loader to search. Based on our experience, the best existing APIs in this regard are those which have a preferred search order which includes an API variant which uses a default class loader (sometimes TCCL, sometimes the API's own, depending on which general case as described above) and a variant which accepts an explicit class loader argument to search. Failing more than one API method, the best overall interface is to accept a class loader as an argument, as the caller can easily explicitly specify the TCCL or the callee's class loader. -- - DML From Alan.Bateman at oracle.com Mon Feb 20 10:50:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 Feb 2012 18:50:45 +0000 Subject: runtime changes for services In-Reply-To: <4F3C39E4.6030701@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> Message-ID: <4F429605.10506@oracle.com> Thanks for going through this. I was slow getting back to this as I had to re-base the patch based on the latest updates and then I rang into a few javac issues. Comments inlined. On 15/02/2012 23:04, Mandy Chung wrote: > : > > On 2/9/2012 9:06 AM, Alan Bateman wrote: >> http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev/index.html > com/sun/classanalyzer/ModuleInfo.java > L46: you're right that it needs to make a defensive copy > of services and providers. I added that comment as a reminder to check it. I've now changed it to make a copy. > > L155-172: would it be better to sort the list before printing > the "requires services" statements? I believe the ordering of > "provides service" statements matters and so it should keep > it the same order as specified in the META-INF/services files. Yes, it should preserve the order. I've fixed this and the same thing in the jar tool where it was storing the provider names in a HashSet, thus loosing the original order. > > java/util/ServiceLoader.java > L357-359: for maintainability, would it be better to replace > these lines with > if (!hasNext()) { > throw new NoSuchElementException(); > } That would be clearer - thanks! > > org/openjdk/jigsaw/Context.java > L173, 203: I assume you want to fix these methods to return a > unmodifiable map, right? I don't see the code that expects > them to be modifiable (maybe I miss something)? This is just a comment as a reminder that the returned collection is mutable. All the current usages are read-only. > > org/openjdk/jigsaw/Linker.java > L296: extra blank line OK > > org/openjdk/jigsaw/Loader.java > L286-289: can these lines be replaced with: > Set remotes = context.serviceSuppliers().get(cn); You're right, this is clearer. > > L278: I wonder if this should return a map of ModuleClassLoader > rather than ClassLoader just be explicit. I don't have a strong opinion on this. I used the least specific type but we may need to change it to ModuleClassLoader in the future. > > L291: this causes the module loader for the service > implementation class be instantiated. I presume we want > the loader be instantiated lazily when it's loaded. On > the other hand, the instantiation cost doesn't look like > too high. It's fine for the initial implementation but > we should look into this open issue. Okay, I'll note this as something to look at it again. The main thing is that the provider is instantiated lazily. > > org/openjdk/jigsaw/Resolver.java > L320,322,323, 338: a space below ":" > There are other places missing the space in the foreach > statements needed fixing too. Our coding conventions badly need to be updated. Subjective as it is, I tend not to put a space before the colon. > > sun/tools/jar/Main.java > L785: would you suggest to replace Charset.forName("UTF-8") > with StandardCharsets.UTF_8 (no real difference though)? There's a complicated story here. Charset.forName("UTF-8") is slightly faster at the moment. > L989: This is not really a question for this change but > you may have the answer. I have seen some copy of readAllBytes > in other places. Have we considered adding this support > to the platform? We added Files.readAllBytes in JDK7 and I think someday we should do something for streams too. > > new services tests > Looks good. The copyright start year should be 2012 :) > I notice that some tests turn on assertion but some don't. > It might be good to set -esa -ea on all tests I think. > At some point we need to pass the VM options through to the jmod/java commands (this goes generally for all the shell tests in the jdk repo). For now I'll use -esa consistently, there aren't any assertions in the java code in the tests. I've put the updated webrev here: http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev.02/ -Alan. From mandy.chung at oracle.com Mon Feb 20 12:43:14 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 20 Feb 2012 12:43:14 -0800 Subject: runtime changes for services In-Reply-To: <4F429605.10506@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F429605.10506@oracle.com> Message-ID: <4F42B062.1060200@oracle.com> On 2/20/2012 10:50 AM, Alan Bateman wrote: > I've put the updated webrev here: > http://cr.openjdk.java.net/~alanb/jigsaw-services/webrev.02/ Looks good. The Context.services() and serviceSuppliers() methods return a mutable map. I understand the current usages are read-only but is inconsistent with other getter methods that return a unmodifiable map. Probably you are thinking about performance - I think it's worth revisiting the immutability of this class and some other classes in the future. Mandy From Alan.Bateman at oracle.com Tue Feb 21 09:43:00 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 Feb 2012 17:43:00 +0000 Subject: runtime changes for services In-Reply-To: <4F42B062.1060200@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F33FD00.20900@oracle.com> <4F3C39E4.6030701@oracle.com> <4F429605.10506@oracle.com> <4F42B062.1060200@oracle.com> Message-ID: <4F43D7A4.1060209@oracle.com> On 20/02/2012 20:43, Mandy Chung wrote: > > Looks good. > > The Context.services() and serviceSuppliers() methods return a mutable > map. I understand the current usages are read-only but is > inconsistent with other getter methods that return a unmodifiable > map. Probably you are thinking about performance - I think it's worth > revisiting the immutability of this class and some other classes in > the future. Yes, I'm thinking about performance so I left this comment as a reminder. I don't mind changing this to return immutable maps for now but it is something we'll need to come back to. -Alan From alan.bateman at oracle.com Tue Feb 21 09:43:45 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 Feb 2012 17:43:45 +0000 Subject: hg: jigsaw/jigsaw/jdk: First installation of support for services at runtime Message-ID: <20120221174418.8847A475BF@hg.openjdk.java.net> Changeset: 79a80e9e356b Author: alanb Date: 2012-02-21 17:30 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/79a80e9e356b First installation of support for services at runtime Reviewed-by: mchung ! make/modules/jdk.depconfig ! make/modules/modules.group ! make/modules/modules.properties ! make/tools/classanalyzer/src/com/sun/classanalyzer/AnnotatedDependency.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleBuilder.java ! make/tools/classanalyzer/src/com/sun/classanalyzer/ModuleInfo.java ! src/share/classes/java/lang/module/ServiceDependence.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/org/openjdk/jigsaw/Context.java ! src/share/classes/org/openjdk/jigsaw/Linker.java ! src/share/classes/org/openjdk/jigsaw/Loader.java ! src/share/classes/org/openjdk/jigsaw/Resolver.java ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! src/share/classes/org/openjdk/jigsaw/cli/Commands.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/ModuleInfo.java + test/org/openjdk/jigsaw/services/hello.sh + test/org/openjdk/jigsaw/services/many.sh + test/org/openjdk/jigsaw/services/optional.sh + test/org/openjdk/jigsaw/services/services-jar.sh + test/org/openjdk/jigsaw/services/view.sh From alan.bateman at oracle.com Tue Feb 21 10:54:05 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 Feb 2012 18:54:05 +0000 Subject: hg: jigsaw/jigsaw/jdk: Sync up ProblemList for tests that can't run with modules images yet Message-ID: <20120221185415.10071475C0@hg.openjdk.java.net> Changeset: f2f3fb80ca72 Author: alanb Date: 2012-02-21 18:51 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/f2f3fb80ca72 Sync up ProblemList for tests that can't run with modules images yet ! test/ModulesProblemList.txt From chris.hegarty at oracle.com Tue Feb 21 12:01:08 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 21 Feb 2012 20:01:08 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. Message-ID: <4F43F804.6020206@oracle.com> Here is a patch to resolve some of the intermittent failing org/openjdk/jigsaw tests. Mainly Windows! 1) test/org/openjdk/jigsaw/TrivialWebServer.java test/org/openjdk/jigsaw/_RemoteRepository.java org/openjdk/jigsaw/remrepo.sh and org/openjdk/jigsaw/repolist.sh fail intermittently, typically Windows, occasionally on Linux. There is a small issue in the handling of Last-Modified in the bundled test HTTP server. This header only supports the granularity of seconds. So, it may be possible that the files lastModified date be actually greater than that of when it is converted to the value passed in the header and then converted back to millis. The solution is to use seconds for comparison ( since this is the granularity of the header). Also a minor issue in _RemoteRepository.java where, since the granularity is seconds, the test should ensure that the updated catalog be "newer". sleep!!! 2) test/org/openjdk/jigsaw/cli/JpkgArgsTest.java Skip testIfFileArgIsNotReadable since File readability cannot be set to false in Windows 3) test/org/openjdk/jigsaw/tester.sh To get resource.sh, resolver.sh, hello-view.sh to run under MKS on Windows. The changes should be harmless on other platforms. Only support one main entry point per test. This is what we support anyway, just to limit the entry in the main file since it can cause problems when trying to put more in, hello-view.sh for example. Secondly, MKS puts a hs_histo file in the working dir and may be mistaken for a test when actually running Webrev: http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.00/webrev/ -Chris. From jesse.glick at oracle.com Tue Feb 21 16:31:37 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Tue, 21 Feb 2012 19:31:37 -0500 Subject: Eliminate silent dependencies was: Mandatory service requirement In-Reply-To: <201202201049.42860.jaroslav.tulach@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F3E70F5.2060302@oracle.com> <4F3E7D36.1060301@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> Message-ID: <4F443769.4070403@oracle.com> Alan Bateman wrote: > "requires service S" means >= 1 implementations of S required. But there is a difference between saying "you must somehow provide an implementation of S if this module is to be used or the system will report an error", which can arguably be useful (in my experience rarely); and actually going out and silently picking one from the repository when none was provided, which is not obviously implied by the above declaration and might be bad. > "requires optional service S" means >= 0 implementations of S required. Which means nothing at all :-) as I noted at the end of my original post "Mandatory service requirement" - there is no reason why you should have to declare that you might load a service, if you can gracefully handle zero implementations. Jaroslav Tulach wrote: > is your suggestion to force the my.corp.app module to always have a direct > dependency on explicit implementation of a parser (e.g. saxon)? Exactly. If Saxon works, why would you want the app to run with something else? If you do, just change the dep (and retest the app). Here "the app" can just be a shell module that assembles all the reusable pieces it needs, so it is really just a module configuration. (There are cases mainly arising I think in the Java Platform where there is just one implementation of an API available for a given system and this depends on the host operating system or the Java vendor; but these situations exist even without ServiceLoader, in fact more commonly, and would probably be handled via module aliases.) For large apps with a user-level plugin system, I would expect Jigsaw to offer reflective APIs so you could build a UI to load named modules and make their services available. > Otherwise others, reusing jaxp or my.corp.wsparser will find out > only during runtime that the execution environment is insufficient. Yes, but compared to other problems this is a very simple one to solve - add the desired implementation. It would just be part of the documentation of an API that calling it (or a certain subset of it!) presumes an implementation of a particular service, and what happens if no implementation is present. > we simplified the usage of that API a lot by replacing this with > > module org.netbeans.projectuiapi { > requires service optional org.netbeans.project.uiapi.ActionsFactory; ... > } This is misleading because there is no equivalent in NB APIs to "requires service optional" ("requires optional service"?): if you do not really "require" it then there is nothing to declare (see discussion above). Rather, what we _had_ was like a (mandatory) "requires service", which made unit tests painful and also forced you to turn on projectui (the impl module) even when none of the above services were to be called in a particular application. That is why I removed the token requirement and wrote no-op fallback implementations of these services. David M. Lloyd wrote: > use its own class loader to locate it Agreed that there are a lot of different variants. However we should not advocate using old-style ClassLoader hacks (especially Thread.contextClassLoader), which can break in all sorts of tricky ways and do not compose well - part of the justification for an official module system in Java is to simplify this kind of thing in the future. I think plain ServiceLoader.load(Class), understood to search in all modules in the loaded configuration, can work for all of the cases where available services must be discovered; if you need to discriminate among implementations, call some method on each (e.g. String[] supportedDigestImplementations()). Or ask your own caller to pass in an implementation in dependency injection style. Unfortunately it seems that Jigsaw offers no integration point for DI frameworks. From Alan.Bateman at oracle.com Wed Feb 22 02:14:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 10:14:04 +0000 Subject: Eliminate silent dependencies was: Mandatory service requirement In-Reply-To: <4F443769.4070403@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F3E70F5.2060302@oracle.com> <4F3E7D36.1060301@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F443769.4070403@oracle.com> Message-ID: <4F44BFEC.30201@oracle.com> On 22/02/2012 00:31, Jesse Glick wrote: > Alan Bateman wrote: >> "requires service S" means >= 1 implementations of S required. > > But there is a difference between saying "you must somehow provide an > implementation of S if this module is to be used or the system will > report an error", which can arguably be useful (in my experience > rarely); and actually going out and silently picking one from the > repository when none was provided, which is not obviously implied by > the above declaration and might be bad. > >> "requires optional service S" means >= 0 implementations of S required. > > Which means nothing at all :-) as I noted at the end of my original > post "Mandatory service requirement" - there is no reason why you > should have to declare that you might load a service, if you can > gracefully handle zero implementations. Jigsaw is a static module system so it needs to know that implementations of S that may be required at runtime so as to include them in the configuration. Furthermore it pre-builds the maps so that there is no searching at runtime. Having an application module (the user of the API, not the one calling ServiceLoader.load) declare a dependency on a module with a specific provider implementation isn't the same thing. It could be made to work for some case but I'm not sure that it would scale. So for now, and in the graph terms, we need an edge (of a different color) from the module using ServiceLoader.load(S.class) to the module that provides S. > > : > > For large apps with a user-level plugin system, I would expect Jigsaw > to offer reflective APIs so you could build a UI to load named modules > and make their services available. Yes, this should come in time as it is critical to container support. Exactly how this works with services remains to be seen. > : > Agreed that there are a lot of different variants. However we should > not advocate using old-style ClassLoader hacks (especially > Thread.contextClassLoader), which can break in all sorts of tricky > ways and do not compose well - part of the justification for an > official module system in Java is to simplify this kind of thing in > the future. I think plain ServiceLoader.load(Class), understood to > search in all modules in the loaded configuration, can work for all of > the cases where available services must be discovered; if you need to > discriminate among implementations, call some method on each (e.g. > String[] supportedDigestImplementations()). > Right, Thread.contextClassLoader was a bad idea and just not interesting in a modules world. ServiceLoader is also class loader centric and not a good fit either. In the current prototype then ServiceLoader.load(Class) does not use the Thread.contextClassLoader when in module mode. -Alan From Alan.Bateman at oracle.com Wed Feb 22 03:34:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 11:34:31 +0000 Subject: Eliminate silent dependencies was: Mandatory service requirement In-Reply-To: <201202201049.42860.jaroslav.tulach@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F3E70F5.2060302@oracle.com> <4F3E7D36.1060301@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> Message-ID: <4F44D2C7.9070203@oracle.com> On 20/02/2012 09:49, Jaroslav Tulach wrote: > : > > Services often act like singletons. Properly used singletons need to be > "inherently initialized" (discussed at [2] and [3]). I think singletons is a good topic to bring up. An interesting question is whether this should be something that the module system or ServiceLoader knows about or whether it's the user of SeviceLoader that enforces it (possible as a side effect of caching). -Alan From Alan.Bateman at oracle.com Wed Feb 22 07:43:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 15:43:52 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F43F804.6020206@oracle.com> References: <4F43F804.6020206@oracle.com> Message-ID: <4F450D38.9080607@oracle.com> On 21/02/2012 20:01, Chris Hegarty wrote: > Here is a patch to resolve some of the intermittent failing > org/openjdk/jigsaw tests. Mainly Windows! > > 1) test/org/openjdk/jigsaw/TrivialWebServer.java > test/org/openjdk/jigsaw/_RemoteRepository.java > > org/openjdk/jigsaw/remrepo.sh and org/openjdk/jigsaw/repolist.sh > fail intermittently, typically Windows, occasionally on Linux. There > is a small issue in the handling of Last-Modified in the bundled test > HTTP server. This header only supports the granularity of seconds. > So, it may be possible that the files lastModified date be actually > greater than that of when it is converted to the value passed in the > header and then converted back to millis. The solution is to use > seconds for comparison ( since this is the granularity of the > header). > > Also a minor issue in _RemoteRepository.java where, since the > granularity is seconds, the test should ensure that the updated > catalog be "newer". sleep!!! > > 2) test/org/openjdk/jigsaw/cli/JpkgArgsTest.java > > Skip testIfFileArgIsNotReadable since File readability cannot be set > to false in Windows > > 3) test/org/openjdk/jigsaw/tester.sh > > To get resource.sh, resolver.sh, hello-view.sh to run under > MKS on Windows. The changes should be harmless on other platforms. > > Only support one main entry point per test. This is what we support > anyway, just to limit the entry in the main file since it can cause > problems when trying to put more in, hello-view.sh for example. > Secondly, MKS puts a hs_histo file in the working dir and may be > mistaken for a test when actually running > > Webrev: > > http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.00/webrev/ > > -Chris. Thanks for sorting these out, it was annoying for these tests not to be pass on all platforms. In _RemoteRepository. testRemove the sleep is 1s but this may not be sufficient to ensure a new time stamp (legacy FAT32 has a granularity of 2s for example). I'm curious about _RemoteRepositoryList.local as I would have thought that we have many tests (in the networking area at least) that would also fail if once could connect to the host name. Otherwise looks okay to me. -Alan. From jaroslav.tulach at oracle.com Wed Feb 22 08:00:09 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 22 Feb 2012 17:00:09 +0100 Subject: Singletons was: Eliminate silent dependencies In-Reply-To: <4F44D2C7.9070203@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F44D2C7.9070203@oracle.com> Message-ID: <201202221700.09099.jaroslav.tulach@oracle.com> >## 22.?2.?2012 12:34:31 ##< > On 20/02/2012 09:49, Jaroslav Tulach wrote: > > Services often act like singletons. Properly used singletons need to be > > "inherently initialized" (discussed at [2] and [3]). > > I think singletons is a good topic to bring up. An interesting question > is whether this should be something that the module system or > ServiceLoader knows about or whether it's the user of SeviceLoader that > enforces it (possible as a side effect of caching). The typical implementation of (injectable) singleton via ServiceLoader is shown at http://wiki.apidesign.org/wiki/Injectable_Singleton#Initialize If this pattern is followed, the only thing that the module system is supposed to do is to enable providers of such service. E.g. using requires (optional) service DialogDisplayer and provides service DialogDisplayer in module-info files of appropriate modules would be enough. Of course the module system can make it even easier. One could annotate the field with @InjectService(fallback=Impl.class) private static DialogDisplayer DEFAULT; Having annotation like this or reusing for example http://docs.oracle.com/javase/6/docs/api/javax/annotation/Resource.html would be more convenient. Whether usage of (injectable) singletons is typical and should be simplified with annotation is something I don't dare to decide. Btw. usage of @InjectService could imply generating "requires service " into module-info.java. Usage of @InjectService with fallback would be equivalent to "requires optional service". -jt From chris.hegarty at oracle.com Wed Feb 22 08:04:38 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 22 Feb 2012 16:04:38 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F450D38.9080607@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> Message-ID: <4F451216.8080909@oracle.com> On 22/02/2012 15:43, Alan Bateman wrote: > ..... > Thanks for sorting these out, it was annoying for these tests not to be > pass on all platforms. > > In _RemoteRepository. testRemove the sleep is 1s but this may not be > sufficient to ensure a new time stamp (legacy FAT32 has a granularity of > 2s for example). Yes, I think 2 or 3 seconds would be better. > I'm curious about _RemoteRepositoryList.local as I would have thought > that we have many tests (in the networking area at least) that would > also fail if once could connect to the host name. This test was failing at L145 "assert rr.location().equals(u1);". RemoteRepository stores it's location() as a URI with a canonical host name ( where possible ). Since URI.equals does a string comparison, equalIgnoringCase, then the hosts need to be the same. -Chris. > Otherwise looks okay to me. > > -Alan. > > > > > > > > From Alan.Bateman at oracle.com Wed Feb 22 08:11:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 16:11:30 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F451216.8080909@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> Message-ID: <4F4513B2.7060805@oracle.com> On 22/02/2012 16:04, Chris Hegarty wrote: > On 22/02/2012 15:43, Alan Bateman wrote: >> ..... >> Thanks for sorting these out, it was annoying for these tests not to be >> pass on all platforms. >> >> In _RemoteRepository. testRemove the sleep is 1s but this may not be >> sufficient to ensure a new time stamp (legacy FAT32 has a granularity of >> 2s for example). > > Yes, I think 2 or 3 seconds would be better. > >> I'm curious about _RemoteRepositoryList.local as I would have thought >> that we have many tests (in the networking area at least) that would >> also fail if once could connect to the host name. > > This test was failing at L145 "assert rr.location().equals(u1);". > RemoteRepository stores it's location() as a URI with a canonical host > name ( where possible ). Since URI.equals does a string comparison, > equalIgnoringCase, then the hosts need to be the same. > Okay, I didn't know which assert was failing. In that case it make sense. -Alan From jaroslav.tulach at oracle.com Wed Feb 22 08:11:49 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 22 Feb 2012 17:11:49 +0100 Subject: Eliminate silent dependencies In-Reply-To: <4F443769.4070403@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F443769.4070403@oracle.com> Message-ID: <201202221711.49226.jaroslav.tulach@oracle.com> > Jesse wrote: > > is your suggestion to force the my.corp.app module to always have a > > direct dependency on explicit implementation of a parser (e.g. saxon)? > > Exactly. If Saxon works, why would you want the app to run with something > else? Because you want somebody else to reuse my.corp.app in different environment. E.g. for reusable components want flexibility. > > Otherwise others, reusing jaxp or my.corp.wsparser will find out > > only during runtime that the execution environment is insufficient. > > Yes, but compared to other problems this is a very simple one to solve - > add the desired implementation. It would just be part of the documentation Having (optional) type information in documentation rather than in source files is more common in languages like Ruby or JavaScript (with all drawbacks and benefits). As Alan wrotes... >## Alan wrote on 22.?2.?2012 11:14:04 ##< > Jigsaw is a static module system so it needs to know that > implementations of S that may be required at runtime so as to include > them in the configuration. ... this is Java and it is supposed to be "type safe" - e.g. if there is a way to prevent runtime errors at compile or install time, we should prevent them. Being able to request (optional) presence of services in an execution environment is essential to modular usage of ServiceLoader and I think the current Jigsaw design goes in the right direction. -jt From Alan.Bateman at oracle.com Wed Feb 22 08:44:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 16:44:04 +0000 Subject: configuration being stored for modules that don't have entry points. Message-ID: <4F451B54.7040109@oracle.com> Mandy - I need a sanity check on a minor change. The issue is that modules installed via install(Resolution,boolean) method are getting a stored configuration even when they don't have an entry point. I noticed this when chatting with David Holmes about the size of the jdk.tls module. In his environment the module was downloaded from a repository and so was installed via this install method that was larger than when installed from a jmod file. It's a clearly a policy issue as to whether we re-generate the configuration for all modules after installing some modules but as we do it when installing jmods then it's probably consistent to do the same here - do you agree? -Alan diff --git a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java --- a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java +++ b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java @@ -1486,9 +1486,7 @@ // Configure // - Configuration cf - = Configurator.configure(this, res); - new StoredConfiguration(findModuleDir(root.id()), cf).store(); + configure(null); } @Override From jaroslav.tulach at oracle.com Wed Feb 22 09:14:23 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Wed, 22 Feb 2012 18:14:23 +0100 Subject: Selecting the right service was: Eliminate silent dependencies In-Reply-To: <4F42535B.7050800@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> Message-ID: <201202221814.23826.jaroslav.tulach@oracle.com> Hello David. >## 20.?2.?2012 15:06:19 ##< > 1) There is only one implementation which is used system-wide (this is > your "services as singletons" scenario). Given your following comment ... > If a service is indeed a true singleton > in every sense (which corresponds to case #1), then the simplest > solution is to have the API import its implementation (or at least > import its services resources in order to be able to locate it) and use > its own class loader to locate it. ... I don't think this is injectable singleton example. Of course if you have a singleton and it is supposed to have just a single implementation, then let the API instantiate the implementation using "new". You can even put the singleton API and its implementation into the same module. No reason to have anything modular, imho. > 2) There are multiple implementations, however normally only one > implementation is selected for the entire application. This is probably what I call injectable singleton: http://wiki.apidesign.org/wiki/Injectable_Singleton#Initialize In contrast to case #1 it makes sense to use modularity here and separate the singleton API into one module and put the implementation into other(s). > 3) There are multiple implementations, but each module may need to > choose a different implementation. > If a service is typically per-module (case #3) then each module would > import (at run time) its preferred implementation and use its own class > loader to search for it. It will be better if the classloading tricks are eliminated as Jesse and Alan wrote. Imho it may be sufficient to get all instances in the system and somehow select the right one by querying its capabilities (e.g. getSupportedXYZ(), etc.). > 4) There are multiple implementations, however implementations carry > semantic meaning and generally must therefore be selected by some > identifier. > Note that this case is unique in > that the conceptual service dependency is not just a base type to be > implemented, but it also has a "flavor" component to specify behavior > characteristics. Actually NetBeans has an example of this style as well. The editor guards API http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor- guards/overview-summary.html benefits from the fact that requires/provides are just string tokens (not a class names). One registers the service capable to work for Java and then uses provides token org.netbeans.api.editor.guards.Java; Users of the editor guards API wanting to deal with Java then use: /* guarantees editor guards API is on classpath */ requires org.netbeans.api.editor.guards; /* guarantees the Java implementation will be found using ServiceLoader */ requires token org.netbeans.api.editor.guards.Java; > If a service's behavior varies by implementation (case #4), as is the > case for cryptographic, digest, and other security APIs (where the > algorithm is significant to determining the behavior of the > implementation) and several third-party APIs, then the application must > import the implementations which it uses A cryptography module providing SHA implementation would use something like provides token java.security.MessageDigest.SHA > All of these solutions have in common that the API to locate the > implementation requires some notion of what class loader to search. I don't think so. You can enumerate all implementations. Sure, it would be more efficient to prevent instantiating unneeded classes and select just the right one, but that is something ServiceLoader does not handle[1] in general, as far as I can tell. -jt [1] One of the reasons NetBeans use Lookup which can handle declarative services as demonstrated at http://wiki.apidesign.org/wiki/CompileTimeCache From david.lloyd at redhat.com Wed Feb 22 09:39:25 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 22 Feb 2012 11:39:25 -0600 Subject: Still driving off the cliff In-Reply-To: <201202221814.23826.jaroslav.tulach@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> Message-ID: <4F45284D.2070104@redhat.com> I disagree entirely with this entire line of thinking. A Java module system should NOT be about writing a container which resolves dependencies and injects values! The Java world does not need yet another OSGi or yet another IoC container. And the Java world definitely DOES NOT need a module system that requires special tools and indexes in order to install and run anything! What is the precedent in other languages? Who would possibly want this kind of API? End users just want to be able to say "I need these modules". They don't want to detect service implementations from their capabilities, they just want to say "give me this implementation". And they definitely don't want their application blindsided by globally installed services! This reminds me so much of JUL, where a complete API was designed and implemented without even talking to anyone who actually has experience with logging frameworks. The end result is an API that nobody uses and everyone has to work around. Guys, *think* about the end user. The end user wants to be able to install and use modules without any special tools required, just like most other languages. The end user wants to be able to overlay their own modules in their home directories, just like most other languages. The end user wants to be able to have application-specific module collections for their application, just like most other languages. The user does NOT want to do a lot of configuration to get a module off the ground. The user can *understand* the concept of a class's initiating class loader if you *let* them. Service loading should normally be relative to the module that is doing the loading, or the application which is being run, *at the user's option*. Let them specify the class loader they want to load relative to. It works well, we've used that technique extensively and people seem to understand it. We have *never* found an effective and robust use for provides/requires capabilities in the real world - there's always a price to be paid which could have been avoided using a simpler solution. Think simplicity, think determinism, think bottom-up design. We don't need more abstractions and rules, we need fewer! By having each module import only the modules it uses (including, if desired, implementation modules for services), ServiceLoader continues to work excellently *as it is today* with no modifications whatsoever! In other words, yes ServiceLoader handles that just fine as it is today! Let the *user* decide the scope for searching for service implementations. Even TCCL, much maligned as it is, is still effective (arguably a hell of a lot more so) in a simple modular environment, if only as an indicator of what application module is being executed. This is completely and perfectly aligned with its use in JavaEE. Having API variants which use TCCL and explicit class loader specification is perfectly reasonable and entirely regular. It's one thing to acknowledge that certain design decisions were possibly mistakes. But it's another to deal with that fact by pretending they never happened. JavaSE as it is right now is not perfect but existing infrastructure can be leveraged a lot more than it is by Jigsaw, and to much better effect I might add. I know none of you guys really take JBoss Modules seriously but *please* do so. It is a very realistic, powerful, performant, and effective depiction of what an SE module system could be. It's out there in the wild, and it works very well, leveraging existing concepts such as TCCL and explicit class loader specification. No new service loader implementations are wanted or needed. At least, not with a module system as its excuse. Would my ideal SE module system look exactly like JBoss Modules? No way - there are definitely things I would want to do differently in the JDK. But the *concepts* are proven to be powerful and effective. And those critical concepts do not include provides/requires resolution OR global module or package registries OR special installation tooling OR any language changes whatsoever! So lets not pretend that *any* of that is needed to make a module system that is fast and effective. In fact you can add to the features list "easy to use", "manageable without special tooling", and "completely customizable". You don't have to throw away every existing concept every time you add a new one. It's far better to find what already exists that fits in to your new idea - and let me tell you, the more that fits, the better, because you'll have happier users who have a better idea of what the hell is going on. This service loader thing is just the latest example of you guys running amok with unnecessary new concepts. Why reinvent this particular wheel, when a module system is all you need to make the old one work to its fullest potential? On 02/22/2012 11:14 AM, Jaroslav Tulach wrote: > Hello David. > >> ## 20.?2.?2012 15:06:19 ##< >> 1) There is only one implementation which is used system-wide (this is >> your "services as singletons" scenario). > > Given your following comment ... > >> If a service is indeed a true singleton >> in every sense (which corresponds to case #1), then the simplest >> solution is to have the API import its implementation (or at least >> import its services resources in order to be able to locate it) and use >> its own class loader to locate it. > > ... I don't think this is injectable singleton example. Of course if you have > a singleton and it is supposed to have just a single implementation, then let > the API instantiate the implementation using "new". You can even put the > singleton API and its implementation into the same module. No reason to have > anything modular, imho. > >> 2) There are multiple implementations, however normally only one >> implementation is selected for the entire application. > > This is probably what I call injectable singleton: > http://wiki.apidesign.org/wiki/Injectable_Singleton#Initialize > > In contrast to case #1 it makes sense to use modularity here and separate the > singleton API into one module and put the implementation into other(s). > >> 3) There are multiple implementations, but each module may need to >> choose a different implementation. > >> If a service is typically per-module (case #3) then each module would >> import (at run time) its preferred implementation and use its own class >> loader to search for it. > > It will be better if the classloading tricks are eliminated as Jesse and Alan > wrote. Imho it may be sufficient to get all instances in the system and > somehow select the right one by querying its capabilities (e.g. > getSupportedXYZ(), etc.). > >> 4) There are multiple implementations, however implementations carry >> semantic meaning and generally must therefore be selected by some >> identifier. > >> Note that this case is unique in >> that the conceptual service dependency is not just a base type to be >> implemented, but it also has a "flavor" component to specify behavior >> characteristics. > > Actually NetBeans has an example of this style as well. The editor guards API > http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor- > guards/overview-summary.html > benefits from the fact that requires/provides are just string tokens (not a > class names). One registers the service capable to work for Java and then uses > > provides token org.netbeans.api.editor.guards.Java; > > Users of the editor guards API wanting to deal with Java then use: > > /* guarantees editor guards API is on classpath */ > requires org.netbeans.api.editor.guards; > /* guarantees the Java implementation will be found using ServiceLoader */ > requires token org.netbeans.api.editor.guards.Java; > >> If a service's behavior varies by implementation (case #4), as is the >> case for cryptographic, digest, and other security APIs (where the >> algorithm is significant to determining the behavior of the >> implementation) and several third-party APIs, then the application must >> import the implementations which it uses > > A cryptography module providing SHA implementation would use something like > > provides token java.security.MessageDigest.SHA > >> All of these solutions have in common that the API to locate the >> implementation requires some notion of what class loader to search. > > I don't think so. You can enumerate all implementations. Sure, it would be > more efficient to prevent instantiating unneeded classes and select just the > right one, but that is something ServiceLoader does not handle[1] in general, > as far as I can tell. > > -jt > > [1] One of the reasons NetBeans use Lookup which can handle declarative > services as demonstrated at http://wiki.apidesign.org/wiki/CompileTimeCache > -- - DML From forax at univ-mlv.fr Wed Feb 22 10:05:16 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 22 Feb 2012 19:05:16 +0100 Subject: Still driving off the cliff In-Reply-To: <4F45284D.2070104@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> Message-ID: <4F452E5C.2080405@univ-mlv.fr> On 02/22/2012 06:39 PM, David M. Lloyd wrote: > I disagree entirely with this entire line of thinking. A Java module > system should NOT be about writing a container which resolves > dependencies and injects values! The Java world does not need yet > another OSGi or yet another IoC container. > > And the Java world definitely DOES NOT need a module system that > requires special tools and indexes in order to install and run > anything! What is the precedent in other languages? Who would > possibly want this kind of API? End users just want to be able to say > "I need these modules". They don't want to detect service > implementations from their capabilities, they just want to say "give > me this implementation". And they definitely don't want their > application blindsided by globally installed services! > > This reminds me so much of JUL, where a complete API was designed and > implemented without even talking to anyone who actually has experience > with logging frameworks. The end result is an API that nobody uses > and everyone has to work around. Guys, *think* about the end user. > > The end user wants to be able to install and use modules without any > special tools required, just like most other languages. The end user > wants to be able to overlay their own modules in their home > directories, just like most other languages. The end user wants to be > able to have application-specific module collections for their > application, just like most other languages. > > The user does NOT want to do a lot of configuration to get a module > off the ground. The user can *understand* the concept of a class's > initiating class loader if you *let* them. Service loading should > normally be relative to the module that is doing the loading, or the > application which is being run, *at the user's option*. Let them > specify the class loader they want to load relative to. It works > well, we've used that technique extensively and people seem to > understand it. > > We have *never* found an effective and robust use for > provides/requires capabilities in the real world - there's always a > price to be paid which could have been avoided using a simpler solution. > > Think simplicity, think determinism, think bottom-up design. We don't > need more abstractions and rules, we need fewer! By having each > module import only the modules it uses (including, if desired, > implementation modules for services), ServiceLoader continues to work > excellently *as it is today* with no modifications whatsoever! In > other words, yes ServiceLoader handles that just fine as it is today! > > Let the *user* decide the scope for searching for service > implementations. Even TCCL, much maligned as it is, is still > effective (arguably a hell of a lot more so) in a simple modular > environment, if only as an indicator of what application module is > being executed. This is completely and perfectly aligned with its use > in JavaEE. Having API variants which use TCCL and explicit class > loader specification is perfectly reasonable and entirely regular. > > It's one thing to acknowledge that certain design decisions were > possibly mistakes. But it's another to deal with that fact by > pretending they never happened. JavaSE as it is right now is not > perfect but existing infrastructure can be leveraged a lot more than > it is by Jigsaw, and to much better effect I might add. > > I know none of you guys really take JBoss Modules seriously but > *please* do so. It is a very realistic, powerful, performant, and > effective depiction of what an SE module system could be. It's out > there in the wild, and it works very well, leveraging existing > concepts such as TCCL and explicit class loader specification. No new > service loader implementations are wanted or needed. At least, not > with a module system as its excuse. > > Would my ideal SE module system look exactly like JBoss Modules? No > way - there are definitely things I would want to do differently in > the JDK. But the *concepts* are proven to be powerful and effective. > And those critical concepts do not include provides/requires > resolution OR global module or package registries OR special > installation tooling OR any language changes whatsoever! So lets not > pretend that *any* of that is needed to make a module system that is > fast and effective. In fact you can add to the features list "easy to > use", "manageable without special tooling", and "completely > customizable". > > You don't have to throw away every existing concept every time you add > a new one. It's far better to find what already exists that fits in > to your new idea - and let me tell you, the more that fits, the > better, because you'll have happier users who have a better idea of > what the hell is going on. This service loader thing is just the > latest example of you guys running amok with unnecessary new > concepts. Why reinvent this particular wheel, when a module system is > all you need to make the old one work to its fullest potential? David, you have my vote on this issue. ServiceLoader API is enough. cheers, R?mi > > On 02/22/2012 11:14 AM, Jaroslav Tulach wrote: >> Hello David. >> >>> ## 20.?2.?2012 15:06:19 ##< >>> 1) There is only one implementation which is used system-wide (this is >>> your "services as singletons" scenario). >> >> Given your following comment ... >> >>> If a service is indeed a true singleton >>> in every sense (which corresponds to case #1), then the simplest >>> solution is to have the API import its implementation (or at least >>> import its services resources in order to be able to locate it) and use >>> its own class loader to locate it. >> >> ... I don't think this is injectable singleton example. Of course if >> you have >> a singleton and it is supposed to have just a single implementation, >> then let >> the API instantiate the implementation using "new". You can even put the >> singleton API and its implementation into the same module. No reason >> to have >> anything modular, imho. >> >>> 2) There are multiple implementations, however normally only one >>> implementation is selected for the entire application. >> >> This is probably what I call injectable singleton: >> http://wiki.apidesign.org/wiki/Injectable_Singleton#Initialize >> >> In contrast to case #1 it makes sense to use modularity here and >> separate the >> singleton API into one module and put the implementation into other(s). >> >>> 3) There are multiple implementations, but each module may need to >>> choose a different implementation. >> >>> If a service is typically per-module (case #3) then each module would >>> import (at run time) its preferred implementation and use its own class >>> loader to search for it. >> >> It will be better if the classloading tricks are eliminated as Jesse >> and Alan >> wrote. Imho it may be sufficient to get all instances in the system and >> somehow select the right one by querying its capabilities (e.g. >> getSupportedXYZ(), etc.). >> >>> 4) There are multiple implementations, however implementations carry >>> semantic meaning and generally must therefore be selected by some >>> identifier. >> >>> Note that this case is unique in >>> that the conceptual service dependency is not just a base type to be >>> implemented, but it also has a "flavor" component to specify behavior >>> characteristics. >> >> Actually NetBeans has an example of this style as well. The editor >> guards API >> http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-editor- >> guards/overview-summary.html >> benefits from the fact that requires/provides are just string tokens >> (not a >> class names). One registers the service capable to work for Java and >> then uses >> >> provides token org.netbeans.api.editor.guards.Java; >> >> Users of the editor guards API wanting to deal with Java then use: >> >> /* guarantees editor guards API is on classpath */ >> requires org.netbeans.api.editor.guards; >> /* guarantees the Java implementation will be found using >> ServiceLoader */ >> requires token org.netbeans.api.editor.guards.Java; >> >>> If a service's behavior varies by implementation (case #4), as is the >>> case for cryptographic, digest, and other security APIs (where the >>> algorithm is significant to determining the behavior of the >>> implementation) and several third-party APIs, then the application must >>> import the implementations which it uses >> >> A cryptography module providing SHA implementation would use >> something like >> >> provides token java.security.MessageDigest.SHA >> >>> All of these solutions have in common that the API to locate the >>> implementation requires some notion of what class loader to search. >> >> I don't think so. You can enumerate all implementations. Sure, it >> would be >> more efficient to prevent instantiating unneeded classes and select >> just the >> right one, but that is something ServiceLoader does not handle[1] in >> general, >> as far as I can tell. >> >> -jt >> >> [1] One of the reasons NetBeans use Lookup which can handle declarative >> services as demonstrated at >> http://wiki.apidesign.org/wiki/CompileTimeCache >> > > From david.bosschaert at gmail.com Wed Feb 22 11:16:54 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Wed, 22 Feb 2012 19:16:54 +0000 Subject: Building Jigsaw on Fedora 16 Message-ID: Hi all, Just wondering what might be the issue here. When, in a jigsaw clone, I do 'make sanity' on Fedora 16 I get the following error message, while on Ubuntu it seems to work fine. Anyone know how I can build on Fedora? $ make sanity ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=/home/david/hg/jigsaw_01/jdk JDK_MAKE_SHARED_DIR=/home/david/hg/jigsaw_01/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.8.0-internal-david_2012_02_22_19_10-b00 PREVIOUS_JDK_VERSION=1.7.0 JDK_VERSION=1.8.0 JDK_MKTG_VERSION=8 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=7 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 ALT_OUTPUTDIR=/home/david/hg/jigsaw_01/build/linux-i586 ALT_LANGTOOLS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/langtools/dist ALT_CORBA_DIST=/home/david/hg/jigsaw_01/build/linux-i586/corba/dist ALT_JAXP_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxp/dist ALT_JAXWS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=/home/david/hg/jigsaw_01/build/linux-i586/hotspot/import BUILD_MODULES=all BUILD_HOTSPOT=true ; ) /bin/sh: line 0: [: /bin/sh:: integer expression expected /bin/sh: line 0: [: /bin/sh:: integer expression expected /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected /bin/sh: line 0: [: No: integer expression expected /bin/sh: line 0: [: No: integer expression expected make[1]: Entering directory `/home/david/hg/jigsaw_01/jdk/make' /home/david/hg/jigsaw_01/jdk/make/common/shared/Sanity.gmk:857: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. make[1]: Leaving directory `/home/david/hg/jigsaw_01/jdk/make' make: *** [jdk-sanity] Error 2 Thanks, David From Alan.Bateman at oracle.com Wed Feb 22 12:16:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 20:16:48 +0000 Subject: Still driving off the cliff In-Reply-To: <4F45284D.2070104@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> Message-ID: <4F454D30.2080900@oracle.com> On 22/02/2012 17:39, David M. Lloyd wrote: > : > > And the Java world definitely DOES NOT need a module system that > requires special tools and indexes in order to install and run > anything! What is the precedent in other languages? I think some tools will be required but they to be as simple as using apt-get to install a native package. > Who would possibly want this kind of API? End users just want to be > able to say "I need these modules". They don't want to detect service > implementations from their capabilities, they just want to say "give > me this implementation". And they definitely don't want their > application blindsided by globally installed services! With ServiceLoader today then the selection of the provider implementation is done by whoever is using ServiceLoader API. In one of your mails you mentioned an example from the JDK, namely NIO, where there can be multiple file system provider installed. For that example the JDK ships with two provider implementations and the API selects the providers based on a URI scheme. Other APIs have other ways based on the provider's capabilities. There have been calls over the years to provide support for selecting providers based on capabilities or some meta data but I don't see us going there in Jigsaw. All we're doing is making it possible to package service providers as modules and to makes them usable with the ServiceLoader API. > : > > Think simplicity, think determinism, think bottom-up design. We don't > need more abstractions and rules, we need fewer! By having each > module import only the modules it uses (including, if desired, > implementation modules for services), ServiceLoader continues to work > excellently *as it is today* with no modifications whatsoever! In > other words, yes ServiceLoader handles that just fine as it is today! ServiceLoader is class loader centric and isn't well really suited to a world where there isn't a class path and delegation that we have today. I think it will have to change to work in the modules world. For now, we've changed it so that the ServiceLoader.load and loadInstalled methods return a ServiceLoader that iterates over the provider implementations that supply (or import to use your term) the user of the API. It works as before in legacy (no modules) mode. Once we have more complete support for reification then once could envisage containers (such as app servers) linking in service providers for specific applications running in the container. Whether that involves ServiceLoader or not isn't clear at this point. -Alan. From mandy.chung at oracle.com Wed Feb 22 12:27:45 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 22 Feb 2012 12:27:45 -0800 Subject: configuration being stored for modules that don't have entry points. In-Reply-To: <4F451B54.7040109@oracle.com> References: <4F451B54.7040109@oracle.com> Message-ID: <4F454FC1.5020303@oracle.com> Alan, I agree with you that both of these install methods should be consistent. As for your patch, should it call configure(res.modulesNeeded()) instead of configure(null)? That's what the install(Collection....) method calls. Although the current implementation ignores the given mids for the installed modules, ultimately we want to re-generate the configurations according some policy which will probably be smart to take the list of installed modules into account. On 2/22/2012 8:44 AM, Alan Bateman wrote: > Mandy - I need a sanity check on a minor change. The issue is that > modules installed via install(Resolution,boolean) method are getting a > stored configuration even when they don't have an entry point. I > noticed this when chatting with David Holmes about the size of the > jdk.tls module. In his environment the module was downloaded from a > repository and so was installed via this install method that was > larger than when installed from a jmod file. It might be my issue of incorrect reading of the code - this install method (from a given Resolution) only configures one root module while the install from jmod files configures all root modules in the current prototype. I would have thought it's smaller. Probably I'm missing some key point here - can you help and explain? Thanks Mandy > It's a clearly a policy issue as to whether we re-generate the > configuration for all modules after installing some modules but as we > do it when installing jmods then it's probably consistent to do the > same here - do you agree? > > -Alan > > diff --git a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > --- a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > +++ b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > @@ -1486,9 +1486,7 @@ > > // Configure > // > - Configuration cf > - = Configurator.configure(this, res); > - new StoredConfiguration(findModuleDir(root.id()), cf).store(); > + configure(null); > } > > @Override > From david.lloyd at redhat.com Wed Feb 22 12:36:36 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 22 Feb 2012 14:36:36 -0600 Subject: Still driving off the cliff In-Reply-To: <4F454D30.2080900@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> Message-ID: <4F4551D4.9050407@redhat.com> On 02/22/2012 02:16 PM, Alan Bateman wrote: > On 22/02/2012 17:39, David M. Lloyd wrote: >> : >> >> And the Java world definitely DOES NOT need a module system that >> requires special tools and indexes in order to install and run >> anything! What is the precedent in other languages? > I think some tools will be required but they to be as simple as using > apt-get to install a native package. > >> Who would possibly want this kind of API? End users just want to be >> able to say "I need these modules". They don't want to detect service >> implementations from their capabilities, they just want to say "give >> me this implementation". And they definitely don't want their >> application blindsided by globally installed services! > With ServiceLoader today then the selection of the provider > implementation is done by whoever is using ServiceLoader API. In one of > your mails you mentioned an example from the JDK, namely NIO, where > there can be multiple file system provider installed. For that example > the JDK ships with two provider implementations and the API selects the > providers based on a URI scheme. Other APIs have other ways based on the > provider's capabilities. There have been calls over the years to provide > support for selecting providers based on capabilities or some meta data > but I don't see us going there in Jigsaw. All we're doing is making it > possible to package service providers as modules and to makes them > usable with the ServiceLoader API. Just to clarify I was talking about the selector provider API, not the filesystem API (I'm old school like that). >> Think simplicity, think determinism, think bottom-up design. We don't >> need more abstractions and rules, we need fewer! By having each module >> import only the modules it uses (including, if desired, implementation >> modules for services), ServiceLoader continues to work excellently *as >> it is today* with no modifications whatsoever! In other words, yes >> ServiceLoader handles that just fine as it is today! > > ServiceLoader is class loader centric and isn't well really suited to a > world where there isn't a class path and delegation that we have today. But the modular world *is* class loader centric, that's my whole point. Java is already 80% of the way towards being modular as of Java 7. All it is missing is a multiple-delegate base class loader and a module loader concept which creates class loaders for modules. A 1:1 module:class loader mapping is completely natural on many levels, and I have yet to see a compelling argument to the contrary. And in this model ServiceLoader works like a champ. > I think it will have to change to work in the modules world. For now, > we've changed it so that the ServiceLoader.load and loadInstalled > methods return a ServiceLoader that iterates over the provider > implementations that supply (or import to use your term) the user of the > API. It works as before in legacy (no modules) mode. My point is that by recognizing that a class loader *already* is a module by another name, you should realize that no new API is needed and no dual-mode situation should even arise. > Once we have more complete support for reification then once could envisage containers > (such as app servers) linking in service providers for specific > applications running in the container. Whether that involves > ServiceLoader or not isn't clear at this point. We already have that today. Granted TCCL is considered ugly by some, but all it's really missing is a clear definition of what it *means*. That's what most users (and classically, framework developers) don't get. It *means* your current application module. That's the only meaning that makes any sense. And there's no way that TCCL is going to go away just because you deprecated it and created "new" mode versus "old" mode. It just needs to be formalized. On app startup, set TCCL to the main application module's class loader. In JavaEE, set it to the currently executing deployment. Consistent and simple. And it fits the existing java.util.ServiceLoader like a glove. -- - DML From Alan.Bateman at oracle.com Wed Feb 22 13:19:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 21:19:05 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: References: Message-ID: <4F455BC9.4090300@oracle.com> On 22/02/2012 19:16, David Bosschaert wrote: > Hi all, > > Just wondering what might be the issue here. > > When, in a jigsaw clone, I do 'make sanity' on Fedora 16 I get the > following error message, while on Ubuntu it seems to work fine. Anyone > know how I can build on Fedora? > > $ make sanity > ( cd ./jdk/make&& \ > make sanity HOTSPOT_IMPORT_CHECK=false > JDK_TOPDIR=/home/david/hg/jigsaw_01/jdk > JDK_MAKE_SHARED_DIR=/home/david/hg/jigsaw_01/jdk/make/common/shared > EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 > TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 > JDK_BUILD_NUMBER=b00 > FULL_VERSION=1.8.0-internal-david_2012_02_22_19_10-b00 > PREVIOUS_JDK_VERSION=1.7.0 JDK_VERSION=1.8.0 JDK_MKTG_VERSION=8 > JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 > PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=7 > PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 > ALT_OUTPUTDIR=/home/david/hg/jigsaw_01/build/linux-i586 > ALT_LANGTOOLS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/langtools/dist > ALT_CORBA_DIST=/home/david/hg/jigsaw_01/build/linux-i586/corba/dist > ALT_JAXP_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxp/dist > ALT_JAXWS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxws/dist > ALT_HOTSPOT_IMPORT_PATH=/home/david/hg/jigsaw_01/build/linux-i586/hotspot/import > BUILD_MODULES=all BUILD_HOTSPOT=true ; ) > /bin/sh: line 0: [: /bin/sh:: integer expression expected > /bin/sh: line 0: [: /bin/sh:: integer expression expected > /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected > /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected > /bin/sh: line 0: [: No: integer expression expected > /bin/sh: line 0: [: No: integer expression expected > make[1]: Entering directory `/home/david/hg/jigsaw_01/jdk/make' > /home/david/hg/jigsaw_01/jdk/make/common/shared/Sanity.gmk:857: *** > missing separator (did you mean TAB instead of 8 spaces?). Stop. > make[1]: Leaving directory `/home/david/hg/jigsaw_01/jdk/make' > make: *** [jdk-sanity] Error 2 > > Thanks, > > David It doesn't look like you've set the bootstrap JDK, try: make ALT_BOOTDIR= sanity and see if you get further. -Alan From Alan.Bateman at oracle.com Wed Feb 22 13:57:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Feb 2012 21:57:52 +0000 Subject: configuration being stored for modules that don't have entry points. In-Reply-To: <4F454FC1.5020303@oracle.com> References: <4F451B54.7040109@oracle.com> <4F454FC1.5020303@oracle.com> Message-ID: <4F4564E0.2010300@oracle.com> On 22/02/2012 20:27, Mandy Chung wrote: > Alan, > > I agree with you that both of these install methods should be > consistent. As for your patch, should it call > configure(res.modulesNeeded()) instead of configure(null)? That's what > the install(Collection....) method calls. Although the current > implementation ignores the given mids for the installed modules, > ultimately we want to re-generate the configurations according some > policy which will probably be smart to take the list of installed > modules into account. > > It might be my issue of incorrect reading of the code - this install > method (from a given Resolution) only configures one root module while > the install from jmod files configures all root modules in the current > prototype. I would have thought it's smaller. Probably I'm missing > some key point here - can you help and explain? You're right, we should pass in the set of modules, even if it's just not used yet. The current code creates a configuration for the root module without checking if it has an entry point. Also the installation may have includes modules that would change the configuration of other modules. So for now I think re-generating the configuration of all modules with entry points is okay. Clearly there needs to be policy discussion. -Alan diff --git a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java --- a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java +++ b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java @@ -1486,9 +1486,7 @@ // Configure // - Configuration cf - = Configurator.configure(this, res); - new StoredConfiguration(findModuleDir(root.id()), cf).store(); + configure(res.modulesNeeded()); } @Override @@ -1538,7 +1536,7 @@ * {@code null} if the configuration of every root module * should be (re)computed */ - public void configure(List mids) + public void configure(Collection mids) throws ConfigurationException, IOException { // ## mids not used yet From mandy.chung at oracle.com Wed Feb 22 14:02:54 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 22 Feb 2012 14:02:54 -0800 Subject: configuration being stored for modules that don't have entry points. In-Reply-To: <4F4564E0.2010300@oracle.com> References: <4F451B54.7040109@oracle.com> <4F454FC1.5020303@oracle.com> <4F4564E0.2010300@oracle.com> Message-ID: <4F45660E.5000201@oracle.com> Looks good. Mandy On 2/22/2012 1:57 PM, Alan Bateman wrote: > diff --git a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > --- a/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > +++ b/src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java > @@ -1486,9 +1486,7 @@ > > // Configure > // > - Configuration cf > - = Configurator.configure(this, res); > - new StoredConfiguration(findModuleDir(root.id()), cf).store(); > + configure(res.modulesNeeded()); > } > > @Override > @@ -1538,7 +1536,7 @@ > * {@code null} if the configuration of every root module > * should be (re)computed > */ > - public void configure(List mids) > + public void configure(Collection mids) > throws ConfigurationException, IOException > { > // ## mids not used yet From chris.hegarty at oracle.com Thu Feb 23 02:53:49 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Feb 2012 10:53:49 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F4513B2.7060805@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> Message-ID: <4F461ABD.2080807@oracle.com> Alan, I updated the webrev as per review comments and also fixed two more failing tests ( and one was a "real" bug ;-) ) - Thread.sleep increased from 1 sec to 2 secs - org/openjdk/jigsaw/cli/timestamp-test.sh fails on windows SimpleLibrary.reIndex was not closing the handle to the modules classes archive, therefore the test could not do its necessary cleanup. I also removed some unnecessary args to jpkg in the test and added a warning for easier diagnosability (arguably this could be fatal). - org/openjdk/jigsaw/cli/signed-modular-jar.sh keystorePasswordURL did not contain the protocol scheme Updated webrev: http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.01/webrev/ -Chris. On 22/02/2012 16:11, Alan Bateman wrote: > On 22/02/2012 16:04, Chris Hegarty wrote: >> On 22/02/2012 15:43, Alan Bateman wrote: >>> ..... >>> Thanks for sorting these out, it was annoying for these tests not to be >>> pass on all platforms. >>> >>> In _RemoteRepository. testRemove the sleep is 1s but this may not be >>> sufficient to ensure a new time stamp (legacy FAT32 has a granularity of >>> 2s for example). >> >> Yes, I think 2 or 3 seconds would be better. >> >>> I'm curious about _RemoteRepositoryList.local as I would have thought >>> that we have many tests (in the networking area at least) that would >>> also fail if once could connect to the host name. >> >> This test was failing at L145 "assert rr.location().equals(u1);". >> RemoteRepository stores it's location() as a URI with a canonical host >> name ( where possible ). Since URI.equals does a string comparison, >> equalIgnoringCase, then the hosts need to be the same. >> > Okay, I didn't know which assert was failing. In that case it make sense. > > -Alan > From alan.bateman at oracle.com Thu Feb 23 03:24:21 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 23 Feb 2012 11:24:21 +0000 Subject: hg: jigsaw/jigsaw/jdk: Regenerate configurations for modules with entry points after installing modules Message-ID: <20120223112501.8D45C47654@hg.openjdk.java.net> Changeset: a23f0d50b86b Author: alanb Date: 2012-02-23 11:23 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/a23f0d50b86b Regenerate configurations for modules with entry points after installing modules Reviewed-by: mchung ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java From david.bosschaert at gmail.com Thu Feb 23 03:29:24 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Thu, 23 Feb 2012 11:29:24 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: <4F455BC9.4090300@oracle.com> References: <4F455BC9.4090300@oracle.com> Message-ID: Thanks Alan. Yes my bad for not sourcing the environment variables. I've set my ALT_BOOTDIR (and LANG=C) but I'm still getting this error around the spaces in Sanity.gmk. See below. Note that I didn't make any changes to the code... It seems to be the same issue that Julien Ponge ran into here: http://live.julien.ponge.info/84822905 Any ideas? Thanks, David $ make sanity ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=/home/david/hg/pj_230212/jdk JDK_MAKE_SHARED_DIR=/home/david/hg/pj_230212/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.8.0-internal-david_2012_02_23_11_24-b00 PREVIOUS_JDK_VERSION=1.7.0 JDK_VERSION=1.8.0 JDK_MKTG_VERSION=8 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=7 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 ALT_OUTPUTDIR=/home/david/hg/pj_230212/build/linux-i586 ALT_LANGTOOLS_DIST=/home/david/hg/pj_230212/build/linux-i586/langtools/dist ALT_CORBA_DIST=/home/david/hg/pj_230212/build/linux-i586/corba/dist ALT_JAXP_DIST=/home/david/hg/pj_230212/build/linux-i586/jaxp/dist ALT_JAXWS_DIST=/home/david/hg/pj_230212/build/linux-i586/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=/home/david/hg/pj_230212/build/linux-i586/hotspot/import BUILD_MODULES=all BUILD_HOTSPOT=true ; ) make[1]: Entering directory `/home/david/hg/pj_230212/jdk/make' /home/david/hg/pj_230212/jdk/make/common/shared/Sanity.gmk:857: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. make[1]: Leaving directory `/home/david/hg/pj_230212/jdk/make' make: *** [jdk-sanity] Error 2 On 22 February 2012 21:19, Alan Bateman wrote: > On 22/02/2012 19:16, David Bosschaert wrote: >> >> Hi all, >> >> Just wondering what might be the issue here. >> >> When, in a jigsaw clone, I do 'make sanity' on Fedora 16 I get the >> following error message, while on Ubuntu it seems to work fine. Anyone >> know how I can build on Fedora? >> >> $ make sanity >> ( cd ?./jdk/make&& ?\ >> ? make sanity HOTSPOT_IMPORT_CHECK=false >> JDK_TOPDIR=/home/david/hg/jigsaw_01/jdk >> JDK_MAKE_SHARED_DIR=/home/david/hg/jigsaw_01/jdk/make/common/shared >> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >> JDK_BUILD_NUMBER=b00 >> FULL_VERSION=1.8.0-internal-david_2012_02_22_19_10-b00 >> PREVIOUS_JDK_VERSION=1.7.0 JDK_VERSION=1.8.0 JDK_MKTG_VERSION=8 >> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 >> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=7 >> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 >> ALT_OUTPUTDIR=/home/david/hg/jigsaw_01/build/linux-i586 >> >> ALT_LANGTOOLS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/langtools/dist >> ALT_CORBA_DIST=/home/david/hg/jigsaw_01/build/linux-i586/corba/dist >> ALT_JAXP_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxp/dist >> ALT_JAXWS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxws/dist >> >> ALT_HOTSPOT_IMPORT_PATH=/home/david/hg/jigsaw_01/build/linux-i586/hotspot/import >> BUILD_MODULES=all BUILD_HOTSPOT=true ; ) >> /bin/sh: line 0: [: /bin/sh:: integer expression expected >> /bin/sh: line 0: [: /bin/sh:: integer expression expected >> /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected >> /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected >> /bin/sh: line 0: [: No: integer expression expected >> /bin/sh: line 0: [: No: integer expression expected >> make[1]: Entering directory `/home/david/hg/jigsaw_01/jdk/make' >> /home/david/hg/jigsaw_01/jdk/make/common/shared/Sanity.gmk:857: *** >> missing separator (did you mean TAB instead of 8 spaces?). ?Stop. >> make[1]: Leaving directory `/home/david/hg/jigsaw_01/jdk/make' >> make: *** [jdk-sanity] Error 2 >> >> Thanks, >> >> David > > It doesn't look like you've set the bootstrap JDK, try: > > make ALT_BOOTDIR= sanity > > and see if you get further. > > -Alan > > > From Alan.Bateman at oracle.com Thu Feb 23 03:32:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2012 11:32:38 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: References: <4F455BC9.4090300@oracle.com> Message-ID: <4F4623D6.1090908@oracle.com> On 23/02/2012 11:29, David Bosschaert wrote: > Thanks Alan. Yes my bad for not sourcing the environment variables. > > I've set my ALT_BOOTDIR (and LANG=C) but I'm still getting this error > around the spaces in Sanity.gmk. See below. Note that I didn't make > any changes to the code... > It seems to be the same issue that Julien Ponge ran into here: > http://live.julien.ponge.info/84822905 > Any ideas? > > Thanks, > > David > I don't have Fedora 16 at hand but what version is make (make --version)? We usually build with 3.81. Otherwise I'm not sure and we might need to move this thread to build-dev (I assume it's the same issue with a jdk8 build without the jigsaw patches). -Alan From david.bosschaert at gmail.com Thu Feb 23 03:41:22 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Thu, 23 Feb 2012 11:41:22 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: <4F4623D6.1090908@oracle.com> References: <4F455BC9.4090300@oracle.com> <4F4623D6.1090908@oracle.com> Message-ID: Actually it's not an issue with the plain JDK 8 build. On that one with the same environment setting 'make sanity' succeeds. Fedora 16 comes with GNU Make 3.82 so that's what I was using. Thanks, David On 23 February 2012 11:32, Alan Bateman wrote: > On 23/02/2012 11:29, David Bosschaert wrote: >> >> Thanks Alan. Yes my bad for not sourcing the environment variables. >> >> I've set my ALT_BOOTDIR (and LANG=C) but I'm still getting this error >> around the spaces in Sanity.gmk. See below. Note that I didn't make >> any changes to the code... >> It seems to be the same issue that Julien Ponge ran into here: >> http://live.julien.ponge.info/84822905 >> Any ideas? >> >> Thanks, >> >> David >> > I don't have Fedora 16 at hand but what version is make (make --version)? We > usually build with 3.81. Otherwise I'm not sure and we might need to move > this thread to build-dev (I assume it's the same issue with a jdk8 build > without the jigsaw patches). > > -Alan From david.holmes at oracle.com Thu Feb 23 04:03:15 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Feb 2012 22:03:15 +1000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: References: <4F455BC9.4090300@oracle.com> Message-ID: <4F462B03.8080200@oracle.com> So to ask the obvious ... On 23/02/2012 9:29 PM, David Bosschaert wrote: > /home/david/hg/pj_230212/jdk/make/common/shared/Sanity.gmk:857: *** > missing separator (did you mean TAB instead of 8 spaces?). Stop. Did you check line 857 to see if it has spaces instead of tab? David > make[1]: Leaving directory `/home/david/hg/pj_230212/jdk/make' > make: *** [jdk-sanity] Error 2 > > > On 22 February 2012 21:19, Alan Bateman wrote: >> On 22/02/2012 19:16, David Bosschaert wrote: >>> >>> Hi all, >>> >>> Just wondering what might be the issue here. >>> >>> When, in a jigsaw clone, I do 'make sanity' on Fedora 16 I get the >>> following error message, while on Ubuntu it seems to work fine. Anyone >>> know how I can build on Fedora? >>> >>> $ make sanity >>> ( cd ./jdk/make&& \ >>> make sanity HOTSPOT_IMPORT_CHECK=false >>> JDK_TOPDIR=/home/david/hg/jigsaw_01/jdk >>> JDK_MAKE_SHARED_DIR=/home/david/hg/jigsaw_01/jdk/make/common/shared >>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>> JDK_BUILD_NUMBER=b00 >>> FULL_VERSION=1.8.0-internal-david_2012_02_22_19_10-b00 >>> PREVIOUS_JDK_VERSION=1.7.0 JDK_VERSION=1.8.0 JDK_MKTG_VERSION=8 >>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 >>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=7 >>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 >>> ALT_OUTPUTDIR=/home/david/hg/jigsaw_01/build/linux-i586 >>> >>> ALT_LANGTOOLS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/langtools/dist >>> ALT_CORBA_DIST=/home/david/hg/jigsaw_01/build/linux-i586/corba/dist >>> ALT_JAXP_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxp/dist >>> ALT_JAXWS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxws/dist >>> >>> ALT_HOTSPOT_IMPORT_PATH=/home/david/hg/jigsaw_01/build/linux-i586/hotspot/import >>> BUILD_MODULES=all BUILD_HOTSPOT=true ; ) >>> /bin/sh: line 0: [: /bin/sh:: integer expression expected >>> /bin/sh: line 0: [: /bin/sh:: integer expression expected >>> /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected >>> /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected >>> /bin/sh: line 0: [: No: integer expression expected >>> /bin/sh: line 0: [: No: integer expression expected >>> make[1]: Entering directory `/home/david/hg/jigsaw_01/jdk/make' >>> /home/david/hg/jigsaw_01/jdk/make/common/shared/Sanity.gmk:857: *** >>> missing separator (did you mean TAB instead of 8 spaces?). Stop. >>> make[1]: Leaving directory `/home/david/hg/jigsaw_01/jdk/make' >>> make: *** [jdk-sanity] Error 2 >>> >>> Thanks, >>> >>> David >> >> It doesn't look like you've set the bootstrap JDK, try: >> >> make ALT_BOOTDIR= sanity >> >> and see if you get further. >> >> -Alan >> >> >> From Alan.Bateman at oracle.com Thu Feb 23 04:08:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2012 12:08:23 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: <4F462B03.8080200@oracle.com> References: <4F455BC9.4090300@oracle.com> <4F462B03.8080200@oracle.com> Message-ID: <4F462C37.1090900@oracle.com> On 23/02/2012 12:03, David Holmes wrote: > So to ask the obvious ... > > On 23/02/2012 9:29 PM, David Bosschaert wrote: >> /home/david/hg/pj_230212/jdk/make/common/shared/Sanity.gmk:857: *** >> missing separator (did you mean TAB instead of 8 spaces?). Stop. > > Did you check line 857 to see if it has spaces instead of tab? I checked it after seeing the second mail and it is spaces (so our fault). It may be that make 3.82 is less tolerant. David - can you replace it with a TAB and see if that sorts out your issue? -Alan From david.bosschaert at gmail.com Thu Feb 23 04:10:54 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Thu, 23 Feb 2012 12:10:54 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: <4F462B03.8080200@oracle.com> References: <4F455BC9.4090300@oracle.com> <4F462B03.8080200@oracle.com> Message-ID: It does, but I on Ubuntu (where I am actually able to build this) it also contains the spaces and the make sanity succeeds, maybe it's a difference between gmake 3.82 and gmake 3.81. In any case, it would be nice if we could build on Fedora 16. I'm currently trying Fedora 15 to see if that makes any difference. Cheers, David On 23 February 2012 12:03, David Holmes wrote: > So to ask the obvious ... > > > On 23/02/2012 9:29 PM, David Bosschaert wrote: >> >> /home/david/hg/pj_230212/jdk/make/common/shared/Sanity.gmk:857: *** >> missing separator (did you mean TAB instead of 8 spaces?). ?Stop. > > > Did you check line 857 to see if it has spaces instead of tab? > > David > > > >> make[1]: Leaving directory `/home/david/hg/pj_230212/jdk/make' >> make: *** [jdk-sanity] Error 2 >> >> >> On 22 February 2012 21:19, Alan Bateman ?wrote: >>> >>> On 22/02/2012 19:16, David Bosschaert wrote: >>>> >>>> >>>> Hi all, >>>> >>>> Just wondering what might be the issue here. >>>> >>>> When, in a jigsaw clone, I do 'make sanity' on Fedora 16 I get the >>>> following error message, while on Ubuntu it seems to work fine. Anyone >>>> know how I can build on Fedora? >>>> >>>> $ make sanity >>>> ( cd ?./jdk/make&& ? ?\ >>>> ? make sanity HOTSPOT_IMPORT_CHECK=false >>>> JDK_TOPDIR=/home/david/hg/jigsaw_01/jdk >>>> JDK_MAKE_SHARED_DIR=/home/david/hg/jigsaw_01/jdk/make/common/shared >>>> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 >>>> TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 >>>> JDK_BUILD_NUMBER=b00 >>>> FULL_VERSION=1.8.0-internal-david_2012_02_22_19_10-b00 >>>> PREVIOUS_JDK_VERSION=1.7.0 JDK_VERSION=1.8.0 JDK_MKTG_VERSION=8 >>>> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 >>>> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=7 >>>> PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 >>>> ALT_OUTPUTDIR=/home/david/hg/jigsaw_01/build/linux-i586 >>>> >>>> >>>> ALT_LANGTOOLS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/langtools/dist >>>> ALT_CORBA_DIST=/home/david/hg/jigsaw_01/build/linux-i586/corba/dist >>>> ALT_JAXP_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxp/dist >>>> ALT_JAXWS_DIST=/home/david/hg/jigsaw_01/build/linux-i586/jaxws/dist >>>> >>>> >>>> ALT_HOTSPOT_IMPORT_PATH=/home/david/hg/jigsaw_01/build/linux-i586/hotspot/import >>>> BUILD_MODULES=all BUILD_HOTSPOT=true ; ) >>>> /bin/sh: line 0: [: /bin/sh:: integer expression expected >>>> /bin/sh: line 0: [: /bin/sh:: integer expression expected >>>> /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected >>>> /bin/sh: line 0: [: /NO_BOOTDIR/bin/java:: integer expression expected >>>> /bin/sh: line 0: [: No: integer expression expected >>>> /bin/sh: line 0: [: No: integer expression expected >>>> make[1]: Entering directory `/home/david/hg/jigsaw_01/jdk/make' >>>> /home/david/hg/jigsaw_01/jdk/make/common/shared/Sanity.gmk:857: *** >>>> missing separator (did you mean TAB instead of 8 spaces?). ?Stop. >>>> make[1]: Leaving directory `/home/david/hg/jigsaw_01/jdk/make' >>>> make: *** [jdk-sanity] Error 2 >>>> >>>> Thanks, >>>> >>>> David >>> >>> >>> It doesn't look like you've set the bootstrap JDK, try: >>> >>> make ALT_BOOTDIR= ?sanity >>> >>> and see if you get further. >>> >>> -Alan >>> >>> >>> > From Alan.Bateman at oracle.com Thu Feb 23 04:16:14 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2012 12:16:14 +0000 Subject: Still driving off the cliff In-Reply-To: <4F4551D4.9050407@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> Message-ID: <4F462E0E.50009@oracle.com> On 22/02/2012 20:36, David M. Lloyd wrote: > : > Just to clarify I was talking about the selector provider API, not the > filesystem API (I'm old school like that). SelectorProvider is a case where the default provider is rarely (or ever) replaced but I don't mind using it as an example. Like other APIs it defines a way to override the VM-wide provider (via a system property in this case). Assuming the override mechanism is not used then it uses ServiceLoader in an attempt to find a provider implementation. If someone "installs" several implementations into the extensions directory then one of them will be used, exactly which one is not defined. An alternative would be to put them on the system class path, in which case it's more predictable. If ServiceLoader doesn't locate any provider implementations there is a fallback/default implementation. In the case of the JDK then we typically have a default implementation anyway and ServiceLoader is just used for cases where folks want to use alternative implementations. Now move to the modules world when there isn't a boot or system class path or extensions class loader. I've packaged my SelectorProvider implementation into a module and I'd like it to be used at runtime without using the override mechanism. The way it works currently in Jigsaw is that you install the module with the service provider and it will be linked as a service supplier to modules that require this service. In this case, it's the jdk.base module that requires this service. Clearly if someone installs another module that also provides a SelectorProvider implementation then it's like installing into the extensions directory in the current world; one will be chosen and there's a way to override it. In the implementation then the order is stable and doesn't change between runs. > > But the modular world *is* class loader centric, that's my whole > point. Java is already 80% of the way towards being modular as of > Java 7. All it is missing is a multiple-delegate base class loader and > a module loader concept which creates class loaders for modules. A > 1:1 module:class loader mapping is completely natural on many levels, > and I have yet to see a compelling argument to the contrary. And in > this model ServiceLoader works like a champ. I don't get your comment on being 80% there. The work we did in JDK7 was mostly on cleaning up dependencies in the implementation in preparation for the modularize effort. With Jigsaw then it's usually a 1-1 mapping between module and class loaders but we do have complications in the platform and it remains to be seen where that goes. In addition I'm not sure where the class loader relationship will be specified or not. > > My point is that by recognizing that a class loader *already* is a > module by another name, you should realize that no new API is needed > and no dual-mode situation should even arise. > > : > We already have that today. Granted TCCL is considered ugly by some, > but all it's really missing is a clear definition of what it *means*. > That's what most users (and classically, framework developers) don't > get. It *means* your current application module. That's the only > meaning that makes any sense. And there's no way that TCCL is going > to go away just because you deprecated it and created "new" mode > versus "old" mode. It just needs to be formalized. On app startup, > set TCCL to the main application module's class loader. In JavaEE, > set it to the currently executing deployment. Consistent and simple. > And it fits the existing java.util.ServiceLoader like a glove. > As I said, I think ServiceLoader has to change. The loadInstalled(Class) method is specified to use class loaders that don't make sense with modules. The load(Class) method is specified to use the threadContextClassLoader but what if that has been set to null or ClassLoader.getSystemClassLoader (we have many of these in JDK). Same thing with load(Class,ClassLoader). For now these methods are using the module class loader of the caller. If the caller's module declares that it requires the service then it gets back a ServiceLoader to iterate over the implementations of that service. On the thread context class loader then my view is that it was a mistake. It's been a continuous source of problems, security issues included. -Alan. From david.bosschaert at gmail.com Thu Feb 23 04:25:17 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Thu, 23 Feb 2012 12:25:17 +0000 Subject: Building Jigsaw on Fedora 16 In-Reply-To: <4F462C37.1090900@oracle.com> References: <4F455BC9.4090300@oracle.com> <4F462B03.8080200@oracle.com> <4F462C37.1090900@oracle.com> Message-ID: On 23 February 2012 12:08, Alan Bateman wrote: > On 23/02/2012 12:03, David Holmes wrote: >> >> So to ask the obvious ... >> >> On 23/02/2012 9:29 PM, David Bosschaert wrote: >>> >>> /home/david/hg/pj_230212/jdk/make/common/shared/Sanity.gmk:857: *** >>> missing separator (did you mean TAB instead of 8 spaces?). ?Stop. >> >> >> Did you check line 857 to see if it has spaces instead of tab? > > I checked it after seeing the second mail and it is spaces (so our fault). > It may be that make 3.82 is less tolerant. > > David - can you replace it with a TAB and see if that sorts out your issue? > > -Alan Yeah, that seems to fix it - at least for 'make sanity'... I see that there are quite a number of places where the tabs are represented as 8 spaces. Quite odd for such a minor update in gmake to change this... David From Alan.Bateman at oracle.com Thu Feb 23 05:35:58 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2012 13:35:58 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F461ABD.2080807@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> <4F461ABD.2080807@oracle.com> Message-ID: <4F4640BE.6000704@oracle.com> On 23/02/2012 10:53, Chris Hegarty wrote: > Alan, > > I updated the webrev as per review comments and also fixed two more > failing tests ( and one was a "real" bug ;-) ) > > - Thread.sleep increased from 1 sec to 2 secs > > - org/openjdk/jigsaw/cli/timestamp-test.sh fails on windows > > SimpleLibrary.reIndex was not closing the handle to the modules > classes archive, therefore the test could not do its necessary > cleanup. I also removed some unnecessary args to jpkg in the test > and added a warning for easier diagnosability (arguably this could > be fatal). > > - org/openjdk/jigsaw/cli/signed-modular-jar.sh > > keystorePasswordURL did not contain the protocol scheme > > Updated webrev: > http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.01/webrev/ > In signed-module-jar.sh then ${SRC} is a file path, not a URL path this is still fragile. In cli/TimestampTest.java then I assume that the reset method should check the return from deleteAll rather than checking if moduleDir exists again. Otherwise I think this is fine and I'm happy to push it for you. -Alan From jaroslav.tulach at oracle.com Thu Feb 23 07:38:35 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Thu, 23 Feb 2012 16:38:35 +0100 Subject: Order of Services was: Still driving off the cliff In-Reply-To: <4F462E0E.50009@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> Message-ID: <201202231638.35356.jaroslav.tulach@oracle.com> >## Alan wrote on 23.?2.?2012 13:16:14 ##< > service. Clearly if someone installs another module that also provides a > SelectorProvider implementation then it's like installing into the > extensions directory in the current world; one will be chosen and > there's a way to override it. In the implementation then the order is > stable and doesn't change between runs. NetBeans solves problem this by positioning. The http://bits.netbeans.org/dev/javadoc/org-openide-util- lookup/org/openide/util/lookup/ServiceProvider.html annotation (that generates the META-INF/services/xyz file) has attribute position. ServiceLoader could be honor such position indicator and sort services accordingly. > As I said, I think ServiceLoader has to change. > The load(Class) method is specified to use the > threadContextClassLoader but what if that has been set to null or > ClassLoader.getSystemClassLoader NetBeans solves[1] this problem by registering special Thread.cCL that can see classes from all enabled modules in the running VM. Thus by default using ServiceLoader.load finds all services provided by all enabled modules. > On the thread context class loader then my view is that it was a > mistake. It's been a continuous source of problems, security issues > included. -jt [1] Sure, unless somebody calls Thread.setCCL. From chris.hegarty at oracle.com Thu Feb 23 13:13:48 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Feb 2012 21:13:48 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F4640BE.6000704@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> <4F461ABD.2080807@oracle.com> <4F4640BE.6000704@oracle.com> Message-ID: <4F46AC0C.5030003@oracle.com> On 02/23/12 01:35 PM, Alan Bateman wrote: > ..... > In signed-module-jar.sh then ${SRC} is a file path, not a URL path this > is still fragile. - test/org/openjdk/jigsaw/cli/signed-modular-jar.sh test/org/openjdk/jigsaw/cli/signed-module.sh I updated the above tests to correctly generate the URL from the given path. I started down the path of supporting paths with spaces! This is more work that I expected! If we really need it we can revisit it. > In cli/TimestampTest.java then I assume that the reset method should > check the return from deleteAll rather than checking if moduleDir exists > again. Done. > Otherwise I think this is fine and I'm happy to push it for you. Updated Webrev: http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.02/webrev/ -Chris. > -Alan > From mark.reinhold at oracle.com Thu Feb 23 13:37:52 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Feb 2012 21:37:52 +0000 Subject: hg: jigsaw/jigsaw/jdk: Fix spaces/tabs in Sanity.gmk to make build work with gmake 3.82 Message-ID: <20120223213810.AB68647673@hg.openjdk.java.net> Changeset: 258a4ac1a2a3 Author: davidb Date: 2012-02-23 20:13 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/258a4ac1a2a3 Fix spaces/tabs in Sanity.gmk to make build work with gmake 3.82 ! make/common/shared/Sanity.gmk From Alan.Bateman at oracle.com Thu Feb 23 13:57:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Feb 2012 21:57:41 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F46AC0C.5030003@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> <4F461ABD.2080807@oracle.com> <4F4640BE.6000704@oracle.com> <4F46AC0C.5030003@oracle.com> Message-ID: <4F46B655.2040900@oracle.com> On 23/02/2012 21:13, Chris Hegarty wrote: > On 02/23/12 01:35 PM, Alan Bateman wrote: >> ..... >> In signed-module-jar.sh then ${SRC} is a file path, not a URL path this >> is still fragile. > > - test/org/openjdk/jigsaw/cli/signed-modular-jar.sh > test/org/openjdk/jigsaw/cli/signed-module.sh > > I updated the above tests to correctly generate the URL from the > given path. > > I started down the path of supporting paths with spaces! This is > more work that I expected! If we really need it we can revisit it. What you have is fine, it fixes the main issues and means the tests (except perhaps hello-native) are working on all platforms. So I'm okay with the changes and will be happy to push them for you. -Alan From chris.hegarty at oracle.com Thu Feb 23 13:56:49 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 23 Feb 2012 21:56:49 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F46B655.2040900@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> <4F461ABD.2080807@oracle.com> <4F4640BE.6000704@oracle.com> <4F46AC0C.5030003@oracle.com> <4F46B655.2040900@oracle.com> Message-ID: <4F46B621.1050400@oracle.com> On 02/23/12 09:57 PM, Alan Bateman wrote: > ... > What you have is fine, it fixes the main issues and means the tests > (except perhaps hello-native) are working on all platforms. So I'm okay > with the changes and will be happy to push them for you. Thanks Alan, I plan to address hello-native separately. -Chris. > > -Alan From mandy.chung at oracle.com Thu Feb 23 15:02:05 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Feb 2012 15:02:05 -0800 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F46AC0C.5030003@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> <4F461ABD.2080807@oracle.com> <4F4640BE.6000704@oracle.com> <4F46AC0C.5030003@oracle.com> Message-ID: <4F46C56D.5000409@oracle.com> On 2/23/2012 1:13 PM, Chris Hegarty wrote: > Updated Webrev: > http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.02/webrev/ Looks good. Thanks for doing this, Chris and the jigsaw tests will pass on all platforms (except hello-native.sh due to its dependency on a compiler) which is good. Two minor comments - it's fine to push what you have if Alan already gets your changeset and address these later. _RemoteRepository.java L108: typo 'catelog' -> 'catalog' _TimestampTest.java L147: It might be better to make this fatal as you suggested since I suspect it'd fail the install later if the module dir is not removed cleanly. Thanks Mandy From chris.hegarty at oracle.com Fri Feb 24 01:19:22 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 Feb 2012 09:19:22 +0000 Subject: RFR: Some intermittent org/openjdk/jigsaw test failures. In-Reply-To: <4F46C56D.5000409@oracle.com> References: <4F43F804.6020206@oracle.com> <4F450D38.9080607@oracle.com> <4F451216.8080909@oracle.com> <4F4513B2.7060805@oracle.com> <4F461ABD.2080807@oracle.com> <4F4640BE.6000704@oracle.com> <4F46AC0C.5030003@oracle.com> <4F46C56D.5000409@oracle.com> Message-ID: <4F47561A.5080004@oracle.com> On 02/23/12 11:02 PM, Mandy Chung wrote: > On 2/23/2012 1:13 PM, Chris Hegarty wrote: >> Updated Webrev: >> http://cr.openjdk.java.net/~chegar/jigsaw/tests_webrev.02/webrev/ > > Looks good. Thanks for doing this, Chris and the jigsaw tests will pass > on all platforms (except hello-native.sh due to its dependency on a > compiler) which is good. > > Two minor comments - it's fine to push what you have if Alan already > gets your changeset and address these later. > > _RemoteRepository.java L108: typo 'catelog' -> 'catalog' > _TimestampTest.java L147: It might be better to make this fatal as you > suggested since I suspect it'd fail the install later if the module dir > is not removed cleanly. Thanks Mandy, I'll include these changes. -Chris. > > Thanks > Mandy From alan.bateman at oracle.com Fri Feb 24 04:02:01 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Feb 2012 12:02:01 +0000 Subject: hg: jigsaw/jigsaw/jdk: Jigsaw tests intermittently failing on some platforms Message-ID: <20120224120233.C8DEB4768E@hg.openjdk.java.net> Changeset: 8df8feaabfa7 Author: chegar Date: 2012-02-24 11:54 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/8df8feaabfa7 Jigsaw tests intermittently failing on some platforms Reviewed-by: alanb, mchung ! src/share/classes/org/openjdk/jigsaw/SimpleLibrary.java ! test/org/openjdk/jigsaw/TrivialWebServer.java ! test/org/openjdk/jigsaw/_RemoteRepository.java ! test/org/openjdk/jigsaw/_RemoteRepositoryList.java ! test/org/openjdk/jigsaw/cli/JpkgArgsTest.java ! test/org/openjdk/jigsaw/cli/TimestampTest.java ! test/org/openjdk/jigsaw/cli/signed-modular-jar.sh ! test/org/openjdk/jigsaw/cli/signed-module.sh ! test/org/openjdk/jigsaw/tester.sh From david.lloyd at redhat.com Fri Feb 24 09:26:36 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 24 Feb 2012 11:26:36 -0600 Subject: Still driving off the cliff In-Reply-To: <4F462E0E.50009@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> Message-ID: <4F47C84C.9010405@redhat.com> On 02/23/2012 06:16 AM, Alan Bateman wrote: > On 22/02/2012 20:36, David M. Lloyd wrote: >> : >> Just to clarify I was talking about the selector provider API, not the >> filesystem API (I'm old school like that). > SelectorProvider is a case where the default provider is rarely (or > ever) replaced but I don't mind using it as an example. > > Like other APIs it defines a way to override the VM-wide provider (via a > system property in this case). Assuming the override mechanism is not > used then it uses ServiceLoader in an attempt to find a provider > implementation. If someone "installs" several implementations into the > extensions directory then one of them will be used, exactly which one is > not defined. An alternative would be to put them on the system class > path, in which case it's more predictable. If ServiceLoader doesn't > locate any provider implementations there is a fallback/default > implementation. In the case of the JDK then we typically have a default > implementation anyway and ServiceLoader is just used for cases where > folks want to use alternative implementations. Sure, in many cases there absolutely should be a configured global default implementation for a given API. JAXP is a great example. > Now move to the modules world when there isn't a boot or system class > path or extensions class loader. I've packaged my SelectorProvider > implementation into a module and I'd like it to be used at runtime > without using the override mechanism. The way it works currently in > Jigsaw is that you install the module with the service provider and it > will be linked as a service supplier to modules that require this > service. In this case, it's the jdk.base module that requires this > service. Clearly if someone installs another module that also provides a > SelectorProvider implementation then it's like installing into the > extensions directory in the current world; one will be chosen and > there's a way to override it. I think it's inaccurate to say "there isn't a boot or system class path or extensions class loader" - yes that's true *but* there is an equivalent concept in the form of the initially executed application module (or in the Java EE case, the currently executing application or deployment). Having the corresponding API module directly import the implementations it uses is fine, for some cases (especially for specifying default implementations). However it doesn't suffice for the cases where the user might (rarely or frequently) want to choose their own implementation. > In the implementation then the order is > stable and doesn't change between runs. This is secondary - it is possible to have stable ordering by many techniques. >> But the modular world *is* class loader centric, that's my whole >> point. Java is already 80% of the way towards being modular as of Java >> 7. All it is missing is a multiple-delegate base class loader and a >> module loader concept which creates class loaders for modules. A 1:1 >> module:class loader mapping is completely natural on many levels, and >> I have yet to see a compelling argument to the contrary. And in this >> model ServiceLoader works like a champ. > I don't get your comment on being 80% there. The work we did in JDK7 was > mostly on cleaning up dependencies in the implementation in preparation > for the modularize effort. I mean that Java has had modules for years. They provide several types of isolation and encapsulation and are widely used, if not widely understood - they're called "class loaders". The only thing a robust module system needs to do is provide a clean way to construct them. Using the platform's getClassLoader() methods as an excuse to ignore this existing concept is a major error. > With Jigsaw then it's usually a 1-1 mapping between module and class > loaders but we do have complications in the platform and it remains to > be seen where that goes. In addition I'm not sure where the class loader > relationship will be specified or not. The *only* reason I can see that Jigsaw doesn't mandate that a module is a class loader is a module is so that platform classes can return "null" to getClassLoader and yet still be called "modules". This is such a very thin foundation on which to base decisions such as redefining what a module *is*, and consequently requiring two *modes* of operation (doesn't that seem really awful to anyone else?). If the platform *must* be considered a single class loader then it shouldn't be considered to be multiple modules - more like a single module with some optionally available "features". With this simple change you don't need to have a "compatibility mode" to run old-style applications, and you can consequently allow users to leverage a *huge* body of prior work. >> My point is that by recognizing that a class loader *already* is a >> module by another name, you should realize that no new API is needed >> and no dual-mode situation should even arise. >> >> : >> We already have that today. Granted TCCL is considered ugly by some, >> but all it's really missing is a clear definition of what it *means*. >> That's what most users (and classically, framework developers) don't >> get. It *means* your current application module. That's the only >> meaning that makes any sense. And there's no way that TCCL is going to >> go away just because you deprecated it and created "new" mode versus >> "old" mode. It just needs to be formalized. On app startup, set TCCL >> to the main application module's class loader. In JavaEE, set it to >> the currently executing deployment. Consistent and simple. And it fits >> the existing java.util.ServiceLoader like a glove. >> > As I said, I think ServiceLoader has to change. The loadInstalled(Class) > method is specified to use class loaders that don't make sense with > modules. The load(Class) method is specified to use the > threadContextClassLoader but what if that has been set to null or > ClassLoader.getSystemClassLoader (we have many of these in JDK). Same > thing with load(Class,ClassLoader). For now these methods are using the > module class loader of the caller. If the caller's module declares that > it requires the service then it gets back a ServiceLoader to iterate > over the implementations of that service. It's not ServiceLoader that really needs to change in this case. The consumer of ServiceLoader should (and often already does) use the class loader variant in this case to load the default implementation (if any). It's the APIs that need to change, not ServiceLoader. The contract for ServiceLoader is already quite clear and can be leveraged to solve all modular use cases. But it's up to the API to know whether there is a default implementation, and how to find it, and whether it is appropriate to first check the TCCL or caller class loader or whatever. > On the thread context class loader then my view is that it was a > mistake. It's been a continuous source of problems, security issues > included. All it does is denote the current application. It's what APIs do with that information which is relevant. Pretending that TCCL doesn't exist is a mistake; better to clean up its contract and document the behavioral expectation of APIs which utilize it. I think it's entirely appropriate to use TCCL to search for implementations in some cases. It's also appropriate to use TCCL for the purpose of identifying the currently running application in some cases. The security issues around TCCL can be mitigated with a security manager, unless you're referring to something specific that I'm not aware of? BTW, somewhat unrelated, if you want to see some platform class loader related code that completely and utterly fails in a modular environment, look at how ObjectInputStream resolves classes by default, and imagine what happens if you have a readObject() from some random module on the call stack... and ask yourself, is it really more worth retaining weird and obscure platform behavior than it is to fix a few glitches and as a result keep well-understood and widely accepted existing concepts? -- - DML From forax at univ-mlv.fr Fri Feb 24 10:15:35 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 24 Feb 2012 19:15:35 +0100 Subject: Still driving off the cliff In-Reply-To: <4F47C84C.9010405@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> Message-ID: <4F47D3C7.7030502@univ-mlv.fr> On 02/24/2012 06:26 PM, David M. Lloyd wrote: >> With Jigsaw then it's usually a 1-1 mapping between module and class >> loaders but we do have complications in the platform and it remains to >> be seen where that goes. In addition I'm not sure where the class loader >> relationship will be specified or not. > > The *only* reason I can see that Jigsaw doesn't mandate that a module > is a class loader is a module is so that platform classes can return > "null" to getClassLoader and yet still be called "modules". > > This is such a very thin foundation on which to base decisions such as > redefining what a module *is*, and consequently requiring two *modes* > of operation (doesn't that seem really awful to anyone else?). If the > platform *must* be considered a single class loader then it shouldn't > be considered to be multiple modules - more like a single module with > some optionally available "features". With this simple change you > don't need to have a "compatibility mode" to run old-style > applications, and you can consequently allow users to leverage a > *huge* body of prior work. There are lot of program like profilers, debuggers, agents etc that relies on the fact that there is a way to separate the platform classes from the application classes, this is usually done by checking if getClassLoader returns null on a class. If you break this assumption a lot of code will just break. So even in a module world, you need a way to separate platform code from application code (it should be better to even have a system which is able to separate the application, from the container, from the platform). I agree with David that we should not have a compatibility mode (at runtime). Instead of having getClassLoader() returning a module class loader, getClassLoader() should still return null for the platform class and jigsaw should add a new method called getModuleClassLoader() that returns the module class loader. R?mi From david.lloyd at redhat.com Fri Feb 24 10:50:03 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 24 Feb 2012 12:50:03 -0600 Subject: Still driving off the cliff In-Reply-To: <4F47D3C7.7030502@univ-mlv.fr> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> Message-ID: <4F47DBDB.8080404@redhat.com> On 02/24/2012 12:15 PM, R?mi Forax wrote: > On 02/24/2012 06:26 PM, David M. Lloyd wrote: >>> With Jigsaw then it's usually a 1-1 mapping between module and class >>> loaders but we do have complications in the platform and it remains to >>> be seen where that goes. In addition I'm not sure where the class loader >>> relationship will be specified or not. >> >> The *only* reason I can see that Jigsaw doesn't mandate that a module >> is a class loader is a module is so that platform classes can return >> "null" to getClassLoader and yet still be called "modules". >> >> This is such a very thin foundation on which to base decisions such as >> redefining what a module *is*, and consequently requiring two *modes* >> of operation (doesn't that seem really awful to anyone else?). If the >> platform *must* be considered a single class loader then it shouldn't >> be considered to be multiple modules - more like a single module with >> some optionally available "features". With this simple change you >> don't need to have a "compatibility mode" to run old-style >> applications, and you can consequently allow users to leverage a >> *huge* body of prior work. > > There are lot of program like profilers, debuggers, agents etc > that relies on the fact that there is a way to separate the platform > classes from > the application classes, this is usually done by checking if > getClassLoader returns null > on a class. > If you break this assumption a lot of code will just break. > So even in a module world, you need a way to separate platform code from > application code > (it should be better to even have a system which is able to separate the > application, from the container, > from the platform). > > I agree with David that we should not have a compatibility mode (at > runtime). > Instead of having getClassLoader() returning a module class loader, > getClassLoader() should still > return null for the platform class and jigsaw should add a new method > called getModuleClassLoader() > that returns the module class loader. Honestly I don't even see the need to actually divide the platform into actual modules. If the desire is to be able to express dependencies on certain features of the platform which would be made optional, then this can be done with module aliases or views or feature dependencies or any number of other ways which don't carry this cost. -- - DML From forax at univ-mlv.fr Fri Feb 24 13:54:26 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 24 Feb 2012 22:54:26 +0100 Subject: Still driving off the cliff In-Reply-To: <4F47DBDB.8080404@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> <4F47DBDB.8080404@redhat.com> Message-ID: <4F480712.8050404@univ-mlv.fr> On 02/24/2012 07:50 PM, David M. Lloyd wrote: > On 02/24/2012 12:15 PM, R?mi Forax wrote: >> On 02/24/2012 06:26 PM, David M. Lloyd wrote: >>>> With Jigsaw then it's usually a 1-1 mapping between module and class >>>> loaders but we do have complications in the platform and it remains to >>>> be seen where that goes. In addition I'm not sure where the class >>>> loader >>>> relationship will be specified or not. >>> >>> The *only* reason I can see that Jigsaw doesn't mandate that a module >>> is a class loader is a module is so that platform classes can return >>> "null" to getClassLoader and yet still be called "modules". >>> >>> This is such a very thin foundation on which to base decisions such as >>> redefining what a module *is*, and consequently requiring two *modes* >>> of operation (doesn't that seem really awful to anyone else?). If the >>> platform *must* be considered a single class loader then it shouldn't >>> be considered to be multiple modules - more like a single module with >>> some optionally available "features". With this simple change you >>> don't need to have a "compatibility mode" to run old-style >>> applications, and you can consequently allow users to leverage a >>> *huge* body of prior work. >> >> There are lot of program like profilers, debuggers, agents etc >> that relies on the fact that there is a way to separate the platform >> classes from >> the application classes, this is usually done by checking if >> getClassLoader returns null >> on a class. >> If you break this assumption a lot of code will just break. >> So even in a module world, you need a way to separate platform code from >> application code >> (it should be better to even have a system which is able to separate the >> application, from the container, >> from the platform). >> >> I agree with David that we should not have a compatibility mode (at >> runtime). >> Instead of having getClassLoader() returning a module class loader, >> getClassLoader() should still >> return null for the platform class and jigsaw should add a new method >> called getModuleClassLoader() >> that returns the module class loader. > > Honestly I don't even see the need to actually divide the platform > into actual modules. If the desire is to be able to express > dependencies on certain features of the platform which would be made > optional, then this can be done with module aliases or views or > feature dependencies or any number of other ways which don't carry > this cost. > I see at least 3 advantages: - ease development of JDK (make integration easier) - push incremental update (module == distrib packet) - get ride of stupid legacy code (CORBA?) R?mi From Alan.Bateman at oracle.com Sat Feb 25 09:17:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Feb 2012 17:17:07 +0000 Subject: Order of Services was: Still driving off the cliff In-Reply-To: <201202231638.35356.jaroslav.tulach@oracle.com> References: <4EEB6998.6070005@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <201202231638.35356.jaroslav.tulach@oracle.com> Message-ID: <4F491793.80803@oracle.com> On 23/02/2012 15:38, Jaroslav Tulach wrote: >> ## Alan wrote on 23.?2.?2012 13:16:14 ##< >> service. Clearly if someone installs another module that also provides a >> SelectorProvider implementation then it's like installing into the >> extensions directory in the current world; one will be chosen and >> there's a way to override it. In the implementation then the order is >> stable and doesn't change between runs. > NetBeans solves problem this by positioning. The > http://bits.netbeans.org/dev/javadoc/org-openide-util- > lookup/org/openide/util/lookup/ServiceProvider.html > annotation (that generates the META-INF/services/xyz file) has attribute > position. > > ServiceLoader could be honor such position indicator and sort services > accordingly. I'm curious as to your experiences with this approach. In particular has it been problematic for cases where the order needs to configured by the user of the service providers? Also I wonder about cases where there are multiple applications are loading the service providers and the order needs to be different. In the JDK we have examples such as the java.security file that list the security providers and the preference order. There are other examples where the preference order is determine by system properties. We don't have a general mechanism for ordering and might be a bit beyond the scope of getting services deployed as modules (still interesting to hear your experiences). > >> As I said, I think ServiceLoader has to change. >> The load(Class) method is specified to use the >> threadContextClassLoader but what if that has been set to null or >> ClassLoader.getSystemClassLoader > NetBeans solves[1] this problem by registering special Thread.cCL that can see > classes from all enabled modules in the running VM. Thus by default using > ServiceLoader.load finds all services provided by all enabled modules. > Sure, but my point was getting code that has it to null or ClassLoader.getSystemClassLoader. In the current prototype the latter is the module loader of the module for the main class and so may not be the right loader. As DML suggested, it would require existing code to change but how we handle such cases it still something that needs further consideration in my view. -Alan From jjh at aicas.de Mon Feb 27 01:11:30 2012 From: jjh at aicas.de (Dr. James J. Hunt) Date: Mon, 27 Feb 2012 10:11:30 +0100 Subject: jigsaw-dev Digest, Vol 37, Issue 29 In-Reply-To: References: Message-ID: <4F4B48C2.2070006@aicas.de> On 02/25/2012 09:00 PM, jigsaw-dev-request at openjdk.java.net wrote: > Message: 1 > Date: Fri, 24 Feb 2012 22:54:26 +0100 > From: R?mi Forax > Subject: Re: Still driving off the cliff > To: jigsaw-dev at openjdk.java.net > Message-ID: <4F480712.8050404 at univ-mlv.fr> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 02/24/2012 07:50 PM, David M. Lloyd wrote: >> > On 02/24/2012 12:15 PM, R?mi Forax wrote: >>> >> On 02/24/2012 06:26 PM, David M. Lloyd wrote: >>>>> >>>> With Jigsaw then it's usually a 1-1 mapping between module and class >>>>> >>>> loaders but we do have complications in the platform and it remains to >>>>> >>>> be seen where that goes. In addition I'm not sure where the class >>>>> >>>> loader >>>>> >>>> relationship will be specified or not. >>>> >>> >>>> >>> The *only* reason I can see that Jigsaw doesn't mandate that a module >>>> >>> is a class loader is a module is so that platform classes can return >>>> >>> "null" to getClassLoader and yet still be called "modules". >>>> >>> >>>> >>> This is such a very thin foundation on which to base decisions such as >>>> >>> redefining what a module *is*, and consequently requiring two *modes* >>>> >>> of operation (doesn't that seem really awful to anyone else?). If the >>>> >>> platform *must* be considered a single class loader then it shouldn't >>>> >>> be considered to be multiple modules - more like a single module with >>>> >>> some optionally available "features". With this simple change you >>>> >>> don't need to have a "compatibility mode" to run old-style >>>> >>> applications, and you can consequently allow users to leverage a >>>> >>> *huge* body of prior work. >>> >> >>> >> There are lot of program like profilers, debuggers, agents etc >>> >> that relies on the fact that there is a way to separate the platform >>> >> classes from >>> >> the application classes, this is usually done by checking if >>> >> getClassLoader returns null >>> >> on a class. >>> >> If you break this assumption a lot of code will just break. >>> >> So even in a module world, you need a way to separate platform code from >>> >> application code >>> >> (it should be better to even have a system which is able to separate the >>> >> application, from the container, >>> >> from the platform). >>> >> >>> >> I agree with David that we should not have a compatibility mode (at >>> >> runtime). >>> >> Instead of having getClassLoader() returning a module class loader, >>> >> getClassLoader() should still >>> >> return null for the platform class and jigsaw should add a new method >>> >> called getModuleClassLoader() >>> >> that returns the module class loader. >> > >> > Honestly I don't even see the need to actually divide the platform >> > into actual modules. If the desire is to be able to express >> > dependencies on certain features of the platform which would be made >> > optional, then this can be done with module aliases or views or >> > feature dependencies or any number of other ways which don't carry >> > this cost. >> > > I see at least 3 advantages: > - ease development of JDK (make integration easier) > - push incremental update (module == distrib packet) > - get ride of stupid legacy code (CORBA?) > > R?mi > Dear Colleagues, Perhaps the biggest reason is to support dynamic programming platforms on systems with limited resources. Modules provide a means of defining clearly what is supported and what not on such a platform. There are even systems where one would like to leave out a seemingly central part of Java, such as file access. Sincerely, James P.S. I do not think CORBA is stupid legacy code, but being able to leave it out or easily provide a better implementation would be helpful. -- Dr. James J. Hunt * CEO & Gesch?ftsf?hrer * Tel: +49 721 663968 22 aicas incorporated 6 Landmark Square, Ste 400 * Stamford, CT 06901 * USA http://www.aicas.com * Tel: +1 203 435 0521 aicas GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Deutschland (Germany) http://www.aicas.com * Tel: +49 721 663968 0 * FAX: +49 721 663968 99 USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim Gesch?ftsf?hrer: Dr. James J. Hunt From jaroslav.tulach at oracle.com Mon Feb 27 01:13:32 2012 From: jaroslav.tulach at oracle.com (Jaroslav Tulach) Date: Mon, 27 Feb 2012 10:13:32 +0100 Subject: Order of Services In-Reply-To: <4F491793.80803@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202231638.35356.jaroslav.tulach@oracle.com> <4F491793.80803@oracle.com> Message-ID: <201202271013.32874.jaroslav.tulach@oracle.com> >## Alan wrote on 25.?2.?2012 18:17:07 ##< > On 23/02/2012 15:38, Jaroslav Tulach wrote: > >> ## Alan wrote on 23.?2.?2012 13:16:14 ##< > >> service. Clearly if someone installs another module that also provides a > >> SelectorProvider implementation then it's like installing into the > >> extensions directory in the current world; one will be chosen and > >> there's a way to override it. In the implementation then the order is > >> stable and doesn't change between runs. > > > > NetBeans solves problem this by positioning. The > > http://bits.netbeans.org/dev/javadoc/org-openide-util- > > lookup/org/openide/util/lookup/ServiceProvider.html > > annotation (that generates the META-INF/services/xyz file) has attribute > > position. > > > > ServiceLoader could be honor such position indicator and sort services > > accordingly. > > I'm curious as to your experiences with this approach. In particular has > it been problematic for cases where the order needs to configured by the > user of the service providers? I'd describe the NetBeans approach as "convention over configuration". The individual library modules contribute their registrations, but the final application can use "branding" and change almost everything. Usually the defaults are OK and then it is enough to include a module in and things work. If there are problems, the application (which knows about all modules it includes) can orchestrate the registrations. The @ServiceProvider annotation http://bits.netbeans.org/dev/javadoc/org-openide-util- lookup/org/openide/util/lookup/ServiceProvider.html has supersedes attribute. It can be used to hide services provided by library modules and replace them with more sophisticated ones. It seems that the position attribute with ability to supersede some implementations is enough for everyone building their applications on top of the NetBeans Platform. > Also I wonder about cases where there are > multiple applications are loading the service providers and the order > needs to be different. That would be achieved by different "branding" in different applications built on top of the NetBeans platform. > In the JDK we have examples such as the > java.security file that list the security providers and the preference > order. There are other examples where the preference order is determine > by system properties. We don't have a general mechanism for ordering and > might be a bit beyond the scope of getting services deployed as modules > (still interesting to hear your experiences). Yes, this may get complicated. The tentative goal might be to "change the order of services without writing any Java code". NetBeans handles that with "branding" which is yet another level on top of L10N. Each application can contribute fragments to existing modules and re- brand any resource found in that module. ResourceBundle[1] then loads the branded file rather than the default. Possibly the application might redefine META-INF/services/xyz file of any library module it is using[2]. > >> As I said, I think ServiceLoader has to change. > >> The load(Class) method is specified to use the > >> threadContextClassLoader but what if that has been set to null or > >> ClassLoader.getSystemClassLoader > > > > NetBeans solves[1] this problem by registering special Thread.cCL that > > can see classes from all enabled modules in the running VM. Thus by > > default using ServiceLoader.load finds all services provided by all > > enabled modules. > > Sure, but my point was getting code that has it to null or > ClassLoader.getSystemClassLoader. In the current prototype the latter is > the module loader of the module for the main class and so may not be the > right loader. As DML suggested, it would require existing code to change > but how we handle such cases it still something that needs further > consideration in my view. I was not trying to advocate usage of threadContextClassLoader. Rather I wanted to say that it makes sense for ServiceLoader to see all services from all enabled modules in the running JVM by default. -jt [1] We use special factory class that understands branding instead of ResourceBundle: http://bits.netbeans.org/dev/javadoc/org-openide- util/org/openide/util/NbBundle.html [2] We don't use rebranding of META-INF/services/xyz files in NetBeans right now, but we do use this technique in other similar situations From chris.hegarty at oracle.com Mon Feb 27 02:33:18 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 27 Feb 2012 10:33:18 +0000 Subject: Update to ModulesProblemList.txt Message-ID: <4F4B5BEE.2020103@oracle.com> Trivial update to add two tests to the ModulesProblemList.txt. The first, ReadProp.sh, is already excluded in the closed/ProblemList.txt for solaris only. It needs to be excluded on all platforms for jigsaw. I added it to the ModulesProblemList, rather than updating closed/ProblemList.txt, since it is jigsaw specific. The second test makes the assumption that the JDK's lib directory contains jar files. closed/sun/management/snmp/generic/GenericTest.sh generic-all closed/sun/management/snmp/snmpCounter64/SnmpCounter64Test.sh generic-all + +# Recursive initialization of system class loader when +# initializing the security manager/provider +# http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-March/001188.html +closed/java/security/Security/ReadProp/ReadProp.sh generic-all ############################################################################ @@ -262,6 +267,9 @@ java/util/zip/InterruptibleZip.java # Assumes JAR files in JDK's lib directory java/util/zip/ZipFile/FinalizeZipFile.java generic-all +# Assumes JAR files in JDK's lib directory +closed/java/util/zip/ZipFile/Collectible.java generic-all + # java.util.ConcurrentModificationException - need investigation java/util/Locale/Bug6989440.java generic-all -Chris. From Alan.Bateman at oracle.com Mon Feb 27 02:49:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Feb 2012 10:49:57 +0000 Subject: Update to ModulesProblemList.txt In-Reply-To: <4F4B5BEE.2020103@oracle.com> References: <4F4B5BEE.2020103@oracle.com> Message-ID: <4F4B5FD5.7080604@oracle.com> On 27/02/2012 10:33, Chris Hegarty wrote: > Trivial update to add two tests to the ModulesProblemList.txt. > Chris - I think it would be better to remove the closed tests from ModulesProblemList.txt and instead add support to the Makefile for a second list. This would be consistent with the existing ProblemList. -Alan. From chris.hegarty at oracle.com Mon Feb 27 03:42:13 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 27 Feb 2012 11:42:13 +0000 Subject: Update to ModulesProblemList.txt In-Reply-To: <4F4B5FD5.7080604@oracle.com> References: <4F4B5BEE.2020103@oracle.com> <4F4B5FD5.7080604@oracle.com> Message-ID: <4F4B6C15.7090807@oracle.com> On 27/02/2012 10:49, Alan Bateman wrote: > On 27/02/2012 10:33, Chris Hegarty wrote: >> Trivial update to add two tests to the ModulesProblemList.txt. >> > Chris - I think it would be better to remove the closed tests from > ModulesProblemList.txt and instead add support to the Makefile for a > second list. This would be consistent with the existing ProblemList. Yes, makes sense. Here is an updated webrev: http://cr.openjdk.java.net/~chegar/jigsaw/problemList_webrev.00/webrev/ -Chris. > > -Alan. > From Alan.Bateman at oracle.com Mon Feb 27 04:06:53 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Feb 2012 12:06:53 +0000 Subject: Update to ModulesProblemList.txt In-Reply-To: <4F4B6C15.7090807@oracle.com> References: <4F4B5BEE.2020103@oracle.com> <4F4B5FD5.7080604@oracle.com> <4F4B6C15.7090807@oracle.com> Message-ID: <4F4B71DD.10501@oracle.com> On 27/02/2012 11:42, Chris Hegarty wrote: > > Yes, makes sense. Here is an updated webrev: > > http://cr.openjdk.java.net/~chegar/jigsaw/problemList_webrev.00/webrev/ > > -Chris. Thanks for doing this, it looks good to me. -Alan From Alan.Bateman at oracle.com Mon Feb 27 04:15:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Feb 2012 12:15:12 +0000 Subject: Still driving off the cliff In-Reply-To: <4F47C84C.9010405@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> Message-ID: <4F4B73D0.9020705@oracle.com> On 24/02/2012 17:26, David M. Lloyd wrote: > > I mean that Java has had modules for years. They provide several > types of isolation and encapsulation and are widely used, if not > widely understood - they're called "class loaders". The only thing a > robust module system needs to do is provide a clean way to construct > them. Using the platform's getClassLoader() methods as an excuse to > ignore this existing concept is a major error. > : > The *only* reason I can see that Jigsaw doesn't mandate that a module > is a class loader is a module is so that platform classes can return > "null" to getClassLoader and yet still be called "modules". > > This is such a very thin foundation on which to base decisions such as > redefining what a module *is*, and consequently requiring two *modes* > of operation (doesn't that seem really awful to anyone else?). If the > platform *must* be considered a single class loader then it shouldn't > be considered to be multiple modules - more like a single module with > some optionally available "features". With this simple change you > don't need to have a "compatibility mode" to run old-style > applications, and you can consequently allow users to leverage a > *huge* body of prior work. > We clearly would like to get to the point where there is a class loader per platform module. There's a lot of rough terrain to cover first. Obvious issues are APIs such as java.beans that have classes in the wrong package but there are a slew of other compatibility and performance concerns, some of which go quite deep in the VM. There is also footprint concerns for the small device case but I don't think one is too bad. As regards a "compatibility mode" (something we've been calling legacy or classic mode) then we have to allow existing applications to work as they do now. This means that the class path, JAR files, and delegation from the system class loader to the extensions and boot class loader have to continue to work. Under the covers there will should be delegation to a module loader (or loaders) for the platform classes but all this should be transparent. When running applications as modules then the notions of class path, boot class path, etc. don't make sense (they do not exist) and this is what we've been calling "modules mode". > > It's not ServiceLoader that really needs to change in this case. The > consumer of ServiceLoader should (and often already does) use the > class loader variant in this case to load the default implementation > (if any). It's the APIs that need to change, not ServiceLoader. The > contract for ServiceLoader is already quite clear and can be leveraged > to solve all modular use cases. But it's up to the API to know > whether there is a default implementation, and how to find it, and > whether it is appropriate to first check the TCCL or caller class > loader or whatever. I think I may have confused you. As it stands if someone invokes ServiceLoader.load(Class,ClassLoader) then the class loader is used. If it's a module class loader then it simply returns a ServiceLoader to iterate over the implementations of the service (pre-computed list, no searching). For other class loader types then it works as it does now. ServiceLoader's javadoc needs work of course. The awkward cases, and something I touched on in one of the mails, is where the loader is specified as null or ClassLoader.getSystemClassLoader. Same thing if the thread context class loader is set to one of these. We need to figure what this mean in module mode. For now these cases work by using the module class loader of the caller. > > BTW, somewhat unrelated, if you want to see some platform class loader > related code that completely and utterly fails in a modular > environment, look at how ObjectInputStream resolves classes by > default, and imagine what happens if you have a readObject() from some > random module on the call stack... and ask yourself, is it really more > worth retaining weird and obscure platform behavior than it is to fix > a few glitches and as a result keep well-understood and widely > accepted existing concepts? > Once we are at the point where we can run all our tests in module mode then I've no doubt that many issues will come out of the wood work. -Alan From Alan.Bateman at oracle.com Mon Feb 27 04:41:24 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Feb 2012 12:41:24 +0000 Subject: Still driving off the cliff In-Reply-To: <4F47D3C7.7030502@univ-mlv.fr> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> Message-ID: <4F4B79F4.3040305@oracle.com> On 24/02/2012 18:15, R?mi Forax wrote: > : > There are lot of program like profilers, debuggers, agents etc > that relies on the fact that there is a way to separate the platform > classes from > the application classes, this is usually done by checking if > getClassLoader returns null > on a class. > If you break this assumption a lot of code will just break. > So even in a module world, you need a way to separate platform code > from application code > (it should be better to even have a system which is able to separate > the application, from the container, > from the platform). > > I agree with David that we should not have a compatibility mode (at > runtime). > Instead of having getClassLoader() returning a module class loader, > getClassLoader() should still > return null for the platform class and jigsaw should add a new method > called getModuleClassLoader() > that returns the module class loader. At present then getClassLoader returns null when invoked on classes that comprise the platform. Invoking the class's getModule().getClassLoader() method returns the ModuleClassLoader. Just on agents, there is a lot to do here as there are several APIs (including JVM TI and java.lang.instrument) that assume the boot and system class loader. It's also important to be able to deploy agents as modules. -Alan From Alan.Bateman at oracle.com Mon Feb 27 05:42:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Feb 2012 13:42:17 +0000 Subject: Still driving off the cliff In-Reply-To: <4F47DBDB.8080404@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> <4F47DBDB.8080404@redhat.com> Message-ID: <4F4B8839.901@oracle.com> On 24/02/2012 18:50, David M. Lloyd wrote: > > Honestly I don't even see the need to actually divide the platform > into actual modules. If the desire is to be able to express > dependencies on certain features of the platform which would be made > optional, then this can be done with module aliases or views or > feature dependencies or any number of other ways which don't carry > this cost. > Duke has a beer belly, we need to be able to scale down the platform to smaller devices. -Alan. From alan.bateman at oracle.com Mon Feb 27 06:09:25 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 27 Feb 2012 14:09:25 +0000 Subject: hg: jigsaw/jigsaw/jdk: Allow ModulesProblemList to be extended Message-ID: <20120227141000.E52D2476D2@hg.openjdk.java.net> Changeset: 830c9470f368 Author: chegar Date: 2012-02-27 13:55 +0000 URL: http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/rev/830c9470f368 Allow ModulesProblemList to be extended Reviewed-by: alanb ! test/Makefile ! test/ModulesProblemList.txt From eric at tibco.com Mon Feb 27 06:48:31 2012 From: eric at tibco.com (Eric Johnson) Date: Mon, 27 Feb 2012 06:48:31 -0800 Subject: Still driving off the cliff In-Reply-To: <4F47D3C7.7030502@univ-mlv.fr> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> Message-ID: <4F4B97BF.9050703@tibco.com> On 2/24/12 10:15 AM, R?mi Forax wrote: > > So even in a module world, you need a way to separate platform code > from application code > (it should be better to even have a system which is able to separate > the application, from the container, > from the platform). I presume that the very notion of "platform" is something that modularization should challenge. If you privilege a particular part of the code base running in the JVM, then you make other uses of the JVM harder and/or burdened by legacy assumptions. Ideally, the only "privileged" module of the JVM is the ClassLoader infrastructure and the bare minimum it needs to do its job. So even your taxonomy of "application", "container", and "platform" seems suspect to me, because these are just (semantically laden) arbitrary labels associated with a particular code base. Ideally, we recognize that and allow an infinite set of notions here, some which might have commonly understood semantics. And if there is a privileged one, it should be *very* small. -Eric. From forax at univ-mlv.fr Mon Feb 27 07:20:58 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Feb 2012 16:20:58 +0100 Subject: Still driving off the cliff In-Reply-To: <4F4B97BF.9050703@tibco.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> <4F4B97BF.9050703@tibco.com> Message-ID: <4F4B9F5A.8020604@univ-mlv.fr> On 02/27/2012 03:48 PM, Eric Johnson wrote: > > On 2/24/12 10:15 AM, R?mi Forax wrote: >> >> So even in a module world, you need a way to separate platform code >> from application code >> (it should be better to even have a system which is able to separate >> the application, from the container, >> from the platform). > > I presume that the very notion of "platform" is something that > modularization should challenge. If you privilege a particular part of > the code base running in the JVM, then you make other uses of the JVM > harder and/or burdened by legacy assumptions. > > Ideally, the only "privileged" module of the JVM is the ClassLoader > infrastructure and the bare minimum it needs to do its job. > > So even your taxonomy of "application", "container", and "platform" > seems suspect to me, because these are just (semantically laden) > arbitrary labels associated with a particular code base. Ideally, we > recognize that and allow an infinite set of notions here, some which > might have commonly understood semantics. And if there is a privileged > one, it should be *very* small. > > -Eric. > The main issue I see in a modular world is how to ensure the same security granularity we have now. A lot of parts of the JDK, perhaps too much you may say, in lang, util, util.concurrent, etc, relies on the fact that the code run in a privileged environment where you can use unsafe tricks. Ideally, as a developer, I also want to be able to install a module with such privileges too, if by example, I'm a developers of language runtimes (Groovy, JRuby, Scala etc.) I want full access to the platform. Currently, those runtimes rely on the bootclasspath, that why I think that even if the bootclasspath is deprecated, jigsaw has to provide a mechanism to mark some modules as platform modules. R?mi From david.lloyd at redhat.com Mon Feb 27 07:20:39 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 27 Feb 2012 09:20:39 -0600 Subject: Still driving off the cliff In-Reply-To: <4F4B8839.901@oracle.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> <4F47DBDB.8080404@redhat.com> <4F4B8839.901@oracle.com> Message-ID: <4F4B9F47.3040108@redhat.com> On 02/27/2012 07:42 AM, Alan Bateman wrote: > On 24/02/2012 18:50, David M. Lloyd wrote: >> >> Honestly I don't even see the need to actually divide the platform >> into actual modules. If the desire is to be able to express >> dependencies on certain features of the platform which would be made >> optional, then this can be done with module aliases or views or >> feature dependencies or any number of other ways which don't carry >> this cost. >> > Duke has a beer belly, we need to be able to scale down the platform to > smaller devices. Yes I *get* that but the actual pieces of the core platform do not have to be modules. We have modules blinders on here. You could just as easily associate a "feature name" with the optional sections of code, and allow a dependency to name a module plus a feature set. In this way you solve the problem just as well, your core platform is still componentized, modules which depend on an optional platform feature still can express a dependency, and you don't lose your 1:1 relationship between a module and a class loader. You could even call them "submodules" if that seems more appropriate. -- - DML From david.bosschaert at gmail.com Mon Feb 27 07:24:47 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Mon, 27 Feb 2012 15:24:47 +0000 Subject: Still driving off the cliff In-Reply-To: <4F4B9F47.3040108@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> <4F47D3C7.7030502@univ-mlv.fr> <4F47DBDB.8080404@redhat.com> <4F4B8839.901@oracle.com> <4F4B9F47.3040108@redhat.com> Message-ID: On 27 February 2012 15:20, David M. Lloyd wrote: > On 02/27/2012 07:42 AM, Alan Bateman wrote: >> >> On 24/02/2012 18:50, David M. Lloyd wrote: >>> >>> >>> Honestly I don't even see the need to actually divide the platform >>> into actual modules. If the desire is to be able to express >>> dependencies on certain features of the platform which would be made >>> optional, then this can be done with module aliases or views or >>> feature dependencies or any number of other ways which don't carry >>> this cost. >>> >> Duke has a beer belly, we need to be able to scale down the platform to >> smaller devices. > > > Yes I *get* that but the actual pieces of the core platform do not have to > be modules. ?We have modules blinders on here. ?You could just as easily > associate a "feature name" with the optional sections of code, and allow a > dependency to name a module plus a feature set. ?In this way you solve the > problem just as well, your core platform is still componentized, modules > which depend on an optional platform feature still can express a dependency, > and you don't lose your 1:1 relationship between a module and a class > loader. ?You could even call them "submodules" if that seems more > appropriate. In OSGi something like this also exists. It's called a 'framework extension', which is effectively a module that at runtime is merged with the framework (bundle 0) and hence shares its classloader. David From alexey.x.fedorov at oracle.com Tue Feb 28 04:55:53 2012 From: alexey.x.fedorov at oracle.com (Alexey Fedorov) Date: Tue, 28 Feb 2012 16:55:53 +0400 Subject: ModuleClassLoader inheritance issue Message-ID: <4F4CCED9.5010700@oracle.com> Hello! I'm playing with modular JDK and trying to modify default ModuleClassLoader behavior: > public class MyModuleClassLoader extends ModuleClassLoader { > > public MyModuleClassLoader(ModuleSystem ms) { > super(ms); > } > > // bla-bla-bla ... > > } But when I call isModulePresent(String) for this new class, > ModuleClassLoader classLoader = new > MyModuleClassLoader(ModuleSystem.base()); > boolean currentModulePresent = > classLoader.isModulePresent("bla-bla-bla"); I see that ClassCastException is thrown: > java.lang.ClassCastException: mypackage.MyModuleClassLoader cannot be cast to org.openjdk.jigsaw.Loader > at java.lang.module.ModuleClassLoader.isModulePresent(ModuleClassLoader.java:86) Is java.lang.module.ModuleClassLoader class planned to be final? Or does modular-jdk Team plan to add some documentation containing overriding/inheritance rules for new Modular API? -- Thank you, Alexey From Alan.Bateman at oracle.com Tue Feb 28 05:37:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Feb 2012 13:37:07 +0000 Subject: ModuleClassLoader inheritance issue In-Reply-To: <4F4CCED9.5010700@oracle.com> References: <4F4CCED9.5010700@oracle.com> Message-ID: <4F4CD883.6090500@oracle.com> On 28/02/2012 12:55, Alexey Fedorov wrote: > > Is java.lang.module.ModuleClassLoader class planned to be final? Or > does modular-jdk Team plan to add some documentation containing > overriding/inheritance rules for new Modular API? I would say it's TBD for now. -Alan From mark.reinhold at oracle.com Tue Feb 28 07:20:36 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Feb 2012 07:20:36 -0800 Subject: ModuleClassLoader inheritance issue In-Reply-To: alan.bateman@oracle.com; Tue, 28 Feb 2012 13:37:07 GMT; <4F4CD883.6090500@oracle.com> Message-ID: <20120228152036.611A5616@eggemoggin.niobe.net> 2012/2/28 5:37 -0800, alan.bateman at oracle.com: > On 28/02/2012 12:55, Alexey Fedorov wrote: >> Is java.lang.module.ModuleClassLoader class planned to be final? Or does >> modular-jdk Team plan to add some documentation containing >> overriding/inheritance rules for new Modular API? > > I would say it's TBD for now. ModuleClassLoader will almost certainly wind up being final. - Mark From david.lloyd at redhat.com Tue Feb 28 07:51:50 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 28 Feb 2012 09:51:50 -0600 Subject: ModuleClassLoader inheritance issue In-Reply-To: <20120228152036.611A5616@eggemoggin.niobe.net> References: <20120228152036.611A5616@eggemoggin.niobe.net> Message-ID: <4F4CF816.6090309@redhat.com> On 02/28/2012 09:20 AM, mark.reinhold at oracle.com wrote: > 2012/2/28 5:37 -0800, alan.bateman at oracle.com: >> On 28/02/2012 12:55, Alexey Fedorov wrote: >>> Is java.lang.module.ModuleClassLoader class planned to be final? Or does >>> modular-jdk Team plan to add some documentation containing >>> overriding/inheritance rules for new Modular API? >> >> I would say it's TBD for now. > > ModuleClassLoader will almost certainly wind up being final. I would strongly recommend against that, as it would prevent OSGi from functioning in a modular environment. The approach we had for JBoss Modules was to make most methods final, and have a constructor which accepted an opaque configuration object. Then the module loader implementation could specify a module class loader factory to use, which allowed subclasses to implement additional interfaces. -- - DML From mark.reinhold at oracle.com Tue Feb 28 08:11:03 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Feb 2012 08:11:03 -0800 Subject: ModuleClassLoader inheritance issue In-Reply-To: david.lloyd@redhat.com; Tue, 28 Feb 2012 09:51:50 CST; <4F4CF816.6090309@redhat.com> Message-ID: <20120228161104.03257616@eggemoggin.niobe.net> 2012/2/28 7:51 -0800, david.lloyd at redhat.com: > On 02/28/2012 09:20 AM, mark.reinhold at oracle.com wrote: >> 2012/2/28 5:37 -0800, alan.bateman at oracle.com: >>> On 28/02/2012 12:55, Alexey Fedorov wrote: >>>> Is java.lang.module.ModuleClassLoader class planned to be final? Or does >>>> modular-jdk Team plan to add some documentation containing >>>> overriding/inheritance rules for new Modular API? >>> >>> I would say it's TBD for now. >> >> ModuleClassLoader will almost certainly wind up being final. > > I would strongly recommend against that, as it would prevent OSGi from > functioning in a modular environment. Not necessarily -- it all depends on how the interop story works out. If there's a good reason for ModuleClassLoader to be non-final then we won't make it final, but in general I don't think it makes sense for it to be arbitrarily extensible. - Mark From david.bosschaert at gmail.com Wed Feb 29 14:14:16 2012 From: david.bosschaert at gmail.com (David Bosschaert) Date: Wed, 29 Feb 2012 22:14:16 +0000 Subject: Debugging Jigsaw test cases in an IDE Message-ID: Hi all, I've been trying to set up my IDE so that I can debug Jigsaw test cases, but without success. For example this test: It works from the commandline: .../jdk/test $ jtreg -testjdk:/home/david/hg/pj_230212/build/linux-i586/jdk-module-image java/lang/module/_ModuleId.java Test results: passed: 1 ... more output ... So I tried to get that working in an IDE. I looked at the Netbeans setup instructions in /jdk/make/netbeans/j2se and set up the IDE that way, but when I do 'Debug File' on the _ModuleId.java test above (or any other test) It fails with: debug-selected-file-in-test: JDK-IDE.debug-selected-file-in-test: Error: Could not find or load main class java.lang.module._ModuleId Java Result: 1 Does anyone have this working in an IDE? Is there any additional set up? I have my ~/.openjdk/build.properties file set as below... Thanks, David bootstrap.jdk=/usr/lib/jvm/java-1.7.0-openjdk jtreg.home=/home/david/apps/jtreg make.options=\ ALT_BOOTDIR=/usr/lib/jvm/java-1.7.0-openjdk \ ALT_JDK_IMPORT_PATH=/home/david/hg/pj_230212/build/linux-i586/jdk-module-image \ LANG=C \ ALLOW_DOWNLOADS=true \ OPENJDK=true From jesse.glick at oracle.com Wed Feb 29 15:41:33 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 29 Feb 2012 18:41:33 -0500 Subject: Debugging Jigsaw test cases in an IDE In-Reply-To: References: Message-ID: <4F4EB7AD.8090502@oracle.com> On 02/29/2012 05:14 PM, David Bosschaert wrote: > I looked at the Netbeans > setup instructions in /jdk/make/netbeans/j2se and set up the IDE that > way, but when I do 'Debug File' on the _ModuleId.java test above (or > any other test) > It fails Not surprisingly, because jtreg is not apparently bound to anything in project.xml, and the generic targets that might get set up if you accept the IDE's offer to generate them have no chance of working for this specialized test harness. I took a stab at writing jtreg NB bindings for this project and am including the patch for you to try. Run File seems to work (opens a browser on the results if there were failures). Note that Debug File does not work for me because of a "transport error"; not sure if this is just a case of debugging being broken in the current VM, or if something in shared.xml is still wrong. Cannot create attachments so just pasting inline - hope you can apply it. This really ought to be applied against OpenJDK 7 and merged into 8 and then Jigsaw, of course. -------%<-------- # HG changeset patch # Parent 115b3bb6de96bbd0ce2203a272b80ef4a5b36d97 # User Jesse Glick Fix up jtreg actions, and bind them to run.single and debug.single in NetBeans. diff --git a/make/netbeans/common/shared.xml b/make/netbeans/common/shared.xml --- a/make/netbeans/common/shared.xml +++ b/make/netbeans/common/shared.xml @@ -75,7 +75,7 @@ System configuration claims architecture is ${platform}-${arch} - + @@ -277,7 +277,7 @@ - + diff --git a/make/netbeans/j2se/nbproject/project.xml b/make/netbeans/j2se/nbproject/project.xml --- a/make/netbeans/j2se/nbproject/project.xml +++ b/make/netbeans/j2se/nbproject/project.xml @@ -79,6 +79,30 @@ javadoc-nb --> + + jtreg-nb + + jtreg.tests + ${root}/test + \.java$ + relative-path + + + + + + + jtreg-debug-nb + + jtreg.tests + ${root}/test + \.java$ + relative-path + + + + + From jonathan.gibbons at oracle.com Wed Feb 29 15:55:16 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 29 Feb 2012 15:55:16 -0800 Subject: Debugging Jigsaw test cases in an IDE In-Reply-To: <4F4EB7AD.8090502@oracle.com> References: <4F4EB7AD.8090502@oracle.com> Message-ID: <4F4EBAE4.4080905@oracle.com> I believe it is "on the list" for the build-infra team to revisit IDE projects after the initial Makefile work is done. Work to make jtreg Jigsaw-friendly is underway. -- Jon On 02/29/2012 03:41 PM, Jesse Glick wrote: > On 02/29/2012 05:14 PM, David Bosschaert wrote: >> I looked at the Netbeans >> setup instructions in /jdk/make/netbeans/j2se and set up the IDE that >> way, but when I do 'Debug File' on the _ModuleId.java test above (or >> any other test) >> It fails > > Not surprisingly, because jtreg is not apparently bound to anything in > project.xml, and the generic targets that might get set up if you > accept the IDE's offer to generate them have no chance of working for > this specialized test harness. > > I took a stab at writing jtreg NB bindings for this project and am > including the patch for you to try. Run File seems to work (opens a > browser on the results if there were failures). Note that Debug File > does not work for me because of a "transport error"; not sure if this > is just a case of debugging being broken in the current VM, or if > something in shared.xml is still wrong. > > Cannot create attachments so just pasting inline - hope you can apply > it. This really ought to be applied against OpenJDK 7 and merged into > 8 and then Jigsaw, of course. > > -------%<-------- > > # HG changeset patch > # Parent 115b3bb6de96bbd0ce2203a272b80ef4a5b36d97 > # User Jesse Glick > Fix up jtreg actions, and bind them to run.single and debug.single in > NetBeans. > > > diff --git a/make/netbeans/common/shared.xml > b/make/netbeans/common/shared.xml > --- a/make/netbeans/common/shared.xml > +++ b/make/netbeans/common/shared.xml > @@ -75,7 +75,7 @@ > > > System configuration claims architecture is > ${platform}-${arch} > - location="${root}/build/${platform}-${arch}"/> > + location="${root}/../build/${platform}-${arch}"/> > > > > @@ -277,7 +277,7 @@ > > > depends="-init,-pre-jtreg,-taskdef-jtreg,-check-tests-defined,-jtreg-setup,-jtreg-make,-jtreg-ant,-post-jtreg"> > - location="${jtreg.dir}/JTreport/report.html"/> > + location="${jtreg.dir}/JTreport/html/report.html"/> > > > > diff --git a/make/netbeans/j2se/nbproject/project.xml > b/make/netbeans/j2se/nbproject/project.xml > --- a/make/netbeans/j2se/nbproject/project.xml > +++ b/make/netbeans/j2se/nbproject/project.xml > @@ -79,6 +79,30 @@ > javadoc-nb > > --> > + > + jtreg-nb > + > + jtreg.tests > + ${root}/test > + \.java$ > + relative-path > + > + > + > + > + > + > + jtreg-debug-nb > + > + jtreg.tests > + ${root}/test > + \.java$ > + relative-path > + > + > + > + > + > > > From jesse.glick at oracle.com Wed Feb 29 16:09:33 2012 From: jesse.glick at oracle.com (Jesse Glick) Date: Wed, 29 Feb 2012 19:09:33 -0500 Subject: ObjectInputStream (was: Still driving off the cliff) In-Reply-To: <4F47C84C.9010405@redhat.com> References: <4EEB6998.6070005@oracle.com> <201202201049.42860.jaroslav.tulach@oracle.com> <4F42535B.7050800@redhat.com> <201202221814.23826.jaroslav.tulach@oracle.com> <4F45284D.2070104@redhat.com> <4F454D30.2080900@oracle.com> <4F4551D4.9050407@redhat.com> <4F462E0E.50009@oracle.com> <4F47C84C.9010405@redhat.com> Message-ID: <4F4EBE3D.6020704@oracle.com> On 02/24/2012 12:26 PM, David M. Lloyd wrote: > look at how ObjectInputStream resolves classes by default ...bizarrely, in fact. In NetBeans we created NbObjectInputStream [1] in part to solve this exact problem. (The getNBClassLoader method returns a "master" loader, also the default TCCL, which can load from any enabled module when unambiguous.) While NbOIS is a helpful replacement for OIS in module code, if a module calls a preexisting library using plain OIS, and this library tries to deserialize an instance of a class defined in some unrelated module, you are out of luck. Perhaps Jigsaw's ObjectStreamClass should be modified to store the module ID where available, which would be easier to use and also handle cases where multiple modules define a class of the same name? [1] https://hg.netbeans.org/core-main/raw-file/default/openide.util/src/org/openide/util/io/NbObjectInputStream.java