Just Java » Java http://blog.cedarsoft.com Johannes Schneider (cedarsoft GmbH) about Java and related stuff Wed, 25 Aug 2010 09:46:33 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 Code Generation done right… http://blog.cedarsoft.com/2010/08/code-generation-done-right/ http://blog.cedarsoft.com/2010/08/code-generation-done-right/#comments Fri, 06 Aug 2010 11:34:33 +0000 johannes http://blog.cedarsoft.com/?p=381 Code Generation solves a lot of problems. And everybody uses it all the day: Ever generated Getters/Setters using your IDE? Or method stubs? Or constructors?

And sometimes complete classes are generated. One famous example is Hibernate that is able to generate Java classes from a database schema.

Most of the projects I have seen so far use a templating engine (FreeMarker or Velocity) to create the source files. Hibernate switched from Velocity to FreeMarker some years ago…

This approach is quite good for simple cases. Those can be solved quite fast using that approach.

Complexity

But things get worse, if you have to generate more sophisticated code. Of course FreeMarker supports conditions and you can do quite amazing things using complex model classes. On the other hand those templates start to get really complicated and hard to debug over time.
And of course you always have two sources: The template file and your data model.

Imports

One thing special to Java source files are the imports. When you conditionally use a class somewhere, you also have to add the import statement conditionally… Nothing that can be solved easily using FreeMarker.

So sometimes one might wish to have a nice API that does all the dirty work for you…

The alternative: Codemodel

I have looked around to find such an API. And it took me quite a long time to find one.
And that API is quite near beside you. Just a little bit hidden.

JAXB has a sub project called codemodel. This is an API that allows you to create Java classes by just using an API…

How to use Codemodel

There is no separate jar for codemodel. But the classes are shipped with every JAXB installation. So since JDK 1.6 the classes are just here and waiting to be used. But since they have renamed the package as “internal” I suggest to import the JAXB jar manually:

For Maven users this should be enough:

1
2
3
4
5
<dependency>
  <groupId>com.sun.xml.bind</groupId>
  <artifactId>jaxb-xjc</artifactId>
  <version>2.2.1</version>
</dependency>

A quick introduction

The API is not perfect yet. And it is not documented very well. But it is nearly complete and I didn’t miss much.
Here is a short example that should give you a fast start:

1
2
3
4
5
JCodeModel codeModel = new JCodeModel();
JDefinedClass foo = codeModel._class( "a.b.c.Foo" ); //Creates a new class

JMethod method = foo.method( JMod.PUBLIC, Void.TYPE, "doFoo" ); //Adds a method to the class
method.body()._return( JExpr.lit( 42 ) ); //the return statement

The code can be written to the file system. But it can also be written to a single output stream. This is great for testing:

1
2
ByteArrayOutputStream out = new ByteArrayOutputStream();
codeModel.build( new SingleStreamCodeWriter( out ) );

This code outputs that code:

1
2
3
4
5
6
7
8
9
10
11
12
13
-----------------------------------a.b.c.Foo.java-----------------------------------

package a.b.c;


public class Foo {


    public void doFoo() {
        return  42;
    }

}

Great, isn’t it?

]]> http://blog.cedarsoft.com/2010/08/code-generation-done-right/feed/ 17 Java Surprise: Setters/Getters and Collections http://blog.cedarsoft.com/2010/08/java-surprise-settersgetters-and-collections/ http://blog.cedarsoft.com/2010/08/java-surprise-settersgetters-and-collections/#comments Thu, 05 Aug 2010 09:27:08 +0000 johannes http://blog.cedarsoft.com/?p=385 Inspired by the Java Killers series, I wanted to post a problem I stumbled across some years ago:

Imagine a bean containing a field.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class Car {
  private final List<Tire> tires = new ArrayList<Tire>();

  public void setTires( List<Tire> tires ) {
    this.tires.clear();
    this.tires.addAll( tires );
  }

  public void addTire( Tire tires ) {
    this.tires.add( tires );
  }

  public List<Tire> getTires() {
    return Collections.unmodifiableList( tires );
  }
}

What is the output of that code?

1
2
3
4
5
6
7
8
9
Car car = new Car();
car.addTire( new Tire() );
car.addTire( new Tire() );

List<Tire> carTires = car.getTires();
System.out.println( "before: " + carTires.size() );
car.setTires( carTires );
System.out.println( "after1: " + car.getTires().size() );
System.out.println( "after2: " + carTires.size() );

The first part is easy:

before: 2

But the rest?

before: 2
after1: 0
after2: 0

We have managed to empty the collection accidentally – even if it is unmodifiable.
The problem lies in the setter and how Collections.unmodifiableList() is implemented:

Collections.unmodifiableList returns a list that is backed by the original list. Every change to the original collections is reflected.
Therefore the “clear” call empties also the unmodifiable list.

1
2
3
4
public void setTires( List<Tire> tires ) {
  this.tires.clear(); //the list is cleared! But since the method parameter is a view of this.tires, it is emptied, too.
  this.tires.addAll( tires ); //since tires is empty now, addAll doesn't do anything...
}

So be careful with collections. They might change a really surprising moments…

]]> http://blog.cedarsoft.com/2010/08/java-surprise-settersgetters-and-collections/feed/ 6 cedarsoft Serialization 1.0.0 released http://blog.cedarsoft.com/2010/01/cedarsoft-serialization-1-0-0-released/ http://blog.cedarsoft.com/2010/01/cedarsoft-serialization-1-0-0-released/#comments Mon, 25 Jan 2010 18:04:36 +0000 johannes http://blog.cedarsoft.com/?p=142 cedarsoft Serialization (GPL with Classpath Exception) offers version aware serialization of java object trees with maximum control. Its goal is to provide some simple classes (very small framework) that enables rapid development of versioned serialization.

Serialized XML contains version informations and might look like that:

<?xml version="1.0" encoding="UTF-8"?>
<businessObject xmlns="http://yourcompany.com/path/2.0.1">
  <name>theName</name>
  ...
</businessObject>

It does not contain any “magic” code. It just offers plain and very fast serialization.

It follows those main ideas:

  • Version support as first class citizen (Every serialized object gets its version information attached –>necessary for stability)
  • Minimized boiler plate code (–> fast results), but:
  • No magic (no bad surprises)
  • KISS
  • Performance, performance!
  • Flexibility and therefore stability: Serialized objects can be read with all future versions.

Do not believe the wrong “everything can be done automatically” promise. Write that code that matters. And nothing more.

]]> http://blog.cedarsoft.com/2010/01/cedarsoft-serialization-1-0-0-released/feed/ 0 Splitting up your pom.xml into multiple files http://blog.cedarsoft.com/2007/09/splitting-up-your-pom-xml-into-multiple-files/ http://blog.cedarsoft.com/2007/09/splitting-up-your-pom-xml-into-multiple-files/#comments Mon, 10 Sep 2007 22:35:00 +0000 johannes http://blog.cedarsoft.com/?p=3 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?

]]> http://blog.cedarsoft.com/2007/09/splitting-up-your-pom-xml-into-multiple-files/feed/ 0