Bruno Fernandez-Ruiz

Once every year I like to spend some time revisiting a personal itch of mine: is Java ready for web prime-time? Sadly, although Java has clearly proven its place in the server-side, it has failed in the frontend, last bit of the server-side, the thin layer that transforms business data into rendered HTML. This is what Rasmus Lerdorf calls the “glue” (PHP is the glue), basically a thin layer of presentational representation that links your server pre-assembled data.

Of course you could build web applications using either JSPs or one of the hundreds of web application frameworks available for Java. And a lot of leading players are doing just this. But contrary to some “enterprise” thinking, Java is by no stretch of imagination the leading language for web development.

The number of available web frameworks for Java is an indication of a ground where a problem exists that has not been addressed in any fully satisfactory way, yet. And I believe the key problem is productivity: Java is, still, not a productive platform for development, whereas it is probably the best available platform for production. And the thing is that although there is a very large, mature and globally distributed pool of Java server-side developers, Java is still hard to develop for because it is not a productive platform for this “glue”.

A clue as of why it is not productive comes from analyzing the prime language users: the frontened web developers. It is actually really hard to find frontend web developers that want to use JSPs or any Java web framework. They rather use PHP, or Python, or Ruby, or Perl.

What all the P- scripting languages share in common is the low specs required to get started, the easiness itself to get started and hack something together, and most importantly that it only takes a single browser refresh to check any change and push the change to a production server. Sure, this is not a good practice (pushing to production), but it’s something that for 99% of sites out there, it just works and it’s good enough.

Java makes deployment hard. Starting a JVM takes seconds, refreshing a JSP takes seconds, changing classpaths, etc. require a restart or reload. Hardly productive. And the thing is, even though Java is more robust, better structured, and enforces better development practices, 99% of the sites out there just don’t need this level of “enterprise” features. And I am not the only one saying so. Even Billy Newport, one of the lead architects behind WebSphere Application Server, and the Chief Architect behind WebSphere XD, has expressed this very same thought, that Java needs to figure out how to become as productive as PHP.

The productivity derived from the scripting language in those 99% of web sites out there is what makes Java unpopular for the remaining 1%. Java has to grow up in the web dev area. Ideally, one would like to take the best of both worlds: the robustness and performance of a JVM, and the productivity of the P-languages.

In my yearly review of the state-of-the-art, I am starting to think that this change to make Java more productive is finally starting to happen in 2008. First was the advent last year of the scripting languages becoming a target of the JVM, such as Jython, JRuby, PHP, Groovy, Scala, etc. made it possible to benefit from the JVM robustness. But still one had to suffer the JVM weight inflicted by Java (the language) centric development practices.

It’s really only been over the last 6 months when we have seen a number of open source and closed-source projects taking on the task of bridging the scripting and JVM world together for web development. A couple of the web frameworks that I am interested in researching more about and that look rather promising to me are Project Zero, and liftweb.

In summary, I really think we may be looking at 2008 as the year when Java finally graduated in the web dev frontend area. I certainly hope so. But only time will really tell.

Disclaimer: this is not, by any stretch of imagination, Yahoo!’s official view. Don’t try to read too much into this posting. For those that know me well enough, you’ll know that I have been looking into application frameworks, web and others, since 2000.

Surely performance is not the prime criteria for selecting a framework. Most people will say developer productivity, ease of maintenance, security and scalability are the most important factors.

I love the Ruby language and its expresiveness. And Rails has been a truly inspiring web framework. This is why I think the web frameworks performance test results run by Alrond (and an update here) are highly disappointing for Rails. In Alrond’s tests we find that Django giving up to 4x faster response times, and 2x more throughput. But I guess this is not a surprise, we always knew Python was faster than Ruby by just looking at Debian’s language shootout.

I would add a couple of remarks to Alrond’s results:

• Most shared web environments only offer PHP. Some hosting providers offer an old version of Python that will not support Django. So when using shared hosting, PHP is likely to be your only choice. PHP is a useful and proven language if you need to integrate with C/Java/whatever, but perhaps not as expressive nor OO as Ruby and Python. On the performance results side of things, CodeIgniter/PHP tests using a bytecode cache (APC) improve performance by 10x, and make them comparable to Django/Python. Plus CI runs on PHP4, which is what most web hosts out there are running today.
• If you want/have to avoid PHP, you are probably looking at Rails and Django as your main options. These will require you to use a Virtual Private Host or a dedicated server. Rails and Django don’t work well on shared hosting. And if you are like me, on a tight hosting budget, you really want to get that extra performance and be on a framework where it’s really cheaper to scale out. This is where Django/Python will shine.

At the end of the day, choosing between one of these web frameworks is actually a language choice. And right now, the only real language contestants for people looking for raw speed and stability are PHP (with opcode cache) and Python. And both seem to deliver comparable performance.

But I would not rule out Ruby completely just yet. JRuby is making a lot progress, and you can even now run Rails with JRuby in Sun’s JEE container (glassfish). On the other hand, another interesting similar development which might rock Python is IronPython, which runs Python on the .NET runtime.

While developing our trading application, I have come across two key things Rails does not have:

* Transactions. Rails does not offer distributed transaction management. This does not bother me much, since I am not a fan of having transactions span across multiple datasources. However, Rails does not offer cross entity transaction management on a single datasource for unrelated entities. The Rails model works well for ensuring autocommits on parent-child relationships, but anything beyond that requires extensive work and bookeeping in your controllers. For most jobs, the Rails model is enough, and does the job. It actually does the job pretty well. But there are jobs, such as updating multiple trading and position tables where Rails is not the right tool.

* Security. Rails is absolutely agnostic of security. Authentication, authorisation and Access-Control Lists are foreign to the framework, by design. The whole plumbing required may become daunting, and while there are engines and plugins out there doing part of the job, I truly hate taking ownership for the security bits within my application.

