What happened to ModuleClassLoader?

[Peter Levart]

Re-sending since I don't see my previous post in the jigsaw-dev archives 
due to problems with mailing list in the past days...


-------- Forwarded Message --------
Subject: 	What happened to ModuleClassLoader
Date: 	Sun, 14 May 2017 23:11:37 +0200
From: 	Peter Levart <peter.levart at gmail.com>
To: 	jigsaw-dev <jigsaw-dev at openjdk.java.net>



Hi,

If I remember correctly, there was a phase in jigsaw development when 
there was a class named ModuleClassLoader. It has since disappeared.

There are static and instance methods in ModuleLayer:

   defineModulesWithOneLoader
   defineModulesWithManyLoaders

...which create appropriate ClassLoader(s) that know how to load classes 
and resources from modules defined in the Configuration. But what about 
method:

   defineModules

...which takes a classloader mapping function (Function<String, 
ClassLoader>). I can't find helpers for constructing appropriate 
ClassLoader(s) that know how to load classes and resources from the 
modules defined in the Configuration. What do you recommend? Should user 
look into jdk.internal.loader.Loader implementation to figure out the 
details?

Suppose that user wants to create a layer that assigns class loaders to 
modules in a manner that is neither 1 ClassLoader for all modules nor 1 
ClassLoader per module. He doesn't want to implement details and just 
wants to partition modules into disjoint subsets and assign each subset 
a separate ClassLoader which would be provided by the platform.

Something that could be specified in a method with the following signature:

defineModulesWithLoaderPerSubset(Configuration cf,
                                            List<ModuleLayer> parentLayers,
                                            Function<String, Object> msskf);

Where:

msskf - The function to map a module name to a subset key (a key is an 
object with appropriate equals/hashCode method - modules mapping to 
equal keys belong to the same subset. each subset gets a separate 
ClassLoader provided by the platform)

The method could check that module read edges and partitioning into a 
subset(s) don't conflict and arrange delegation among class loaders 
appropriately.

Above two utility methods (defineModulesWithOneLoader and 
defineModulesWithManyLoaders) could then be just special cases:

defineModulesWithLoaderPerSubset(..., mn -> true); // equivalent to 
defineModulesWithOneLoader(...)
defineModulesWithLoaderPerSubset(..., mn -> mn); // equivalent to 
defineModulesWithManyLoaders(...)

What do you think?

Regards, Peter