my take on things

RESTful applications in practise @ JUG-Ka

2009-11-06T05:44:00.000+01:00

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

2009-11-02T05:44:00.000+01:00

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.

package de.linsin.sample.tools.bug;

import static org.junit.Assert.*;

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;

public class ToolsJarTest {
@Test
public void testJVMInstances() {
assertTrue(VirtualMachine.list() > 0);
}
}

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

2009-10-26T05:35:00.000+01:00

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:

public class Bot extends PircBot {
private boolean silentMode = false;
private Collection notificationServices;

private Collection messages;
private Timer messagesTimer;
static final int MESSAGE_BATCH_SIZE = 20;
static final int MESSAGE_BATCH_DELAY_MS = 60000;

@Override
protected void onMessage(String argChannel, String argSender, String argLogin, String argHostname, String argMessage) {
batchMessages(format(argSender, argMessage));
}

@Override
protected void onJoin(String argChannel, String argSender, String argLogin, String argHostname) {
User[] users = super.getUsers(argChannel);
switchSilentMode(users);
}

@Override
protected void onQuit(String argChannel, String argSender, String argLogin, String argHostname) {
User[] users = super.getUsers(argChannel);
switchSilentMode(users);
}

private void switchSilentMode(User[] argUsers) {
for (int i = 0; i < argUsers.length; i++) {
User user = argUsers[i];
if (user.getNick().equals(alterEgoName)) {
silentMode = true;
return;
}
}
silentMode = false;
}

private void batchMessages(String argMessage) {
if (messages.isEmpty()) {
messages.add(argMessage);
messagesTimer.schedule(new TimerTask() {
public void run() {
processMessages();
messagesTimer.purge();
}
}, MESSAGE_BATCH_DELAY_MS);
} else if (messages.size() < MESSAGE_BATCH_SIZE) {
messages.add(argMessage);
} else {
processMessages();
messagesTimer.purge();
}
}

private void processMessages() {
StringBuilder builder = new StringBuilder();
for (String message : messages) {
builder.append(message).append("\n");
}
sendToService("message", builder.toString());
messages.clear();
}

private void sendToService(String argTitle, String argMessage) {
for (NotificationService service : notificationServices) {
if (!silentMode) {
service.notify(argTitle, argMessage);
}
}
}
}

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.

public class AppNotificationService implements NotificationService {
private final String credentials;
public static final String USER_CREDENTIALS = "user_credentials";
public static final String NOTIFICATION_LONG_MESSAGE = "notification[long_message]";
public static final String NOTIFICATION_TITLE = "notification[title]";
public static final String MESSAGE_LEVEL = "message_level";
public static final String URL = "https://www.appnotifications.com/account/notifications.xml";
public static final String HTTP_USERAGENT = "http.useragent";

public AppNotificationService(String argCredentials) {
credentials = argCredentials;
}

public boolean notify(String argTitle, String argMessage) {
HttpClient client;
PostMethod method = null;
try {
client = setUp();
method = setUp(argTitle, argMessage);
int returnCode = client.executeMethod(method);

if (returnCode > HttpStatus.SC_OK) {
return false;
} else {
logger.info("Sent notification!");
return true;
}
} catch (Exception e) {
throw new AppNotificationException();
} finally {
if (method != null) {
method.releaseConnection();
}
}
}

HttpClient setUp() {
HttpClient client = new HttpClient();
client.getParams().setParameter(HTTP_USERAGENT, "IRC Bot");
return client;
}

PostMethod setUp(String argTitle, String argMessage) {
PostMethod method = new PostMethod(URL);
method.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=utf-8");

method.addParameter(USER_CREDENTIALS, credentials);
method.addParameter(NOTIFICATION_LONG_MESSAGE, argMessage);
method.addParameter(NOTIFICATION_TITLE, argTitle);
method.addParameter(MESSAGE_LEVEL, "2");
return method;
}
}

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.

