Tomcat vs. Geronimo

I talked in an earlier post about Java "word salad" and I still stand by it. It's only after playing with the various products that I finally understand the differences between Tomcat, Geronimo and Glassfish for example.

In plain English, Tomcat is a web and application server that implements a java servlet container.

Geronimo and Glassfish are the implementation of the Java EE platform by Apache and Sun respectively. Like Tomcat, Java EE servers need to provide the servlet feature. This can be accomplished by including Tomcat proper and this is indeed what Geronimo does for example. However, a Java EE server also needs to implement tons of other stuff too: transactions, EJB, JDBC, message queues, persistence, clustering, management beans and an internal SQL database to name a few.

Each set of features provided implements interfaces specified in the various java community specification documents. This means you can swap various features for others, e.g., Glassfish implements the JMS API using Sun's Java System Message Queue product, a.k.a OpenMQ, but Geronimo uses ActiveMQ. You could for example put ActiveMQ in GlassFish to gain additional features found in that product. That being said, you could also install ActiveMQ or OpenMQ standalone on additional servers to either complement your Java EE application servers or just for use as a standalone message queue.

Not all components found in these open source Java EE platforms are distinct however. The internal database found in both products is Apache Derby for example.

The Java Ecosystem

I promised myself to look at the .Net 3.5 Beta by now but I've been overwhelmed by the number of technologies found in the Java ecosystem that I haven't yet found the time. It doesn't help that I only work 2 to 3 hours a day either.

But seriously, I feel like a newborn experiencing all these interesting technologies:

1. Google Web Toolkit. Write a Java application and compile it down to JavaScript to get an Ajax site. Really interesting and really fund to code. I can definitely think of a large application or two that I wrote on the desktop that would have been on the web had this been around circa 2002.
2. Project Phobos. So, if you're planning on writing the web front end in java, why not write the server in JavaScript? OK, haven't played with this one yet but interesting nonetheless and I certainly will find something to do with this if it works well.

The number of tool kits that Sun has made available under its open source initiative is staggering. Need federated single sign on? No problem, just use OpenSSO. It also supports OpenDS as an LDAP back end. If you consider that OpenSSO is extensible and can be made to support InfoCard. Even more attractive it becomes when you consider you can use it from any language thanks to its support of web services via SOAP and Rest.

Moving Blog

Apparently some of my Unix friends still hate Microsoft so this blog is moving over to blogspot. What I find funny is how these guys still hate Microsoft for abusing their market position... i.e., Microsoft the evil corporation.

Personally, I find the Microsoft of today to be significantly different than the one that launched Windows 95. The focus today is really on creating incredibly high quality software and innovation, e.g., UAC and the Office 2007 ribbons to name a few.

The other thing that I find funny is that http://codepimps.blogspot.com is actually taken. The codepimps.org domain will now point to http://codepimpsdotorg.blogspot.com/.

Fresh Pot of Java or The Java Platform, Ten Years Later

I haven't looked at Java in a long while, almost ten years. I remember walking away very unimpressed with the language and runtime back then. The promise of "write once, run everywhere" was laughable at most. The only thing I really liked was applets but ultimately dismissed them due to the need of distributing the JRE to clients. Not exactly sure when, but I also played around with JSP when it came out. Ultimately, I felt Java was slow, big, not portable, that the language was just too clean and lacked some very important features and that crafting libraries to compensate for those missing features was just too painful.

I also felt the supporters of the technology downplayed real issues (and still do?) when building applications in order to market the language. Correct use of threading and memory management to name a few are still no walk in the park no matter what the environment supports or not. I also worried about deployment issues related to applications and the runtime itself.

In any case, I started looking at Java again recently. Not sure why, maybe it's the idea of the virtual machine that I always liked, just plain boredom or maybe just a new outlook on life in general.

With the latest version of Java, i.e., 6, I can honestly say it's nice, real nice. I still don't know how portable it really is but I don't particularly care anymore. Let's face it, with most applications delivered over the Web now, the application/JVM would run on a server/OS that would be fully validated anyway.

Things I really like:

