303

This is my last blog post here on blogger.com! You'll find my new thoughts, projects and development ramblings at http://dlinsin.github.com. I migrated to blogger.com in late 2005 and was always quite happy with it. More than 5 years and exactly 502 posts later it's time to move on to something new. Subscribe to my new blog feed, check my stuff on github or follow me on Twitter.

GWT @ JUG-Ka

Tomorrow night there'll be the another event of the Java User Group Karlsruhe. It'll feature a talk on the Google Web Toolkit by Papick Taboada, who is quite an expert on the topic. The second part of the event will be a get-together after the talk, where you can discuss GWT over a beer. My company Synyx GmbH & Co. KG is kindly sponsoring the drinks.

The talk will take place at University Karlsruhe in room 101 and start at 7:15pm. The room is located in the basement, which you will find easily, if you follow our duke featured logo.

If you are interested in our lottery, where you can win a JetBrains or ZeroTurnaround license, submit your details through our online form. The winners are going to be announced at the end of the talk and must be present.

Last but not least, check us out on Twitter and subscribe to our Google Calendar or join our Xing Group.

Community Gathering @ JUG-Ka

After the first successful JUG Karlsruhe talk on Groovy, we will kick off the community involvement with a gathering this coming Wednesday.

Everybody who wants to get involved in our little Java User Group here in Karlsruhe is invited. We are looking for people with lots of ideas, sense of community and passion. I prepared a couple of slides, which will help us structure the gathering, but mainly we are hoping to get your feedback and ideas heard.

You can help steer the JUG in the direction which you want it to go. Just join us on Wednesday at 7:15pm, the usual time and the usual place. The University of Karlsruhe kindly sponsored a room (SR-107), which is located in the basement, next to the usual location.

I'm looking forward to see you guys on Wednesday to share some ideas on how to improve your Java User Group Karlsruhe.

Watch the Java User Group Karlsruhe Online

This is our first attempt to record a talk of the Java User Group Karlsruhe. Please forgive us the weird camera angle and the volume, we promise to improve that. Other than that I think it's quite reasonable.

I'm really impressed by the tools and platform Parleys.com provides. The best part is - it's free for JUGs. A big thank you from Karlsruhe to Belgium for that!

Groovy @ JUG-Ka

The first talk of 2010 at the Java User Group Karlsruhe is this coming Wednesday. After a successful finale in December 2009 with a talk on Scrum, we are turning our attention to the technical side of things again - Groovy.

We had a talk on Groovy back in early 2008, in case you remember. It was an introduction, whereas this coming talk will target a more advanced audience.

The speaker of the night will be Dierk König from Canoo Engineering AG, Switzerland. He is a Groovy committer and author of the book Groovy in Action. He'll give us an overview of 7 scenarios in which to use Groovy in your project.

I'm excited, that we are going to have a Groovy expert in the house Wednesday evening. If you have any questions on Groovy, it's your chance to get an answer, so make sure to drop by.

The talk will take place at University Karlsruhe in room 102, located in the basement - just follow our duke featured logo. The talk will start at 7:15pm.

Our monthly lottery of JetBrains and ZeroTurnaround, which are each giving away a free license of one of their products is already on. If you are interested in participating in the draw, submit your details through our online form. The winners are going to be announced at the end of the talk and must be present.

To keep up with all the JUG goodness in 2010 subscribe to our Google Calendar or join our Xing Group.

Spring's ResourceBundleMessageSource

Last week my colleague Marc spent hours trying to figure out why a ResourceBundle wasn't loaded in a Spring based web app we are developing here at Synyx. It turned out to be a broken Unicode representation, which wasn't properly reported by Spring's ResourceBundleMessageSource.

In case you don't know ResourceBundleMessageSource, here's an excerpt of its javadoc:

MessageSource implementation that accesses resource bundles using specified basenames. This class relies on the underlying JDK's ResourceBundle implementation, in combination with the JDK's standard message parsing provided by MessageFormat.

We are leveraging the basename functionality of ResourceBundleMessageSource in our application, the way it's suggested in the javadoc. It's pretty neat and you should definitely check it out, if you've never used it.

The problem we encountered indicated that the bundle could not be found. This is what we saw in our log statements:

