A programmer's blog

Method calls through interface references are slower (on Android)

2010-02-05T10:29:00.002+02:00

In the 2009 Google I/O talk about writing real-time games for Android http://developer.android.com/videos/index.html#v=U4Bk5rmIpic it is recommended that for performance we don't use interfaces. Supposedly the calls through an interface reference are about 30% slower. It is also mentioned that calls to static methods are faster.

In these circumstances, i asked myself if all calls to a non-direct reference are slower. I'm not an expert at low level stuff, but it looks to me that calling a method through a interface reference is about the same thing as calling a method through a reference to a parent class. But this would mean that we shouldn't use inheritance at all. And that, for someone like me that usually trades performance for scalability, it sounds crazy.

I decided to make a quick test to see if this is true. Here's the code I used: http://pastebin.com/m7c7c0043

First I ran it on my PC and I was stupefied to find results like these at every run:
Direct refference => 1,596,318,257
Parent refference => 1,550,725,582
Interface refference => 1,552,626,591
Static refference => 1,751,394,872
So the interface calls are about the same. Actually sometimes they were faster by a negligible amount.

Then I tested it in an Android application, using a HTC Hero Phone. (Note: I reduced the number of iterations from 1000000000L to 5000000L).
Results were something like:
Direct refference => 3,767,791,749
Parent refference => 3,477,020,264
Interface refference => 4,690,185,547
Static refference => 3,327,636,719

So the interfaces are slower. I can now confirm with my own test. I guess the virtual machine is quite different.
The good thing is that calls through parent references are not slower. Wohoo! OOP for life

Simulate bean initialization in GWT with GIN

2009-11-13T16:41:00.003+02:00

I currently use Google-Gin in my project and I wanted a simple, clean way of calling an initialization method on some injected objects, right after all the properties have been set.
For Spring users, this would be the equivalent of afterPropertiesSet(). Up until now this hasn't been a problem as I was doing the injection in the constructor and I could call this method myself at the end of the constructor.
However, constructor injection and the GWT split points don't like each other so I need to do method injection (I like this better anyway).

After a bit of thinking, the simplest solution I've found is the following:


@Inject
public void setAll(A a, B b, C c) {
  this.setA(a);
  this.setB(b);
  this.setC(c);
  this.init();
}

You can do the same thing as in constructor. Instead of having multiple injected setters you can have a single injected method like above.

Always read the comments

2009-08-08T22:49:00.004+03:00

I've been using the db field identity and equals + hashCode override approach suggested in this article because the Hibernate official doc on equals seemed to have gaps.

However, I only recently read the comments on that article while doing a quick research on this subject. I seems that the Hibernate team is not happy at all with it. If you endure to read through the annoyed and dismissive responses they give (to be fair, I bed they have to repeat the same stuff to 1000 different dummy people so anyone would become dismissive), you'll find out that

you only have to override these methods if you use detached objects. And they feel there are much better alternatives to using detached objects.

This brings me in the position to reconsider if I'm using the right approach.

ALWAYS READ ALL THE COMMENTS DUMMY!

Hibernate + Spring + TimerTask = No Hibernate Session bound to thread

2009-08-06T12:57:00.004+03:00

I recently come across a problem in a Spring+Hibernate project when trying to execute an operation with a delay.