Spring DM with Annotations

2009-10-19T05:45:00.000+02:00

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:

import org.springframework.osgi.extensions.annotation.ServiceReference;

public class MyService {
private LogService logService;

@ServiceReference(cardinality=ServiceReferenceCardinality.C0__1)
public void setLogService(LogService argLogService) {
logService= argLogService;
}
// other stuf
}

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:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

<bean class="org.springframework.osgi.extensions.annotation.ServiceReferenceInjectionBeanPostProcessor"/>
<bean id="testService" class="de.linsin.sample.springdm.MyService"/>

</beans>

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:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd">

<util:properties id="extenderProperties">
<prop key="process.annotations">true</prop>
</util:properties>

</beans>

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

2009-10-12T05:48:00.000+02:00

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

2009-10-05T05:45:00.002+02:00

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:

@At("/guestbook")
public class Guestbook {
private List entries;
private Entry newEntry = new Entry();

@Inject
private EntryDao entryDao;

public List getEntries() {
return entries;
}

@Get
public void load() {
entries = entryDao.readAll();
}

@Post
public String save() {
newEntry.setDate(new Date());
Integer id = entryDao.save(newEntry);
return String.format("/sample/guestbook/%1$s", id);
}

public Entry getNewEntry() {
return newEntry;
}

public void setNewEntry(Entry argNewEntry) {
newEntry = argNewEntry;
}
}

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:

<body>
@Repeat(items=entries, var="entry")
<p>
<a href="/guestbook/${entry.id}">${entry.id} on ${entry.date}</a></p>

<form action="/guestbook" method="post">

Name: <input name="newEntry.name" type="text"/>

Text: <input name="newEntry.text" type="text"/>
<input type="submit" value="save" name="save"/>
</form>

</body>

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

2009-09-28T06:17:00.000+02:00

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

2009-09-22T07:19:00.006+02:00

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:

17.09.2009 09:08:23 org.springframework.osgi.web.deployer.tomcat.TomcatWarDeployer afterPropertiesSet
SEVERE: No Catalina Service found, bailing out
org.springframework.osgi.service.ServiceUnavailableException: service matching filter=[(objectClass=org.apache.catalina.Service)] unavailable
at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:395)
at org.springframework.osgi.service.importer.support.internal.aop.ServiceDynamicInterceptor.afterPropertiesSet(ServiceDynamicInterceptor.java:455)
at org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean.createProxy(OsgiServiceProxyFactoryBean.java:185)
at org.springframework.osgi.service.importer.support.AbstractServiceImporterProxyFactoryBean.getObject(AbstractServiceImporterProxyFactoryBean.java:86)
at org.springframework.osgi.service.importer.support.OsgiServiceProxyFactoryBean.getObject(OsgiServiceProxyFactoryBean.java:137)
at org.springframework.osgi.web.deployer.internal.util.Utils.createServerServiceProxy(Utils.java:117)
at org.springframework.osgi.web.deployer.tomcat.TomcatWarDeployer.afterPropertiesSet(TomcatWarDeployer.java:90)
at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.createDefaultWarDeployer(WarListenerConfiguration.java:197)
at org.springframework.osgi.web.extender.internal.activator.WarListenerConfiguration.(WarListenerConfiguration.java:105)
at org.springframework.osgi.web.extender.internal.activator.WarLoaderListener$1.run(WarLoaderListener.java:353)
at java.lang.Thread.run(Thread.java:619)

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.

Git Svn

2009-09-14T06:22:00.000+02:00

Last week I started working for my new company and like most of the IT businesses today, we are running subversion for Source Control Management (SCM). While we are still discussing, moving to a Distributed SCM (DSCM), I didn't want to lose the advantages of working with git. Remembering Samuel's talk at Java User Group Karlsruhe and with a hint from Ollie, I started using git-svn.

The git manual describes the svn capabilities as follows:

