Java 7 Language Changes Poll Results

Inspired by Stephen Colebourne's whiteboard initiative at Devoxx, I started a similar poll on new Java language feature about a month ago. I sent an invite to the local JUG and posted it on DZone.

I'm really surprised, that over 200 fellow developers participated! Thanks to everyone for voting!

Now let's check out the results. First of all I gave you the choice to let me know how you found this poll.



There were 80 votes submitted through my blog and about 50% of all submissions came through various other channels like DZone or Alex Miller's Java 7 blog. I'm a little disappointed about the participation of our JUG. Only 22 people voted, although there are about 173 members signed up in our Google Group.

Unfortunately about 10% of the votes are invalid. Maybe I should have put the instructions on the blog post directly instead of using Stephen's presentation. However, there are 181 correct votes and those are used in the following charts:

1. Map for-each



2. For-each iteration control



3. List / Map access



4. Infer generics in declarations



5. Multi-catch of Exceptions



6. String Switch



7. String interpolation



8. Multi-line Strings



9. Resource Management



10. Null-handling




It looks like most people wanna see an improved Null handling (change no 10) in the coming Java 7 release. The improved List/Map access (change no 3) on the other hand is something that almost all the correct voters oppose. If you are interested in the cleansed results, I published as a separate website.

I thought a lot about how I should interpret these votes. Frankly, I'm a little surprised about the results. I didn't think that so many fellow developers would like to see an improved Null handling. However, the votes at Devoxx indicated the same and I do admit Null handling can be a huge PITA. What I am kind of shocked about is the huge resistance to closures-related features like resource management (change no 9) or Map for-each (change no 1). Maybe this indicates that a lot of developers are not yet ready for closures in Java. After all, it might have been a reasonable decision of Sun to drop closures - for now.

So, what am I gonna do with those votes? Well, I'll email them to Joe Darcy and hope Sun will include your votes into their decision-making process. I know these votes only speak for a very small fraction of the Java community, but I think every vote counts.

Thanks again everyone for voting!

JUG-Ka Stammtisch(BETA)

This coming Thursday at 7pm, the Java Users Group Karlsruhe will meet up for beer and chatting about Java at Marktplatz. If you'd like to join, check out the Google Group for further details or drop me an email.

Technical and Business Aspects in one Domain Model

We recently had a discussion at work about mixing technical and business aspects in your domain model. In the following post, I want to elaborate on why we had this argument, how we solved it and what conclusion I drew from this discussion.

In our domain model we have a Customer class, which has multiple Contracts. In order to keep it simple let's say the Customer class has a member called contracts of type Collection.



Our application is an Eclipse RCP client with a Java EE backend. In order to support the "Eclipse way", we allow the user of our application to modify multiple contracts of a customer and save those in one batch. Since those Contract instances only live within the context of a Customer, we pass the Customer instance for persistent storage to the server-side and that's where the fun begins.

Customer alfons = customerService.getFromServer("alfons");
Collection<Contract> contracts = alfons.getContracts();
for(Contract c : contracts) {
  c.setEndDate(today);
} 
contracts.add(newContract);
customerService.saveToServer(alfons);

Usually this is straight forward. You would leave it to Hibernate or some other O/R mapper to save those changes for you. It's no problem for Hibernate's proxy-collection to keep track of what happened. The framework can write those changes for you to a persistence storage of your choice. However, what if you want to know about those changes?

Well as you might assume, we do want to know about the changes made on client side. We need to process and send each modiefied Contract instance individually to an external backend-system. Thus we had the choice to either piggybacks the Hibernate proxy-collection somehow or come up with a design, which supports tracking those changes. We decided to do the latter and frankly, I'm not too sure if it was the right decision.

My idea was very straightforward: we designed an API for the Customer class, which allows transparent changes to Contracts. Transparent in the sense that the client of the API doesn't know what happens behind the scenes. This way we could push the responsibility for keeping track of changed Contract instances to the Customer implementation.

Customer alfons = customerService.getFromServer("alfons");
Collection<Contract> contracts = alfons.getContracts();
for(Contract c : contracts) {
  c.setEndDate(today);
  alfons.addContract(c);
} 
alfons.add(newContract);
customerService.saveToServer(alfons);

So I added a Customer.addContract method and Customer.getContracts would return a immutable Collection. The client now works explicitly with a Contract instance and adds it to the Customer, after it was modified. In the Customer.addContract method changes are being tracked with a separate Collection. This very decision, using another Collection to track the change set, caused an argument of whether it is a technical detail and thus shouldn't be part of the Customer class.

