m4rkl1u / introtojigsaw

#Getting started with Jigsaw

This repository is a companion to a 2-part Jigsaw blog series on https://blog.codecentric.de

###Prerequisites You need to have Java 9 available on your system. Take care to download the version of JDK 9 that includes Jigsaw from https://jdk9.java.net/jigsaw/. There is also a version that does not include Jigsaw.

This project heavily uses shell scripts that expect an environment variable named JAVA9_BIN that leads to the bin folder of the JDK without trailing /, so for example /Applications/jdk1.9.0.jdk/Contents/Home/bin.

##Examples from the first post

###Two modules, OK This example introduces two modules - one module for an address checker with reads (depends on) a zip code validation module. You can compile the two modules seperately (using the compile-zipvalidator.sh and compile-addresschecker.sh). Compilation of the addresschecker will fail if you haven't compiled the zipvalidator first. You can also compile both modules at once by using compile-all.sh. As the modules are well-formed, you can then run the "app" with run.sh <zip code to check> where you pass the zip code to check as a param You can also create modular jars and run the application from those with the provided scripts.

###Two modules, compile time error We try to access a class from a non-exported package of the zip code validator from the address checker. This will result in a compilation error.

###Two modules, runtime error This time we try to access the internal class of the zip code validator by using reflection. This will compile, but execution will fail

###Two modules, cyclic In this example, we introduce cyclic dependencies. This will fail to compile

###Three modules, no implied readability This example introduces a new module that the zip code validator depends on. Compilation will fail because the public api of the zip code validator uses a class from this new module, but does not export it transitively

###Three modules, ok This fixes the problems from "three modules, no implied readability" by transitively exporting the new module

##Examples from the second post

###Three modules, exports-to ok This demonstrates how to restrict exports to certain modules

###Three modules, exports-to fails This shows what happens when you try to access a type that was not exported to you

###Two modules, multiple versions In this example, we create a new version of the zipvalidator, but keep the name and put both on the module path

###Two modules, multiple versions, different module names In this example, we create a new version of the zipvalidator, change the module name and put both on the module path

###Three modules with automatic module ok This example includes the usage of automatic module guava

###One module with unnamed, illegal access Here we use a module from a non-modular class, but do not stick to module rules

###One module with unnamed, ok Here we use a module from a non-modular class and stick to module rules