“The classpath is dead“ … that’s what Mark Reinhold (Principal Engineer @ Sun) said at a general session during JavaOne 2009. It’s the type of statement that should resonate with any of us who have been victims of classpath/jar hell. Mark announced this in the context of reviewing the new language features due to be released in JDK 7 (ETA 2010) or more specifically the new Java module system codenamed Jigsaw.

Module Systems and Jigsaw

Jigsaw is a low level implementation of a module system, which also includes some language and VM changes that are specified in JSR 294 (note that Jigsaw is being done outside of any JSR and is not a reference implementation of 294). Another implementation of a module system most Java developers are likely more familiar with is OSGi. But what is a module system and why do we need one?

Depencies on multiple versions (of module B in this example)

A module system enables modular programming, it allows developers to separate code into clearly defined modules that can specify what other modules they depend on and their versions, can be internally modified without breaking other modules that depend on it and can hide its own internals from external modules.

A module system can solve the classpath/jar hell problem by leveraging the previously mentioned features in order to allow an application to use the right versions of the set of libraries it requires. In the diagram shown here, we have an APP module that depends on the A, B and C modules. But module C also depends on B, however this dependency is to a different version of B than the one APP needs. A useful module system would then allow us to have 2 versions of the B module, with the compatible version and implementation visible to the appropriate modules (in this case APP and C).

Also, by clearly expressing module dependencies, we no longer have to look at random lib folders or hidden documentation when using a 3rd party library, just so we can guess what the corresponding jar files are needed to run it. With the system implemented by Jigsaw, we can simply introspect the module and let it tell us what those dependencies are. It takes the guesswork and the dark magic completely out of the equation.

But back to Mark’s presentation at the general session. The main reasons to introduce Jigsaw into JDK 7 are the following:

• Eliminate classpath complexity (classpath/jar hell problem already discussed).
• Increase performance. The VM download size can be made smaller, and startup time should improve because for small programs (say HelloWorld) unnecessary classes don’t have to be loaded at all. Mark showed how he could run HelloWorld by only using 2 modules listed by the new jmod command; jdk.base@7-ea and jdk.boot@7-ea.
• Enable native integration for installing modules.

Mark demonstrated that last point by showing a demo of him installing various JDK packages via the Synaptic Package Manager.

Installing Java modules via Synaptic Package Manager

Alex Buckley’s presentation

I attended Alex Buckley’s (Computational Theologist @ Sun) session on “Modularity in the Java Programming Language: JSR 294 and beyond”, which had a lot more details on the specific language changes to be implemented in order to support this new feature.

The most noticeable aspect of this is the introduction of module-info.java. This file goes at the top of your module filesystem, and is the class that specifies at compile and runtime the definition of the module. Here is an example, coming from Alex’s slides;

module org.planetjdk.aggregator {
          system jigsaw;
          requires module jdom;
          requires module tagsoup;
          requires module rome;
          requires module rome-fetcher;
          requires module joda-time;
          requires module java-xml;
          requires module java-base;
          class org.planetjdk.aggregator.Main;
 }

Our module is “org.planetjdk.aggregator” and uses the jigsaw module system. Depenencies are denoted by using requires and providing the module name, Alex calls this part of the module metadata the “logical classpath” of the module. You can also define the main class for the module which in this case is “org.planetjdk.aggregator.Main“.

You’ll also notice that the module name is quite long “org.planetjdk.aggregator”, while the list of required modules uses shorter names. This can be done by supplying a module alias. In the previous example, we could have added the line;

provides module aggregator;

This would then allow other modules to say “requires module aggregator” and successfully link to this module by this shorter form of the name.

Also, you can specify your module version and version dependencies in module-info.java. This updated example illustrates this mechanism;

module org.planetjdk.aggregator @ 1.0 {
          system jigsaw;
          requires module jdom @ 1.*;
          requires module tagsoup @ 1.2.*;
          requires module rome @ =1.0;
          requires module rome-fetcher @ =1.0;
          requires module joda-time @ [1.6,2.0);
          requires module java-xml @ 7.*;
          requires module java-base @ 7.*;
          class org.planetjdk.aggregator.Main;
}

