Java Magazine, July/August 2018
ORACLE COM JAVAMAGAZINE JULY AUGUST 2018 63 libraries the packages whose public types should be accessible The devil is in the details though Before the module system was introduced there was no way to mark classes that needed to be public but that you didnt consider a public API You could always back out of supporting them by adding a comment or having your documentation say which classes were supported That meant a package could contain some supported and some unsupported public classes the new module system takes that option away By exporting a package youre not only making all public types in it accessible youre also making a promise that youre going to support all of them If you dont want to support a class that class needs to be nonpublic or in a nonexported package This means that defining your public API might require some shufling around of classes that you do not support The most common solution is to move them to a diferent package which is subsequently not exported Using and providing services If your library interacts with other JAR files by providing or using services you need to include this information in your module declaration as follows For every service you use meaning for every type that you call ServiceLoader load with you need to add a uses directive to the declaration For every class name in a file in META INF services you need to add the line provides filename with class name to the declaration Note that your users are not forced to use your modular JAR file as a module and if they dont the module declaration is ignored That means you need to keep the files in META INF services around and in sync with your module declaration Delivering multiple modules I want to point out two details for the situation in which you deliver your library in more than one JAR file The first is that as Ive discussed split packages are a problem Therefore make sure your JAR files dont split packages between them If they do now you need to move classes around or rename packages before modularizing your library The second point concerns the moving around of classes With the class path it didnt matter which JAR file a class came from As long as some JAR file contained a needed class the application worked just fine That made it possible to move classes between JAR files without
You must have JavaScript enabled to view digital editions.