public class Customer {
  private Collection<Contract> contracts;
  // tracks changes to contracts
  private Collection<Contract> contractsChangeSet;
  ...
} 

I do agree that the change set is a technical detail of how Customer organizes its Contract instances. However, I argue that it is hidden behind an API, which doesn't cause any overhead for the client. It might not be a very clean solution, but from an API point of view, I think it's a reasonable design.

You could argue that the implementation is rather pragmatic. I could have used something like AOP to track changes instead of doing it manually. However, I think from a maintenance point of view the implementation is easy to handle. Even using the Customer class in a context where no change set is necessary would work.

Since we all agree, that mixing responsibilities is evil, I'm asking myself when is it okay to compromise and when should you strive for a better solution? Consulting Domain Driven Design, which usually enlightens me on such topics, I couldn't find anything related to this problem. As I mentioned before, I'm not quite sure anymore, if this solution is the best way to tackle this particular problem.

Maybe I should take a step back and look at this in a more general way: when is something technical and when is it related to business?

Java 7, Jigsaw and the Missing JSR

A couple of weeks ago, at Devoxx, Mark Reinhold released some details about what's in scope for Java 7, as well as its planned release timeframe. Joe Darcy blogged about this before, so I'm not gonna recap all of the stuff. Instead I'll try to summarize my understanding of the Devoxx kenyote as well as the BOF with Mark and Alex Buckley.

The most interesting Java 7 announcement for me was the proposed language changes, which are steered by Sun. The Devoxx whiteboards as well as the keynote by Mark Reinhold suggested various "small improvements". Among others are:

a for-each construct for Maps

a for-each iteration control

an array-like list/map access

type inference on generics declaration

multicatch of Exceptions

resource management

For further details check Stephen Colebourne's slides.

My understanding is that those changes are not set in stone. Josh Bloch told me that Sun is still gathering feedback from the community, on which changes to implement. However, eventually it's up to Sun which changes to include and how to implement them. One thing is for sure though: Closures are not going to be in Java 7. I won't go into this again. I simply think and I'm not alone on this, it is a missed opportunity for Java.

If you didn't attend Devoxx and look for a way to give feedback on the proposed changes, check out my poll and make your voice heard.

Modularization is another topic, which was mentioned by Mark in his keynote. Like me, you've probably heard about Sun's plans to split up the JRE's libraries into separate modules. What surprised me though, was the fact that this effort won't be specified and implemented by a JSR, but rather an open source project called Jigsaw. According to Mark there is no time for a JSR.

Jigsaw will be a module system, which bootstraps the JRE. It's available to developers as well, to modularize applications, similar to OSGi. Speaking of which, my understanding is that Sun wants to work with OSGi. How this is going to look like, is yet to be determined.

I think it's quite difficult to work on something like a module system without a proper specification. Let's say you want to port your application, which is based on Equinox and OSGi, to the new Java 7 module system. How is this supposed to work? Is this going to work at all? If it's technically possible, I think OSGi will eventually support Java 7 modules. However, I find it rather odd that there's no spec for this endeavor.

Despite all of my rants here there is at least JSR 294, which specifies the language and JVM changes. Don't get me wrong, I'm not a spec freak. I just think that for interoperability and compatibility with other module systems a spec is a necessity. In my current project we invested a lot of work in OSGi. I just don't like the fact that those efforts are probably in vain, if we would like to use Jigsaw instead. I know it's a little far-fetched, but I'm just thinking it should be possible to switch module systems.

In general I like where Java 7 is going. Language changes are finally starting to take shape and Sun's efforts to modularize the JRE, however they might turn out, sound promising.


Top 2008 Content

I'm following others and revealing my humble blog stats for the past year. At the bottom there's a list of the top 5 blog posts. For a more detailed view, click on the picture of the Google Analytics report.

To my surprise, the post with the most hits is on a topic, that is very subjective, thus near and dear to my heart: how companies frustrate the heck out of you, if you are trying to be productive.

I wrote that blog post out of deep frustration and it's nice to see that others feel the same way about this topic. On the other hand - that's the downside - it probably means, that people out there experience similar frustrations. I think more people should write about this and thus show companies, that we could be so much more productive, if they'd just give us the chance.

Top 5 blog posts of 2008

1. How Corporations Constrain Productivity

2. JSR 203 More New I/O

3. JBoss Rules Example

4. Java's Runtime.exec() openes too many files

5. Nothing wrong with TDD, right?