git svn is a simple conduit for changesets between Subversion and git. It provides a bidirectional flow of changes between a Subversion and a git repository.

git svn can track a standard Subversion repository....Once tracking a Subversion repository (with any of the above methods), the git repository can be updated from Subversion by the fetch command and Subversion updated from git by the dcommit command.

You can create a fully featured git repository from the trunk of a subversion repo with the following command:

git svn init -T https://svn.hostname.de/svn/projects/project/trunk

The git repository, that you just created is hooked to the trunk, passed with URL in the command. To get the HEAD, just run:

git svn fetch

Now you are ready to work with git, as if you had cloned a repo from GitHub. You can work with branches locally and commit your changes offline. When you want to share your work and push it back to subversion, you can use the following command:

git svn dcommit

You might ask yourself how to get the latest changes from your fellow developers? First, you should have no un-commited changes when you run:

git svn rebase

The reason for that, is this command is similar to svn update. It uses git-rebase instead of git-merge, in order to preserves linear history.

Those couple of commands got me started in no time and I didn't have to wait for a company-wide repository in order to have all the advantages that come with git.

No Improved Exception Handling

2009-09-07T06:03:00.000+02:00

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

2009-08-31T06:17:00.000+02:00

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.

Http Basic Authentication with Android

2009-08-24T06:00:00.000+02:00

The Google App Engine infrastructure, I'm developing in my spare time, is meant to be used by an Android client. To give our users at least a vague feeling of security, we decided to use a Basic Authentication together with HTTPS. Apparently, Android 1.5 is shipping with Apache's HttpClient 4.0 Beta2, which has a pitfall, when it comes to Basic Authentication.

When you search for HttpClient and Basic Authentication, Google will most definitely send you to the official documentation of HttpClient 3.x, which shows you, how to do Basic Authentication in a preemptive way. That means, sending the client's credentials with every request, instead of waiting for a 401 Unauthorized response and only then sending the credentials. That's probably what you want to in the first place, because it saves your client a request.

HttpClient client = new HttpClient();
client.getParams().setAuthenticationPreemptive(true);
Credentials defaultcreds = new UsernamePasswordCredentials("username", "password");
client.getState().setCredentials(new AuthScope("myhost", 80, AuthScope.ANY_REALM), defaultcreds);

This sample code won't compile with HttpClient version 4. The method called setAuthenticationPreemptive is missing. The problem is, if you omit this very method call, the code still works, but the authentication is not preemptive. We missed this little detail and only noticed after a while, that every request was preceded by a 401 Unauthorized request/response cycle. That doubled the amount of requests we served.

The HttpClient 4 documentation shows how to do preemptive authentication with the new API. You need to implement a so called HttpRequestInterceptor:

HttpRequestInterceptor preemptiveAuth = new HttpRequestInterceptor() {
    public void process(final HttpRequest request, final HttpContext context) throws HttpException, IOException {
        AuthState authState = (AuthState) context.getAttribute(ClientContext.TARGET_AUTH_STATE);
        CredentialsProvider credsProvider = (CredentialsProvider) context.getAttribute(
                ClientContext.CREDS_PROVIDER);
        HttpHost targetHost = (HttpHost) context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);
        
        if (authState.getAuthScheme() == null) {
            AuthScope authScope = new AuthScope(targetHost.getHostName(), targetHost.getPort());
            Credentials creds = credsProvider.getCredentials(authScope);
            if (creds != null) {
                authState.setAuthScheme(new BasicScheme());
                authState.setCredentials(creds);
            }
        }
    }    
};

It basically sets the Basic Authentication headers, before each requests and thus avoids the 401 response. In order for the interceptor to work, you need to add it to the request chain:

DefaultHttpClient httpclient = new DefaultHttpClient();
httpclient.addRequestInterceptor(preemptiveAuth, 0);

You might also run into the problem of using the old HttpClient 3.x way of doing Basic Authentication. It does work, but it's not preemptive, which you might not notice right away. Save yourself some time and checkout the sample code provided by Apache.

