Thursday, February 7, 2013

Where Java Fails

Today a local software developer and I enjoyed one of those wonderful French lunches. We had met a few times over the phone because we have a shared interest in the local Internet fibre, paid for by the county, but that seems hardly used. Before the lunch I visited his office to have a chat. where it immediately became clear that Java was a 4-letter word in the office, despite being an IBM shop. The story they told me was quite tragic and I am afraid that thousands, maybe even hundreds of thousand shops can retell this same story at the detriment of the Java community.

At the beginning of this millenium Java was heavily promoted by IBM since this language could unify their amazing breadth in incompatible platforms. So they send their (COBOL and RPG) developers to IBM for training. After 4 weeks they returned, no longer being to walk with their heads up, and not having a clue where to start with a Websphere application. Then, when they finally got something to run it actually crawled. It did not take much time before they got so disgusted that they threw it all out and happily moved to PHP ...

Yes, Java is big at big corporations (a not unimportant market) but what does it say when developers run for the door when it is their own money? Actually, my lunch partner confirmed what I always felt: Enterprise Java is making simple things really hard and as a result we loose a large number of potential Java developers. Working on an enterprise like application for the last year I actually find Java quite perfect for the task. After working with Javascript and Coffeescript over the past year I know using Java is a lot less frustrating. Not that the language is superior, there are many nicer languages, it is the Eclipse JDT with Java combination that is far superior to anything else I know. Scala might be nicer as a language but last time I looked their plugin it was not even close. Loved Xtend as a language but using it sucked 0without the brilliance of JDT. Pretty sure Ceylon has superior language features but confident that their plugin does not come close to JDT without even having to look. The lack of support for refactoring makes using any language a pain in comparison and Java is quite lonely at the top due to JDT. 

My lunch partner never even heard of refactoring, he had disengaged long before those incredibly powerful tools became opportune. So where is the gap? Let us take a look at some of the issues.

Object/Relational mismatch. Much of what enterprise developers do is shuffling around information in databases so you would think this should be easy to do in an Enterprise language. However, since all we had was objects Java crashed right into relational database technology. It is almost awesome to see what lengths our industry is willing to go (think Hibernate, JPA) to cover this fundamental impedance mismatch. What you can do with a few lines of PHP takes XML, Java, Annotations, and more in our world. Looking at many frameworks one can only be awed for the amount of complexity we are willing to add for ease of use (and fail at it).

Develop Cycle. I f there is one thing I learned in the last year it is that I spent most of my time figuring out how things really work out there. Documentation is often lacking and the only way to figure out what works and what isn't is trying, looking at the result, and making corrections. Turnaround time in PHP and other dynamic languages is negligible since you just change the file on disk.  We have a fundamentally more lengthy edit/compile/debug cycle. Any second between saving your code and being able to view the result is just plain unpleasant. Even though we have in process code replacement nowadays, it is still not as fluid (although bndtools is nowadays as close as it gets).

Custodians mismatch. Over the last years I've worked with many system developers. Many of them really good people, bright, hard working, and sincere. However, few of them have actually developed real world applications, they invariably have worked on the software vendors site. More often than not hired from University. And still, these people are the trend setters, write the specifications, and are more or less the custodians of Java. Just something to ponder: how come there is no money type in Java? Enterprise software is very much about shuffling money; readers that ever had to write this kind of code know money calculations are not straightforward and map neither well to int, long, double, or float and calculating with BigDecimal is a daft. The absence of such a type illustrates the discrepancy between the custodians of the language and their users.

Modules. All popular web languages (Perl, PHP, Python, Ruby, etc) have a module system, CPAN being the father of them all. We utterly lack something in Java. Yes, Maven central is a great collection but using a maven artifact is for many reasons a lot more complicated than using PHP Pear or NPM. Not only should it be a lot easier to reuse components, it should also be really easy to modify them to suit our needs. Though there a multitude of open source projects, cloning is expensive since it is often not cohesive and usually quite large. There are very few highly cohesive uncoupled enterprise components ready for reuse out there.

Concluding, the reason my lunch partner had not discovered the joys of refactoring is because he could not start simple. I also learned this when I wanted to teach Java to my children or when I wanted to build a simple website. There is no Java alternative to Ruby on Rails or just plain old PHP. And actually this frustrates me to no end since I do believe we have by far the best technology. Despite this advantages, we seem to be unable to provide a simple entry point to our temple for the rest of the world. Sadly, in our quest for backward compatibility we actually tend to make it harder and harder for newcomers, something that does not bode well for our industry.

Peter Kriens


  1. "using a maven artifact is for many reasons a lot more complicated"

    I disagree with this.

    There's not much that is easier than copying and pasting in some artifact coordinates in to an XML file and then hitting build (or update project in Eclipse).

    On a Mac you'll find Maven already installed and ready to go. All you need is a pom file. PHP/Perl actually end up being a LOT harder to use and get going, never mind trying to use modules (neither work on my Mac "out of the box").

    "There is no Java alternative to Ruby on Rails ... "

    Spring ROO comes pretty close.

    "... or just plain old PHP."

    Erm, JSP? Especially with Servlet 3.0 you don't even need a web.xml. Not that I would build a solution "Model 1" style... which is also why I don't like PHP.

    How should you build a modern web application with Java? Well I know you know about Vaadin and GWT. Do these not deserve some credit? The "service oriented front end architecture" is not difficult to do in Java, especially when you use JAX-RS (or even Spring MVC) to help you build REST APIs.

    You know me (hopefully) - I'm all for OSGi but I don't think you're accurately representing the ecosystem with these statements. It's not as bad as you're making out, IMHO. And yep, I'm putting *my own money* on the table and still using Java.

  2. I think you've been too long in the industry if you find out of java source XML (your maven example) and JSP even close to easy to use or comprehend. Once you know those technologies it may start to look easy but from what I see newcomers have a very steep threshold to climb and often disappear to less demanding inclinations.

    When you are at a high-level plateau like Java things look complex relative to your perspective. The problem is that a lot of people out there are still in the plains, worse, they have a choice.

  3. I think Play Framework 1.* is a great framework for web development in Java.
    When I used it some time ago, it was the framework that resembled RoR the most. It is quite simple to understand, simple to setup and the edit/compile/cycle is very short. I loved the ability to reload a web page and see my changes immediately, something that I didn't found in other java web frameworks. It made web development fun again!
    And it is fun because they kept away J2EE stuff, like the servlet model (I think JPA is the only "enterprisy" techonology they use). And from what I can remember, Play apps didn't used a single XML file.
    My company is now using RoR, because the new Play framework doesn't look as good as before, but I miss JDT and Java a lot.

  4. Don't think that Java 8 will solve most of these problems (except the modular system)?
    They plan to add money and time API (which are definitely lacking in the language for so long time ago) and lambdas.
    Wouldn't these features simplify the usage by software house development?
    IHMO the part where Java really lacks is the UI. So far Oracle and Sun failed to provide an easy way to create visual interfaces.
    Swing is over complex and JavaFX is still not there yet.
    I believe that's because there are no tools so good like MS Visual Studio.Honestly, we are far away to be able to create UI in an easy way.

  5. I think one of the core problems is still OO. Today no longer because people do not get it but because OO just sucks for separated processes, in time (persistence) and space (distributed).

    Though the GUI has been a huge missed opportunity I am flabbergasted in any investment in this direction since it seems clear in my mind that today the GUI == browser. Swing, JavaFX, etc. pale in comparison to what you can do with Javascript, HTML, CSS, and SVG.