So, I have been in an official IBM training course for WSAD this week. Course WF311 - Servlet & JSP Development using WebSphere Studio Application Developer V5.x For those who don't know, WSAD is the less-than-savvy acronym for IBM's WebSphere Studio Application Developer. That's the integrated development environment (IDE, translated tool) for software development that's offered by IBM.
My experience so far has been close to what I expected. It has lots of bells and whistles, with the ability to do all kinds of things in a single wizard if you are willing to careen into vendor lock-in at the speed of light.
I experienced an especially disturbing thing with WSAD today.
Apparently, it's not that uncommon. While working on the lab portion of the training class, I suddenly had an error message regarding the application deployment descriptor. The trainer recommended rebuilding the project. So, I did, and I immediately received a litany of additional error messages. There were now loads of class not found errors to accompany my deployment descriptor error (which, by the way, did not make sense, since my deployment descriptor source text matched the guy next to me). Allegedly, this is because WSAD and the integrated instance of WebSphere Application Server (WAS) sometimes cause resource contentions and resultant corruption of the filesystem. Woo hoo!
So, a few hours later I am quite behind on the lab work, with no idea where the problem is. We get run out of the classroom at 5:00 PM sharp every day, so I was unable to catch up. Top that off with 4 hours of trying to get mutt, exim, procmail, and sendmail working well on Debian Linux on my PowerBook, and I was fried.
I was particularly disturbed when the trainer told me that the common approach was to delete your workspace and start with one of the pre-baked, catch-me-up-with-everyone-else workspaces (workspaces are file folders that hold all the stuff you are working on). Because I am too proud to condescend to such a pragmatic solution, I was determined to figure out what the hell went wrong. I eventually found that, although the classes were present in the file system, parts of the IDE were apparently not aware of them. Deleting the files and restarting did not fix the problem, for those who may be thinking of that as you read this. It turns out that switching to the Server Perspective in WSAD and choosing to refresh the view of the package containing the problematic servlet class cleared up all of the errors.
A happy ending, right? No way. I now had an error-free project that could not run without throwing a 500 error as soon as you move off the welcome page. And hey, that was a lab; what about when that happens with a project? That's the thing about so many IDEs. Their silver-bullet promises come at the high cost of unexplainable foul-ups when attempting to use the very pixie dust they created. I am not advocating that everyone revert to vi (although knowing vi would do anyone some good). It's just that these tools that promise the moon so often come at a high price of excessive dependency on a specific tool that obscures principles that developers should be aware of.
The slogan on IBM's website for WebSphere is "WebSphere Studio V5.1.2: Making Java development easier". You couldn't have convince me of that today.
Posted by barryhawkins at June 24, 2004 08:45 PM