Furthermore, I wasn't abel to find any official site, which states the version of HttpClient, used in Android 1.5. There are various sources, you might encounter, when searching Google, but I would like to see an official site, that states the version. A reason for Google not to reveal this information might be, that they adopted HttpClient and thus are not compatible anymore. However, to avoid mistakes and confusion, it would be nice to know, on which version the Android HttpClient is based on.

Cron Jobs on Google App Engine

2009-08-10T06:15:00.000+02:00

I've been developing for the Google App Engine (GAE) for a couple of months now and there's a lot, I want to talk about in future blog posts. This installment is about scheduled tasks on the GAE - cron jobs - and a couple of pitfalls that you should be aware of.

The configuration of a cron on GAE is pretty straightforward. You define your job in a file called cron.xml, which goes to your WEB-INF folder in your WAR file.

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
    <cron>
        <url>/cron/clean</url>
        <description>job to clean tmp every 5 minutes</description>
        <schedule>every 5 minutes</schedule>
    </cron>
</cronentries>

The file is easy to understand: url denotes where the GAE is supposed to send a GET request to, when the cron is triggered. Whatever you place behind the denoted url is your own choice. It can be a plain Servlet or some RESTful resource. The schedule tag contains a english-like syntax to define when the url is supposed to be requested. In this example GAE makes a HTTP GET request to http://yourname.appspot.com/cron/clean every 5 minutes.

One of GAE's subtle details is that your application is being shutdown, as soon as there are no requests coming in for a certain period of time. That's no a problem by itself, however, if you want to access the cached data of your application from within your cron, you are in trouble. It's not a severe problem, you just need prepared for it.

Another pitfall, that you might encounter, is configuring the url of the cron to be secured by SSL. You can define which urls are supposed to be confidential in your web.xml. As soon as you add your cron's url, you'll encounter an error message in your admin console under "Cron Jobs", which says "Too many continues". This indicates, that GAE wants to execute cron jobs using http instead of https, which leads to a HTTP 302 response. Browsers can easily interpret it as "don't use http, use https instead", but the GAE can't.

This is not a security problem, since the urls of your cron job should only be accessible by administrators anyways. You can easily exclude the cron's url from your SSL configuration and everything should work fine.

There are more little gotchas, that I encountered developing for the GAE and I'm going to blog more about it soon.

JavaFX @ JUG-Ka

2009-08-03T06:15:00.000+02:00

With our new logo, designed by Samuel Mellert, who held last month's session on Git, we want to start into the second half of 2009. There are a couple of exciting talks coming up at Java User Group Karlsruhe, beginning with an introduction to JavaFX this week. To get the latest updates of the JUG-Ka sign up for our Google Group or join us on XING.

Stefan Schneider from Sun Micorsystem is going to give an introductory level session on JavaFX, with samples and time for QA. Stefan gave a couple of talks here in Karlsruhe and I'm very pleased he is back with something new.

The session takes place this Wednesday at University Karlsruhe and starts at 7:15pm. As usual, JetBrains and ZeroTurnaround are each giving away a free license of one of their products. There'll be a lottery, so 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.

I'm sure you all know the DZone network, which provides all sorts of services and information for developers, like Javalobby, JRoller or EclipseZone. They also have a service called Refcardz - nice little cheat sheets on a variety of topcis. You can download those Refcardz and print them yourself or you can come by on Wednesday and get one for free. DZone was kind enough to provide a couple of professionally printed Refcardz, which I will give out at the end of the next talk.

Git Stash

2009-07-29T06:10:00.000+02:00

After a great talk on Git at the Java User Group Karlsruhe and a couple of other experiences, I started to really dig the Distributed Source Control Management (DSCM) notion and its advantages. A neat and quite helpful feature of Git is stashing.

The Git manual has as an exceptionally helpful description of stashing. They call it "Temporarily setting aside work in progress".

