Following the discussions about QVector and QList on the qt development mailing list is almost a dayjob, I sighed on krita’s irc channel, this morning. It’s also slightly amusing, and it ties in with something I’ve been thinking about lately.
Category: java
Java — it’s a weird world
So, after a foray into Javascript and into PHP I’m back, for a bit, coding Java. A stupid little web application with maybe four data objects and a webservice interface. And I am not liking it. We’re using Appfuse (nice community, helpful maintainer — no quibbles with that) to generate all the boilerplate for us. Generating boilerplate code was a cardinal sin already in 1993 when Visual C++ would clutter your application with its reams of generated MFC boilerplate, and it’s still a Bad Thing.
So, for this little web app without any logic, running the unittests on a test set of three instances per data object takes 96 mb of memory. Making one little mistake in the initial class definition of the Plain Old Java Object means dropping the database and regenerating the whole thing — which means two manual actions per data object. But they’re planning on reducing that to a single manual action per data object. Whee!
Adding the WS-plain-old-and-basic-based-on-a-simple-wsdl web service to the application is another exercise in frustration. Appfuse is, er, underdocumented. What documentation there is belongs to the previous version. It suggests using XFire, but that has merged with another project to form CXF. Besides, Axis2 is the standard thing for Eclipse.
And creating a webservice from a wsdl using Axis2 and Eclipse isn’t hard (except that Eclipse tries really hard to be Emacs of the 21st century, without any of the elegance, sophistication and consistency of its great predecessor, so it takes 650MB to run, using my little app project, and except that Eclipse WTP is a bit buggy, so following the tuturials is not a guarantee for success). However, trying to add the generated web service to the app-fuse app is completely undocumented.
We’re using Maven2 here, which is a kind of package manager without a package search functionality, and a kind of build system, and a kind of deployment system — and configured in a big, complex XML file, of course. So is the web app server. Where do we configure the web service servlets? Where do we configure the compile-time dependencies? Where the run-time dependencies? More XML files. All not meant to be edited manually, but there are neither good command line tools nor good gui tools. I mean — having to search through http://mirrors.ibiblio.org/pub/mirrors/maven2/ for the libraries you need, then finding the right bit from the right xml files and paste them into your project file — which year are we living in? I cannot believe I’m actually doing this. And if there is a better way of doing this, where is that documented?
Oh — and where the Spring people proudly claim that through their triple-layered design (datasource — date-handler — logic object) it’s now possible to — gasp! — change the datasource without changing a line of Java code, they completely fail to realize that we now have to hack more unreadable XML code. Inversion of Control. Dependency Injection. Standing on your head is so comfortable! And walking on your hands saves shoe-leather.
I don’t mind Java as a language — much. (I do think that the generics feature has been designed and implemented by a bunch of weak-minded interns with water on their brain, who, having seen that C++ has types in angular brackets thought “Cool! We want types in angular brackets, too!”) But the language itself is still nice enough.
But really, the Java world has lost its way. Frameworks that are designed to solve the problems caused by the complexity of previous frameworks only get more and more complex; the aggregation of vast libraries and disparate tools in enormous frameworks that need a dependency management system that makes me long for apt, all this suggests to me that the java application framework developers have, in an orgy of architectural excesses, lost sight of the original goal of writing applications: deliver something that’s usable, maintainable, economic and portable. Dash it — four tables, twenty fields. Create, update, delete and expose through RPC. When I needed that kind of thing in 1998, I wrote a couple dozen lines of Python code.
There are application servers out there, you know, that can run twenty big, interactive, dynamic websites on a single server, instead having to run a single website on twenty load-balanced servers.