WARNING: ResourceBundle [broken_messages] not found for MessageSource: Can't find bundle for base name broken_messages, locale en_US

Of course, we tried to fiddle with the classpath, changed the names of the properties files and moved them to different directories in our WAR file - it would only print the above log statement. After hours of trying and failing, Marc discovered an invalid Unicode character representation (something like d\u00Fvid instead of d\u00FCvid) in the ResourceBundle, which wouldn't let ResourceBundle load the damn thing.

So where's the problem with ResourceBundleMessageSource? The problem is that it swallowed the cause of its own MissingResourceException. Here's what Java's good old ResourceBundle class tells you in case of a broken \uxxxx representation:

java.util.MissingResourceException: Can't find bundle for base name broken_messages, locale en_US
...
Caused by: java.lang.IllegalArgumentException: Malformed \uxxxx encoding.

You can clearly figure out what the problem is and how to solve it. Whereas, with the message of MissingResourceException the least you would expect, is to look for the problem in the properties file itself.

I created a small test case to reproduce the problem and filed a request for improvement. I hope there'll be a fix, so that other people don't have to suffer the same way we did.

Scrum @ JUG-Ka

The upcoming talk at the Java User Group Karlsruhe this Wednesday is kind of an experiment. It features Scrum, which according to Wikipedia:

... is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development.


It's an experiment, because we usually feature sessions on development topics like REST, Hibernate and Flex. A talk on a management framework, although it's closely related to development, is rather unusual for us. If you are not interested in this kind of topic, let me know, we appreciate your feedback.

The talk will take place at University Karlsruhe in room 102, located in the basement. Unusual topics call for unusual timings, so we'll start at 8:00pm this time. Our speaker is Dr. Jürgen Hoffmann of scrumcoach.de.

This month we are giving away a free book called "Growing Object-Oriented Software, Guided by Tests by Freeman&Pryce". If you are interested in participating in the lottery, drop me an email. The winners will be announced at the end of the talk.

This is the last gathering of the year 2009. There's even more to come in 2010, so subscribe to our Google Calendar and stay up-to-date.

Playing with Spring's RestTemplate

A couple of week ago, I saw a talk on Spring 3.0's MVC REST support. It's quite impressive how simple SpringSource made REST development by applying the proven concepts of the core Spring Framework.

One of those great core concepts is Templates. Spring's Data Access Framework is an example, where templates are used extensively. One of the templates is the JDBCTemplate. It provides a set of predefined methods to access a database, without worrying about Connection management or Exception handling. Templates are a nice way to help you the the job done, without constraining flexibility. The book "Building Spring 2 Enterprise Applications", which I reviewed last year, there's a whole chapter on Data Access and the corresponding Templates.

The RestTemplate is the latest child in the family. Arjen Poutsma from SpringSource wrote a blog entry about it and describes it as follows:

The RestTemplate is the central Spring class for client-side HTTP access. Conceptually, it is very similar to the JdbcTemplate, JmsTemplate, and the various other templates found in the Spring Framework and other portfolio projects. This means, for instance, that the RestTemplate is thread-safe once constructed, and that you can use callbacks to customize its operations.

In the before mentioned blog post, Arjen shows how to pull pictures from Flickr, using their REST API, and display them in a JFrame. He uses an XML based approach, whereas I'll show you some code, which handles JSON:



You can see it's quite easy to work with a RestTemplate. You simply create an instance, tell that instance what your expected content is going to be and you are good to go. In this case we expect the request and response to be JSON. Spring is using the Jackson JSON Processor, to automagically map POJOs to JSON and all the way back.

The concept of a MessageConverter is really neat. You can set multiple converters and specify to use a certain converter for certain POJOs. You can also handle multiple content types by setting multiple instances of MessageConverter.

In order to make a REST call with the predefined MessageConverter, you simply use the getForObject method. You pass the url to call, the type the response is supposed to be mapped to and the values to be replaced in the url. The type of the response is actually a wrapper class:



It is necessary since the following JSON response, which is represented in the POJO Issue, needs some kind of holder object:



As you can see, it's really easy to work with Spring's new RestTemplate. These couple of lines are enough to retrieve a JSON or XML response from a REST call. With the Template approach, you have the full flexibility to hook almost every method and tweak it to your needs.