While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. You would like to fix it before continuing. You can use git-stash(1) to save the current state of your work, and after fixing the bug (or, optionally after doing so on a different branch and then coming back), unstash the work-in-progress changes.

$ git stash save "work in progress for foo feature"

This command will save your changes away to the stash, and reset your working tree and the index to match the tip of your current branch. Then you can make your fix as usual.

... edit and test ...
$ git commit -a -m "blorpl: typofix"

After that, you can go back to what you were working on with git stash pop:

$ git stash pop

Git's stashing feature saved me quite some trouble a couple of days ago, while working on a side project. I developed a feature on branch "B" and had quite a big change-set, while someone found a bug on the stable branch, let's call it "A".

Coming from SVN, I thought I had to check-in my changes in order to switch to Branch "A" and fix the bug. That's quite ugly, because it screws with your history of commits and even might break your builds. I know that there are other possibilities with SVN, like copying your changed files or creating a patch file. However, to me those all look like workarounds rather than solutions.

So I simply stashed my changes from branch "B" and got a clean branch with HEAD. I switched to branch "A" and was able to fix and commit the bug. After switching to branch "B" again, I simply poped the changes from the stash, as if I had never stopped working on the feature.

After working with Git for some time, I would really recommend people to switch to a DSCM. I'm not alone with this. SpringSource's DM server team migrated their repositories to Git a couple of weeks ago and they didn't hear any complaints from the community. No matter if you choose Git or Mercurial, the advantages of a DSCM really outweigh the initial costs of getting started.

Jug-Ka Summer Stammtisch

2009-07-13T06:00:00.000+02:00

Since we haven't had a Stammtisch of the Java Users Group Karlsruhe for a while, I thought it's time to get together again.

We are gonna meet on Wednesday, July 15th - 20:00, at a nice pub called Litfass, near Marktplatz. For further information you can send an email to our Google Group or join us on Xing.

When Unchecked Exceptions Go Wrong

2009-07-06T05:53:00.000+02:00

In the application I'm developing right now, we found a bug right before going live. A colleague of mine forgot to catch an unchecked Exception in a loop, which led the loop to exit, before iterating over each element. Bugs like this are so subtle and hard to track, that's why I think it was kind of my fault for not using a checked instead of an unchecked Exception.


// must work all jobs
private void workAllJobs() {
  for(MyJob job : allJobs) {
    job.work(); // throws RuntimeException
  }
}

Let me be clear, I don't want to engage into the checked vs. unchecked Exception war. I made my point clear a couple of times, however I simply think I need to revise my position.

I used to think forcing a client of an API to catch an Exception was evil! That's why I usually design custom Exceptions to inherit from RuntimeException and declare each and every case carefully in the javadocs of my API methods. I simply followed the expert's advice:

Always declare checked exceptions individually, and document precisely the condition under which each one is thrown using the Javadoc @throws tag. .... While the language does not require programmers to declare unchecked exceptions that a method is capable of throwing, it is wise to document them as carefully as the checked Exceptions.

Unfortunately, the expert's advice didn't work in my co-worker's case. Should I say in most cases? He is with the sad majority of developers, that don't ready javadocs - not even on public API methods. Maybe I should have listened to people telling me this:

I kind of disagree with your example; documenting everything in every tiny detail may be a requirement for widely used public APIs (like the JDK), but IMHO a more relaxed approach is useful for the rest of us. Like "configuration by exception" is considered a good idea, there should also be "documentation by exception". That is, don't document every tiny detail but instead follow some higher level conventions. Many people do that intuitively, but unfortunately forget to document those conventions.

Like Matthias, my co-worker argued, that he thinks conventions should define what happens if e.g. you pass null to a method or which Exceptions are being thrown from an API method. I do agree, conventions are a great tool to define this kind of behavior. The problem with conventions are: How do you get the whole team to agree on certain conventions and more important - how do you manage those convetions?

