Java Magazine, July/August 2018
ORACLE COM JAVAMAGAZINE JULY AUGUST 2018 64 libraries breaking downstream code if it was done carefully Modules make this much harder For a module to access types in one of your library modules it needs to read that exact module which usually means it needs to require it If an application requires only one of your several library modules and you move a class out of that module and into another one the application will not be able to access the class and its compilation and execution will fail So moving types between modular JAR files has a higher risk of causing compatibility problems than with plain JAR files Be careful when you have to do it Conclusion Going from Java 8 to full modules on Java 9 and later releases can be quite a lot of work but for most projects it isnt The smaller your library and the more plain Java code it contains the less efort it typically requires article Nicolai Parlog @ nipafx has found his passion in software development He constantly reads thinks and writes about it and codes for a living as well as for fun He wrote the justpublished book The Java Module System Manning He blogs about software development at codefx org and is a long tail contributor to several open source projects java proposals of interest JEP 296 Consolidate the JDK Sources into a Single Repository This proposal which was implemented in Java 10 illustrates some of the dificulties in maintaining a codebase that has the special requirements of the JDK Specifically Java Enhancement Proposal JEP 296 addresses the following problem many code commits span several of the individual repositories in the source base Consequently its not possible to make atomic commits to the source code manager When speaking of a commit atomic means that the action is carried out in its entirety as a single operation or not at all Clearly if a commit must be done separately to several repositories to be complete there is no possibility of atomicity This means that every commit is labor intensive and fragile until completed In the JDK there are eight principal repositories and roughly 1100 defects and requests span more than one of them So this JEP proposed merging these repositories into a single repository The advantages of a central single repository are increasingly being recognized by companies that have large codebases For example Google and Facebook have frequently broadcast their use of a single monolithic repository for all their products code The Google repository which contains more than 2 billion lines of code has reportedly generated several advantages unified versioning simplified code sharing and greater reuse Invariably this JEP will require changes to internal development practices and DevOps Should those changes have value to Java developers at large well report on them in a future issue
You must have JavaScript enabled to view digital editions.
