Johannes Schneider (cedarsoft GmbH) about Java and related stuff

Generics are surely the biggest change (considered from developers point of view) in Java since a very long time. And they are very powerful and comfortable to use. Learning a new API is *much* easier now.And it also saves a bunch of key presses when using an IDE (who needs Closures when your IDE creates generified anonymous classes?).

But unfortunately very often Generics are used wrongly.

Most of the time most of us are simply too stupid to understand Generics. Do you know anybody that completely understands the concepts? Me neither.

While Generics offer very big improvements for the user in conjunction with Collections, it seems to be hard to set them up correctly (for the design of an API). And there exist several famous failures…

Famous Failures

Google Guice

Although Bob Lee is a brilliant guy (much smarter than I ever will be) there exist several flaws within his great framework Guice.I have created a patch that solves the biggest mistake. Unfortunately the patch has been accepted only partially and just fixed the worst issues.

Glazed List

Uuuh… At least there exists a generified version. But that is the only positive thing that could be said about.Main problem: At the moment it is impossible to register an EventListener to an EventList that has a bounded wildcard (okay you can add some fancy casts to “solve” this issue…).

Assumed you have something like EventList (EventList extendes java.util.List). You won’t be able to register an EvenListener…

So now is the time to improve the world!

Now is the time to improve your API 100 times with just one simple, foolproof step.

You don’t have to fully understand the concepts of Generics (I am far away from it). Just follow this advice and most of the cases will work just as expected:

Never, never, never use any type of Collection *without* (bounded) wildcards in a method signature.

There only exist very few cases where a collection without a wildcard is needed. And most of these cases should be described accurately as hacks.

Don’t return a collection without a (bounded) wildcard.

Wrong:

public List getCustomers();

Instead use:

public List< ? extends Customer> getCustomers();

And please, please never accept a collection without a (bounded) wildcard.

Wrong:

public void addThings( Collection things);

Instead use:

public void addThings( Collection< ? extends Thing> things);

Why is it so important?

It is *very* important because it is not possible to widen a collection later:
List doubleList = new ArrayList();
List numberList = doubleList; //Compiler error!!!

numberList.add(new Integer(4)); //as numberList==doubleList
A list of Doubles is a completely other thing than a list of Numbers. It is often forgotten that Collection classes also offer *write* access. And the compiler must avoid the addition of objects to collections with the wrong type.

The killer argument

You *only* have to know the exact type of a collection, if you try to change that collection (e.g. add an element).

If you return an unmodifiable collection (and you really should in most cases), nobody will ever be able to add an element to that collection. So nobody will ever have to know the *exact* type of that collection.

Return a collection generified with a bounded wildcard and nobody will ever *think* about touching the list!

Same goes for method parameters. In the most cases only the content of the collection is used – no write access is needed! So it isn’t necessary to know the exact type of the collection. Offer the caller a little luxury and go without the additional but completely useless bit of information.

Conclusion:

As long as there is no need for changing a collection use wildcards.

I use db4o (GPL) within some projects. It is a really great peace of software. If you don’t need a relational database (and often you don’t!), db4o is definitly worth taking a look at it.

It is possible to use db4o with a client-server architecture. Often this is a faster and easier way to use db4o than some sort of RMI. Applications that shall use a common database but run on different machines (rich clients within a LAN) can benefit from those features of db4o.
For the next version (6.4) the performance of client server architectures is within focus – with success:
client server performace

Josiah Hester has created a great tutorial about image manipulation in Java. Take a look at it, it is very interesting and a good answer
to frequently asked questions.

The article contains informations about loading and drawing images. But then Josiah talks about image operations like flipping, rotating, splitting….

Today I tried to calculate some interest rates for one of my customers. In Germany we have several different and complicated calculation rules…

To solve this problem I used the Joda Time framework. This is a complete replacement for java.util.Calendar. When you ever tried to do any calculations related to dates, you know that *every* framework is better than java.util.Calendar….

