Top 10 Java Technologies at Cambridge Technology Partners

In the second part of our "Top 10" series, we dive into the actual technologies we use in our projects.

• Enterprise JavaBeans (EJB) 3:
  Already declared as dead, Java EE has managed to jump back on the train with EJB 3. It incorporates many best practices like convention over configuration, dependency injection and usage of annotations, simplifying development a lot compared to its predecessor.
  
  Although the spec for EE 5 has been out for quite a while, adoption at our customers has taken a while - but now starts getting momentum. I've seen some very nice "Aha!" moments while demonstrating what the new platform has to offer to developers. The combination of POJOs, annotations and Java standard makes setting up projects and unit tests very easy and a powerful mix for development.
  
  EJB 3.1 looks also promising in terms of further simplifications (and fixing some holes left in the APIs) - we're looking forward to help our customers taking this turn as well!
  
  
• Java Persistence API (JPA) and Hibernate:
  As a de facto standard for object persistence, Hibernate has been used in our projects for years now. While working with other persistence technologies like Beehive DB Controls, iBatis or even Entity Beans due to legacy code, Hibernate has proven most efficient once the domain model got a little complexer.
  
  With the new Java Persistence API coming in Java EE 5, Hibernate gets even easier to integrate and use into an enterprise application. We're still missing some Hibernate features like a criteria API in JPA, but JPA 2.0 is about to fix this. Besides easier integration, JPA makes applications also more portable - there are also a couple of other JPA implementations available: Oracle TopLink, openJPA (or its big brother Kodo) or Apache Cayenne to name the best known. Being part of the EE standard, it's not a surprise that integrating JPA with EJB (or vice versa) works great!
  
  Mentioning JPA 2.0, let's see how EclipseLink (nominated as reference implementation) compares to Hibernate!
  
  
• JavaServer Faces (JSF):
  MVC frameworks seem to be around like sand on the sea. From old school Struts over Wicket to Google GWT (or other fancy new AJAX frameworks) - it's hard to decide for "the right one" on projects. My recommendation usually goes to using JSF (with Facelets). Investing in a standard is in general a good thing.
  
  In case of JSF:
  - It has proven to be extensibe. There are a couple of very nice AJAX component libraries around, like JBoss RichFaces, Woodstock or ICEfaces. And also, JBoss Seam adds a few killer features to JSF, just to name stateful navigation or transactional backing components here.
  - It is programmable with a declarative view definition in XHTML and an expression language. Facelets adds an extremely powerful templating to JSF, which I found much easier to use than frameworks like Tiles or SiteMesh.
  - Growing IDE support (Eclipse WTP, JBoss Tools, NetBeans and the latest IntelliJ to name some) featuring WYSIWYG editors or (for me much more useful) XHTML and EL code completion.
  
  By the way, Java EE 6 features JSF 2.0, including enhancements for component developers as well as standardazing on Facelets!
  
  
• JBoss Seam:
  In my humble opinion, one of the most innovative frameworks over the last years. As already mentioned in a previous post, the stack around Seam works for me extremely well and efficient to develop web applications.
  
  Getting back on my previous statement on investing in standards - I'm looking forward to WebBeans (I hope JSR-299 makes it into Java EE 6), combining Seam with typesafe dependency injection of Google Guice! Looking back at my first servlet based web application during CS studies, things have become amazingly elegant to develop!
  
  
• Spring Framework:
  Both EJB 3 and Spring in the same list? Yes, Spring is also a great piece of technology in use at many of our customers. It has not been the first open source dependency injection container (just to mention e.g. Pico) but was the first "enterprise ready" implementation out there making me extremely happy to work with after sweating on an EJB 2 project.
  
  Third party products (e.g. CRMs) which do not support Java EE 5 application server versions are sometimes limiting constraints for upgrading, which make usage of Spring a great alternative to customers which are still bound to EJB 2. Even if you don't deploy a Spring runtime, it offers great support for your unit tests - like using SimpleNamingContextBuilder to mock an InitialContext!
  
  The latest 2.5 release of Spring makes also (finally) use of annotations to inject bean dependencies, which is a great improvement over the previous "XML salad". Adam Bien has written a nice post on XML vs. annotations in EJB 3, which covers with my experiences and can be similarly handled in Spring.
  
  
• JAX-WS:
  While we've gone through a couple of web service technology stacks, the JAX-WS standard has been for us the most convincing on to work with (did I already mention we generally like standards? ;-). Its reference implementation Metro has made its way into major application servers like Oracle WebLogic, JBoss, GlassFish (and probably others), allowing us to easily take best practices from customer to customer.
  
  If you're rather out for something simpler than a full SOAP stack, also have a look at JAX-RS, the standard for RESTful web services. Its reference implementation Jersey is on its way to version 1.0, but already now ready for some really cool use cases (try it out with e.g. JFreeChart to create dynamic charts in web applications)!
  
  
• TestNG:
  While writing unit tests for years with JUnit, I've made the experience that some limitations of the framework have somehow led to ugly test code - clunky test method signatures with no arguments, no mechanism to define dependencies between tests and no built-in mechanism to run test methods with different test data.
  
  In a real world enterprise project, testing just the "unit" is not always enough. With Spring for example, we can run the whole container and execute test cases on it - this is definitely much faster than deploying to the container. TestNG has shown to be more useful than JUnit in this context. Also several large open source projects have decided for TestNG, to name JBoss (by the way: congrats for passing the EE 5 TCK!) or GlassFish.
  
  
• jBPM and Drools:
  Probably not the most advanced BPM on the market, but at least in the open source space jBPM is the leading engine we've been working with so far. Now part of JBoss middleware suite, jBPM together with the Drools rule engine form a powerful couple when shaping SOA applications. But also running without jBPM, Drools has shown to be a great engine to externalise business rules in a very clean and maintainable way (which would otherwise probably have ended up in some ugly if-else jungle or rather complex decorator pattern classes).
  
  
• Java Content Repository (JCR):
  It is extremely common for applications to store various pieces of information, most of the time in relational databases. While they do a great job when working with regular data types (e.g. int, string), we think they are not very efficient when dealing with binary data (unstructured), for example images or documents (structure binaries). On top of that, many features are not covered by pure DB products out of the box:
  Usually, such requirements we encounter on projects are proper management of documents, versioning, enhanced meta data tagging, handling of structured as well as unstructured content, proper handling of dependencies between content nodes (known as referencial integrity), flexibility with regards to node attribute extensions and inheritance, administration delegation, and many more.
  
  In such cases where an extra layer is needed on top of a database, JCR and JSR-170 quickly come into the picture of our solution proposals for our customers.
  
  More details will follow in a few days regarding JCR at CTP.
  
  
• Scala:
  Honestly, we haven't had Scala in a customer project yet. Still it seems to be the most interesting newcomer in the "scripting on the JVM" category, offering static typing and a couple of interesting language constructs (to build e.g. DSLs). Unfortunately the learning curve is a little steeper than with other scripting languages, so a deeper analysis on where we can leverage this at our customers will have to wait until my next "beach time".