From mandy.chung at oracle.com Mon Feb 14 18:43:07 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 14 Feb 2011 18:43:07 -0800 Subject: Use cases for multi-module packages in the JDK Message-ID: <4D59E83B.2080501@oracle.com> This document summarizes the use cases in the JDK that can benefit from multi-module package support: http://cr.openjdk.java.net/~mchung/jigsaw/analysis/multi-module-package.html It describes how the multi-module package reduces dependency across modules and that results in a cleaner modularization of JDK. Mandy From david.lloyd at redhat.com Tue Feb 15 09:29:40 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 15 Feb 2011 11:29:40 -0600 Subject: Use cases for multi-module packages in the JDK In-Reply-To: <4D59E83B.2080501@oracle.com> References: <4D59E83B.2080501@oracle.com> Message-ID: <4D5AB804.30000@redhat.com> On 02/14/2011 08:43 PM, Mandy Chung wrote: > This document summarizes the use cases in the JDK that can benefit from > multi-module package support: > http://cr.openjdk.java.net/~mchung/jigsaw/analysis/multi-module-package.html > > > It describes how the multi-module package reduces dependency across > modules and that results in a cleaner modularization of JDK. The term "multi-module packages" might be a bit misleading. It could and should be possible for more than one module to define a package of the same name. However it seems that each package would have to have its own seal base, Package instance (tied to its module's ClassLoader), etc. There really is no sensible alternative that I can see. And this means that, by your proposed changes, the following statement is true: java.beans.ConstructorProperties.class.getPackage() != java.beans.BeanInfo.class.getPackage() to pick a random other class from that package. Assuming that this is OK, then the changes seem a bit ugly but reasonable. But note that this is a change which could affect backwards compatibility (though it could be argued that it might already be surprising enough that JDK classes would now come from multiple class loaders). -- - DML From mandy.chung at oracle.com Tue Feb 15 12:06:11 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Feb 2011 12:06:11 -0800 Subject: Use cases for multi-module packages in the JDK In-Reply-To: <4D5AB804.30000@redhat.com> References: <4D59E83B.2080501@oracle.com> <4D5AB804.30000@redhat.com> Message-ID: <4D5ADCB3.2070301@oracle.com> On 02/15/11 09:29, David M. Lloyd wrote: > On 02/14/2011 08:43 PM, Mandy Chung wrote: >> This document summarizes the use cases in the JDK that can benefit from >> multi-module package support: >> http://cr.openjdk.java.net/~mchung/jigsaw/analysis/multi-module-package.html >> >> >> >> It describes how the multi-module package reduces dependency across >> modules and that results in a cleaner modularization of JDK. > The document above is intended to report my analysis of the JDK so that the data can be used to decide if multi-module package support is a requirement to the Java module system. Thus it didn't cover the design and considerations (which is out of the scope). > The term "multi-module packages" might be a bit misleading. It could > and should be possible for more than one module to define a package of > the same name. However it seems that each package would have to have > its own seal base, Package instance (tied to its module's > ClassLoader), etc. There really is no sensible alternative that I can > see. And this means that, by your proposed changes, the following > statement is true: > > java.beans.ConstructorProperties.class.getPackage() != > java.beans.BeanInfo.class.getPackage() > If a module system allows splitting a package across multiple modules, this would be an issue if the above statement is true. I can share some details how the current design and implementation of jigsaw addresses that. The current design in jigsaw requires that multiple modules defining types in the same package must be loaded by the same class loader. The local dependence [1] (i.e. the 'local' modifier) is specifically designed for this use so that the client module can declare a local dependence on the base module: module client { requires local base; } In this case, the jigsaw module system will assign the base and client modules in the same context (during the module configuration process) so that they all wind up in the same class loader at run time. See more at: http://cr.openjdk.java.net/~mr/jigsaw/api/org/openjdk/jigsaw/Configurator.html > to pick a random other class from that package. Assuming that this is > OK, then the changes seem a bit ugly but reasonable. But note that > this is a change which could affect backwards compatibility (though it > could be argued that it might already be surprising enough that JDK > classes would now come from multiple class loaders). For the JDK classes, they are loaded by null class loader (e.g. System.class.getClassLoader() == null). Regardless of whether a package is allowed to be split across multiple modules or not, as for backward compatibility, getClassLoader() possibly needs to return null for JDK classes in the modular world. [1] http://openjdk.java.net/projects/jigsaw/doc/language.html