Improved modularity in Java 7

Java 7 has been evolving @ at jdk7.dev.java.net for some time now. I decided to peep in and have a look at the features of what the next generation JDK has to offer. One of the eye catching features is the enhancement of modularity feature in JDK7. Technically we can call it: "JSR 294", but for now let’s have a look at it.

The JSR 294 calls for language extensions in support of information hiding and separate compilation. Along with this we also have JSR 277 which calls for a new form of distribution format or say new "jarring" technology. According to D.L. Parnas information hiding is :

Each module is characterized by its knowledge of a design decision which hides from all others. Its interface is chosen to reveal as little as possible about its inner workings.

So, Information hiding is powerful and should be enabled by the language itself. Java already has packages for information hiding. What is wrong with this? What are its limitations? For this we have the new "super package" or JSR 294!

Java packages supports information hiding, prevents name conflicts and they can be hierarchical. But projects are not confined to just one simple package. Thus public in a package become too "public"! Well what does that mean? Let’s have a look... In the current scenario, we can have a package P and another P.Q. Now when we import P.* to a client, we are able to access the entire P package’s hierarchy. What if we want to restrict P.Q package? So the goal of new language construct is to have an entity bigger than the package, provide a runtime access control, interfaces for packages and a new basis for deployment modules.



Thus, superpackage is defined as: A superpackage is a named collection of one or more packages or superpackages and their types. For example:

superpackage example.sample.lib {

    // member packages
    member package example.sample.lib;

    // member superpackages
    member superpackage example.sample.lib.network, example.sample.lib.parser;

    // list of exported types
    export example.sample.lib.SampleClass;

    export superpackage example.sample.lib.network;

}

By using the superpackage feature we can limit the access to certain package part. We can depict it like this:



So, how are we going to work? What changes and do we implement this superpackage? To implement we will have another java file say, super-package.java. This file will declare which type belongs to the superpackage. The normal java class file will not have information on which superpackage it belongs to. On compiling the superpackage declaration file, we get a with .spkg extension which will contain declarations about the superpackage. At the run-time, accessibility inside the superpackage remains the same as today. Outside the superpackage, the JVM consults the .spkg file to determine accessibility. Other features of superpackage are nested superpackage and interfaces.

Conclusion:

Superpackages are an effective mechanism for information hiding in the Java programming language. It will work fine with the existing deployment mechanisms like JAR, WAR and EAR. But watch out for the JSR 277 (Java Module System).