Java Modelling Language

I came across an interesting article on Kuro5hin about the Java Modelling Language (JML).

Sometimes ideas don’t get the attention that they deserve. The Java Modelling Language (JML) is just such an idea. JML is something every Java programmer should know about. That does not mean every project in Java should make use of JML, only that developers should be aware of it so they can use it wherever it does make sense. The fact is that JML provides so many benefits for so little extra work that it deserves far more use than it gets. If you program in Java it could definitely make your life easier.

Read the whole article here. My only reservation is that without IDE support that hides the JML annotations the source code will be too ugly for my stomach to handle.


JRuby is quite a sweet thing. I started playing around a bit with it today and did this stupid program:

require “java”

include_class “java.util.Random”

5.times do |i|
random =
print “#{random.nextInt}\n”

As I said, a stupid program, but it shows how to access Java classes from inside of Ruby.

Java Applets and Class Loaders

What’s New in Java Plug-in 1.3.1_01a

Prior to version 1.3.1_01a, Java Plug-in would use a single class loader to load multiple applets during a browser session. This practice allowed the multiple applets to share information with each other through static variables.

In order to maximize compatibility with the Java virtual machines embedded in Microsoft Internet Explorer browsers, beginning with version 1.3.1_01a Java Plug-in uses separate class loaders for applets that differ in their codebase and/or the value of the ARCHIVE parameter in the APPLET tags that invoke the applets. Only if two or more applets share the same codebase and have the same value for their ARCHIVE parameter will the same class loader be used.

I naturally assumed that it worked the way it works now but without a way to control the version of the Java Plug-in used by the browser it might not be safe to assume that kind of behaviour. One way around this is to hash on e.g. the Applet ID when referencing statics, which seems to be what Sun do in Swing.

Hibernate vs. Rails: The Persistence Showdown – Hibernate vs. Rails: The Persistence Showdown

I would say that comparing these two is like comparing apples and oranges. They are designed to address different problems. Rails’ persistence engine is made with the aim of being as easy as possible to use. Hibernate feels more like it’s trying to be the kitchen sink of ORM tools. That doesn’t have to mean it’s bad in any way, just that it’s trying to address and solve a bigger and different problem than Rail’s built-in ORM support.

So in a way it’s quite unfair to compare the two but it does highlight the differences.

Nice – a better Java?

I found the Nice programming language yesterday and it seems amazing! After a quick glance I believe it corrects most of the annoyances with Java while remaining compatible by generating normal Java bytecode.

On the other hand, if one is leaving Java but staying on the Java platform one can use Jython instead and gain even more.

Dynamic Java

Tim Bray over at Sun arranged a Dynamic Java session with leaders from the Java world and the Perl and Python worlds. Let’s hope something comes out of this in the future…

The more I work with Java the more I wish for features present in dynamic languages. I’m gonna have a look at Jython again, I played with it like 4-5 years ago, it might provide a good middle ground. Though my heart has a soft spot for Ruby so maybe I should take JRuby for a spin as well.

Decisions decisions decisions…

Dependency injection and open vs. closed designs

Rickard has written a blog entry about dependency injection and open vs. closed designs and I’ve come to the same conclusions as he when maintaining a huge Java system at work. Without consciously thinking about it I’ve been re-writing parts into a more “open” design as Rickard calls it. It just seems to simplify things a lot and at the same time it makes the components more independent, which simplifies unit testing a lot.