1. The huge class libraries
2. Support for generics. I can't tell you how I hated having containers full of "Object" classes and having to rely on runtime exceptions to determine correctness. This is the job of the compiler to tell me and it's about time it did so.
3. Tools. Eclipse and NetBeans to name a few. The NetBeans 6 Beta is really nice.
4. Application servers. Only tried Glassfish and Tomcat, neither really have everything I want but interestingly enough, if combined they would most likely be ideal.
5. Management of application servers. Haven't tried to do anything with them really yet scalability wise but I have written quite a few highly scalable servers in my day and configuration and management was always lacking. Why? Time simply, budgets had to be spent on other areas. The administrative application included with Glassfish is good and does its job really well.
6. Web deployments
7. Java DB, A.K.A. Apache Derby. If you're dealing with simple brochure website or something like that, it might be worthwhile to just use this DB and not bother with anything else if your developing in Java, it's included in the SDK after all.
8. Java.nio was something I solely missed previously. Let's face it, sometimes simple blocking I/O just won't do even with thread support. In my line of work, standard blocking I/O is too often the wrong answer.
9. Support for scripting. JRuby, JPython and Sun also has its own scripting language whose name escapes me right now.

Also, I found that speed and application interactivity is fine on modern hardware and that assertions are finally supported.

In all, I invested two full days on Java and its related technologies and came away impressed. Using Eclipse, I wrote a sample console application. Using NetBeans, I wrote a sample web application. The application was unimpressive but the web application I wrote was much more interesting.

This web application was a less (much less) ambitious version of the DinnerNow .Net sample application. Ajax support, Google maps, mobile backend, web marketplace driven by Apache Derby in network configuration of all things and a simple workflow using BPEL. I didn't bother with all features, i.e. command line client, management console and secure authentication didn't make the cut. However, I did enough to get a feel for Java and found it pleasant to work with which is a lot more than I can say about it ten years ago.

That being said, not everything is positive. I've been around this industry for a while. It's easy for me to pick up new toolkits and languages. I really feel the Java documentation is hard for newcomers to get into easily. The name of the different Java technologies and tools is one such barrier. A much more complete map of Java related technologies is needed and more importantly, it needs to offer guidance on how these technologies relate to one another.

Don't believe me? Have a look at the Apache Software Foundation site. Obviously, a priceless resource for any aspiring Java developer. Look at the software directory on the left side of the main page... You will see a list of very colorful names like Cayenne, Jakarta, Lucenne and Maven among others with no clear indication of what these really do for you or where to start. To learn about each project, you have to dwell into each of their individual websites and somehow track all the projects yourself, great. Needless to say, Apache is not Sun but the company does suffer from the same techno word salad in its own documentation of the Java platform.

It's still too early to tell if I will use using Java in a future project but I'm seriously considering it. I plan on delving into .Net shortly in the future since I haven't bothered looking since 1.1 beta something. This evaluation will obviously impact this one on Java.

Wii Game Boy Channel?

I've been experiencing with the Wii channel technology lately. I picked up a few games for the different platforms available and tried them. The ports are really good but I still do not quite understand why the Wii insists on stretching the output if you have a wide-screen television set. Needless to say, these retro titles do not support wide-screen.

The other big question that comes to mind is why is there no Game Boy channel? It seems that Nintendo is no longer actively promoting this platform and with good reason considering the massive success of the DS. It is true that the DS can play Game Boy Advance games and Nintendo may still be protecting revenue there. That being said, the DS is incapable of playing older titles for the original Game Boy(GB) and Game Boy Color(GBC) platforms since it doesn't contain the vintage hardware to run those games.

The GB and GBC platforms have a fantastic software library that I never got to play. Do I really want to pickup Zelda: Oracle of Seasons and a GBC from Ebay? No, no I don't, but I can really see myself purchasing that title virtually on the Wii however.

Now, what about linking? That annoying game technology that Nintendo tried to push on the market as an alternative to online play. The simple answer... just don't support it. The DS doesn't after all. Nintendo was able to use this linking technology to provide some unique gaming experiences but it ultimately failed since most gamers seemed isolated or missing all the required hardware and cables. So again, just don't bother supporting it.

Finally, I would argue that Nintendo is probably losing some real sales here. There seems to be an abundance of GB emulators and illegal software ROMs available on the Internet. A legalized option, at least, would most certainly deter some gamers from getting the setup on their computers.