Java Magazine, Jan/Feb 2016
An Early Look at Java 9 Modules Preparing for modularity a significant change that is the cornerstone of the next major release of Java ORACLE COM JAVAMAGAZINE JANUARY FEBRUARY 2016 59 path to java 9 Until now that is up through Java 8 the languages model for controlling access to code has been relatively straightforward Classes are arranged into packages Packages are globally visible and open for extension with the exception of packages that start with java or javax Packages are designed for the logical organization of code and nothing more The unit of delivery for code is the JAR file Regular unprotected packages can span multiple JAR files Classes and methods can restrict access For example they can enforce that they are accessible only to instances of the same type or to other code in the same package This is expressed by the familiar Java keywords for access control This design has the advantage of being simple to understand and to reason about However it does lead to several issues related to access control Of these the most important problem is this non JDK libraries are powerless to prevent client code from creating additional classes in the libraries packages Creating such classes gives access to all of the protected and package access classes and methods that are defined in the package This is sometimes referred to as the shotgun privacy problem after this famous observation about the Perl programming language by its designer Larry Wall Perl doesnt have an infatuation with enforced privacy It would prefer that you stayed out of its living room because you werent invited not because it has a shotgun For Java however shotgun privacy represents an important issue As the language and environment currently stand theres no way to control access across an entire package Another way of saying this is that Java libraries want to be able to define a public API and know with certainty that clients of that API cant subvert it or directly couple to the package internals Many enterprise applications would very much like to enforce a tight level of access control where the only accesses are through a known and enforced API However this level of control of APIs is not completely possible in Java 8 and below This was one of the principal reasons that Oracle and previously Sun wanted to develop a set of technologies capable of implementing this level of safety As became clear though work on this problem began to allow the possibility of solving other problems The resulting core goals of the upcoming JDK 9 modules system have become the following over time Extend access control so public APIs can be fully enforced by introducing a concept of sealing access within a deployment unit Facilitate modular deployment of code at a scale larger than a single package Modularize the JDK itself so that the platform can improve JVM startup times reduce resource consumption remove packages that shouldnt be in the core and remove or hide internal classes to reduce the attack surface of the platform Oracle has sponsored a project within OpenJDK called Project Jigsaw whose mission is to deliver modularity for the Java environment As the release date for JDK 9 starts to approach code from Jigsaw has begun to be migrated into the mainline OpenJDK repositories This means that at the BEN EVANS PHOTOGRAPH BY JOHN BLYTHE
You must have JavaScript enabled to view digital editions.