Getting a team of strongly opinionated individuals to even agree on minor details, e.g. how to name interfaces, is almost impossible. Believe me, I have been there! After more than a year, we still can't agree on wether to use Eclipse's notation of IService or my preference - simply Service. I cannot imagine how hard it will be to agree on really important topics like passing null to methods and wether to throw IllegalArgumentException or NullPointerException in that case.

The second issue with conventions is how to manage them. Who is responsible to maintain those agreements? Do you put those conventions on a wiki page, which nobody updates and nobody reads anyways? I argue, that for us developers code and eventually the IDE is where we live, thus I think that's the place those conventions should live as well. Code is the common single point of truth for us and hence javadocs are in my opinion the best way to document any code related conventions.

I guess you can see where this is going. It's a trade-off, as always in software development. However, it's a trade-off with a catch. I think it's simply not enough to "just have conventions", they need to be documented and managed in the code and my weapon of choice for doing that is javadocs.

Java Forum Stuttgart

2009-07-03T07:27:00.001+02:00

Yesterday, I was attending the 12. Java Forum Stuttgart and compared to the last time I went, which was in 2005, the event has really fledged.

The quality of the sessions was good and the hallway was filled with familiar faces. The theme of the conference for me, was JPA and O/R mappers. There were a couple of really great talks about it and it seems like there's a lot of going on in that area at the moment.

I'm definitely gone be there again next year and I would love for the conference to be extended to a 2-3 days event.

Wrapping-up Jazoon09

2009-06-29T06:03:00.000+02:00

I was attending Jazoon09 in Zurich, Switzerland last week. As with springOne 2009, I wasn't really satisfied with this content of the conference.

The problem was, that there were only a few really good speakers and thus only a couple of great talks. The keynotes were average, only Adrian Colyer's presentation on the last day was standing out. Even James Gosling's presentation or Danny Cowards talk were both not that exciting.

However, instead of telling you what sucked, I rather want to highlight, that the organization of the conference was great! The food was really good! There was an vegetarian alternative every day and the coffee was delicious. Jazoon took place in a movie theater, just like Devoxx, thus it was easy to get there by train and the seats were nice and comfy. Kudos to the organizers.

There were a couple of great talks I want to highlight: Neal Ford's "Smithying in the 21st Century" as well as Ed Burns' "Secrets of the Rockstar Programmers" were really awesome and I can only commend listening to them, in case they come up on the schedule of another conference.

I'm not too sure if I'll come back to Jazoon next year, although I think it could be a really cool conference and a great alternative to Devoxx, which takes place in Antwerp.

Jazoon 2009

2009-06-21T10:58:00.000+02:00

I'll be at Jazoon 2009, which is starting next week on Monday with a Glassfish Day. It's going to be my first time in Zurich this year and I'm really excited, because they have a great line up of speakers.

Among others, there's gonna be the father of Java himself Mr. James Gosling. For me it's always something special to listen to a keynote of him.

There's gonna be sessions on a wide range of topics, e.g. "Concurrency and Performance Reloaded" with Kirk Pepperdine, "Development for the iPhone" or "Design Patterns in Dynamic Languages" with Neal Ford, to name only a few of the first conference day.

Git talk @ JUG-Ka

2009-06-15T05:52:00.000+02:00

This coming Wednesday Samuel Mellert (1&1 Internet AG) is going talk about "Distributed SCM with Git" at the Java User Group Karlsruhe. I'm a newbie when it comes to distributed version control and especially Git, that's why I'm really looking forward to this meet-up. The talk starts at 7:15pm and takes place at University of Karlsruhe.

JetBrains and ZeroTurnaround are each giving away a free license for their products. We are gonna have a lottery, so 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.

To get the latest updates of the JUG-Ka sign up for our Google Group or join us on XING.

Git(Hub) Pain

2009-06-08T05:55:00.001+02:00

