When Java goes wrong
In the software team where I work there is a strong focus on using Java as the language of choice for building web-based applications. Now, Java has many strengths. In an environment where many software engineers are working on the same code, and the purpose of that code is to interface with diverse data sources and deliver an enterprise-scale application via a web-based interface (i.e. an HTTP browser), then its usage is a no-brainer.
But, the users (sorry, customers!) of the applications that are developed by the organisation I work for are almost entirely from the academic sector. And very often, the funding for the applications we develop comes from research-orientated resources that wish to develop prototypes or demonstrators utilising new concepts or involving new internet technologies such as Web Services, portlets or AJAX. These projects typically have short lifespans, limited resources and the only deliverable is sometimes a written evaluation report rather than a fully-functional software application. It is also very common for only a single software engineer to be working on the code for the whole lifecycle of the project.
In these circumstances, very often Java is not the optimum choice as a development platform. In fact, trying to use J2EE methodologies for this sort of project can cause unecessary delays and the creation of a codebase that is hugely out of proportion to the task in hand.
Sometimes in software engineering projects, the only way the task will succeed is if the code is kept simple and, above all, lightweight. Lightweight means not relying on large libraries of code and compile-time dependencies, which seems to be par for the course for Java-related development. It also means not relying on things like multiple-user development environments, versioning systems, graphical interfaces and usage of enterprise-scale databases, frameworks and containers.
These things can be very important of course, but it is also important to identify when they are not required. And, in my professional experience, they are very often not required, but continue to be used, and cause a lot of unecessary headaches.
A case in point is a project I was involved in recently which developed a search engine that used SOAP messaging to query a remote database. The whole point of using Web Service technologies and methodologies is that they use standardised XML schemas and HTTP and hence are platform and language neutral. It is also the case that building a Web Services query client should be a (compared to building a database-supported Web Services query server) relatively simple task. And in this case it was. If I used Perl to write the client. A few tens of lines of code and the use of the SOAP::Lite module, and a simple client was built in a couple of hours.
But, Java was mandated as the language to use as part of the contract for this project, with absolutely no good technical reason why. So Java it was. This meant using installations of Axis and Tomcat because there is no distinction in the Java Web Services world between building a server and a client, depite their differing orders of complexity; if you want to build a client, then you have to deal with the server code libraries.
The difference between the Perl approach and the Java approach in this instance was truly staggering. I had to wrestle for many days with the hard-to-debug Java code to get it to make the same simple Web Services XML request that took me a couple of hours with Perl. When the project deadline came, the finished search engine was lighter on functionality than it should have been, because I spent valuable days lost in the huge and complex world of Java.
What went wrong here was the failure to recognise the need and utility of a lightweight development methodology, and that Java was the wrong approach. A simple, interpreted language with support for HTTP and XML, like Perl, would have been absolutely ideal.