Localisation and internationalisation is yet another third a bit weak in Rails, but I am yet to have true requirements in this area to be able to give an opinion.

Anyway, Django looks like a promising alternative. It offers both more comprehensive transaction management support and a complete security model, with the whole plumbing being in the framework itself. Whether it will fit the shoe, we’ll see as soon as I write the order island book.

I have tried for the last couple of days to overcome some of the transaction management problems I was having with Rails, and the more I look at it, the more I am convinced Rails is not right for my trading application. Rails has its sweet spot, and for me, there won’t be anymore PHP.

I came back to my usual Java stack, with the usual suspects, Tapestry, Spring and Hibernate. But, after the Rails experience, it was just … yuck! The development environment is complex to setup, there are library dependencies, tons and tons of XML sit-ups! Enough!

I would like to use annotations, and it seems like Hibernate and Tapestry all have it in already, so no more need for XML files, and complex build and packaging using XDoclet. But development environment support for this flavour is very flaky. So much, that I got frustrated.

And this made me re-evaluate an old friend: EJBs. The EJB3 in JavaEE 5 leverage the annotations to make it expressive and put the focus on the model.

I have no more need for Spring, which I was only using for transaction management. I am happy with stateless EJBs.

I have no more need for accessing Hibernate directly. I rather using Entity Beans, and have the implementation be Hibernate3 (wow, I am sooo surprised to read this … given how such of an anti-entity beans advocate I have been!!).

And as for Tapestry - well, sorry. It’s just too much, even with Hivemind. Unit and integration testing is still hard with Tapestry, and there are far too many conventions around.

Which only left me JSF and Wicket on the web component development frameworks front. And given that I don’t like the JSP baggage in JSP, I’ll go for Wicket, which shares a lot of the Tapestry principles.

So, my new stack is Wicket 1.2 and EJB3. Let’s see how it goes.

Transactions in Rails are starting to bother me, and quite a lot. Once in a while I dive into my latest application,booki.es, a web application for trading long-term futures using play money.

Rails was fantastic for building my wife’s eCommerce site: fairly static content and not many associations between entities. Rails transactional block was sufficient, something of the sorts of:

Account.transaction do
account1.deposit(100)
account2.withdraw(100)
end

or

Account.transaction(peter, paul) do
paul.deposit(350)
peter.withdraw(350)
end

Even ActiveRecord takes care of the transaction integrity for parent-child relationships, so when you save the parent, all child rows get also saved.

Now when a trade is exectued in my trading application, an update and a few reads happen on quite a few tables, including trades, positions, accounts, and historics, but some of these entities don’t have any relationships between them. I need to ensure data integrity and atomicity, and Rails does not seem to have anything like the Java Transaction API (JTA).

I would love a simple transaction API like JTA being exposed for databases, like there is Transaction::Simple, but for databases. Ideally, I would like to have nested transactional support, even if it is a flatten model like in JTS.

But I don’t have it, so I am having to modify my controllers and models to overcome the limitation. And to be honest this sucks. Maybe I should go back to my Tapestry/Spring/Hibernate combo for this one app. The right tool for the right job …

I have spent some time over Christmas period playing here and there with Ruby on Rails and getting an overdose of AJAX. I really wanted to see whether all the hype and marketing from 37things.com and associates makes any sense.

I have two objectives in mind:

1. Should I throw away J2EE for Rails?
2. Should I throw away PHP for Rails?

My impression of Rails has been extremely good so far. However, I am really more pleased with Ruby than I am with Rails itself. Rails is interesting, don’t get me wrong, but far from being revolutionary. All concepts and patterns in Rails have existed for a while in the Java and J2EE world for a while now. If so, why is Rails so cool and sexy? I’ll give you a few reasons I found for myself:

• Ruby is a very expressive language for those like us coming from strongly typed language background.
• Rails makes agile development easy. It is extremely easy to come up with a concept in the morning, and have a prototype in the afternoon to show to your client. This is because development and execution architectures are tightly coupled.
• Rails principle of convention over configuration works great for 99% of the cases. No need to know how to define or configure something - it just works as long as you follow the principles.
• Rails provides a really easy-to-use and lightweight structured MVC architecture for those PHP addicts hacking web site after web site.

Would I throw J2EE away now that I encountered Rails? No. J2EE is a distributed component on steroids - so if you don’t need distributed components, you don’t need J2EE. But if you rely on JMS, JCA, JTA and distributed components, then Rails is not your medicine. Rails is a pure web application framework, with some quick O/R mapping facilities to ease the pain of DB access — it’s great for those web applications only backed by one database custom developed for the particular application. Rails is more of a pain relief for PHP folks than for Java programmers.

If you have been doing pure web frontends in Java using JSP and JDBC, well, sorry, I think you should go back and examine Python (Django), Ruby (Rails) and PHP (Yellow Duck, BlueShoes) and stop wasting your time.

Then there is Trails, a Java replica of Rails, using the “best-of-breed” Tapestry-Spring-Hibernate (yeah, fits my resume). However, I feel there is no much meaning in Trails nor TRAX. If I have complex problems (integration, distribution, transaction management, and messaging), I’ll use Spring or directly the J2EE APIs, and will not rely on a generation framework and convention. I will want configuration, and full control.

Finally, there is also PHP On TRAX, a Rails version for PHP. It might have a niche market, for those loyal to PHP. But given Ruby is sooo expressive, why would anybody program in PHP?

Bottom line, Rails and J2EE cover different needs and developer populations. There will surely always be an overlap - and over time they will both mutate to copy features from each other. But it is more likely that we see Ruby 2.0 running on the JVM, than iBatis or Hibernate on Rails!