This is a little bit of a rant post, so if you are not interested in my subjective experience with GitHub, you should stop reading now.

A couple of weeks ago I started playing with Git. First of all, I love the notion of distributed version control, although it took me a while to wrap my head around it.

Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

I found it quite hard to explain Git or distributed version control in general. The best explanation I heard so far comes from Joel Spolsky, who talked about it on the stackoverflow podcast. It goes something like this:

You are working on a local clone of the full repository and a commit is basically a set of changes applied to a version of that repository.

I have a little side-project with 2 other developers and we decided to use Git as our version control system. One of the reasons why we choose Git, was the limitations we saw in our daily work with SVN and the more important reason - isn't it just cool to try something new?

One way to let others participate in your development, is to have a repository on GitHub. Others can come in and get a local copy of your work, contribute to it and merge it back into your original source tree later on. Everything is accessible and essentially open source. However, if you pay GitHub some money, you can have private repositories with contributors - that's what we did.

The move from SVN to Git wasn't easy. We had to adopt our style of working with version control, because we ran into trouble pretty early. I guess we first needed to grok the mindset of branching and merging, before we could really leverage the advantages of distributed version control.

Unfortunately GitHub didn't help getting started. I don't know if it's because of broken tools or if it was GitHub's fault, but we managed to damage one of our branches. When I tried to pull from the branch I got the following error message:

crusty:doublemill dlinsin$ git pull origin master 
error: Could not read 9b82bba67693db3b47189aefea07ec4e1d7be38e 
fatal: bad tree object 9b82bba67693db3b47189aefea07ec4e1d7be38e 
remote: Counting objects: 13, done. remote: Compressing objects: 100% (8/8), done. 
error: waitpid (async) failed 
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. 
remote: Total 8 (delta 0), reused 0 (delta 0) 
remote: aborting due to possible repository corruption on the remote side. 
Unpacking objects: 100% (8/8), done. 
error: waitpid (async) failed fatal: error in sideband demultiplexer

Since I couldn't find clear information on the problem, I decided to open an issue with GitHub support. Unfortunately after almost a week, I got a reply to my issue which was more than disappointing:

The best thing to do would be to delete the repository and recreate it with a fresh git push.

I mean seriously? Is that the best they can do? Sure, it's the easiest way out for GitHub, but not the most customer friendliest way I can imagine. It's just so disappointing, because I like GitHub and I have no problem to pay for their service. In fact, I guess I would have paid them anyways, because they have a great product and deserve some support. I just don't like this kind of "Have you tried turning it off and on again?" - attitude.

However, even after all the trouble we had, I'm still glad we choose Git. I think distributed source control is the future and I would suggest anybody to have a look at it, before starting the next project with SVN.

More JDK 7 Language Changes

2009-05-28T13:07:00.001+02:00

A couple of month ago, Joseph Darcy announced the first six new language features for JDK 7. Yesterday, he posted another 7 proposals, which Sun will take into further consideration:

1. Byte and Short Integer Literal Suffixes by Bruce Chapman

2. Binary Literals by Derek Foster

3. Underscores in numbers by Derek Foster

4. Language support for JSR 292 by John Rose

5. Indexing access syntax for Lists and Maps by Shams Mahmood Imam

6. Collection Literals by Joshua Bloch

7. Large arrays (revised) by James Lowden

Joseph says:

All the selected proposals were reviewed and judged to have favorable effort to reward ratios and to preserve the essential character of the language.

I think "Collection Literals" and "Indexing access for Lists and Maps" will considerably improve my daily coding life as an average Joe developer. Furthermore, "Underscores in numbers" could really improve working with numeric data. Here are a couple of code snippets from the proposals:

6. Collection Literals:

final List<Integer> piDigits = [3, 1, 4, 1, 5];
final Set<Integer> primes = { 2, 7, 31, 127, 8191};

compare that to the current way of creating a immutable List:

final List<Integer> piDigits = 
Collections.unmodifiableList(Arrays.asList( 3, 1, 4, 1, 5));

