- Provide an API whereby a user can load a module and link to it (in other words, get a classloader which can be used to load exported classes), possibly with a mechanism to "run" a module, similar to how one can execute "java -jar foo.jar" today
- Support a per-module access control level, in the Java language and JVM
- Provide a way to specify what other modules are required/optional, and whether they are imported or imported and exported (in other words, "metadata")
- Provide a way to recursively locate, load, register, and link referenced modules in an efficient manner (in other words, "resolution")
The user API would amount to a new ModuleLoader class which has API elements to load a module and return an instance of a new Module class, which has the ability to either access the exported classes therein directly, or get at a ClassLoader which can do so.
A per-module access control level can be implemented by one simple rule: If a class is loaded from a module's ClassLoader, change "package-private" to mean "module-private" instead. Otherwise, stick to the old rules. Very straightforward.
Metadata can be implemented very simply as plain data objects which are read by the appropriate ModuleLoader, or even as an implementation detail of ModuleLoader itself.
Resolution could (and should) be a pluggable thing within a ModuleLoader. This would enable customized handling like the ability to load modules right out of Maven, or the ability to download modules on demand from a trusted remote repository.
So what's the deal? Wouldn't this small group of classes (and one small JLS/JVM change) be sufficient to solve the problem?
3 comments:
Hi David,
First, it is useful to distinguish visibility and accessibility. See BJ Hargrave's blog entry on the topic: http://blog.bjhargrave.com/2009/03/i-am-visible-but-am-i-accessible.html
Second, most of your points concern visibility. The 294 Expert Group has discussed visibility a lot this year and there has not been much agreement.
The main issue is that dependencies and resolution are not as simple as everyone thinks. OSGi and Jigsaw support different kinds of dependencies based on their primary use cases (dynamic services v. modular JDK). More information on the Jigsaw use cases can be found in numerous public presentations by Sun.
Third, there will soon be an Early Draft Review from JSR 294. If you have further comments, it would be helpful to send them to the JSR 294 observer list.
Alex
"OSGi and Jigsaw support different kinds of dependencies based on their primary use cases (dynamic services v. modular JDK)."
This argument is given often, but how come a "modular JDK" can't be looked at as "dynamic services"? I imagine there's no technical hurdle. Is it purely philosophical?
"This argument is given often, but how come a "modular JDK" can't be looked at as "dynamic services"? I imagine there's no technical hurdle. Is it purely philosophical?"
You imagine wrong. Copious information on what "modular JDK" means is given at http://thestrangeloop.com/sessions/modularity-jdk7 and in Mark Reinhold's Devoxx 2009 talk. It is nothing to do with dynamism or services.
Further discussion on the technical details of the modular JDK, and the tool changes being made for it (e.g. javac's new modulepath), occur at the mailing list linked from http://openjdk.java.net/projects/jigsaw/.
Post a Comment