Modules in JDK 9 by Alex Buckley

hi everyone welcome to modules in JDK 9 my name is Alex Buckley and I write the specification of the Java language and the java virtual machine i've worked on the java platform since 2006 so i've seen the full life cycles of JDK 7 8 & 9 I worked on project coin and invoke dynamic in JDK 7 on lambdas and type annotations in JDK 8 and on the modules in JDK 9 that we'll be talking about today first we'll talk about what modules are and how they improve the developer experience second we'll talk about how the JDK has been turned into modules and third we'll talk about some of the things you need to know about migrating to JDK 9 one of the core features of any programming language is the ability to reuse code so the large programs can be built from small programs in Java the basic unit of reuse is traditionally the class Java has wonderful mechanisms for promoting reuse of a class such as inheritance for reusing behavior and interfaces for reusing abstractions however when your Java program gets to be 5 10 20 packages in 2 4 8 jar files it becomes difficult to visualize how all those classes and interfaces interact which means it's hard to control who is reusing what just imagine how difficult it is to control reuse within a really large code base like the 217 official packages shown here from JDK 8 the only way to share code between packages is with the public modifier but then the code is shared with everyone a package is a great way to organize classes but most people wish there was a way to organize packages to modules let you do that a module is a set of packages designed for reuse this is a long-overdue building block in the java language in effect modules recalled to the structure of your program so that the parts you want to be reused can be reused while the parts you don't want to be reused can't be reused a program built of modules will be more reliable than a program built from a loose set of packages in jar files that can access each other freely and that exposed to many api's to the outside world here's a module that everyone will soon be familiar with Java base it's the foundation of every Java program like java.lang object is the root of every class in blue are the packages of Java base intended for use by code outside the module these are its exported packages in red other packages internal to Java base they can be used by code inside the module but not by code outside the module these are its concealed packages a module is declared in a new kind of file called module info Java it gives the name of the module and its exported packages by exporting the java.lang package it means that the public classes of java.lang are accessible from outside java base a package that is not explicitly exported such as calm sun crypto provider is concealed it's public classes are not accessible outside java base this is the first feature of modules in jdk 9 strong encapsulation a module isn't just a set of packages it's a set of exported packages and concealed packages this means that access control is more powerful in jdk 9 than in jdk 8 in jeddah q9 you can arrange for public classes to be accessible to everyone or accessible only to other classes in the same module or accessible to classes in the same module and a limb set of friend modules so if you're looking at public on a class declaration it no longer means that everyone can access the class access depends on whether the class's module exports the classes package when you write your own module you specify the modules it depends on this is the second feature of modules in JDK nine reliable dependences a module isn't just a set of packages it's the set of packages that reuse the packages exported by other modules here we have a hello world module that exports a package of its own and depends on Java base with the requires keyword this means the code in the HelloWorld module can import any of the packages exported by Java base but there is no way for code in the HelloWorld module to import any of the packages concealed by Java base there are quite a few benefits to putting code in modules for a starts the HelloWorld module can be run with a simple Java command that points to a directory of modules the minus P and the module to be run the minus M you don't need to set the class path the modules themselves say what they depend on JDK 9 checks the dependencies both when you compile and when you run it checks that every module that is required is available that's a big improvement over the class path where you don't discover missing jars until later it checks that modules don't require each other in a cycle cycles lead to code that is hard to understand and maintain finally it checks that a package is exported from exactly one other module this means there are no split packages split packages are the mess you get on the class path when two jars contain the same package and you load some classes from one jar and other classes from the other jar avoiding split packages is also a win for performance because JDK 9 knows exactly where each package which is much better than repeatedly scanning every jar on the classpath looking for a needed class by the way modules are not mandatory you can keep putting jars on the classpath and jdk 9 supports a gradual migration to modules so that you can choose the trade-off of how much work you're willing to do to modularize versus the benefits of modules let's turn our attention to the JDK 20 years ago the Java platform was small just a few hundred classes and the organization of the JDK wasn't a problem but every year the platform grew bigger and now it's tens of thousands of classes the JDK is huge and worse its monolithic in reality the Java platform is not one thing it's more like 25 separate frameworks including the swing UI framework a crypto framework a scripting framework multiple XML processing frameworks and so on there's no reason these separate frameworks have to be tightly coupled in one download in fact it's an impediment in developing the JDK the overly tight coupling raises development and testing costs which turns into slower platform evolution plus the larger the surface of your platform the more difficult it is to secure and it's an impediment to a lot of users both those who want to run their applications on smaller devices and those who want to run more instances of their of their application on large systems even if you only wanted a part of the JDK you've had to take all of it that all changes in JDK 9 we've taken the monolithic JDK and broken it up into a few dozen modules some of these are part of the Java SE specification some are just part of the JDK implementation here's a graph of the Java SE modules at the bottom there's Java base which everything depends on and which depends on nothing itself we've broken out the various frameworks into their own modules instrumentation logging XML scripting desktop which you can require or not require as you'll need to dictate there's a Java SE module which has no actual code in it but just has dependences so you can say requires java SE and be guaranteed to have all these modules available it's worth mentioning that merely finding these module boundaries which might be obvious in hindsight was a tremendous engineering effort you'll find in your own code that decoupling a monolith is much harder than building a loosely coupled system from the beginning the good news going forward is that the discipline imposed by modules will prevent all of us from accidentally recreating a monolith I'd like to quickly review the expectations of compatibility from JDK 9 first up there are various technologies from Java EE that ship in the JDK as well as in app servers the list of Java EE modules in JDK 9 includes Cober Jack's B jax-ws and common annotations these modules are deprecated in JDK 9 and will be removed in a future release because of this they are disabled by default in JDK 9 if you're running code on the classpath you may need to use the add modules command line flag to enable the Java EE modules second a lot of tools and libraries try to access parts of the JDK that are meant for internal use only unfortunately it'll take a while for tool and library developers to move away from this practice so JDK 9 temporarily allows access to JDK internals but prints a warning when it happens there's a command line flag to avoid these warnings so please check with tool and library developers about how to deploy on JDK 9 finally there are miscellaneous changes in JDK 9 that are unrelated to modules but might affect code that ran on JDK 8 notably code that assumes the Java version stream begins with one dot or assumes that the JDK lives in a file called RT jar will fail on JDK 9 again please check with tool and library developers about which versions are needed to run on JDK 9 to conclude JDK 9 is important because it enables modular development all the way down the java language and the java virtual machine understand modules very deeply so that the applications you write and the libraries you consume and even the jdk itself can all be developed and tested and packaged and deployed as modules with clear api's and well protected internals making everyone play by the same modular rules has great benefits for reliability maintainability and security though it may take some time for popular tools and libraries to catch up you can download JDK 9 now and follow what's happening with JDK development at open JDK also follow us on Twitter at open JDK and hashtag Java 9 and with that thank you very much

Channel: Java

Views: 46,006

Keywords: java, JDK9, Java programming language, Java 9, What's new in JDK 9, key changes in JDK9, module system in JDK 9, How to migrate to JDK 9

Id: 22OW5t_Mbnk

Length: 12min 11sec (731 seconds)

Published: Tue Sep 26 2017