And Joda Time is really great. You need some minutes to understand which interfaces to use (ReadableDateTime is a default replacement for java.util.Calendar). But especially the possibility to get many informations about a period between to dates is great. Joda Time fully supports several types of describing those periods. A period may be half a year, 6 months, 26 weeks, 182 days or a composition of them (1 year, 2 months and 15 days).
All you need is just a specific org.joda.time.PeriodType.

I am a big fan of Guice. Unfortunately Guice is not complete yet. There are several features that should be added as fast as possible – so everybody is waiting for version 1.1.

Tim Peierls has posted an interesting article about injecting method interceptors. Take a look – this is definitely worth a look.

http://tembrel.blogspot.com/2007/09/injecting-method-interceptors-in-guice.html

One of the main problems of Guice is that it is so different than Spring (but better). Several problems require a different approach than what an old Spring user expects. Because of that fact is is very inspirating to see people doing such things with Guice.

Google Guice is a really great Dependency Injection Framework and worth a look. Especially the performance and – much more important – the configuration using Java code in a very intuitive form are great features.

They have now released another project that can be very, very helpful. It is called Google Collections and provides some small but helpful classes.

A series describing the details can be found here:
http://publicobject.com/2007/09/coding-in-small-with-google-collections_08.html

Ever had to deal with a really, really huge pom.xml? As soon as you start not only to declare the dependencies but also to add informations about the distribution (repositories, site), mailinglists or developers, the pom.xml starts to become really huge.

It is hard to find the informations you search. And it is much harder to find that revision a dependecy has changed if there is so much noise due to changes in other sections.
Many applications with huge configuration files started to convert their files into directories over the last years. Apache now has its “conf.d” directory, crontab uses “cron.d” and so on.

Why not take the same step, too? Why not split up the pom.xml into several files that are placed within a directory called “pom.d”?
So I have created a proposal for Maven 2.1.

What do you think?

This is not a joke. It is possible to shut down your crashed linux box safely. It is possible to perform various low level commands regardless of the system’s state.

To perform such a command you have to press Alt + SysRq (Print) + a key representing the command.

To shutdown your box safely use the following combo:

1. Alt + SysRq + R – takes the keyboard out of raw mode.
2. Alt + SysRq + E – terminates all processes (except init).
3. Alt + SysRq + I – kills all processes (except init).
4. Alt + SysRq + S – synchronizes the disk.
5. Alt + SysRq + U – remounts all filesystems read-only.
6. Alt + SysRq + B – reboots the machine.

More details can be found at Wikipedia.

Some days ago, Bean Bindings 1.0 has been released – also known as JSR 295 (and as the JSR suggests, this may be added to the Java very soon).
I really love bindings. And I use JGoddies Binding very often. But the JGoodies Bindings has one big disadvantage. The binding is done based on strings.
You have to write something like that to bind a property:

PropertyAdapter adapter = new PropertyAdapter(bean, "propertyName", true);

The problem is, that it is necessary to write the name of the property as String. It is very hard to refactor that code later… And it is impossible for the compiler to verify it (without a major improvement).
But as we don’t have any better support build into Java now, it is better than nothing (as said, I use it often)…
And now there is this JSR. And they work really hard on that binding issue. And they talk and write and talk and write and finally release version 1.0. And what must I see?

Property firstP = BeanProperty.create("firstName");

That is exactly the same code (in its essence) as the other Binding Frameworks use. And this is *not* the way. Java has its weaknesses. But one of the most important strengths is the strict compiler…
Integrating sublanguages as EL into Java complicates everything: Compiler, Code Editors, GUI Tools….

I prefer waiting another two years for a good solution based on some other language feature (such as closures) than adding such an awful thing…

To be clear: I don’t criticize the details of the implementation. I didn’t even take a look at the code. I am sure it is done very well. All I hate is that awful string based thing…