Dependency Injection Obscures Your Code

During listening to Software Engineering Radio's Episode 148 - "Software Archaeology with Dave Thomas", I got quite annoyed by a comment made by one of the respected authors of "The Pragmatic Programmer".

To quote Dave Thomas correctly, here's what he said at around 23 minutes into the podcast:

... that is one of the reasons why I, in general, are not very happy with the DI style of development, because I actually think it obscures the code quite a lot, when it comes to reading it ..... what it actually does is, it give you another dimension, that you have to read in order to understand the code.

My first reaction was "What the deuce!?!". I mean how can someone claim, that Dependency Injection obscures code and makes reading code harder? Are all those hours I spent blogging and promoting DI in vain? Are the SpringSource guys wrong or is Dave Thomas just crazy?

However, his statement and even his argument are completely reasonable, if you listen to the first couple of minutes of the podcast. Dave said at around 11 minutes into the podcast:

.... actually, I don't typically use an IDE, I use an editor like Textmate on the Mac.

And there you go! No wonder, you'll find it harder to read and understand code, if you compare the following two screenshots from a bunch of code, using Spring:





If you are reading the code above and don't understand where those two dependencies in the constructor come from, your IDE gives you a hint, without leaving the context of that particular file. You know that, they'll be injected by Spring. In addition to that, you can even directly navigate to the configuration file with a single click.

Now if you are using a text editor, you really have no idea where to look for. I guess you would have to grep for new TxTestService(). In case of using Spring, not even that would give you any more clues.

Don't get me wrong, if Dave likes Textmate better than an IDE - fair enough! I just think everyone should use the right tool for the right job! Frankly, an IDE makes a much better job here than a plain text editor.

I think the Java world has amazing tooling and in my opinion there's almost the philosophy, that if there is no tool support for a technology - it sucks. I don't fully agree with that. However, I do think that, when it comes to Java, tool support can definitely
assist you reading and thus understanding code.

RESTful applications in practise @ JUG-Ka

This coming Wednesday Gregor Roth from 1&1, you might know him from his InfoQ article, is going to give a talk on RESTful applications at the Java User Group Karlsruhe.

He will show how to implement applications leveraging a RESTful architecture and point out the mismatch between a RESTful and RPC-style approach. Furthermore Gregor will highlight the difference between HTTP PUT and POST and finally demonstrate how to implement none CRUD operations using REST.

I'm really looking forward to this talk. In my spare time I developed the REST interface for an Android game and it's going to be interesting to see what we could have done better and hopefully what we've got right.

As usual, the talk will be held at University Karlsruhe in room 102, which is located in the basement. We'll start at 7:15pm, if the door opens as planned this time.

JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in participating in our monthly lottery, send me an email. The winners will be announced at the end of the talk. In addition to that, Atlassian sponsored a couple of great T-Shirts, which you can pick up at the end of the talk.

If you want to know more about upcoming talks, subscribe to our Google Calendar. You'll also be able to see the planned talks for 2010.

Having Fun with JDK's tools.jar

This week I had to trace a bug in a legacy application, I'm maintaining at the moment, which drove me up the wall. The application uses a class from JDK's tools.jar, to determine the JVM instances currently running. Unfortunately, there are incompatibilities between JDK versions.

Tracking down the bug took a humongous amount of time, because the fun part of working on a legacy application is that all the developers, which are responsible for the code you are maintaining, are usually no longer available. Don't even get me started on documentation! However, as a good developer, I created the following JUnit test, to isolate the problem from the rest of the code.


If you run this test with Sun's JRE 1.6 and tools.jar of Sun's JDK 1.6 on the classpath, you won't encounter an problems. However, with my current project, we need backward compatibility with other Java versions. That means, there are multiple tools.jar on the classpath, in different versions. Depending on their order, the test above fails or succeeds.

More precisely, there is a JDK 1.4 and 1.5 version of tools.jar on the classpath, in addition to the 1.6 version. 1.6 is needed, because in previous JDKs the class VirtualMachine doesn't reside in the package com.sun.tools.attach. So running the test without tools.jar in version 1.6, you'll get a NoClassDefFoundError.

