Adam Bien's Weblog

I like the whole Rails vs. Java EE or Ruby vs. Java discussion. Most of the content out there is really funny. Posts like "I switched from Java to Ruby and now all my problems are solved", or "Yesterday evening I tried the Ruby thing....and it sucks". I'm working with Java since the JDK 1.0 days and I looking at Ruby/Rails for several months, Ruby years now. The Ruby language and the Rails framework are very interesting and excellent. Ruby is really object oriented, everything is an object and extensible - which is great. Rails is a framework which was built to support the realization of web application / products, and in this area it is excellent and exceeds the productivity of the Java frameworks. I also like the philosophy of the 37signals company ("do more with less"), which prefers high quality software (perfection), instead of growing (If I hear "growing" I remember immediately the crazy new economy days with many bubbles :-)).

But Ruby and Java follow complete other philosophies, so they cannot be compared. The context of, at least my,  projects differs from the rails vision. Because Rails was build for application and product environment, it is very efficient for "green field" projects. In this case you can fully use the power of "convention over configuration". Project template can be generated from a "beautiful" database. In my projects the database often already existed and was really not beautiful :-). So we have enough to do to beautify the database with basic OR-layer. The "convention over configuration" advantage was gone in this case.
We had often also to deliver Swing and WebClients in parallel. In this case we needed a service contract (as strongly typed java interface), otherwise the different teams couldn't rely on a common business logic (which leads to redundant code). I have to admit, that in the last 11 years, I had only few "green field" projects...

Beside this fact, the main work occured in the integration area. We have often to struggle with things like adapters to legacy systems, queuing, synchronization of different datastores, distributed transactions etc. Because of the broad industry support - Java is really great in the area - but I had enough to do. In the integration layer you have no advantage of "convention over configuration" things - you have to "hack" you code to access the legacy box, after this we realized a lean adapter layer to beautify the uggly, and procedural interfaces.

So in SOA/EAI space I would prefer strongly typed interfaces - it minimizes the risks and runtime errors. In case something changes - the compiler recognizes it. On the other hand it is a good idea to use scripting or dynamic languages as a glue to wire the strongly typed interfaces together. In real world you will need both: the dynamic and strong typing in one project. So using Java and Groovy could be really interesting.

Funny enough: the ECMA-Script/JavaScript guys are thinking about optional static typing (which is similar to Java :-))

However, both technologies will die because of CIT :-)

Posted at 12:48PM Aug 27, 2006 by Adam Bien in Enterprise Architekturen, Leitfaden für Effiziente Softwareentwicklung  |  Kommentare[4]

[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices