\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020\u0020
\u0063\u006c\u0061\u0073\u0073\u0020\u0055\u0067\u006c\u0079
\u007b\u0070\u0075\u0062\u006c\u0069\u0063\u0020\u0020\u0020
\u0020\u0020\u0020\u0020\u0073\u0074\u0061\u0074\u0069\u0063
\u0076\u006f\u0069\u0064\u0020\u006d\u0061\u0069\u006e\u0028
\u0053\u0074\u0072\u0069\u006e\u0067\u005b\u005d\u0020\u0020
\u0020\u0020\u0020\u0020\u0061\u0072\u0067\u0073\u0029\u007b
\u0053\u0079\u0073\u0074\u0065\u006d\u002e\u006f\u0075\u0074
\u002e\u0070\u0072\u0069\u006e\u0074\u006c\u006e\u0028\u0020
\u0022\u0048\u0065\u006c\u006c\u006f\u0020\u0077\u0022\u002b
\u0022\u006f\u0072\u006c\u0064\u0022\u0029\u003b\u007d\u007d

Guess what is this?*

Java Puzzles is one of these great book you can read when travelling short distances. It keeps you fit in the language basics and is fun to read. I also like the fact that being an  IT book for once and doesn’t require a computer to work it through. This is from a newer edition of Java Puzzlers Joshua Bloch and Neal Gafters book on traps, pitfalls and corner cases in the Java programming language.

* A Java Hello world in Unicode, due to Java’s native Unicode support this is completely legal.

I started using Jersey back in 2007 when it was at version 0.4. Netbeans however already had a plugin to get you started on the fast track by generating REST Webservices out of Entity Classes, which you can also generate out of an existing db schema. At that time I was only starting learning JPA and was happy that the Netbeans Code Generators took care of most of my Entity Access Code. In retrospective I should have made the effort of learning everything JPA beforehand and not gradually as I worked along. Usually I actually would have done that, but the Code Generators tricked me into not doing it: It just seemed too simple to bother.

Here is what Netbeans generated to get an object by primary key:


Foo result = (Foo )service.createQuery("Select e from Foo e where e.id = :id").setParameter("id", id).getSingleResult();

Compared to:

Foo result = (Foo )service.find(Foo.class, id);


Problem with first approach besides being the obvious bloathed version: this will likely not be an easy cache hit wheras the second method, depending on your persistence provider will likely go a direct way to find the object within an identity map in the second level cache.

No big deal you might say just change the Query to a Finder method. Unfortunately its not just done with this because the getSingleResult also throws an unchecked NotFoundException when the Entity was not found, opposed to returning null in the finder method. In the generated code this exception was catched, wrapped and rethrown as a checked one. Nice so in some parts of my code was building logic upon those rethrown Exceptions when an entity was not found. So changing the way to retrieve an object had a long tail unfortunately.

Besides that the bigger problem is the design of an efficient and effective object domain model. I am speaking about fetch definitions, caching strategies, lazy / eager loading, and all that. At that time I was frankly just overloaded with a lot of other work beside the JPA stuff so I basically thought that the defaults that Netbeans generated might just work out well. Well no no no.

Another example are the Web Services Generators in Netbeans 6.7. As it turned out, the plugin developers have sometimes simplified-out methods as with the Facebook Service: There is no batching. You probably won’t write a Facebook application without using the batching support.

It feels to me that nowadays many IDE’s and tools come out with the message that they will do all the work for you. What you have to do is just some simple plumbing: enter an API key here, connect to your datebase there and you are done. My experience however is, even for a quick learning curve (and not learning by a bad example), it is better not to trust those generators in the first place and only use them if you can easily spot wrong code and correct such pieces yourself.

• performance – too slow: this was quite a while ago. JVM’s are very fast nowadays
• bloated: still true for some aspects. E.g. no closures (still..)
• too complex & heavyweight, meaning too many dependencies to setup and take care of. Especially for J2EE this was the case. JEE changed a lot here.

The list could go on, but is mostly centered on those arguments which are however mostly referring older releases of the language and its libraries. Nowadays JEE is actually very lightweight, has a great set of tools that speed up app development and is lighening fast. With the advance of tooling support, common IDE’s make it irrelevant if you have to generate setters and getters (bloated?) or not, and enable refactoring of code with a button click.

When you compare the (web)framework support between Java and interpreted scripting languages Java has learned a lot from past mistakes with J2EE 1.2-1.4. CoC (Convention over Configuration), DRY (Don’t repeat yourself), Scaffolding, etc. can be found in Java frameworks just as in RoR. I don’t think that there’s a general winner – this really depends on the task and situation at hand.

Then there’s dynamic types vs. static types. There are pro and cons for both here, I prefer static typed to detect errors early at development time.

I claim that the real reason for the continued success of scripting languages are the faster development cycles. Especially there is no compilation, un- and redeployment needed. This speeds up development considerably and enables more trial and error coding if you feel like – though better do white-box testing.

Apart from that I cannot see any real advantage of interpreted languages today especially in compare to Java. The JVM is some of the most advanced piece of technology we have today: robust, scales, understood and has many mature implementations on all platforms.

What is your preferred language and why?

On one of my favorite sites on scaling you can find out all the tricks how popular SNS and web 2.0 sites overcame the drawbacks of using such a scripting language in the long term, which served them well at the start for a quick front-end result. Why drawbacks? I agree scripting languages are actually a trend, think of Groovy or RoR, however for a solid backend with good session data handling, distributed caching, management tools, security etc. I would still prefer a compiled language, statically typed, sandboxed with security features, with all the API’s and services like Java has to offer – or maybe C#.

So thinking of todays Social Networking Applications, most require a lot of session data a combined solution: scripting in the front-end and the JVM/JEE in the backend would maybe a good solution. The backend might be a messaging layer or business logic layer with domain oriented architecture or something else.

There it comes the guys from Caucho Resin, an appserver I have used actually once for a University project long long time ago, have implemented the complete PHP language in Java! They call it Quercus and as of the time of this post its version 3.1. Quercus is deployed as a standard webapp and can be run on any JEE container. A Drupal installation apparently benefited from a 4x improvements over standard mod_php. However for a fair performance comparison it has to be compared with op-code caches – i heard good things about XCache – (php code compiled and cached), which typically reduces server load and increases the speed of PHP code anywhere from 2-10 times. Also lighthttp maybe faster than apache.

Performance aside, more important to me is actually to test if I can integrate my php app with my JEE apps and share a Persistence layer /ORM cache as well as clustering aspects with e.g. Terracotta. I will defenetly follow up on this with some results of this technology “mash-up”.