So what's the problem you might ask? As long as tools.jar of JDK 1.6 is on the classpath, when running the aforementioned test, everything should be okay, right? It should be, but it isn't. As soon as tools.jar of JDK 1.5 is before the 1.6 version on the runtime classpath, the test fails. Every other combination works just fine.

Why tools.jar of JDK 1.5 causes this problem is a mystery to me. Sun's bug parade, doesn't contain any relevant information - at least I couldn't find any. Frankly, I think this problem is so absurd, that I cannot motivate myself getting to the bottom of it.

Nevertheless, the problem exists in our application and we'll have to find a solution. I guess that's the reason why it's a legacy application - I have to deal with problems that are totally outdated and nobody knows the answer to.

Push IRC messages to your iPhone

In my new company one of the main communication channels is IRC. Unfortunately, I'm not able to hang out on IRC all day. That means, I'm not only missing interesting discussions, but I'm also always the last to get to know about interesting developments. To put an end to my offline-misery, I came up with a solution to push IRC messages to my iPhone.

First a couple of things you need to know. You'll need an iPhone app to receive push notifications, more about that later on. Furthermore, you'll need a server, which is able to host a Java-based IRC bot.

The bot is leveraging the famouse PircBot library, which unfortunately is based on inheritance:

I stripped out some of the code, you can find the full version on GitHub.

The usage of PircBot, as you can see above (line 11, 16 and 22), is quite easy. You simply override the methods you want to hook into, and execute your code. That's pretty much all the magic that is to PircBot. In order to limit the notifications pushed to the iPhone, I batch a certain number of messages for a pre-configured time and eventually send them to a NotificationService. I'll come back to the NotificationService in a second, but there's another feature I'd like to point out - silent mode. I don't want to be notified on my iPhone, when I'm actually on IRC myself. So whenver a pre-configured user enters the channel, the Bot will switch to silent mode. As soon as the user leaves the channel, it'll switch back.

As you can see, the NotificationService implementation, simply makes a Http Post request to a service called App Notifications. The request contains a couple of key/value pairs, which are used to configure your iPhone's push notifications.

I'm using Commons HttpClient to makes the Post request, since I have some experience with it. In order to use App Notifications, you'll need to setup an account. After the setup, you'll receive a credential String, which must be passed along with the Post request.

The only part missing is the iPhone app, that you need, in order to receive push notifications. The app is not free, but it's quite reasonable. Actually it's a good deal to pay for the app once and not on a request or monhtly bases. However, keep in mind, that the app can only receive push notifications - nothing else. If you that's what you need, this app is for you.

Putting together all parts of the puzzle, you'll get an IRC bot, which connects to the channel you want to be notified about. The bot batches messages and sends them to a service, which in turn pushes them to your iPhone. On your iPhone you have the notification app, which displays the messages from IRC.

The App Notification service is very reliable and super fast. However, there is one downside to the iPhoen app. You cannot switch off the notification sound without also switching off the vibration feedback. The App Notification developer told me, he'll address this issue in a future update.

I also had to play with the batch size and delay, since there are a lot of messages on the channel, I'm interested in and it got quite irratating getting pounded with notifications constantly.

Overall, I do admit, that this combination is quite adventurous, but it works very well. If you'd like to check it out, grab the code from GitHub and let me know what you think.

jBPM 4 @ JUG-Ka

Today I'm pleased to welcome Bernd Rücker from camunda services GmbH to the Java User Group Karlsruhe. Bernd is going to talk about the Open Source Business Process Engine JBoss jBPM. I'm really excited about this talk, because it's a topic I was quite dedicated to a couple of years ago.

The session takes place today at University Karlsruhe, building 50.34 in the multimedia room 102, located in the basement. The talk starts at 7:15pm, our usual timing.

There will also be our monthly lottery, where JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in participating in the draw send me an email. The winners are going to be announced at the end of the talk.

There are still two more great talks coming up this year. You can subscribe to our Google Calendar to get the latest updates. There's also a Google or Xing Group to stay on top of things.

Spring DM with Annotations