I had a service bean (let's say EntityService):

public class EntityService{
...
@Transactional(readOnly = false)
public void generateWithDelay(String id, long delay){
Entity e = new Entity();
e.setStatus("IN_CONSTRUCTION");
e.setId(id);
this.dao.save(e);
this.scheduler.addTask(id, delay, this);
}

@Transactional(readOnly = false)
public void finishGeneration(String id){
Entity e = this.dao.get(id);
e.setStatus("DONE");
this.dao.save(e);
}
....
}

I wanted to call generateWithDelay at a user action then after N seconds finishGeneration to be called.

I created a "Scheduler" an addTask method, that accepted the delay, the parameters of the call and a callback (for wich I created a SchedulerCallback interface that my service implemented).

Under the hood the scheduler would simply create a TimeTask than when the time passed it called the callback with the suplied parameters. This way the timerTask is as generic as possible and the finishGeneration is where it belongs in the entityService.

All nice and joly. generateWithDelay would work ok. It ads the entity in the DB and it starts the timer. However when the timer called the finishGeneration method I would get:

org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
at org.springframework.orm.hibernate3.AbstractSession FactoryBean$TransactionAwareInvocationHandler.invo ke(AbstractSessionFactoryBean.java:300)

Obviously something is wrong with the transaction. A transaction never gets created before reaching the dao even thow finishGeneration is annotated with @Transactional. The annotation should work beacause it works just fine for generateWithDealy.

What to do? what to do? My first thought was that it's the source of the call that creates the problem. The hibernate transaction usually is the JPA transaction that the J2EE container provides. So if the call is not initiated by a user action the transaction might never get called. But I'm not running in a J2EE environment and I have:

<prop key="hibernate.current_session_context_class">org.hibernate.transaction.JDBCTransactionFactory</prop>
<prop key="hibernate.transaction.factory_class">thread</prop>

so it can't be it.

As a first fix I solved this by programatically opening a transaction in the timerTask just before invoking the callback. With springs Transaction Template it's actually quite easy. After this little trick it works just fine.

Lucky for me I remained curious about why it won't work with declarative transaction. In the end I found the problem.

When I provide the callback to the scheduler I do:

this.scheduler.addTask(id, delay, this);

As you know, in Spring the transaction is started by the proxy that wraps the entityService. However, because I use JDK proxies, this won't be the proxy, but the proxy target (the original service). So when the callback is invoked it bypasses the transaction mechanism completely. The trick is to provide the actual proxy to the scheduler. I did this by letting EntityService implement ApplicationContextAware and BeanNameAware and fetching the proxy from the applicationContext at initialization:


public class EntityService implements ApplicationContextAware, BeanNameAware, InitializingBean{  
...  
public void setApplicationContext(ApplicationContext ac){
 this.ac = ac;
}
public void setBeanName(String beanName){
 this.beanName = beanName;
}
public void afterPropertiesSet(){
 this.myProxy = this.ac.getBean(this.beanName);
}
...
@Transactional(readOnly = false)  
public void generateWithDelay(String id, long delay){  
 Entity e = new Entity();  
 e.setStatus("IN_CONSTRUCTION");  
 e.setId(id);  
 this.dao.save(e);  
 this.scheduler.addTask(id, delay, this.myProxy);  
}

Spring to solve GWT - Hibernate mess

2009-06-21T18:00:00.005+03:00

Everybody knows that GWT and Hibernate don't get together too well. At least not when you're using GWT-RPC. That's because Hibernate changes your beans when you're using collections or properties/associations with lazy fetching and GwtRpc can't serialize those beans.

For example if one of your beans has a Set of other beans, when the bean will be fetched Hibernate will use it's PersistentSet implementation of Set. This implementation contains references to other complex Hibernate objects like the SessionFactory. So the serialization will fail even if your bean implements IsSerializable and follows all the serialization rules.

The common solution is to force all your GwtRpc services to return a deep-copy of the bean, instead of the bean itself. This way you can use the standard collection implementations and de-proxyfy any lazy-loading properties.

GWT Type 'package.class' was not serializable and has no concrete serializable subtypes

2009-06-15T12:25:00.002+03:00

Uhh, these pages saved me a lot of trouble! Juri Strumpflohner's TechBlog: Strange GWT compiler error when trying to serialize Java objects, http://tom.jteam.nl/?p=6.

Note to self! don't you ever skip-read important pages as: http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=DevGuideSerializableTypes and http://code.google.com/docreader/#p=google-web-toolkit-doc-1-5&s=google-web-toolkit-doc-1-5&t=FAQ_RPCSerializationSupport

So basically in order to make a class gwt-serializable (the red lines were what caused my problems):
#1. It must implement com.google.gwt.user.client.rpc.IsSerializable. After GWT 1.5 you can also use java.io.Serializable.
#2. All non-final, non-transient instance fields are themselves serializable
#3. Prior to GWT 1.5, it must have a public default (zero argument) constructor or no constructor at all.
#4. As of GWT 1.5, it must have a default (zero argument) constructor (with any access modifier) or no constructor at all.
#5. Not all JRE classes that implement java.io.Serializable are gwt-serializable. In my case it was java.lang.Class

Best way to have synchronized singletons

2009-05-18T18:26:00.002+03:00

Use the last method:
http://java-x.blogspot.com/2006/03/singleton-pattern-in-java.html

Efficient way to iterate maps

2009-05-18T18:00:00.002+03:00

True! I see it every day in Spring framework code.
http://jtoee.blogspot.com/2008/05/better-way-to-iterate-java-maps.html

Advising Spring @Controllers with AOP

2009-05-15T14:34:00.005+03:00

As I mentioned in my previous post Spring AOP can't advise controllers the best solution is that you can use @Controller annotated beans instead of the Controller hierarchy.

As I found out this gave me a headake too. When I managed to make then accept the AOP advice they wouldn't be detected as controllers. When I made them detected as controllers they wouldn't be advised. When I managed to do both request mapping annotations wouldn't work.

After some poking on the Spring forums and with the help of Marten Deinum, I finally made it work exactly as I wanted. I'll share my findings with those of you having trouble using aop with controllers.

So, we have the main application context (the one started by org.springframework.web.context.ContextLoaderListe ner) with one ore more xml files.

Here you should instantiate the service and lower application levels beans. This can be done by placing here the beans (by xml) or by placing the component scan component that will do that for you. Make sure that your controller beans are not instantiated here.

Also here you need to include the aop:aspectj-autoproxy component and the aspect beans that will advice you service (or lower levels) beans. Notice that here you can use JDK proxies or CGLIb by your choice.

In the servlet context, you place the instantiation of the controllers by component scan. You can do it as xml but component scan would be preferably.

Now you place another aop:aspectj-autoproxy component. Notice that you now have to specify proxy-target-class="true" because only GCLIB will work (when using JDK proxies the RequestMaping annotations will not work because they're not inherited by proxyies while they are by subclasses). You also place here the instantiation of the aspects that will advice your controllers.

That's all! Because as Marten said the bean processors apply only to the current context (and the main AC and the servlet AC are two separate context just linked together), you can have JDK proxies on service beans and autwired, automapped, GCLIB advised controllers.

My only concern is that this will break if Spring will decide to make bean processors work with linked application contexts (actually won't break but will force the use of CGLIB application wide).

Google Web Toolkit Blog: GWT and Maven - Playing Nicely Together Since 2008

2009-05-08T16:12:00.002+03:00

Hmm, it seems my previous post about automatically downloading the GWT dependencies (http://cristianvrabie.blogspot.com/2009/05/automatic-install-gwt-dependencies-with.html) is a bit deprecated. You can now reference all dependencies with a compile scope as for any other artifact. Thanks to the GWT guys for a great post: Google Web Toolkit Blog: GWT and Maven - Playing Nicely Together Since 2008

Automatic install Gwt dependencies with Maven

2009-05-08T15:02:00.007+03:00

From what I noticed so far, many Maven-Gwt users fulfil the dependency to Gwt using system artifacts. This means downloading GWT manually and adding a dependency like:


<dependency>
  <groupId>com.google.gwt</groupId>
  <artifactId>gwt-dev-windows</artifactId>
  <version>${gwt.version}</version>
  <scope>system</scope>
  <systemPath>c:/gwt/gwt-dev-windows.jar</systemPath>
</dependency>

This will obviously not work well in a team as all must install gwt in the same location. The quick solution is to use a system variable or a property in .m2/settings.xml like this


  <systemPath>${env.GWT_HOME}/gwt-dev-windows.jar</systemPath>

This works well but still presents the problem that when you want to upgrade to a newer gwt version you have to instruct all the team to update their version.

There is a more elegant solution to it: use the maven-dependency-plugin. Let's get started.
First you must add this to your build » plugins section in pom. This will download a zip with the specified gwt artifacts and unpack it in your local repository.


<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>unzip-gwt-libs</id>
      <phase>compile</phase>
      <goals>
        <goal>unpack</goal>
      </goals>
      <configuration>
        <artifactItems>
            <artifactItem>
              <groupId>com.google.gwt</groupId>
              <artifactId>gwt-dev</artifactId>
              <version>${gwt.version}</version>
              <classifier>${platform}-libs</classifier>
              <type>zip</type>
              <overWrite>false</overWrite>
            </artifactItem>
          </artifactItems>
          <outputDirectory>${settings.localRepository}/com/google/gwt/gwt-dev/${gwt.version}</outputDirectory>
        </configuration>
      </execution>
    </executions>
  </plugin>

Now that the rights dependencies are in the repository you can add the dependencies:


<dependencies>
     <dependency>
      <groupId>com.google.gwt</groupId>
      <artifactId>gwt-servlet</artifactId>
      <version>${gwt.version}</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>com.google.gwt</groupId>
      <artifactId>gwt-user</artifactId>
      <version>${gwt.version}</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>com.google.gwt</groupId>
      <artifactId>gwt-dev</artifactId>
      <version>${gwt.version}</version>
      <classifier>${platform}-libs</classifier>
      <type>zip</type>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>com.google.gwt</groupId>
      <artifactId>gwt-dev</artifactId>
      <version>${gwt.version}</version>
      <classifier>${platform}</classifier>
      <scope>provided</scope>
    </dependency>

In case you're wondering what platform is, it's just a trick to ensure that both windows and linux users get what they need automatically:


<profiles>
  <profile>
    <id>windows</id>
    <activation>
      <os>
        <family>windows</family>
      </os>
    </activation>
    <properties>
      <platform>windows</platform>
    </properties>
  </profile>
  <profile>
    <id>linux</id>
    <activation>
      <os>
        <family>unix</family>
      </os>
    </activation>
    <properties>
      <platform>linux</platform>
    </properties>
  </profile>
</profiles>

Voila! Maven at it's full power.

I also pasted the entire pom:
- here it is for gwt 1.6: http://www.paste-it.net/public/ud8181b/
- here it is for gwt 1.5: http://www.paste-it.net/public/re927e7/
Note that both are for projects that use the noServer option but is easy to configure them otherwise. Also, the 1.6 project uses a different plugin to compile gwt as the one i used for for 1.5 is on it's way to deprecation, and it does not support hosted mode as well in 1.6.

Spring AOP can't advise Controllers

2009-05-06T13:50:00.006+03:00

I recently had a problem with advising a Spring MVC controller by using Spring AOP. It was the first time I tried to advise a controller method. The thing would basically not work, as that method call was never intercepted. My setup was ok as any other bean would get advised correctly.

The problem is that the methods of the controller are called internally from org.springframework.web.servlet.mvc.AbstractController and the proxy method that Spring AOP is using can't detect such a call.

The solution is to not use the Controller hierarchy. Just use beans annotated with @Controller and map your classes via @RequestMapping. This way the methods will be called via reflection by a subcomponent of the dispatcher.

However, if you're stuck inheriting the Controller class, the best thing you can do is to use a poincut like execution(* org.springframework.web.servlet.mvc.AbstractController.handleRequest(..)) because this is the method that is getting called from outside. Based on what you want to do this might be or not be enough. For me this is a too generic join-point, as all controler methods would get advised and I want only a specific one to be.

The foolproof solution is to use a full blown AOP solution like AspectJ that uses a loadtime or compile time weaving, and would be capable of intercepting an internal method call.

New GWT Event System

2009-02-27T10:53:00.003+02:00

Following my last post about the GWT listener collection, i found out that in GWT 1.6 a new event system is to be implemented: http://code.google.com/p/google-web-toolkit-incubator/wiki/GwtEventSystem
It looks pretty cool. I can hardly wait to try the new toy :D

GWT listener collection and ConcurrentModificationException

2009-02-26T20:45:00.001+02:00

I noticed that if you try to alter the list of a widgets listeners in the listener implementing method, you get java.util.ConcurrentModificationException: null. For example:


public class MyApplication implements EntryPoint, ClickListener {
  public void onModuleLoad() {
      Button w = new Button("clickme");
      w.addClickListener(this);
      RootPanel.get().add(w);
  }
  public void onClick(Widget sender) {
     ((Button)sender).removeClickListener(this);
  }
}

This is to be excepted since we're modifying the listener collection while iterating over it. However, this can be solved in the FocusWidget implementation by iterating over a clone of the listener collection instead of the actual collection. As result, the collection on which we iterate can never change and the behavior is consistent.


public void onBrowserEvent(Event event) {
  switch (DOM.eventGetType(event)) {
     case Event.ONCLICK:
         if (clickListeners != null) {
           clickListeners.clone().fireClick(this);
      }
      break;
   ......
}

I don't know how often people remove listeners in the actual event, so I can't tell that the cloning of the collection is worth in the long run. If only the listener collection would be protected instead of private someone could overwrite onBrowserEvent to add this functionality on any widget that might need to remove listeners while iterating over the collection. It's better than using DefferedCommand.

Die IE6! Die!

2009-01-28T23:23:00.002+02:00

I currently stumbled on a chart showing the decrees in IE6 users and cheered on the news. As an ex WEB/SCRIPT/CSS/DO-IT-ALL developer, i know the pain of making everything right on all browsers in 10 minutes then loosing 3 days to "try" to make it look at least remotely the same on IE6.

As I said on many forums damn IE6 is like a stubborn beast that just won't die. I really hope it's this year...
And when it happens I bet many of us will still have nightmares about it :)

- AAAAA!!!
- Honey, what's wrong? Why are you crying?
- That damn PNG won't work!
- What?!?!

Seriously now. I'm glad it's almost over! Die bastard! Die!

BitFlags and EnumSet

2009-01-16T17:33:00.008+02:00

Have you ever had a method call like this?


public void doSomething(MyObj obj, boolean detailed);

Beautiful ... simple ... elegant ... until the PM decides to do have a bit more options.


public void doSomething(MyObj obj, boolean withParam1, boolean withParam2, boolean withParam3, boolean withParam4, boolean withParam5, boolean withParam6 );

And for the sake of backwards compatibility you do all the intermediate methods.


public void doSomething(MyObj obj);
public void doSomething(MyObj obj, boolean withParam1 );
public void doSomething(MyObj obj, boolean withParam1, boolean withParam2 );
.
..
...

And each time he adds another parameter you feel like slamming your hear (or optionally his head) with the door.

Well, for this situations, I discovered EnumSet as being a very good, anti-head-slamming solution.

If you get to read the dark scroll of the Java Enums, you'll see that there's more to the tiny Enum than you might know. In Java, Enums are not glorified integers as in other languages, but you can do all sort of interesting stuff with them as add data, add behaviour or use them as bit flags inside an EnumSet. And since your method really looks like it needs something like bit flags.

For those of you don't know what I'm talking about, bit flags are something like this. However Enum set looks much more civilized and since they're implemented as bit arrays, they're quite efficient.

So how do you use them? First of all you need an Enum. Lets say


public Enum DoSomethingWith{
  PARAM1,
  PARAM2,
  PARAM3,
  ...
}

then you change your method like this:


public void doSomething(MyObj obj, EnumSet include);

you call your method like this:


doSomething(obj, EnumSet.of(DoSomethingWith.PARAM1, DoSomethingWith.PARAM3, DoSomethingWith.PARAM10));

and you check like this:


if(include.contains(DoSomethingWith.PARAM3)){...}

Way to go EnumSet! That's until your PM decides to add a non boolean parameter to the method :)

StringBuilder vs. String

2009-01-16T14:32:00.013+02:00

While writing an serializer i suddenly and concatenating strings like hell i suddenly remembered that Strings are in fact immutable objects and might be actually inefficient to do a lot of concatenations. So i started to read about String vs StringBuffer vs StringBuilder (the younger faster, not thread-safe, brother of StringBuffer).

Man, I'm telling you, it's a fight out there. Everybody is throwing "specialist" opinions left and right. So i still don't know if


String s = "a" + var + "b";

is or is not faster than


StringBuilder sb = new StringBuilder();
s.append("a");
s.append(var);
s.append("b");

Anyway, my opinion is that for simple operations there's no damn difference. It doesn't matter anyway. Loop operations are those that matter. I won't start using StringBuilder for "a"+"b". So even though I've seen tons of decompiled bytecode and sf theories, I haven't seen a single real case time. So I did a quick one (note that the situation might not be very realistic to you but it makes sense to some scenarios I've been throough like my serializer) :


int[] runfor = {10,100,1000,10000,100000};
  String a = "fdafdsf";
  String b = "sjnfadhbfdsaf";
  int buffersize = a.length()+b.length();
  
  for(int i=0; i<runfor.length;i++){
   long start = System.currentTimeMillis();
   String s = "";
   for(int j=0;j<runfor[i];j++){
    s += a + "--" + b;
   }
   long end = System.currentTimeMillis();
   System.out.println("String concatenation x "+runfor[i]+" times: "+(end-start)+" miliseconds");
   
   start = System.currentTimeMillis();
   StringBuilder sb = new StringBuilder();
   for(int j=0;j<runfor[i];j++){
    sb.append(a);
    sb.append("--");
    sb.append(b);
   }
   end = System.currentTimeMillis();
   System.out.println("StringBuilder concatenation x "+runfor[i]+" times: "+(end-start)+" miliseconds");
  }
 }

And, damn, I was surprised!!

# Runs	Time for String concatenation (milliseconds)	Time for StringBuffer append
10	0	0
100	2	0
1,000	37	0
10,000	15888	3
100,000	GOT BORED WAITING	49

At first I thought that i divided the string buffer by 1000 as to display it in seconds. :) Hmm.. and there were people actually saying that they'll give up performance for clarity any time of the day. Hmm.. Obfuscation forever baby! :)))

Hibernate Love and Hate relationship

2009-01-14T22:57:00.004+02:00

I was just praising Hibernate a few days ago for how much it helps with simplifying your work, reducing boilerplate code and how well lazy loading works, actually making it enjoyable to work with RDBs, when I hit another major limitation. It seems you can't perform a DISTINCT query via Hibernate Criteria API :|

The only workaround for it is to use a ResultTransformer but which runs at memory level (so if you have a result set of hundred of items you're screwed) and has the bad habit of not working all the time.
.setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)
Plus, you cannot use this with limit because if you use limit 10 and from those 5 are duplicates, you will have random result number :|

A Jira issue is opened since 2003 http://opensource.atlassian.com/projects/hibernate/browse/HB-520 and just sits there with tens of votes.

I'm telling you, this "Hibernate" experience it's one bumpy carousel. You don't know what tomorrow might bring.

My server is too fast

2009-01-08T10:08:00.005+02:00

I was currently working on a GWT application when I had some problems involving null pointers :) Ok, ok, i know that should not be happening to a "pro" developer but hang on a bit..
So i was doing something like this:

- expect triggering event
- send ajax call
- draw stuff
- receive ajax response
- use the received data to complete the drawing

The reason why I was sending Ajax call first was so the response time is:

|----------| (draw time)
|-----------------------| (ajax request time) - this is the actual time because the draw and request run in parallel

instead of
|----------||-----------------------|
(draw time) (ajax request time)

However, i haven't counted that the ajax response might be back before JS finishes drawing. That never happened before to me so that's my only excuse. So when the response was back the elements i needed were not there yet thus the null pointer exceptions.

Ofcourse the fix is quick:

in drawing:


doneDrawing = false;
hasUnrenderedData = false;
unrenderedData = null;
sendAjaxCall();
draw();
if(hasUnrenderedData){
 callback(unrenderedData);
 unrenderedData = null;
 hasUnrenderedData = false;
}

in callback:


if(doneDrawing){
 finishDrawing();
}else{
 unrenderedData = deserialize(response);
 hasUnrenderedData = true;
}

Hope I learned from this and I don't shame myself again like this :)

ByteArray in JSON

2008-12-25T02:12:00.002+02:00

I recently found out that string transmitted thought JSON can't be as wild as you may wish them to be.

I wanted to bundle some variables into a byte array then convert it to a string and transmit it as a string property of a json object. The purpose was to obtain the shortest possible message. It would look something like:


{"bytes":"","otherProperty":"etc..."}

Well, it seems that this is not right. Or at least some JSON validators tell me (since the string obviously contains non printable characters). After some Java Ranch posting I found out that this also happens to SOAP messages so if it's not a standard (as i haven't seen anywhere in the JSON documentation), it's at least a tacit agreement.

