Pragmatic Programmer Issues

Java Modules

The JSR 294 is about modularity. All of us know that we must write modular application. We know that modular is better to test, maintain, share knowledge and so on. So we introduce interfaces, protocols, we try also hide information so no one should use it. Everyone agree that encapsulation is good, every new language provides some statements which help us to hide internal representation.

In Java language we have packages which should be used for information hiding, but in my opinion public is too public and packages are not hierarchical so if you have class info.pietrowski.app.util.SuperUtility and info.pietrowski.app.Main than class Main don’t see any of SuperUtility members instead public ones. In today life we used some tricks to hide this information. The common way is simple to not include documentation to SuperUtility to avoid using it. But today we read documentation when we must to. We use IDE which has auto-complete, when we press Ctrl+Space in Eclipse we see SuperUtility class and all it public members. Shit.

Ninjas tries to avoid it by introduce class loaders or static classes but in my opinion is not the way we should go. One option is OSGi the second is already mentioned JSR 294. OSGi is better but it’s more then simple modularity. JSR 294 introduce a term superpackage.

Superpackage is by definition a named collection of one or more packages or superpackages and their types. Public classes can be exported. Only exported classes are accessible outside superpackage.

superpackage app {
member package info.pietrowski.app;
member package info.pietrowski.app.util;
export info.pietrowski.app.Main;
}

For more information visit JSR 294 read Alex Buckley homepage and Andreas Sterbenz blog

Thanks

Categories