A couple of days ago, I implemented a sample application, based on Spring Dynamic Modules (DM) 1.2.0, with its annotation extension. Unfortunately the documentation doesn't contain any sample code, which might cause some unnecessary work, if you are not too familiar with Spring DM.

Spring DM's annotation extension allows you to pull in an OSGi service reference by annotating a setter of a property:


Unfortunately, you don't get rid of the XML configuration completely, but that's not so bad after all, because you still want to let Spring to all your wiring:


In addition to the instantion part, you need to configure a BeanPostProcessor. It tells Spring to handle your methods annotated with @ServiceReference. If you want all your bundles to use annotations, this might get a little tedious. That's why you can configure annotation processing for all bundles, by defining a fragment bundle, which overrides the default configuration of Spring DM's extender:


Unfortunately, the configuration of the fragement bundle is not in the offical documentation.

Now, that you've got a glimpse of how to use annotations with Spring DM and the ways of configuring it, you might ask whether you want to use it or not? For me this boils down to the question, whether you want to have your dependencies in your xml file or in your code?

It's a tricky question and I think annotations only bring real value, if they make your life easier. Let's take a look at Spring's Web MVC for example: before annotations were introduced, you had to implement an interface in order to code a controller and thus you had dependencies on javax.servlet in your controller code. Spring Web MVC's annotation approach still leaves you with the dependency on Spring, but eliminates the javax.servlet dependency.

In addition to that, it improves testability of controller classes significantly, which I think is worth living with the dependency on Spring.

I think, that the features of Spring DM annotations, at least at the moment, are not compelling enough to have dependencies on it in your code. With the right tooling, Spring's XML configuration should be as easy to handle as annotations.

Book Review Dynamic Modules for OSGi

Apress was kind enough to pass me a copy of this book, which I agreed to review in return.

I have been sitting on Pro Spring Dynamic Modules for Osgi(tm) Service Platforms for a while, although I got a fresh copy right after if was released earlier this year.

One reason for this might be, that after reading the first chapter, it felt like I was reading a manual rather than a book. Personally, I like a little bit more subjectiveness, because it improves the reading experience significantly. The author should spice up the dry material, so you won't get bored that easily. Unfortunately, that's what happened to me - I got bored. However, let's turn the spotlight to the content of the book.

The introduction chapter on OSGi is sufficient to get you up to speed. There are about 60 pages of Spring introduction. However, I think you should at least have some practical experiences with Spring, before digging into Spring Dynamic Modules or even Spring DM Server. It's simply not enough to explain the technicalities, to get someone an understanding of what Spring an its concepts is all about.

There's lot's of code in the book, which you can download and play with. If you like to read code, printed in a book, you are probably gonna like "Pro Spring Dynamic Modules for Osgi". For me, a book is not the preffered media to consume code. I have nothing against small code samples, but having pages over pages full of code, is really confusing and hurts readability.

The manual kind of feeling of the book continues the further you keep reading. Let me give you a concrete example: In chapter 4, called "Spring Dynamic Modules for OSGi", the author explains how the scope attribute of a bean declaration works:


Unfortunately, the how is all there is to the explanation. I expected a real life example of when to use the scope attribute and where it might not be suitable. I do understand, that the book can't go into details all the time, but especially those powerful Spring DM features like scoping, deserve more spotlight. Most of the time, the book stops when it gets interesting and you are left with your own imagination of how to apply that particular feature.

Despite the criticism, I got some neat tips from the book. The author suggests to split the OSGi dependent and traditional Spring configuration to make life easier for testing and mocking. I also gained a lot of knowledge from chapter 6, called "Versioning with OSGi and Spring". The author explains the concepts and implementation of versioning most of the time in a very understandable manner.

Overall, I think Pro Spring Dynamic Modules for Osgi(tm) Service Platforms is a reasonable reference book, with a nice sample application. If you are new to Spring and OSGi, you might have a hard time understanding the use case for those technologies, so I'd suggest to get this book as an addition to some basic reading material.

Google Sitebricks

Last week I stumbled upon an interview on InfoQ with a Google developer working on a new web framework called Google Sitebricks. On my research day at Synyx, I had time to produce some sample code.

Google's mission statement goes as follows:

Sitebricks is a simple development layer for web applications built on top of Google Guice. Sitebricks focuses on early error detection, low-footprint code, and fast development. Like Guice, it also balances idiomatic Java with an emphasis on concise code.

A Sitebrick based web-application is deployed as a good old WAR file in a servlet container. That's the first information not explicitly stated on the website. If you have worked with another web framework before, you probably know the concept of a controller or a REST-based Resource. You can find the same concept in Sitebricks, too:


You can see that the class is pretty simple and it reminds me a lot of Restlet, which I used extensively the past few months. With the At annotation you declare the Uri under which your resource should be available. You can also define variable parts in your Uri, e.g. /guestbook/:id, which is used in my sample to access an entry of the guestbook.

The methods annotated with Get and Post are being called upon a request with the corresponding method. If you take a closer look at the method load(), you can see, that it doesn't return any value. That's where the convention or should I call it magic, of the framework begins:


In your Html file, that you define along with your resource, there are expressions, that access members of your resource class. In the Html snippet above we iterate over a Collection named "entries". It's a member of the Guestbook class and is assigned whenever there's a Get request, which triggers the method load() to be called. The expression items=entries calls the getEntries() method on Guestbook, to return the Collection.

Frankly, this strikes me kinda odd. You call a method to populate a member and then its getter to retrieve the value? Shouldn't the annotated Get method return the value directly? I'm not quite sure what the design goal was here, but the first thing that comes into my mind is concurrency. If your resource class is a Singleton, you could run into quite some trouble.

Take a look at the form in the Html snipped above. It has two input fields, which are properties, mapped by name to the member newEntry. The member must be accessible under the resource declared in the action attribute of the form. This was not mentioned in the Sitebrick docs either. When you submit the form, the getNewEntry() method is called and the input field values are set at the returned instance. After that, the annotated save() method is called with the member newEntry already populated.

Again, the design here is rather unusual. You are working on a member, which in case of a Singleton resource, means there is shared state. Of course, if you define your resources not as Singleton, you don't have any problems. However, it's definitely a pitfall, in my opinion.

Overall, I think Google Sitebricks contains a couple of cool ideas. I like the expression language kind of approach, which makes it easy to work with Html snippets. The possibility to define little components (Bricks) and add them in other sites, is another really cool feature.

The project is still in its early stages and I hope they'll address those odd design decisions, mentioned above. Although it's not standards-based, with Google backing the framework, I could imagine Sitebricks getting some traction.

Tuning Hibernate and JPA @ JUG-Ka

After two sessions on client development, we are now turning our attention to the server side again. I'm very happy to welcome Michael Ploed from Senacor Technologies AG to talk about "Tuning Hibernate and JPA Applications" at the Java User Group Karlsruhe.

Michael will show us how to approach tuning of your Hibernate powered applications and which options exist, to increase your application's performance. Furthermore he will talk about Hibernate's second-level cache, which I'm looking forward to in particular. Finally, he'll demonstrate his tuning advices with a demo application.

This month we have a special prize in our monthly lottery: a free pass to the W-Jax conference, held this coming November in Munich. All you've got to do is send me an email and be present at the end of the session, when Michael will draw the winner.

The session takes place this Wednesday at University Karlsruhe, building 50.34 in the multimedia room 101, located in the basement. The talk starts at 7pm, a little earlier as usual.

We have more great talks coming up, the next couple of months. In order to get the latest updates, sign up for our Google Group or join us on Xing.

Spring DM Web Extender Problems

In my current project, I'm evaluating moving a large and very old code base to OSGi. Part of that is getting the the development team on board. I'm trying to point out, how much you can benefit from designing your application with OSGi in mind and the advantages you can have, running your application in an OSGi container.

I created some sample code with the help of the book "Pro Spring Dynamic Modules for Osgi(tm) Service Platforms" to highlight some of my OSGi presentation bulletpoints. One of the samples is running Tomcat inside of Equinox together with Spring Dynamic Modules. Although the sample is really simple and I sticked to the steps in the book precisely, Equinox spit out the following Exception:


After various failed attempts to google for a solution, I decided to consult the book again. Although, I thought I sticked to the steps closely, I missed an important point: start levels.