Note also that you can only have one module-info.java per module, in only one location, so if you have a big source tree and you want to create multiple modules from it you will have to either separate your source into different trees or use some creative scripting to accomplish this at build time. I believe Mark mentioned they had to use some scripted solution for the jdk base as I believe it's one tree.

The rest of Alex's presentation focused on how to locate modules at compile and runtime by using the "modulepath", the use of the new module keyword and how it affects accessibility, and he gives a glimpse as to how they plan to support other module systems (for example, the version notation can be different when using other module systems).

This is all better explained in Alex's slides, so I encourage everyone to take a look at his presentation (link provided above).

The Modular Java Platform: Q&A

There were rumors in the meeting that the clown is a secret member of the Java Posse

Wednesday night, I attended a BOF like meeting hosted by Mark and Alex setup in order for the community to openly ask and voice any concerns over the work presented by them on modular Java. The setup was sort of a round table configuration (without the round table) in a very informal setting (btw it was hard for participants in the back to listen well, hopefully microphones are used next time). The first question was kind of funny, somebody asked Alex what a "Computational Theologist" does (the title makes it sound like the equivalent of a Thomas Aquinas for the nerd world).

After that, it seemed some people were very concerned about how to deploy modules, patch jars and other deployment issues. My impression was that a lot of people had a problem with the native installation part of the proposal. Mark answered that Java developers have gotten used to being in our own little jar world, separate from the OS integration issues of module and library management and that it was time for Java to integrate more with these systems. He has a point, do we really have to deploy log4j jars with all our products over and over instead of simply having a log4j installed in the system that all modules can refer to?

However, installation with native package systems is a big change. And it is also unclear what that is going to look like in Windows. It seemed like the Windows part of the equation has not been finalized, would Java 7 include some type of Java specific module registry or would it leverage something like .NET's Global Assembly Cache?

Somebody bought up the point that this new system was imposing more work on open source projects. That is, today you want to release your library as a jar, you know it's going to work everywhere. With Jigsaw, projects may have to deliver a large set of native module packages depending on all the platforms they want to deploy to. Many suggested to Mark and Alex that a cross platform package format was needed, but Mark acknowledged that Sun is not really working on that and they're just worrying mainly about specifying the module file structure and leaving the rest to the native package systems.

I noticed a few members from the OSGi community in attendance, I recognized Peter Kriens (member of the OSGi Alliance), Richard S. Hall (From Apache Felix, works for Sun in the Glassfish team) and BJ Hargrave (CTO of the OSGi Alliance, committer on Eclipse Equinox and IBM employee). Peter and Richard are both members of the expert group for JSR 294, so I was a bit surprised they weren't at all in "harmony" with Mark and Alex and the work they've done with Jigsaw. See, last time I saw discussions on this topic, JSR 277 was still active (it is on hold for now) and I was under the impression that Sun and OSGi had reached some type of "gentleman's agreement". That doesn't seem to be the case at all.

OSGi is a very mature technology and has more features than Jigsaw. However OSGi doesn't address the issue of native package installation, and you could argue that it would not be suitable to solve the issue of modularizing the JDK itself. I think on that last point, many people don't mind Jigsaw even on the OSGi side, the arguments come when you say Jigsaw could be used as an application level module system. Additionally OSGi still has some key features that are missing in Jigsaw; it allows more dynamic loading of modules (useful for plugins) and is backwards compatible (Jigsaw will only be supported from Java 7 and up).

Having said that, one thing I like more about Jigsaw is how it defines dependencies is the module-info.java file. It is a much better syntax than the error prone use of manifest files used in OSGi, where an extra space can break the whole thing for you. Adding keywords for module accessibility is also a very nice thing, and it seems the goal is to also let a modular system like OSGi take advantage of these features. Now how can these both systems inter-operate between each other in a single VM? I have no idea how that works ... yet.

In the end, the Q&A showed that there is a lot of controversy and confusion over this new feature. There was also a noticeable lack of questions during the meeting, with a few of the same people asking all the questions. I got the impression that the need and functionality of a module system in Java is not generally fully understood, so to me that means a lot more work needs to be done to explain just what is going on and why there is so much effort going into this area.

Some key questions I'd like to see clarified:

• A more technical and detailed explanation of why Jigsaw was chosen over OSGi.
• Will the JDK provide tools for wrapping modules in native packages?
• Is a cross platform package system completely out of the question?
• How would multiple modules systems work together in the same VM/application instance?
• What happens when an applet or javafx application requires core JDK modules that are not present in the current installation?
• Native library module integration issues (I sort of asked this in the Q&A). Where are native packages placed, and what happens when multiple modules include the same native libraries (say 2 modules have the same DLL embedded in them)?

This doesn't affect me, why should I care?

These changes will affect everybody, at the very least under the hood your core Java packages will be loaded in a more modularized fashion. For people who would like to run Java in other devices, you will notice that you have better ways to split up your Java distribution to only the parts that you need.

However, if you are interested in scaling your code the right way and modularizing it, you should start becoming familiar with what is going on in this space. For your applications, you'll still have the choice of using existing modular systems like OSGi or using the new facilities provided by Java 7. In the future, we should expect more details to come out as to how you can combine both (Jigsaw and OSGi). Others might prefer not to depend on an external Java project like OSGi and leverage the core support that will be provided for modules.

On the other hand, some people criticize that his is a repeat of the java.util.logging fiasco and say they can mostly ignore these changes. The jury is still out, but this is a very fundamental change in the language and platform and a very different scenario than choosing what logging package to include in the core JDK.

