3 ms·
I'm biased (currently authoring http://shop.oreilly.com/product/0636920049494.do http://shop.oreilly.com/product/0636920049494.do), but I believe categorising t
by SanderMak 10y ago
I'm biased (currently authoring http://shop.oreilly.com/product/0636920049494.do http://shop.oreilly.com/product/0636920049494.do), but I believe categorising the new module system as just something organisational is a bit too dismissive.
The module system brings two essential features: reliable configuration and strong encapsulation. Both are a boon for modular development and I believe all but trivially small codebases can benefit.
Reliable configuration means every module explicitly describes its dependencies on other modules. This is consistently available throughout all phases: compilation, run-time and even a new phase, link-time (for more information about linking see http://openjdk.java.net/jeps/282 http://openjdk.java.net/jeps/282). No more classpath hell, and the explicit dependency information allows for new use-cases like linking.
Strong encapsulation brings new tools to truly modularise your application. Combine it with the services mechanism for maximum benefit (see for an example http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/ http://branchandbound.net/blog/java/2015/10/osgi-to-jigsaw/). As a side-effect, the platform becomes more secure by virtue of strong encapsulation of 'dangerous' platform internal classes.
- agumonkey 10y agoI tend to believe that it will allow for better reuse and ... modularity. But that's all guessfest on my side.
- needusername 10y ago> reliable configuration How can you say this when versioning is not covered? What have you gained when you know that your dependencies are present but you don't know whether the versions match? Asked to comment about this the JDK architects respond with "well you always have build system that verifies you dependency graph including the versions anyway", with this attitude why do you even need validation at runtime when the validation was already done at build time.