I did a quick read of the specification... And here are my first reaction :
- Great! A module system for Java... At last, Java application will be easier to install and we will have a dependable versioning system,
- Why do I need to specify in the module definition all the classes that are present in the module? Maybe I did not understand the value of the "members" definition, but I guess that everything inside a module should be a module member. I see no reason to duplicate that information,
- I could say the same thin about the "class-exports". Why does the module system need this? It could use class visibility modifiers to do the same thing. I can see a bit of value if it was there to suggest the main entry points and/or API of the module. It should be optional,
- There is no use cases on how to install and manage existing module using tools. The specification says that it does not specify any tools. I believe that local repository management tools are a must and should be provided and made standard. At least a command-line tool should be specified. Just like we have a standard specification for using the "java" command even if it has implementation specific options.
3 comments:
Why do I need to specify in the module definition all the classes that are present in the module? Maybe I did not understand the value of the "members" definition, but I guess that everything inside a module should be a module member.
Specification of the members of a module makes it possible for development and runtime tools to play with module information without resorting to a jam download. In effect controllers or system applications can work much more efficiently with relatively small module descriptions compared to relatively big jam files.
Emmanuel asked: Why does the module system need this? It could use class visibility modifiers to do the same thing. I can see a bit of value if it was there to suggest the main entry points and/or API of the module.
The class access qualifiers public, private and protected work well providing all of your classes exist within a single package namespace. As soon as you application grows to the point where it makes sense to break out code into defferent package namespaces then the class-level access qualifier breaks down. You are forced to push access to public in order for classes in different packages to access each other. Something this conflicts with the ideal public API you want to publish and maintain.
By enabling the notion of a module and for formal "class-export" the final public APIs will be cleaner and as a result easier for developers to maintain.
Emmanuel said: The specification says that it does not specify any tools. I believe that local repository management tools are a must and should be provided and made standard.
277 is a draft specification of APIs and semantics. Based on that specification it is possible to project a rationale line towards delivery of an implementation. There will be requiremets for changes to the javac compiler (module metadata generation), and the runtime (security enforcement with respect to class access).
Tools related to registry mananagement would be resolved as a part of the JDK development (as this is an implementation concern).
The exclusion of this subject from the spec is a good thing. Assuring that effective tools are delivered as a part of SE7 is another subject that should be address to the SE7 development project.
Post a Comment