Still driving off the cliff

[Alan Bateman]

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