Java Modules

Posted in java by pedro | Tuesday, September 4th, 2007 at 6:58 am

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

Leave a Reply

about me

My name is Sebastian Pietrowski. I've finished Warsaw University as Master degree. I started my journey with Java 1.1 with Thread and JDBC programing in 1998 as I worked for merlin.pl. In 1999 I've passed Java Programer Certificate for Java 1.2, and was solution architect of merlin.pl infrastructure when we was moving from pl/sql to J2EE. It was great performance optimization with 10 times more req/sec than in requirements and 85 times faster as original solution.

Currently I work as Expert Software Development Java at F.Hoffmann-La Roche. The company was founded in 1896 and today, Roche employs over 80.000 people. After work I'm involved in activities related to Scala/Lift, Ruby/Rails/Merb, Python/Django. This is because I try to be pragmatic also I'm focused on application performance and tuning with success in my daily work.

My Yoda's motto: Do, or do not. There is no try.