A start level is simply a non-negative integer value. The Framework has an ‘active start level’ that is used to decide which bundles can be started. Bundles themselves have an associated ‘bundle start level’ which is used to determine when a bundle is started. The bundles at a given start level will all have their start method completely executed before any bundles at a higher level are started. When booted, the Framework monotonically goes through each start level and starts relevant bundles (all the way until the active start level is met).
...
In the end, start levels are there to simply determine the start order of bundles.

I missed the fact that there is a start order in my Equinox run configuration. The bundles, which are in charge of bootstrapping Tomcat, need to be activated in special order, otherwise the previously mentioned Exception is raised. In particular the following bundles need to start in order:

...
org.springframework.osgi.catalina.osgi@3:start, \
org.springframework.osgi.catalina.start.osgi@3:start, \
org.springframework.bundle.osgi.web.extender@4:start, \ 
...

In "Pro Spring Dynamic Modules for Osgi" the config only orders the bundles and doesn't add any explicit start levels. However, I still ran into the same Exception from time to time, depending on other bundles I loaded. I put explicit start levels in my run configuration to solve those problems.

No Improved Exception Handling

Last week Joe Darcy announced the Project Coin finalists. There will be 7 "improvements" to the Java Language for the upcoming JDK 7 release. Unfortunately, one of my favorite proposals "Improved Exception Handling" didn't make it. Don't worry, I promise this is not gonna be a rant post, rather my personal view on what I have to work with for the next couple of years.

I have to admit I was a little pissed at first, when I read, that "Improved Exception Handling" didn't get in. Especially, because it was one of the most requested proposals. However, after reading Joe's explanation on his blog, I do see, that it is not easy to prefer one proposal over the other:

Improved exception handling would be a fine change for the language, but it ventures near the type system and we do not estimate we have resources to fully develop the feature within JDK 7. I would like to see improved exception handling reconsidered in subsequent efforts to evolve the language.

At this point I would start the ranting on how Sun couldn't have enough resources, but I made a promise I wouldn't. There's another reason I shouldn't start ranting:

If there are frustrations waiting for Java language changes, I assure you there are also frustrations working on Java language changes. For example, I find it frustrating (and self-inconsistent) that people state "I don't have technical expertise in this area" while simultaneously expecting their preferences to be selected without any contribution on their part. [LINK]

I guess I am one of those frustrated people. I have no idea, if I lack the technical expertise, but what I do know is that I have enough technical expertise to judge that this is a PITA:

Statement stmt = null;
try {
   // do stuff that uses Statement instance
} catch (SQLException e) {
  // handle state
  log.error("Bad database", e);
} catch (NullPointerException e) {
  // handle state
  log.error("Bad parameter", e);
} catch (Exception e) {
  // handle state
  log.error("Bad luck", e);
} finally {
  try {
    stmt.close();
  } catch (Exception ex) {}
}

It is quite irritating, that this is what Java developers have to work with for the next couple of years. It is annoying, that there is no standard in the Java Language addressing this problem. There might be workarounds or some OpenJDK whatever branch with a prototype hacked into it, which exactly solves this problem. In my opinion, that's not a solution whatsoever.

In order to reduce programming errors, I think the Java Language must address this problem with a standard solution like "Improved Exception Handling".

Java & Flex @ JUG-Ka

I was amazed how many people showed up at our last session on JavaFX and I would love to see such a crowd at every session.

Was it the new technology, that made so many people show up? Was it the fact that it was about client development? Or was it simply because we had a speaker from Sun? I'm really curious to know and I would love to get some feedback, in order to improve the topics of our sessions.

This Wednesday, our new theme on client development continues with a session on Flex & Java. Adobe Flex is a framework for building web and desktop clients. Corneliu Vasile Creanga from Adobe, will give us an overview of the framework and how it can interact with Java. The session starts at 7:15pm, this Wednesday and takes place at University Karlsruhe room 101 in the basement.

There will also be our monthly lottery, where JetBrains and ZeroTurnaround are each giving away a free license of one of their products. If you are interested in getting a free copy of IntelliJ or JavaRebel, send me an email to participate in the draw. The winners are gonna be announced at the end of the talk.

We have a lot more exciting talks coming up this year. To stay on top of things, sign up for our Google Group or join us on XING.