I really like this proposal, it'll make life so much easier. I use the notation above almost in every JUnit test to create some sample data in a List or Set. It's so much cleaner and more readable using the proposed syntax.

5. Indexing access for Lists and Maps

List<String> l1 = ["a", "b", "c"];
String firstElement = l1[0];

I like this notation, it's concise and feels very natural. On the other hand, I don't really mind writing List.get(0). Actually, this reminds me of Scala, where you can also say something like:

val l1 = List("a", "b", "c")
val firstElement = l1(0)

3. Underscores in numbers

int phoneNumber = 555_555_1212;

This proposal is supposed to increase readability and everything that accomplishes this should be added to Java. However, I believe, you have to find the middle ground and only apply conciseness, where it makes sense and doesn't hurt readability, but that's another story.

Most of these proposals are only nice additions and are not really essential. However, I think a lot of them are going to make my daily coding life more enjoyable. I'm excited to see them implemented and hope there will be a JSR soon.

Make it Easy to Contribute

2009-05-25T06:03:00.000+02:00

The past couple of weeks, I've been playing a lot with Restlet, a Java based REST framework. I like the it a lot, because it's easy to use and you can get it up and running in no time.

The current version of Restlet is 1.1, but when I compared it to the upcoming version 1.2-M2. it was clear that I would start using that right away. It has built in Google App Engine support and uses an Annotation driven approach, which increases testability and ease of use. This is one of the rare uses cases, where I think Annotations are perfectly suited, but I'm digressing. Overall, it was a natural choice to use the milestone build 1.2 right from the beginning.

After a couple of weeks of coding against 1.2-M2, I started to encounter a couple of weird side effects. After testing the code against the current stable version, it was clear, that it must be a bug in the 1.2 milestone release. So I checked the Restlet site, which nicely describes the process of reporting bugs.

Before entering a new report, you should query the current issue database for similar open issues.

As a decent developer, I followed the link to the issue tracker and saw this:

I was shocked to see this kind of interface! I know I'm a developer and I should love these kind of fine grained and detailed options to query an issues tracker, but that's too much! It's not the first time that I see this interface, Java.net uses it too and I just think it's a PITA to use! Compare it to google's code hosting issue tracker interface:

It's worlds apart in terms of usability and ease of use! And the screenshot above even shows the "advanced" search mode. In most cases, you can find everything with a single search box - google like!

I think, if you want the community to interact and contribute to your project, make it as easy as possible for them. They are trying to help you! We all know the problem of issues reported multiple times or reporters not taking time to correctly file an issue. However, every feedback is valuable and you can always ask for further and more detailed descriptions, if necessary.

Coming back to my bug in Restlet, after I managed to query the issue tracker, I saw that it had already been reported. So I decided to switch back to the current stable version. Unfortunately, I had to jump through a couple of hoops to make it work on the GAE, but that's another story altogether.

Is JavaFX Really the Future?

2009-05-18T06:14:00.000+02:00

A java.net poll, which took votes over the past week, shows that a lot of developers are not quite sure, if JavaFX is the way to go in Java UI space. The "Editor's Daily Blog" tried to blandish the numbers:

The first thing to note is that more than 600 votes were cast. That means that this poll stimulated more community participation than any of the other recent polls. Does this matter? I think so. I think it suggests that, whatever may people think about the future of JavaFX, JavaFX is something that has captured their interest. People are following JavaFX.

To be fair, I voted for "It will endure as a secondary option". I'm not too sure if JavaFX will take off in the future. There was a lot of fuzz about it at last year's Devoxx. I talked to a couple of people back then, but all of them had different opinions. Some of them liked it, other were sceptical. However, the general opinion was "We'll have to wait and see!".

I rarely push out this kind of bash blog posts, but with Sun putting a lot of resources into JavaFX and this significant developer refusal, I think it's worth mentioning it.