The only thing left to do is to apply a base64 encoding to the string which gets rid of all the problems and keeps my string as short as it can be. I also found a nice converter script which i can use both on server side and gwt client side (praise you google for your miracle invention! :) )

GWT Module projects with Maven

2008-12-15T08:37:00.003+02:00

I recently had the necessity to break a GWT-Maven project into multiple subprojects. The situation is pretty common: 2 or more projects used the same code so I had to make a commons module (library). I wasn't quite sure how the maven-googlewebtoolkit2-plugin, that I use, was handling this but finally nailed it down.

So the trick is to have the commons project packed as a jar, opposed to a standard entry point project that would be packed in a war. The absolute critical aspect of this is to include the source *.java files in the jar. I do this by using the maven-resources plugin in the pom file of the library project:


  <build>
  <resources>
    <resource>
      <directory>src/main/java</directory>
      <includes>
        <include>**/client/**</include>
        <include>**/public/**</include>
      </includes>
    </resource>
    <resource>
      <directory>src/main/resources</directory>
      <includes>
        <include>**/client/**</include>
        <include>**/public/**</include>
        <include>**/*.gwt.xml</include>
      </includes>
    </resource>
  </resources>
  </build>

I also used include on the resources folder because i place my .properties file (or any non-java file) in there.

Ok. Good. Now we have a jar that includes the source file (note that we didn't applied any gwt compilation - that will be done by the including project). We install it with a classic:


mvn install

Going to the gwt project that includes the library, i use a normal dependency include.


<dependencies>
    <dependency>
      <groupId>com.myproject</groupId>
      <artifactId>gwt-commons</artifactId>
      <version>${myproject.commons.version}</version>
    </dependency>
  </dependencies>

Because of this, the maven-googlewebtoolkit2-plugin will add the path to the jar file to the classpath before executing the compile.

Note:
I noticed that if the project includes a lot of modules you might get a "line too long" from windows. A common solution is to move the local maven repository to a shorter location: for example C:/.m2/.. rather than C:/Documents and Settings/../.m2/..

Now, all that is left is to include the maven-googlewebtoolkit2-plugin as usual:


 <build>
    <plugins>
      <plugin>
        <groupId>com.totsp.gwt</groupId>
        <artifactId>maven-googlewebtoolkit2-plugin</artifactId>
        <version>${maven.gwt.compiler.version}</version>
        <configuration>
                
          <logLevel>${gwt.compile.log.level}</logLevel>
          
          <extraJvmArgs>${gwt.compiler.memory}</extraJvmArgs>
          
          <style>${gwt.compiler.codestyle}</style>
          
          <noServer>${gwt.noserver}</noServer>
          <port>${gwt.port}</port>
          
          <runTarget>myproject-web/com.myproject.MyProject/index.html</runTarget>
          
          <compileTargets>
            <param>com.myproject.MyProject</param>
          </compileTargets>
                    
          <generatorDestinationPackage>com.myproject.client</generatorDestinationPackage>
          <generateGettersAndSetters>true</generateGettersAndSetters>
          
        </configuration>
        
      <executions>
        <execution>
          <goals>
            <goal>compile</goal>
          </goals>
        </execution>
        
        <execution>
          <id>compile</id>
          <phase>process-classes</phase>
          <goals>
            <goal>compile</goal>
          </goals>
        </execution>
        
      </executions>
      </plugin>      
    </plugins>      
</build>

Note:
Note that you have to have defined the properties used by through the pom files like ${gwt.compiler.codestyle}. For more information about what values can these have, have a look at the gwtmaven documentation.

Hibernate is ultra-sensible at collections!

2008-11-26T14:55:00.005+02:00

Found (another) tricky thing about Hibernate.

To be honestly is starting to piss me off. Maybe because I still don't have the experience to steer clear of these problems or i just miss the old days when I was writing every query with my own hand and everything that happened was so predictable.

So I have a standard class A that in the hbm mapping has a bag of objects B. I wanted to use bag because they say everywhere that bags are very efficient. However in my class i use a HashMap to store the B objects so it's easier to manage them. The key of the map is a property from the B object itself.

To make the conversion i use a trick in the setter/getter:


public class B{
  private String name;
  //.. other properties
  //.. setter and getters
}

public class A{
  HashMap<String,B> objs;
  public Collection<B> getObjs(){
    return this.objs.values();
  }
  public setObjs(Collection<B> objs){
    for(B o:objs){
      this.objs.put(o.getName(),o);
    }
  }
}

This seems not to be on the liking of Hibernate, and a simple get to an object A seems to trigger an update in the database.


A a = dao.get( id_of_a );

My guess is that before the session closing, a is checked for modifications and the hash code in A.getObjs() is obviously different than when hibernate originally put it there, this triggering an update.

Remember that ordinal parameters are 1-based!

2008-11-20T11:05:00.005+02:00

I recently came across java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based! I decided to mark this down because it's not that common and can be quite ambiguous.

For example, the first time i got this it was because i provided an array with to many parameters to a query:


Object[] params={ "usr","usr@gmail.com","some other", "parameters",2, 3 };
getHibernateTemplate().find( "from User user where user.username=? and user.email=?, params)

The second time was even more ambiguous:
I got this because i haven't mapped a file. For example, if I have a User entity and i forget to add User.hbm.xml to the hibernate.cfg file but no other entity points to User, then it won't fail at startup because hibernate can't possible know that we need that entity. It will however fail when having a query request the entity, but not with a nice "not known entity" exception but with java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based!.

Hibernate enhanced Enum Mapping to String

2008-11-20T00:29:00.000+02:00

Found a nice "enhanced" method of mapping Enums to Char/Varchar in Hibernate which requires only one class, opposed to the standard hibernate method in which you would need to create a class for every type of enum you wanted to map. Further more, you can use this as id or as discriminator.

Downright weird things about how programs are executed!

2008-11-19T23:45:00.006+02:00

Following my previous post Paranoid about concurency in a Spring web application, by reading the first 2 chapters of Java Concurrency in Practice - which by now i found it's a very good book; i recommended to anyone who's into threads - i found some downright stupefying things about how programs are run and what problems you have to think about.

Let's take this simple example:


public class A{
    private static boolean ready;
    private static int number;

   private static class ReaderThread extends Thread{
          public void run(){
           while(!ready)
                     Thread.yield();
                System.out.println(number);
    }
   }

    public static void main(String[] args){
          new ReaderThread().start();
          number = 42;
          ready = true;
  }
}

What can go wrong you say?! The thread will wait till the other thread sets ready to true, by then number will be set and we will print 42.

NOT THAT FAST! It seams since in the main thread there's no special need to have the 2 assignments in a certain order, the processor or jvm might decide to run them in a different order. So ready might be called before number is set! Hmmm.. this is something new :)

To quote from the book:

In the absence of synchronization, the compiler, processor, and runtime can do some downright weird things to the order in which operations appear to execute. Attempts to reason about the order in which memory actions "must" happen in insufficiently synchronized multithreaded programs will almost certainly be incorrect.

Paranoid about concurency in a Spring web application

2008-11-05T18:11:00.003+02:00

After some "light" reading in (in Java Concurrency in Practice and Patterns of Enterprise Application Architecture) i became a bit paranoid about possible concurrency problems in a simple Web Application.

To quote the authors of Java Concurrency in Practice - chapter 1.4 Threads are everywhere -

Even if your program never explicitly creates a thread, frameworks may create threads on your behalf, and code called from these threads mus be thread safe. [...] Frameworks introduce concurrency into applications by calling application components from framework threads.

Then there's a listing of some very usual and used frameworks that make use of thread and might add problems to your otherwise liniar code:
- Timer
- Swing and AWT
- RMI
- Servlets and JSP

Putted shortly: EVERYWHERE!!!

With this fresh in mind I placed some posts on the Spring and JavaRanch forums in search of confirmation: "a simple web app application do present concurrency problems". You can view the posts here (and admire my horrible sketches): http://forum.springframework.org/showthread.php?p=211392#post211392,
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=83&t=001935.

And it is true. Since Spring creates a single object used by all incoming servlet threads all the application down to database access is on the access-path of those threads and must be thread-safe.

There is a positive side though. Thread-safety problems only apply to "mutable state access" of the object. Meaning that if you service to dao classes just forward method calls and use variables local to methods these will be saved on the execution stack and not made visible to separate threads. As long as you don't have properties in these objects you're safe. This is however of small consolation because the projects i usually work are rarely that simple.

Bottom line: I got to finish reading those 2 books!

How OpenSessionInViewFilter can mess with your head :)

2008-11-04T09:52:00.004+02:00

I recently started having some troubles in a Spring - Hibernate web application. I kept receiving

org.springframework.orm.jpa.JpaSystemException: org.hibernate.HibernateException: Illegal attempt to associate a collection with two open sessions;

.

At first I thought that it's because I'm not using transactions and the Spring wrapper for Hibernate Session (HibernateTemplate) is not reusing the session so I was doing something like:

My Controller -> My Dao -> HibernateTemplate -> Get New Hibernate Session -> Get A Object With An Associated Map;
My Controller -> Change something in the associated map of the object
My Controller -> My Dao -> HibernateTemplate -> Get New Hibernate Session -> Update the object

This would certainly explain the error since i was getting a collection from one session and saving it with other, thing not possible with Hibernate.

So I tried the normal fix, to release the lock on the collection from the first session and reattach it to the second session. Big was my surprise when that didn't work as expected. I kept getting ugly new exceptions.

I directed my attention on my other possible cause. Having two session opened at once (though not a direct cause, this might occasionally lead to Illegal attempt to associate a collection with two open sessions. The other session I had opened was the one Spring was opening for me through OpenSessionInViewFilter. Once I removed the filter, surprise surprise, everything works OK.

Now, removing OpenSessionInViewFilter is not by far an ideal solution. I would hate to eager fetch all lazy associated objects for view.

The solution that would solve the problem and keep the OpenSessionInViewFilter would be to force the filter to reuse the old session (the singleSession parameter) but that is know to cause other ugly problems. I will have to look into this and check for a better solution.

The - java.lang.NoSuchMethodError: ConfigurableWebApplicationContext.setConfigLocation - hell !!!

2008-10-29T20:37:00.008+02:00

I recently had a lot of trouble with a Spring-Maven project. I kept getting this error when starting the web server.

java.lang.NoSuchMethodError: org.springframework.web.context.ConfigurableWebApplicationContext.setConfigLocation (Ljava/lang/String;)

Apparently the problem was that one of my dependencies (in my case net.sf.gwt-widget.gwt-sl) was introducing org.springframework.spring:2.5.1 as a dependency, and having this and org.springframework.spring-webmvc together breaks something.

I resolved the problem by excluding the org.springframework.spring dependency as I didn't needed it anyway.

Thanks to ram-2008 for posting the solution on this thread: http://forum.springframework.org/showthread.php?p=198644

Where in the world is the @Controller Spring annotation?!?!

2008-10-29T20:15:00.004+02:00

I recently found myself in the situation of banging my head on the wall when in a Maven - Spring project, in which I used org.springframework.spring-webmvc (version 2.5.5), the @Controller annotation could not been resolved.

After some digging in the spring pom files i found that the annotation is not actually defined in the spring-web or spring-webmvc packages, but in the spring-context package. Weirdly enough spring-context is a dependency in spring-webmvc but for some reason is not propagating to my project.

Even more strange, the dependency is resolved if I include the maven org.springframework.spring artifact where are bundled a bunch of spring dependencies but no spring code.

The quick fix I used is to include org.spring-framework.spring-context in my dependencies list and everything works OK, but the matter worth more digging as it may lead at the discovery of bug either in the spring pom files or even in maven.

Java's Map.containsKey()

2008-09-30T14:12:00.006+03:00

Had a little problem recently with some complex keys in a map. The keys of my map were of this class:


class Point{
  private int x,y;
  //...getters and setters
  @Override
  public String toString(){
    return "("+x+","+y+")";
  }
}

The problem was that if i had a map containing an element with the key (1,1) and I would try to check if that key is in the map like this: myMap.containsKey( new Point(1,1) ) this would not work. I tried to add the equals method:


class Point{
  private int x,y;
  //...getters and setters
  @Override
  public boolean equals(Object obj){
    if(this == obj) return true; //exact same pointers
    //check if same type
    Point p = (Point)obj;
    return (this.x==p.getX()&&this.y==p.getY());
  }
  //...toString() (see above)
}

I thought this would surely solve the problem but it didn't. It seems that my equals method is not used at all. After some thoughts I realize that using equals would not be really efficient so they must be using something else. And of course, the most efficient mode of comparison is to use hashCode().


class Point{
  private int x,y;
  //...getters and setters
  //...equals() (see aboveve)
  //...toString() (see above)
  @Override
  public int hashCode(){
    return x<<16|y;
}
}

This is it! It now works and i can use myMap.containsKey( new Point(1,1) ).

My friend Bogdan Coanda suggested me x<<16|y as being the fastest way to obtain an unique hash for the x,y combination. It's roughly equivalent with x*(2**16)+y but faster as it doesn't care about carry on bits. This would give me unique values as long as my x and y stay below 16 bits numbers. This is a slight inconvenient but it does not affect me as my x and y are surely to stay below 16 bits.

Generics and Hibernate polymorphism

2008-09-23T23:50:00.009+03:00

I recently found myself in the position to have to map, using Hibernate , a class family that had several common properties and a totally different one (among subclases) . The whole challange in that, was that i still had to keep a reference to that property in the abstract ancestor class (could have been an interface).

To make sence, here is the class model:

public abstract class Ancestor{

  //...id property+getter and setter
  private int commonProperty1;
  //... public getters and setters for common property

  public abstract Object getDifferentProperty();
  public abstract void setDifferentProperty( Object prop );
}

public class Child1 extends Ancestor{
  private Integer differentProperty;
  public Object getDifferentProperty(){
    return this.differentProperty;
  }
  public void setDifferentProperty( Object prop ){
    this.differentProperty = (Integer) prop;
  }
}

public class Child2 extends Ancestor{
  private String differentProperty;
  public Object getDifferentProperty(){
    return this.differentProperty;
  }
  public void setDifferentProperty( Object prop ){
    this.differentProperty = (String) prop;
  }
}

Now, how you might have noticed, this is not such a good solution as the type cast in the setter is unsafe and the getter is useless unless you know to what to cast it. You could use reflection to make the cast safe or to check what's comming out of the getter, but still, there's a better solution. Let me show you.

First, let's make the abstract ancestor take a generic as parameter.

public abstract class Ancestor<MyType>{

  //...id property+getter and setter
  private int commonProperty1;
  //... public getters and setters for common property

  public abstract MyType getDifferentProperty();
  public abstract void setDifferentProperty(MyType prop );
}

Now, lets put that to use and use that in the children.

public class Child1 extends Ancestor<Integer>{

  private Integer differentProperty;
  public Integer getDifferentProperty(){
    return this.differentProperty;
  }
  public void setDifferentProperty( Integer prop ){
    this.differentProperty =  prop;
  }
}

public class Child2 extends Ancestor<String>{
  private String differentProperty;
  public String getDifferentProperty(){
    return this.differentProperty;
  }
  public void setDifferentProperty( String prop ){
    this.differentProperty = prop;
  }
}

As you can see, now the child classes have setters and getters for the different property that ensure type safety and can still be used with calls that hit the ancestor class.

Now, the trully beautifull thing for me was that this maps in Hibernate in no time:

<class name="Ancestor" table="ANCESTOR" abstract="true">

  <id name="id" type="string">
    <generator class="uuid.hex" />
  </id>

  <discriminator column="type" type="string"  />

  <property name="commonProperty1" column="comon_prop_1" type="interger" />

  <property name="commonProperty2" column="comon_prop_2" type="timestamp" />

  <subclass name="Child1" discriminator-value="C1">
    <join table="CHILD_1">
      <key column="id">
      <property name="differentProperty" type="integer" />
    </join>
  </subclass>

  <subclass name="Child2" discriminator-value="C2">
    <join table="CHILD_2">
      <key column="id">
      <property name="differentProperty" type="string" />
    </join>
  </subclass>

</class>

Voila! Everithing will work as expected.

Spring, CommonsLogging and Log4J

2008-09-17T16:24:00.008+03:00

Had some time lately to play with more than the usual default settings for log4j and found that Spring uses and supports Commons Logging to put a thin layer between the logging mechanism implementation and the logging call.

For those that don't know about Commons Loggins, this provides a Log interface wich you use to log data, instead of calling the concrete implementation of Log4J for example. This way you can change from Log4J to any other supported loggin mechanism at any time. If in your project logging is important, you'll see the advantage of this.

Anyway, what's more nice, is the way you can instantiate and inject the same logger in you beans. To instantiate the logger you create the bean org.springframework.beans.factory.config.CommonsLogFactoryBean in your application context like this:

<bean id="mylog"
class="org.springframework.beans.factory.config.CommonsLogFactoryBean">
    <property name="logName" value="mylog">
</bean>

CommonsLogFactoryBean is a factory bean, wich means that when you reference it in another bean it won't return an object of type org.springframework.beans.factory.config.CommonsLogFactoryBean , but an object created by the factory (wich is preaty cool). Note that the factory will know by itself what type of logger you want to use based on the configurations you make. So when we place this config for log4j in web.xml it will khow that it must return a log4j logger.

<context-param>  <param-name>log4jConfigLocation</param-name>  <param-value>classpath:/config/log4j.xml</param-value></context-param><listener>  <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class></listener>

One remark here that will save you some frustration: you have to place the log4j listener before the Spring ContextLoaderListener or it won't configure right.

Ok, now we can inject mylog in any bean you want and start using it (remember, it's of type Log).

In the last part of the blog I want to share with you some links about the configuration of log4j with an xml file. For a long time a properties file was used, but the xml is much more cool, an easier to understand. Actually, there are some stuff you can only configure with an xml.

log4j xml format: http://wiki.apache.org/logging-log4j/Log4jXmlFormat
an example with the usage of some appenders: http://www.javaworld.com/javaforums/showflat.php?Cat=2&Board=TheoryPractice&Number=2396&page=0&view=collapsed&sb=11&o=&fpart=1

The choice (II)

2008-07-15T10:16:00.011+03:00

I've finally made my decision about what to use for the presentation layer. Spring MVC. The reason behind my choice are the great level of configurability, the good quality of the documentation and samples, the vibrant community around it, the easiness of integration with Spring, Spring Web Flow, Spring Web Services and Spring Security one of my favorite project.

The reason I previously discarded Spring MVC is because it seemed to require too much configuration for simple things. However, meanwhile I looked at the newly introduced convention over configuration chapter in the Spring MVC documentation which describes how by sticking to established conventions and having reasonable defaults you can substantially cut down on the amount of configuration that is required to set up handler mappings, view resolvers, ModelAndView instances, etc.

Here's my setup of the project with wich I'm very happy. Makes things almost as easy as working with the defaults in a scripting language framework as Cake PHP.

First step is to start a normal project setup and write your deployment file (web.xml) and your applicationContext files. I won't get into details as this is either common to any project or to specific for your needs. I'll just mention that you have to setup the Spring dispatcher servlet. This is where the http request will first get to, and will be forwarded to a controller capable of resolving it. I do this by placing these lines in /WEB-INF/web.xml

<servlet>
  <servlet-name>default</servlet-name>
  <servlet-class>
    org.springframework.web.servlet.DispatcherServlet
  </servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>default</servlet-name>
  <url-pattern>/*</url-pattern>
</servlet-mapping>

This instantiates a dispatcher that listens to all requested urls and tries to find a controller for them. If you want to have different dispatchers for different type of urls you can adjust the url-pattern. But again, this is about convention, and you will almost always need a single dispatcher.

The next step is to set up a handler mapping in /WEB-INF/default-servlet.xml (or a matching application context in case you didn't named your dispatcher servlet default). This is actually the component that tries to find for the dispatcher a controller suitable for a certain url. There are many types of handlers, including ones that expect a manual mapping of the url to the controller, or you can write your own handler, but the one i use is:

<bean class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping"/>
This will instantiate one of the simplest handlers. This will take the url, strip the prefix and the suffix and will search for a bean controller that matches that name. For example, if the requested url is: www.mydomain.com/users/all, this will search for a bean called: usersController. Preaty simple, right? You can now provide the controller:

<bean name="usersController" class="com.mydomain.web.controllers.UsersController" />
This handler will suffice for most situations. You can read more about it from the spring documentation.

Ok, so we reached the point where we actually have to handle the http request. A controller's job is to do exactly that. Now, there are several types of controllers each particularly good in a situation, but the one I think is the most useful is the MultiActionController. I find it that usefull because it can bundle the code for several requests in a single class. That's particullary useful when you have tasks concerning the same problem. For example you can treat the urls mydomain.com/users/add, mydomain.com/users/delete, mydomain.com/users/show etc. in the same controller.

public class UsersController extends MultiActionController {

  private UserDao userdao;

  public ModelAndView all(HttpServletRequest request, HttpServletResponse response) throws Exception {

    List<user> usrs = userdao.getAllUsers();

    ModelAndView mv = new ModelAndView();
    mv.addObject("users",usrs);
    return mv;
  }

  public void setUserDao( UserDao userdao ){
    this.userdao = userdao;
  }
}

Now that we have the multiaction controller we must have a method of deciding which method will be called and when. This is the job of a Method Name Resolver. To keep things simple we will use the org.springframework.web.servlet.mvc.multiaction.InternalPathMethodNameResolver.
This takes the url immediately after the controller name part and tries to match it to a method in that controller. Basically the, previously used www.mydomain.com/users/all url will be matched to the all method in the usersController bean. The method name resolver would have to be specified as the methodNameResolver property of the multiaction controller, but fortunately if we don't specify any, Spring will provide exactly this one for us.

One last note: in order for a method of a multiaction controller to be considered, it must have at lease 2 parameters: HttpServletRequest request, HttpServletResponse response. You can read more about what parameters the methods can take on the spring documentation.

Ok, we're done with the controller. Let's go to the view. As you maybe have noticed i haven't provided any view name when i instantiated the ModelAndView. This might look at least weird. The fact is that I use another configuration trick. I use a bean instantiated by Spring which finds a name for the unprovided view names based on the url. The bean is: org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator and as I said, it's instantiaded by Spring so you don't have to do anything about it. The name it provides is by stripping the prefix and the sufix of the url. So in our case, from the www.mydomain.com/users/all url we would get the users/all name.

We're almost there. One thing left to do: the view resolver. I used Velocity for my sample but you can use whatever view technology you want. Here is my setup:

<bean id="velocityConfig" class="org.springframework.web.servlet.view.velocity.VelocityConfigurer">
  <property name="configLocation"><value>/WEB-INF/velocity.properties</value></property>        
</bean>
<bean id="velocityViewResolver" class="org.springframework.web.servlet.view.velocity.VelocityViewResolver">
  <property name="viewClass" value="org.springframework.web.servlet.view.velocity.VelocityView"/>
  <property name="prefix" value="/WEB-INF/views/"/>
  <property name="suffix" value=".vm"/>
</bean>

So, now that we're done, let's see what have we accomplished. We have a basic Spring MVC setup which by using different convention tricks provides a straight forward way of writing your web layer, without requiring you to write a ton of xml for each controller. A url in the form: www.mydomain.com/users/all will be sent to a bean with the name usersController, to it's all method. This in turn will perform any required processing and send the model to the /WEB-INF/view/users/all.vm velocity template for rendering. For any new controller we will only have to vrite the xml than instantiates it. It's a great way to speed up your developing process by cutting down significantly the required configuration xml, and providing an intuitive url handling chain.

Do you want to uninstall your OS?

2008-06-20T20:08:00.006+03:00

I recently installed the new Ubuntu 8.04 LTS to check out what's new in the Linux world. I had a few months try a while ago with the Ubunutu 7, but eventually rolled back to XP because I was missing Photoshop to damn much (that thing is addictive) and editing 10000 x 10000 pixels pictures in virtual machine is a killer.

What i first noticed was the "Install inside Windows" and checked it thinking that that's just a fancy way to say "dual operating systems". Everything went well and as I dived in the new Ubuntu I was nicely impressed by the progress done in bug fixing, look improvements and easyness of use. Now, I think, they really have a competitive alternative to windows. You can configure almost everything in a Windows fashion and the Synaptic installer is the chery on the cake (as always). Plus, wine now supports Photoshop CS2 really well and even iTunes.

But enough about that, I'll decide if to give linux another go later. I was telling about the "install inside windows" option. The big surprise was when i restarted back to xp and noticed that i have all my drives intact. The only difference was that my D: drive was occupied with the ammount i indicated to Ubuntu to use. The bigger surprise, was when i navigated through the new ubuntu folder and found the magic "Uninstall-Ubuntu.exe". Preaty cool huh? I think it's a brilliant move, allowing people to check out Ubuntu much more easy, without having the worry of that headake uninstall process (with the repartitioning and removing of grub, etc). And as I said, the new features, or perhaps improvements, are to be checked out.

Go go Linux group, go! (even thow i almost alwasy used windows beacuse of different software requirements, i always found something phrenetic about using linux).

The choice (I)

2008-06-06T00:00:00.001+03:00

As I'm at the begining of a fresh new web project I get to choose what frameworks I'm going to try next from this huge set of options in the Java Universe. As much as this promises to be a mess, I keep telling myself this is actually a great opportunity to move forward, discover new, better ways to do things.

Some things i have clear:

I'll use Spring as my IoC container. It seems by far the most appreciated of it's kind. The thing I like the most is that it stays out of the way. You get to decide how much of it will you use.
Hibernate will be my ORM tool. It's complex and shiny and scarily big, but the size of my project says I do need an ORM so why not get what offers me most functionality. I'll worry about optimization later.

However, when it get to the presentation layer it gets crazy. Until now I've read dozens of "x vs y" articles, tens of "what my framework can do" screencasts and still haven't decided. Have you seen the choice range? Let me spill a few for you:

Echo	Cocoon	Millstone	OXF
Struts	SOFIA	Tapestry	WebWork
RIFE	Spring MVC	Canyamo	Maverick
JPublish	JATO	Folium	Jucas
Verge	Niggle	Bishop	Barracuda
Action Framework	Shocks	TeaServlet	wingS
Expresso	Bento	jStatemachine	jZonic
OpenEmcee	Turbine	Scope	Warfare
JWAA	Jaffa	Jacquard	Macaw
Smile	MyFaces	Chiba	JBanana
Jeenius	JWarp	Genie	Melati
Dovetail	Cameleon	JFormular	Xoplon
Japple	Helma	Dinamica	WebOnSwing
Nacho	Cassandra	Baritus	Stripes
Click	GWT

Easy right? The simple truth is that there are to many damn choices and from all these there is no "best framework". Certainly some of them more complex, more documented, scale better, have a smaller learning curve, but in the end it's all about taste. You heard me: taste. The discussion around this article of Tim O'Brien made me realize that. Some prefer to do things in one way some in others. And for them, doing stuff just as their brain patterns out the problem makes it the best possible choice.

But what I'm looking for? Well, coming from a long experience with PHP and CakePHP, what I noticed first is the difficulty to configure for most of them. All the great features and power come with a heavy price. In order to display a page you have to write a ton of xml or other stuff that in most cases is plain redundant. Or if not, you have to invest much more time in finding secret ways to avoid that. I would surely want to see more Convention over Configuration in Java world. For now it seems like most of the frameworks were made for control freaks.

Let's list the candidates i have so far:

Struts 2 - this is a more elegant, complete, rewrite of the old Struts framework which even with serious flaws was once the most used framework of its kind. I would choose this because I could benefit from my past knowledge with the old Struts. Plus, being under the Apache umbrella is always a good sign.
SpringMVC - this would get me nice integration with Spring, SpringWeb and SpringSecurity. It's extremely configurable, but it requires tons of xml for things that should be direct.
Click - this seems one of the lightest, but I'm thinking it's maybe too light. It contains only a few packages.
Tapestry - looks kind of nice and less heavy but everybody is complaining that it has a huge learning curve.
Stripes - heard a great deal about this but it might be just programmers bloating. However i got to investigate it further. If what they say in the slogan is at least 50% true it might be what I'm looking for: Stripes aims to provide an experience similar to owning Apple hardware, Sony TVs and luxury German cars (without the price premium); things just work, they feel right and every now and again you get that "oh, it does that too? awesome!" feeling.