Oh and you might soon see new annoying interview or exam code questions trying to trip you up with gems like this one (from Alex's slides and this blog entry):

package module;
// BTW you should NEVER write code like this!!!
module class module {
        module module module = new
            module();
        module module() {}
}

Anyways, sorry for the longish blog post but hopefully this sheds some light into some of the discussions about this topic that took place at JavaOne. If you are interested in getting more in depth details about this topic, please take a look at some of the following links;

Java SE: Project Jigsaw: Modularizing JDK 7
Project Jigsaw (Mark's blog)
The Modular Java Platform (Mark's blog)
The massive, monolithic JDK (Mark's blog)
Packaging Java code (Mark's blog)
Project Jigsaw: Language changes for Modules
Project Jigsaw (Peter Kriens, his version of the "saga of Java modularity)
Project Jigsaw #2 (Peter Kriens, some criticisms of the proposed system)
Project Jigsaw #3 (Peter Kriens, Jigsaw != JSR 294)
Jigsaw - the death knell of JSR277?
Jigsaw vs OSGi?
A wrinkle with 'module' (Alex's blog)
Modularity in Java (Alex's presentation at DEVOXX 2008; covers module friendship, "virtual modules", multi-module packages, type observability and other topics not covered in the JavaOne slides I linked to in this article)

Update. Some additional links that have come to my attention after publishing this blog post;

Jigsaw Feedback Roundup (Dalibor Topic)
Java Posse #259 - Jigsaw and JSR 294 Interview (Java Posse podcast interview with Mark Reinhold and Alex Buckley)

JavaOne officially starts tomorrow but today Sun has kicked off CommunityOne. Which is a more open source focused and free conference that precedes the bigger event.

The main theme this year is cloud computing. The presentation today has been about showing several vendor solutions in the areas of virtualization and large scale application deployment that is very easy to use (and graphical). To be completely honest, I think “cloud computing” is a big buzzword approaching marketroid levels, but there is some interesting technology here. I’ll be attending a few cloud computing sessions to see if I become one of the converted.

Currently, we’re listening to some of the folks from OpenSolaris and JavaFX in a setup that seems like a nerd version of David Letterman from an alternate reality.

BTW we got a small announcement that JavaFX is now officially released for OpenSolaris. Although I’m not sure there’s a large community of OpenSolaris users looking forward to that

I have to say, the most difficult part of preparing this presentation was trying to figure out the Spanish version of common programming words and concepts. Part of the problem is that when I was learning how to program in Panama (when I was around 10-12 years old) all of my resources; magazines, books, etc where all in English. So I never knew that array is “arreglo”, that a developer is called a “desarrollador”, or what the corresponding word for loop is. It would be really nice if there was some type of resource out there with a table with all these terms, and maybe other languages. One challenge is that it seems not all of these words are “settled”. I noticed some people were still pretty comfortable with the English versions, while others used the Spanish ones exclusively. Also, there are a lot of emerging technologies and concepts in Computer Science which I think still don’t have Spanish translations. Pretty much a more difficult challenge than I expected.

One more thing, JavaFX has changed a lot in the last year. When I did this presentation, I didn’t cover how much effort has gone into optimizing this technology or the new changes to the animation API (like the deprecated dur keyword). There is a preview JFX SDK coming out next month, and you can sign up for it at javafx.com. I didn’t attend JavaOne this year, so I don’t know all the details, but I’m hoping the SDK comes with some of the tooling that Sun has promised. Designer level tools are key to this technology’s success. I hope to make a blog post with a quick review of the SDK once it comes out.

The other day I saw a Java interface with well over 300 methods (with no inheritance). It’s one of these interfaces that is a single point of entry into a system, and I’m partly to blame. Really didn’t think about how the API should scale, and now that there’s years and years of development depending on this interface, refactoring this single interface is not a trivial class (it would have to be broken up at least in a dozen smaller interfaces).

That got me wondering, what could be the maximum number of methods in a class. A quick google search yielded a forum discussion with the answer as defined in the JVM spec (2nd edition);

The number of methods that may be declared by a class or interface is limited to 65535 by the size of the methods_count item of the ClassFile structure (§4.1). Note that the value of the methods_count item of the ClassFile structure does not include methods that are inherited from superclasses or superinterfaces.

So even if you have 300 methods you are still very far away from ever hitting the limit. I wonder if there are any open source projects out there with classes with this number of methods. If you count inheritance, some of the AWT/Swing classes do have a large amount of methods, but there have to be more examples of this.

Anyways, my little piece of advise is to be forward thinking when designing APIs and make sure the API can scale as more functionality is added. It is always a good idea to think very modular and to group functionality in classes and packages that make sense.

Obviously, when others depend on your code, it never hurts to practice good design usability.

So the other day I’m looking at somebody’s code and notice a class name that caught my attention; “GenderEditor”. I think it was just your normal JTable class to show a “gender” property, but I thought it was kind of funny because the class name implied you could use this program to switch a user’s gender very easily (with no surgery!).

I talked to the developer and we had a good laugh about it. Then I noticed in the code a class called “GenderRenderer”. Well, you don’t have to use a lot of imagination to figure out how this class could be potentially a problem (what should we use to represent gender … hum).

There’s nothing wrong with these class names of course, but it made me think about how hard it is sometimes to come up with good names for our classes and how easy it is to come up with some awkward and sometimes embarrassing names.

I can’t remember any similar to GenderEditor, but I do know somebody that got carried away with naming everything *Broker. UserControllerBroker, GroupManagerBroker, SaveTheDolphinsBroker. If that wasn’t enough, then actual “broker” implementations just appened “Impl” at the end of the name, making things even more convoluted; UserControlerBrokerImpl, GroupManagerBrokerImpl, etc. I guess good descriptive names are nice, but you can get carried away trying to define what the object does in the name. We do have comment blocks in most languages, so sometimes it’s best to just say what the thing is supposed to do there.

I’m also not a big fan of putting a big “I” in front of interfaces. IUser, IConsumer, ICreditCard, this convention is used a lot by Microsoft and IBM. You look at the Eclipse code and it is littered with it. I see the point though, sometimes you want to make clear people separate interface from implementation, but we do have IDEs that let us know quickly and visually what is a class and what is merely an interface.

The again, having some basic naming conventions is often better than none at all. As long as you apply a bit of common sense and make sure you read the names you are using out loud, you won’t end up with weird names or potentially offensive sounding classes.

No, I’m not proposing my brand new Java logo replace the latest one from Sun. As a matter of fact it’s hardly a good logo, and seems more like a book cover, but for some reason a very similar logo (the one mine is based on) was selected as the official one for Ruby.

People are being a bit harsh on the thread from that last link, but yeah the logo they selected is not that great. Maybe it would make an OK book cover, but you would expect something a bit simpler and more visually appealing. Also was it really necessary to put “programming language” as part of the logo? That just looks bizarre.

But the reaction is interesting. Judging on the responses of that and other threads, developers seem to be very passionate about programming language logos. More specifically, it seems people get excited about how their favorite language gets marketed!

Which brings me to my next topic; programming language marketing.

I don’t remember much marketing activity around Ada, Pascal or even C. When Java came out, you could tell things were a little bit different. The language (or platform if you want to see it that way) had a logo, a slogan and even a mascot! Heck, I can even remember a Duke comic book I got at a conference once.

I’m noticing a similar thing with Ruby. The interesting thing is that it seems this is much more of a grass roots effort. Were the Java marketing was part of a corporate strategy, Ruby’s marketing is not orchestrated by an army of marketroids but by a good number of bloggers, dedicated advocacy sites, online books, Flash video demos and even parody YouTube videos.

However there’s always the danger of over marketing and over hyping technologies (something many accused Sun of doing with Java), which can result in turning people off. Often the marketing gets annoying, a bit arrogant, or extremely obnoxious. But to be fair, Scott McNealy would often go over board with his advocacy too, so this is not unique to Ruby. Speaking of annoying, Adobe thank you for not showing the Flex Bruce Eckel ads on every Java site all the time anymore.

It’ll be interesting to see what the Ruby adoption is in a few more years, right now it’s a very vocal yet relatively small community. When we talk about the next great computer languages, hopefully we’ll all be deciding based on technical merits, but it seems that today if you want a language to be successful you just can’t ignore the marketing side of things anymore.

I like Apple, it’s a highly innovative company with great products. I passion for programming was developed as a kid when I had an Apple //c. I own a couple of iPods and wouldn’t mind having one of those cool MacBooks. A few years ago, and at this year’s JavaOne, I noticed lots of developers with cool looking Apple computers. They definitely look a lot more interesting than the standard corporate Dell stuff. But one thing got my attention at this last JavaOne, I noticed a lot of Sun engineers with Apple laptops, and doing demos on those machines.

Nothing wrong with that, I didn’t expect them to be hauling some of those Sparc/Solaris laptops. However, Java 6 had already been out and there was a lot of talk of future features (Java 7 and beyond) related to the language and I found it odd that it seemed like a lot of Sun engineers would do their work on an Apple machine with versions of Java that are not current. I expect Microsoft engineers to have no problem running the latest and greatest versions of the .net framework, but tosee some of the Java desktop guys running on a machine that didn’t have the latest desktop features, didn’t seem to me like the best idea.

Due to Leopard and its lack of support for Java 6, it seems many of these same engineers are changing their minds, like James Gosling.

Many people have expressed that the OS X is a great platform for developing Java, but it has always been clear to me that this can’t be the case, specially when you consider that:

1. Java releases are tied to OS X version upgrades
2. Apple doesn’t provide a clear road map for their Java support
3. The iPhone; no Java ME support

1. Tying Java runtime versions to an OS release is a bad idea. It only makes sense if the features of that runtime really demand new support from the operating system, but this is the standard operating procedure for OS X and it makes no sense. I can’t imagine having to upgrade my whole OS just to use the latest versions of something like a Java VM. That people were putting up with this, is pretty amazing.

2. Apple’s been “working” on a Java 6 SDK for quite a bit, with beta releases but no clear date as to when it was going to get released. It’s pretty painful to read blogs from other developers speculating when their Java version will be released in what version of OS X. Wouldn’t it be better for Apple to just say when if at all they are releasing these things. The lack of communication on this front is truly confusing. But again, why developers would put up with this is pretty baffling to me. I wouldn’t want to setup a development environment where it’s so uncertain what versions of a compiler and a runtime I will have available at least in the near future!

3. There is no Java ME support, even though there are so many phones out there and applications that support this environment. What a disappointment it was to find out the iPhone wouldn’t support this Java runtime. For general 3rd party develpoment, up until not too long ago there wasn’t even going to be an SDK for this platform available to 3rd parties, that has changed but this shouldn’t even have been a question when the iPhone was first announced.

The pattern is clear, Apple can release some fantastic products, but very often the options the create for developers are pretty rotten. Ironically, the platform that is often accused of being very closed and monopolistic is much more open in this regard, and it should be clear that if you want a better Java development environment you should likely drop Apple and get yourself a Windows machine. That or wait for some open source project to do the work that Apple seems to have been doing but doesn’t seem to want to support.

When I launch Netbeans 5.5, it seems I’ve installed some version control module that produces these two dialogs whenever I start the IDE. I still can’t figure out what the program wants me to do here. First of all, it has to be a bug and not a feature that it’s popping up 2 modal dialogs at the same time. Very annoying. However, what really confuses me is that one dialog is for “CVS” and the other for “VCS“, which adds to the confusion because just by looking at the text you really get the terms confused. (I’m guessing I get these because they are 2 different but related Netbeans Modules/Plugins)

But the worst part is that I’m not sure what these dialogs are trying to tell me. Both say that a module is being installed, while an older version of the source control infrastructure is being disabled. Both dialogs have almost the same exact text, but one at least is telling me that it “strongly recommends I restart the IDE after the installation is complete”. The question is, why do I have to do this manually? I’m not even sure when the installation is complete, there’s no visual indication. Wouldn’t it be better to bother me about the restart option once you are ready? Even better, how about restarting the IDE when it needs to do this (Would you like to restart the IDE so VCS/CVS modules can complete their installation?).

I also don’t know how to get rid of these dialogs. I get the impression I’m not supposed to do any manual operation, but I keep getting them. Perhaps it’s time to blast my current installation and start over again, which is never a fun thing to do.

I uploaded the first version of the “magnetic desklet”. If you have AB5K installed, it should install and start by clicking/downloading this:
http://sellmic.com/download/MagneticDesklet.desklet.

I have a blog entry that describes the concept of what this is trying to do (not everything is implemented), and another post on the desklet dev list with more details. The short description is that it’s sort of a window manager for desklets (desklets are the same concept as gadgets or widgets) with a magnet metaphor.

There’s a lot of changes being committed to AB5K now, so this desklet won’t work for long. Give it a try if you get a chance.

At work, I spend a lot of time talking about usability, and often find that people think I’m just talking about the aesthetics of a particular application. Usability is much more than that. At its essence, it’s a way to ensure that a product is really solving the needs of its intended users, in an efficient, intuitive and easy to learn way. But the word says it all, “is the product usable?”.

wget is a very useful GNU utility used to retrieve files in various protocols, you can use it to retrieve the main page of a site (ex: wget cnn.com), “copy” a whole site to a local directory (ex: wget -r pjprimer.com), or download files contained in links or ftp sites. Because it’s a command line tool, you often wouldn’t associate ease of use with it, since most users prefer graphical versions of these tools. wGetGUI (see screenshot above) is a graphical version of wget. On its website it’s described as “The easy to use Graphical User Interface (GUI) for the powerful webgrabber wGet“. There is nothing easy or intuitive about this GUI, in fact, it’s a good example of what happens when you build a user interface without having usability in mind. I feel bad criticizing an open source product like this, but it shows something that happens a lot, programmers building graphical user interfaces that are not only ugly but just not usable. The first thing that a user will notice when launching this program, is the large amount of buttons, check boxes and text fields available. The common problem here is the temptation to visually represent every option in a dialog. We could organize these into tabs, menus, or a preferences dialog, but that wouldn’t really solve the problem. The approach here is to go back to basics; “Who are the users?”, “What are they trying to do?”. For this application, you usually just want to download a link, or copy a whole website to a local folder. The type of user who needs this functionality is most likely technically savvy, but that doesn’t mean that we should throw all options into a window. Note that wGetGUI, has a “minimal” version of the interface, which you can intuitively access by hitting a button with a “-” label. The minimal version is not much of an improvement, with buttons labeled “Start wGetStart.bat”, which are hard to associate with any download function. The irony is that the non-graphical version is more usable. Compare the first screenshot to this one:

The only “hard” part about this interface is the use of switches (options). In this case “-r” which stands for “recursive” and allows you to download the whole contents of the site (doesn’t work on all sites, btw). For the switches, like most command line tools, if you use the “-h” switch (or “–help”) you’ll get a list of all the options available with short descriptions. This type of interface is a bit alien to a lot of Windows users, but once a person becomes familiar with the basic mechanics of their command line shell, you can see how typing “wget -r pjprimer.com” is just much easier than going thru the pain of launching something like wGetGUI. Now I don’t give the impression that I’m advocating ditching graphical interfaces, not at all. I just wanted to point out that many times people think that because a tool has a GUI associated with it, the graphical version should be easier to use by definition. That’s only true if the GUI is well designed, and it’s built with usability in mind.