You are currently browsing the archives for the java category


Going to euroclojure

I just bought my ticket for euroclojure on May 24-25. I’m looking forward to it and hope to meet all those awesome clojure developers in real life.


Bye bye java! Welcome clojure.

A long time that I’ve been blogging… I lost interest in java (as a language) in favour of clojure. Finally a LISP done right (in my eyes). No more fighting with OO design that did never gave me the expression power I experience with clojure’s concept of time and identity, macros and community. I’d changed the title of my blog to reflect my personal realignment.

So, bye bye Java, you served me well over the last 16 years (wow that’s a long time!). Welcome clojure! You make me feel more powerful day for day. But beware: YMMV!


Dependency Injection is not only about compile time dependencies

Tinou complains that dependency Injection was broken. I want to add some points to his / her statements:

The problem I’ve always had with DI frameworks, be it Spring or Guice, is they create this nasty dependency tree. If you don’t want to use GlobalApplicationContext.getBean() or Injector.getInstance() then you’ll need to inject all your dependencies at the root. It annoys the crap out of me, but I suppose there’s just no way around it…
Except if the language had a mechanism to realize interfaces and abstract classes at runtime, either built-in or through some extension.
[…]The fundamental problem with all dependency injection tools is they are trying to do what language should be doing (instantiating objects that implement some interface[!]).

These toughts might be correct if you reduce dependency injection to “instanciate a class that implement this or that inferface”. But I understand dependency injection as a tool for inversion of control and decoupling of implementations. Dependency injection shall enable the developer to reconfigure the application without compilation of the compontents that depend on eachother.

Yes, at some point you will have to decide which implementation of a certain interface shall be used, and one can argue where this “wiring information” should be placed: Spring uses an XML file, PicoContainers can be composed hierachically, guice can use annotations. But if you have only one implementation of the interface you can do without a dependency injection framework at all.


  • Fixed typos
  • As pointed out by Paul Hammant PicoContainer of course can be configured with XML as well as with Groovy, Python, Beanshell and Ruby. I’m sure one can add Yaml and Json easily as well. Furthermore I think this is possible to some extend for Spring and Guice as well and the Qi4J developers would be able to add something to this, too. What I wanted to make clear is that one can argue about when, where and how to wire the components; the different ways the mentioned frameworks offer emphasize this.

This must be shared: /^1?$|^(11+?)\1+$/ to check for prime numbers

That’s all and checks if a string does not consist of a prime number of “1“, e.g. “111” is prime whereas “1111” is not:


Although this seems cryptic its rather straight forward: match on either “” or “1” (first part until “|“) or match on a substring of 2 or more “1” with repeatedly fits the whole. For the string “111111” the substring “11” fits in 3 times.

Over all its a very high level description of a primality test. I never considered regular expressions as a mathematical domain language.

More details on Avinash Meetoo’s Blog.


Don’t subclass DefautListCellRenderer for Swing’s Nimbus LAF

If you follow the common practice to subclass JLabel to add some formatting to your combobox you will be surprised that this will break the rendering of JComboBoxes in the Nimbus Look Ant Feel.

Examples of bad JLabel-based CellRenderer

Basically the nice glass like look of the combobox will disappear and the old flat look will be restored. This comes due to Nimbus using a custom CellRenderer:


Fortunately this renderer is based on JLabel, too. This is why you can simply wrap the renderer and add some blinkenlights when needed:

Good example of renderer wrapping the original renderer

The implementation is straight forward:

public class InstanceWithIconCellRendererWrapper implements ListCellRenderer {
private final ListCellRenderer wrapped;
public InstanceWithIconCellRendererWrapper(ListCellRenderer listCellRenderer) {
this.wrapped = listCellRenderer;
public Component getListCellRendererComponent(JList list, Object value, int index, boolean isSelected, boolean cellHasFocus) {
String displayName = String.valueOf(value); // customize here
Component renderer = wrapped.getListCellRendererComponent(list, displayName, index, isSelected, cellHasFocus);
if (renderer instanceof JLabel) {
Icon icon = new ImageIcon(); // customize here
((JLabel) renderer).setIcon(icon);
return renderer;

Use it as follows:

jComboBox.setRenderer(new InstanceWithIconCellRendererWrapper(jComboBox.getRenderer()));