Closed jabrena closed 7 years ago
https://www.sitepoint.com/reflection-vs-encapsulation-in-the-java-module-system/ http://www.javaworld.com/article/2878952/java-platform/modularity-in-java-9.html https://thoughtfulsoftware.wordpress.com/2016/08/29/java-9-why-modules/ http://mydailyjava.blogspot.co.uk/2015/12/project-jigsaw-incomplete-puzzle.html https://es.slideshare.net/SimonRitter/jdk-9-big-changes-to-make-java-smaller http://stackoverflow.com/questions/3091040/why-do-we-use-rt-jar-in-a-java-project
https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns http://blog.osgi.org/2015/01/java-modularity-revisited.html http://blog.codefx.org/java/dev/motivation-goals-project-jigsaw/ http://wildfly.org/news/2016/12/12/Jigsaws-Missing-Pieces/ https://github.com/moditect/moditect
Why we need a Module system?
Software can be seen as a system of interacting parts and in Java it is common to package each of those parts in its own JAR. Conceptually a part consists of three properties: a name, a public API for the rest of the world to use, and dependencies on other parts. This graph-like model helps developers and tools dissect, analyse, and work with software systems.
But none of those properties exist inside the Java runtime, which uses the classpath to access a bunch of JARs and simply rolls them all into one big ball of mud. Any distinction between JARs is entirely lost and only a flat set of packages remains, with no capability of further validation. So important questions like “are these all required JARs?”, “are these even the correct JARs?”, “are there conflicts?”, or “are only public APIs used?” cannot be answered by the running JVM.
Project Jigsaw will enhance the compiler and runtime to come closer to the structured model. Its main goals are reliable configuration (by declaring dependencies) and strong encapsulation (by hiding internals) and its agent for both is the concept of modules.
JAR hell? (Or is it classpath hell? Or dependency hell?) http://blog.codefx.org/java/jar-hell/
Unexpressed Dependencies NoClassDefFoundError
Transitive Dependencies https://en.wikipedia.org/wiki/Java_Classloader http://javarevisited.blogspot.com.es/2012/12/how-classloader-works-in-java.html
Shadowing Sometimes different JARs on the classpath contain classes with the same fully-qualified name. This can happen for different reasons, e.g. when there are two different versions of the same library, when a fat JAR contains dependencies that are also pulled in as standalone JARs, or when a library is renamed and unknowingly added to the classpath twice.
Version Conflicts Complex Class Loading
Version conflicts are the single most problematic aspect of JAR hell.
Classpath vs Modulepath
It is necessary to write about:
-Why we need a Module system? -API Reorganization -How to create a Module? -Build systems -Open issues
Points to talk in 15m:
http://openjdk.java.net/projects/jigsaw/quick-start https://www.infoq.com/articles/Latest-Project-Jigsaw-Usage-Tutorial https://www.infoq.com/articles/Project-Jigsaw-Coming-in-Java-9 http://www.javahispano.org/portada/2012/1/11/el-proyecto-jigsaw-de-java-8.html