On Monday (July 21st) Compuware announced version 3.0 of OptimalJ. This has some important new features, writes Phil Howard, of Bloor Research.
However, perhaps even more interesting is the simultaneous release of independent performance analyses that the company has commissioned into the performance benefits of OptimalJ compared to Integrated Development Environments (IDEs).
These analyses indicate pretty conclusively that OptimalJ offers substantial advantages when compared to the more prosaic coding approaches. Actually, Compuware is keen to point out that it is not really OptimalJ that has been compared to IDEs but the use of a model-driven architecture (MDA) in general. However, there is no getting way from the fact that it is Compuware's implementation of MDA (which is an OMG standard) that has proved to be so much more efficient than conventional coding.
Compuware has commissioned three different studies of which two have reported. The first results are from The Middleware Group, which is very well respected within the Java community. The Middleware Group assigned two groups of similarly experienced developers to build the same J2EE-based application, one using OptimalJ and one using a popular IDE (though it is important to note that in the latest release you can use JBuilder, WebSphere Studio or Sun ONE Studio in conjunction with OptimalJ, as well as the built-in NetBeans).
The bald figures were that the IDE group took 507 hours to build the application, whereas the OptimalJ group took just 330 hours. Moreover, the quality of the code generated by OptimalJ was higher. Of course this doesn't count the training period for the developers using OptimalJ (who had not previously used it). On the other hand it doesn't take account of the fact that those developers would probably be more proficient.
The second reference test was done by EDS which undertook two investigations. In the first case, it looked at the number of lines of code that needed to be manually written to write the Java Pet Store reference application (which was also used by The Middleware Group), using J2EE, J2EE with OptimalJ and for comparison, using .Net. The total application required 14,273 lines of code for J2EE; 3,484 for .Net and just 610 for OptimalJ.
The second investigation by EDS was to find out the time taken to migrate from an EJB 1.1 based application (again, using the same application as above), to an EJB 2.0 environment. Normally you might measure such an upgrade in months. Using an MDA approach (with OptimalJ) it took a mere 30 minutes.
So far as the new release of OptimalJ is concerned, this contains a number of new features. Apart from the support for additional IDEs (only JBuilder was supported previously) and the introduction of new licensing options, perhaps the most significant new development is that Compuware has opened up the technical patterns in OptimalJ.
The technical patterns provide the rules that convert the domain model to the application model. So being able to access these rules means that you can introduce your own rules, where appropriate. For example, if you wanted all EJBs to be message driven then you could define such a rule and then the appropriate generation would be automated.
It's unusual but I think the new features of OptimalJ are overshadowed by the results of the performance comparisons it has commissioned. These should do much to further the cause of the OMG's model-driven architecture in general, and OptimalJ in particular.