RAD - 'the evil WSAD legacy' strikes back

Ok, interestingly I read that IBM will not support WSAD from September 30th, 2006; so inevitably that means the big corporates will migrate to RAD (IBM's Rational Application Developer) over the next year.

The experience I have had with RAD is minimal. Of interest, I did, however, try and import a legacy J2EE project which was being developed and maintained with WSAD. RAD was unable to do this.

Let me clarify this - RAD was able to import all the source, ejb folders and the J2EE project was able to compile. The RMIC deployment however was significantly flawed. The only theories I have at the moment are:

(1) WSAD embeds IBM-centric descriptors in the configuration of EJBs (in particular entity beans) that are not fully supported in RAD
(2) the RMIC deployment tool between WSAD and RAD is not the same (requires some feature to deply RMIC code like WSAD)
(3) more stringent validation occurs in the RMIC deployment of RAD over WSAD
(4) updates to libraries (e.g. database drivers) causes errors in the OR mappings

Unfortunately, for the J2EE legacy project I am working on, this means that WSAD is no longer supported and RAD cannot support it! And indeed the error messages that RAD has produced have been highly ineffectual.

So IntelliJ? well that would be a great! but like any high-quality IDE it does not allow cyclic dependencies. So what now?

J2EE development and the 'evil WSAD legacy'

Around 2 years ago, I read a blog from a prominent software engineer in Melbourne (Jon Eaves) who posted about the 'evils' of Websphere Application Developer - having never used it, I read with curiosity and this reaffirmed my own development management of the team I was running at the time, in using: IntelliJ for an IDE, Maven for an independent test/build/development management system, and predefined, one-per-developer based IBM Webpshere Application Server (to which developers deployed to).

2 years forward (and as mentioned before, working on a legacy J2EE project) - I am using IBM's Eclipse2.0-based WSAD and a 1 hour + ANT development management system. After using it for a week, there are several key characteristics of WSAD which seem to engender poor code and development practises:

• In-built pseudo 'test' Websphere Application Server; what is the rationale in deploying to a IDE-based server? if everything deploys what has this actually proven? it has not been deployed on a Websphere Application Server and does not mitigate any of the risk associated with this. If anything, it promotes point-and0click testing and runtime debugging to be used as a substitute for unit testing. A better idea would be to have WSAD / RAD, etc. to have an extensible / callable EJB container that could be invoked off a unit testing framework such as JUnit, TestNG such that unit tests of legacy EJB2.0 code actually be tested. Assumptions regarding the full application deployment could then be verified on developer instances of WAS (and with integration tests).
• Non-standards based directory structure; if WSAD / RAD is going to provide Wizards to set up a new project - then conform to the industry standards in terms of directory structure, or at least allow any directory structure to be used. Currently, WSAD imposes a directory structure.
• Non-standards based artifact generation. Upon seeing the monolithic ANT development management process, I thought, I would be easy able to refactor the constituent jars, wars, and ejbs of the project. Unfortunately, this is not possible because IBM introduces its own bindings in the ejb-jar.xml such that it does not even conform to the schema - nonetheless it is able to be deployed on WSAD, WAS. Now only through WSAD (or by calling WAS libraries) is a deployment possible - complete vendor lock-in!
• Loose intra / inter project error checking - WSAD allows projects to have cyclic dependencies - when is this ever a maintainable approach? Error checking within a project is also poor (somewhat an artifact of Eclipse2.0).
  
• Extremely poor IDE responsiveness / performance on projects with multiple modules.
  

The 'evil WSAD legacy' results :- J2EE projects that are WSAD-bound (i.e. not able to develop / develop in any other IDE), poorly defined, poorly error-checked, and poorly tested. Of course, this is somewhat dependent on the developers that worked on the project in the first place - but with WSAD's loose industry compliance - it is difficult to see how any significant J2EE project will be maintainable in the long run if it has been developed, and continues to be devloped on WSAD.

So what do all the projects that have been run on WSAD do in the next 2-3 years when dealing with this legacy unmaintanenable code ...