The Agony and Ecstacy of Web 2.0 Development in Java

I started programming in Java in 1996.  

Back then, Java was going to be the glue that held the Internet together.  It was going to replace C/C++ as the primary programming language.  We were going to join hands and jump off the edge into Java Applets -- remember Java Applets?  -- which would power our online lives.  It promised what C/C++ did not -- automatic memory allocation and garbage collection.  All of C++'s speed with C++'s power with none of the horrific memory traps while theoretically running universally.  

And today, Java does power the Internet.  Just not in the way we thought it would back in 1996 when we were trying to embed heavy front end applications in a web browser.  It runs the Internet like the giant evil puppetmaster in the back room pulling the strings and munching data.

When I sit down to think about Java and how I would employ it these are the two competing camps who war in my head:

The Good.

  1. Libraries!  Java has libraries.  It has all the libraries.  Literally all the libraries. In the world.  Need your code to do something?  It has a library for that.  Let's face it, Java has some amazingly good libraries for doing standard things.
  2. Tools! Also, tools.  All of them.  Literally all of them.  Java has every tool.
  3. Really freaking fast.  And it's enormously powerful!  Want to do something enormously powerful?  Java is really freaking fast and enormously powerful.  Java produces the lurking horrors in the back cupboards of the Internet quietly turning data into more data.
  4. Pretty Straight Forward to Cluster.  JMS is actually very nice and interfaces with almost all messaging middleware platforms.  Unlike many of the newer development languages, many of the clustering issues with Java have been, at least at their beginning levels, solved.
  5. Connection Pooling.  "I want 4 JDBC connections in this pool to the DB, please."
  6. Mature Development Environment.  Yep, it's stable and it's not going anywhere.  It's the COBOL of the Internet.

The Really Terrible.

  1. Programming a fancy Ajax- wielding front end in Java is like dripping hot acid into your eyes.  It's horrible.  Seriously.  You thought programming front ends in Python was bad.  At least programming front ends in Python is an accomplishable task in a measurable life time.  Annotations?  A million toolkits from hopeful Java zealots grow like flowers in spring time trying to force a low level programming language to basically string parse.  A half hour of this nonsense and it's time to reach for a PHP book -- or any language with a half decent regex parser.
  2. The java programming culture is about dithering.  The web frameworks -- especially anything in Spring -- is all about taking one's time to meticulously produce anything.  It's meticulous!  It's beautiful!  It's like a shiny star!  And it produces one goddamn web page.  I don't get what the deal is with the million layers of abstraction and the love for XML documents.  As an ancient C++ programmer, the whole let's make an object model that fits the Designs of the Eyes of God baffles me.  DRY is good.  DRY to perfection -- we need to ship products here, guys.   
  3. WebLogic.  Yep.  Horrible.
  4. It's possible to write a web application in ancient versions of Sanskrit faster than in Java.  I once wrote a web application in Struts2, and then did the same one in Ruby on Rails.  One took me a week.  The other two hours.  The answer to which was faster is left to the reader.   
  5. Tuning a java servlet container is better left unsaid.  There is a dark art to tuning a java servlet container - especially Tomcat - so that it both runs in the RAM allocated in its virtualization container and doesn't require VMs with 128G of RAM.


I'm not actually a Java hater.  I'm just a front-end development Java hater.  I never want to program a front-end MVC2 application in Java.  I've done it, I've been there, I've bought the ticket and taken the ride.  It's horrible.  Don't do what I did, kids.  Don't do drugs and don't do front-end development in Java.

But giant engines that munch data?  The behemoth that lurks in the back room or is silently embedded in a system where it quietly runs in its JVM paradise?  It thrives in its place.  

You will have Java in your massive distributed system somewhere because Java produces  back end server powerhouses.  It does many other analytic functions close to the speed of C++ without the memory management foo overhead.  If it's not Zookeeper, it's Thrift, Accumulo, Cassandra, HBase and Hadoop, Hive, Pig, Solr, Lucerne... all the main pieces that build up the new hot Big Data systems are all implemented in Java.  

If you're going to get into the Big Data stuff, you're going to need to pick up a Java book and read it.  Understanding how these big pieces implemented in their the various ecosystems is the key to architecting a system using diverse services without getting into some sort of weird language hell. 

As for Project Butterfly, until it starts generating logs all over the system at a high clip, it will be Java-free.  Once it has data Java will come in to start building out the customer analytics engine.

Oh, and I still don't believe it will run on every operating system.  It does... in theory.  Are you going to stand up your Solr and Lucerne instance on Windows?  Yeah, I didn't think so.

  • Note: I have been told it's possible to write a Java backend server in Jersey/JAX-RS quickly.  I will believe it when I see it.  ^v^