Merry Christmas, World!

Using the unofficial Google translator API, here's a Merry Christmas greeting to everyone around the world! (or at least whose language are supported by the translator) :)

import java.lang.reflect.Field;

import com.google.api.translate.Language;
import com.google.api.translate.Translate;

public class MerryXmasWorld
{
public static void main( String[] args )
{
Field[] fields = Language.class.getFields();

for ( Field field : fields )
{
String lang = null;

try
{
lang = (String) field.get( null );

if ( lang.equals( Language.ENGLISH ) )
{
continue;
}

String translatedGreeting = Translate.translate( "Merry Christmas, World!", Language.ENGLISH, lang );

System.out.println( translatedGreeting );
}
catch ( Exception e )
{
System.err.println( "Cannot translate to " + lang );
}

}
}
}

The waterfall trap for “agile” projects

Gojko Adzic's summary of Thoughtworks' Jeff Patton at XpDay last month in London:

http://gojko.net/2007/12/04/waterfall-trap/

"The problem was that the concept of iterating had been lost and iterations were replaced by increments - making the project fall into the same trap as waterfall projects do."

Makes sense. But doing increments has it's merits as well. Will ponder on this on the next posts.

Exploring JEE

I love the Spring Framework, and really have no strong case to move out of it. But of course, that doesn't hamper us from exploring what's beyond this space.

Spring was created to address the complexity of doing J2EE. It presented an easier more lightweight alternative. Spring gave power to the POJO, giving relief to container-bound, tightly-glued-together layers of the supposed standard. That was then of course..

Now comes Java EE5. Learning from the mistakes of the past (and success of competing technologies), this latest incarnation of the Enterprise version of Java features is aimed more at developer productivity. More modular and loosely-coupled. No more unnecessary three-object-cum-proxy-pattern-poster-boy persistence layer. An integrated yet pluggable web layer. Strategic use of annotations and component model. And a strong framework for web services. Here's a good overview/tutorial:

http://www.ibm.com/developerworks/java/library/j-jee5/

Most Spring-based applications are deployed on web containers only. Some may argue that the demarcation between a web container and a full JEE-server is starting to get blurry. Because of the modular nature of Spring-based apps, some services such as persistence and transaction becomes pluggable objects that the web container need not know about. Of course, the biggest turn-off again for using full blown J2EE is the very complicated persistence standard it uses. Things are different now of course. Your familiar Struts/Spring-MVC/Tapestry+Hibernate/JDO+Axis/Xfire could be translated to JEE. Would probably look like this: JSF+EJB3+JAX-WS, and still could be pluggable, implementation-wise, though not as flexible as the former.

Now the question is, would the now modularized and more configurable JEE stack be better suited for a more integrated experience compared to web container + addons?

Also, JEE can still make use of a framework on top of it that would make things more productive to the developers. Enter JBoss Seam:

http://www.jboss.com/products/seam

At first glance, looks very promising, and makes use of technologies that are very familiar. I just don't know though how tightly-knitted this framework is with JBoss AS as opposed to being used on other JEE application servers.

Again, I really don't know how much business value there is in migrating to a full JEE implementation. Still pretty comfortable, to reiterate, with our current stack. But again, this is just an exploration as to give us more options and a better understanding of technologies emerging beyond our backyard so to speak.