Top Five Java Technologies that Didn’t Make the List and Why

Share the article!

I’m delighted that Joseph Ottinger has so graciously posted my previous post “Top Five Java Technologies to Learn in 2008” on the Serverside. A list limited to a select five entires surely will bring out some controversy. There will always be those who would feel left out. Of course, the list could have been expanded to 10 entries, but that defeats the entire point. As the Attention Economy has revealed, an individual’s attention is a scarce commodity.

Its been suggested that Polyglot programming be in the list. Even though I do subscribe to the notion that learning other languages are beneficial to one’s craft, it simply is not pragmatic advice. It is not practical to recommend that someone study Ruby, Groovy, Scala and who knows what other language is vying for your attention. Stick to a couple of languages and do it well. Some languages are better than others for certain tasks. However the biggest fallacy of all is that, a dynamic language is not considerably better than a static one. It’s no magic bullet.

Finally, of the Five technologies I selected, there’s an underlying recipe to it. That is, all are about infrastructure. See, it isn’t about the language. If anything is going to make you successful in creating the next killer it app, then the platform that it runs on would influence your success more than your selection of language. As anecdotal evidence, look at the Chandler project, they had to re-invent the wheel several and in fact did that several times. Life would have been simpler if they used what ever was out there. Unfortunately, NIH reared its ugly head before it was too late to notice.

Let me go down the list to explain my point about infrastructure. OSGi is about managing the complexity of deployment. The default Java classloading mechanisms are clearly inadequate for a system where multiple versions of the same jar file are used. A higher level structuring mechanism is required and that is what OSGi precisely provides. Bill Kayser has a very good read on this matter:

In most cases, the JVM still loads classes from the big vat of class soup indicated by the class path. What is needed is something more fundamental, something that would completely xe2x80x9cinvertxe2x80x9d the control of the whole application, executing everything as services, not the chosen few components.

Java Content Repository (JCR) is about managing unstructured content. In my development travels I find it disappointing to find that most projects consider a RDBMS as the only choice of data storage. It is clearly unfortunate since almost all systems require some kind of unstructured content storage. Even though you could shoehorn your data in blobs in a RDBMS, there still remains the additional task of building infrastructure around it. For example, how would you search through those blobs? SQL’s text search mechanisms are going to be a massive disappointment for those who are all too familiar with Google. But going beyond just usability, there will always be the need for users to annotate the data they work with.

GWT is about managing the complexity of Javascript. The two main problems with Javascript are (1) the extreme flexibility of the language and (2) the lack of consistency of browser implementations. GWT tackles the first problem by employing Java and treating Javascript as an assembly language. For most developers, it should not be necessary to have to delve deeply into assembly language to get your tasks done. The second problem is handled by the maintainers of GWT, they have painstakingly crafted variants of the Javascript that is generated to handle the different nuisances of the browsers. As browsers continue to evolve, GWT developers will continue to tweak their compiler. We should all be thankful that someone else is doing this arduous work.

Then there’s the controversial selection of Groovy. Groovy allows you easy access to meta-programming features in a dynamic manner. Java infrastructure has continually improved its meta-programming features. It has progressed initially form JavaBeans then to BCEL/ASM (runtime bytecode management)to finally Annotations and Aspect Oriented Programming. Groovy’s meta-programming features is one additional method in the tool chest. Of course, the scripting language shortcuts are indeed helpful.

Finally there is that notion of cloud computing. Cloud computing has been around for some time now, however I think Amazon’s entry into the space with a pay as you go model is truly disruptive. It is the convenience of it all that makes it all different. The amount of time saved, by not having to do it yourself or even not having to require a conversation with a human to get it done, is tremendous. The ability to scale up without a massive up front investment is changing the playing field as we speak.

In summary, the list is about technologies that add a base infrastructure to build you next killer app. Surely you can use whatever framework is out there, but ultimately your success will be influenced based on how much work you didn’t have to do by leveraging what was already out there.

Now going to the top five technologies that did not (or just barely) make the list:

  • #5 Android – Google’s attempt to turn the telco space on its head. This is expected to be not only game changing but disruptive. I of course will like to wait for (a) an actual hardware device to play with (b) Google winning the 700Mhz spectrum and (c) the deployment of 700Mhz cell towers across the states. The problem I have with Android is the problem the plagues J2ME devices. How do I keep my sanity as the variety of mobile devices increases exponentially? I have yet to have heard a compelling story (OSGi perhaps?) in this area. That’s plain unfortunate because it’s the biggest pain point for mobile developers.
  • #4 JRuby – Rails is certainly getting a lot of attention; JRuby channels that attention towards the JVM. The Ruby job market has grown to a stunning 3.3% of the size of the Java market. If you need something new (don’t ever try this with legacy code) then possibly the quickest route to a working application is via Rails (use Streamlined while your at it). However, not all applications consist only of CRUD screens, you’ll need to add more mojo into it. That’s when you have to question Rails viability. Convention over configuration only works well if you’re building something conventional.
  • #3 Scala – Scala is a brilliant well thought out language. It’s a language that is not only extremely expressive but one that doesn’t have the performance baggage of a dynamically typed language. In short, you could use it to build bleeding edge infrastructure stuff. The kind of stuff you would never dream of building using slow as molasses languages like Ruby. Sure, you have to subscribe to the static typing religion, it’s an unfortunate trade-off you have to make if you want to build really tight systems. It however didn’t make the list because I would only recommend it to ‘rocket scientists’ building serious heavy lifting infrastructure. Web front end developers need not apply.
  • #2 Seam – Gavin King (Hibernate’s creator) is an accomplished developer. So when he builds another framework, it behooves you to take notice. Seam is his latest creation and it merges JSF and EJB3 into a seamless workable framework that’s all hangs together with Annotations. Unfortunately, its strength is also its weak spot. All that annotation work is going to be a nightmare to debug. Personally, I think Spring is good enough, however if you must have an overarching framework then Seam would be it.
  • #1 Flex – If anything should have been on the list, this would be it. If you want to build rich applications on a browser then plain DHTML and Javascript isn’t going to cut it. The most innovative desktop like applications on the web are unfortunately built on Flash. GWT isn’t going to help you build applications like YouTube, Mindomo, Buzzword, Sketchcast or Pandora but Flex will. The bad news is that Flex isn’t Java, however the good news is that Adobe’s soon to be open sourced server (BlazeDS) is thankfully in Java.

So if you do have that extra bandwidth, I would recommend learning about these additional five technologies. Who just never know, these just might be the top five for 2009 ;-) .


Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>