The Best (and Worst) Java Tools, Frameworks, Libraries etc.


Probably the most unique thing about Java is the wealth of tools, frameworks and libraries available, the majority at low or no cost. The subsequent difficulty for new Java developers is what to learn, what to use, and what to avoid. Although this type of list can degenerate into a religious argument hopefully the reasons for choosing each will be fairly clear and at least thought provoking.

The Best:

  1. Eclipse ecosystem: from its beginnings as IBM Workbench, which seemed like no more than a feature short, bloated attempt at replacing Visualage for Java with a tool that didn’t put all your Java directories into a Smalltalk repository, Eclipse has grown into the most comprehensive ecosystem available in any programming language. Whether using it for its wealth of plugins supporting just about every Java server, JDBC accessible database, program messaging system and scripting language; using it for its rich UI toolkit that can provide a flexible UI that will run unchanged on every major platform or even be remoted into a web browser; taking advantage of the speed of incremental in-memory compilation or the variety of code, style and syntax validators, Eclipse answers just about every need a Java developer might have in terms of features, capabilities and overall reliability. The cost of course is its complexity: you can’t learn the whole ecosystem overnight, and configuring it optimally with the right set of plugins for a given project requires a level of expertise in itself. That it’s open source and supported by every major Java vendor completes the picture.
  2. Java EE 5+: Keeping the capabilities of J2EE but automating the majority of the configuration and replacing the amount of rote code required in J2EE with simple annotations, Java EE 5 and its successor versions provide just about every major standard required for enterprise applications, nicely packaged, and with a choice of implementations of the most used standards, including EJB3, JPA for object-relational persistence, JMS for inter program messaging, JTA for transactions, including support for distributed transactions, and advanced server clustering.
  3. Apache Synapse / WSO2: from using Synapse as a small library with enterprise service bus capabilities to its full blown server versions put out by WSO2, the combination is the most flexible and reliable ESB solution available. And it’s open source with available support.
  4. Glassfish 4.0: There are a wealth of Java / Java EE servers available, but Glassfish stands above the rest in being open source, being the reference implementation for Java EE, which means it almost always supports the newest standards first, and the performance and flexibility of its OSGi engine.
  5. Open Identity Management stack (ForgeRock): taking Sun’s open sourced identity management stack abandoned by Oracle due to Oracle Identity Manager being a direct competitor, OpenAM, OpenDJ and OpenLDAP together provide a rock tight access and security foundation for Java and web applications, with built in integration and normalization of user repositories from various LDAP implementations to Active Directory. The provisioning component is coming along nicely as well, and for performance and scalability even the expensive solutions from Tivoli and Oracle can’t handle the number of users or achieve the performance offered by this stack.

Honorable mentions:

  1. Netbeans 7.x: Netbeans doesn’t have the wealth of support, features and plugins of Eclipse but it does what it does very well. For those using Maven or Ivy Netbeans also offers the most transparent integration, although the addition of Maven integration to the Eclipse web toolkit project evens that up with Maven at least a fair bit.
  2. JDeveloper: too specialized to Oracle technologies to win out over Eclipse or Netbeans, JDeveloper is still a very good IDE if those are the technologies (Oracle DB, Oracled’s ADF implementation of JSF, and Toplink in particular) that your organization has settled on.
  3. Glassfish ESB / OpenMQ: With the best guaranteed once and once only message delivery other than IBM’s very expensive MQ Series / Websphere MQ, but a zero dollar price tag and better flexibility than IBM, Glassfish ESB and OpenMQ together offer a compelling ESB and message queuing solution.
  4. Apache Service Mix: Similar to Glassfish ESB / OpenMQ, Service Mix offers a vastly scalable, from the very small to the very large, and from the very centralized to the very distributed, system with excellent reliability and the option of using RabbitMQ to support telephony protocols (i.e. non TCP/IP based messaging).
  5. Apache Geronimo 3: with similar performance and flexibility to Glassfish (and even a similar design with an OSGi based engine), in many cases the choice of Geronimo 3 or Glassfish ¾ comes down to one’s preference for the libraries chosen to be included (and tested) with the server. Glassfish currently edges out Geronimo 3 due to its support for Java EE 7 and the easy to configure embedded version.
  6. JSF: as a compromise between UI interactivity and server side control JSF 2.0, with its clean programming model and interconnectivity to Javascript at the browser side offers a lot in terms of easing web development. Even if you are hellbent on HTML5/Javascript for the most extensive user interactivity possible, using JSF as a bridge can save hundreds or even thousands of expensive hours of UI work on a project by handling the housekeeping duties and slightly less immediately interactive features in a manner that both keeps a good coupling to the server and is quickly written and tested.

The Worst:

  1. IntelliJ IdeaJ: Idea was once a fairly advanced development environment, but today it falls well behind all the other major IDEs in terms of features, framework support and performance, with the added disadvantage that all the others barring JBuilder are free, while IntelliJ wants to charge for anything but an introductory version.
  2. Spring IOC/MVC/Data: Spring IOC became an anachronism the day Java EE 5 was released, and it has only fallen further behind. As a lighter weight alternative to J2EE with easier configuration it had its time and place for mom n’ pop shop projects, but Java EE 5+ offers easier configuration and a more flexible programming model than Spring IOC, together with a superior feature set and vastly superior reliability. Spring MVC offered a few advantages over Struts, but while Struts 2 addressed most of those, the biggest reason Spring MVC offers little to nothing to attract any new users is that the page routing metaphor of both Spring MVC and Struts is convoluted and irritating when compared to the single-page application models favoured by both HTML5/Javascript and JSF. That Spring MVC doesn’t provide sufficient communications routes for JSF 2. 0 is the nail in the coffin. Using JPA with Spring IOC is fragile enough, since JPA entities are in reality EJB3s and the JPA implementations expect container features either not present or half hacked into the IOC container, adding Spring Data’s CRUD JPA framework turns your advanced relational database and advanced object relational mapping system into an unreliable set of spreadsheets. A better idea is to learn how to use relational databases in the first place.
  3. Oracle Service Bus: not to be confused with Oracle Enterprise Service Bus, a decent but overly expensive ESB solution, Oracle Service Bus is the old Aqualogic ESB sold by BEA before Oracle bought them out. Aqualogic didn’t work back then and hasn’t changed, and is really nothing more than a toy to get-you-in-the-door and then upsell you to the far more expensive Oracle ESB. Do yourself a favour and use one of the open source ESBs mentioned above, and avoid messing with OSB or paying for OESB.
  4. Tomcat Java Server: abandoned by its developers in favour of a complete rewrite (Glassfish), the original Java server reference implementation is a hopeless anachronism. Yes the base server starts up quickly, which developers like when having to restart a Java server over and over to test code changes, but by the time you add enough libraries to give it a reasonable set of capabilities it becomes much slower to start up, never mind its performance once running, than Glassfish or Geronimo. Tomcat also has more potential race conditions in its code than the Paris-Dakar rally, so anyone using it outside the developers’ machines is just asking for trouble.


     

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s