More than once, the last couple of weeks I repeatedly stumbled across situations in which I had to remember the infamous Law Of The Instrument in order to explain some peoples attitude towards technology and overall technological decisions. I am not sure if this “law” holds completely true all the time, but I am sure there are some valid points to it.
Does “Java EE vs. Spring” really matter?
One of the first things that has been nagging me in ages is the ongoing dispute of what “platform” might overally be better – the Java Enterprise Edition or rather the technology ecosystem built around the Spring Framework. No, I will not go into detail enumerating each ones advantages and disadvantages as this happened before a myriad of times and should be familiar by now to those who care. Bottom line in my opinion, however, is: Does it matter? Shouldn’t, in the end, an application matter? I am not complaining that either of these technologies really are bad or pointless, in fact I make heavy use of at least Java EE in my everyday life. But, from some points of view, they both at times feel like being unable to provide reasonable answers to questions raised by other technologies. Just remembering the Ruby On Rails ‘hype’ a bit earlier: Sure, an outstanding technology – if everything’s fine. In our environment, however, we quickly ran into the limitations of these approaches, learning that, though being great in “greenfield” projects, these frameworks, concepts, technologies at large suck as soon as you got to deal with existing data structures, an existing database schema (which is far from normalized or even “sane”), or, worse, in some situations, data functionality exposed by CRUD stateless services rather than done via direct database access. It feels all “greenfield” somehow. Sure, you can use RoR also in an environment as the one outlined before, but it’s way less “fun” or effective.
Being technology for “enterprise computing”, I sometimes would expect Java EE (or Spring, for that matters) to, in this direction, provide solutions offering benefits of platforms or technologies like RoR while at the same time keeping focus on enterprise development and computing requirements, especially in terms of integration and “brownfield” development, the fact that quite a lot of people don’t have the chance of starting all over again. Unfortunately, Grails, based upon Java and Spring, “just” tries to resemble RoR it seems, on top of the Groovy language. It’s a pretty good framework, and it offers a bunch of features – and yet has the same shortcomings as RoR, in my use cases. There’s no real “additional enterprise benefit” here, apart from running on top of the Java VM out of the box which allows for deeper (manual) Java integration.
NoSQL databases in my opinion is another interesting aspect. So Java EE 6 has been published a while ago, there are a few application servers already providing support for it, there is an all-new and rather good persistency layer (JPA 2.0), fairly powerful, and yet – I again and again happen to run into the situation of thinking about how to meaningfully persist data structures which are rather simple yet dynamic. Sure, persisting
Properties using JPA works (and has fairly improved in recent versions of JPA). Then again, ever tried CouchDB for these purposes? Maybe there’s always, also, the risk of considering things “golden hammers”, but in the end, NoSQL databases are a pretty good tool to be added to the day-to-day working toolbox, to solve one problem or the other maybe more effectively than other approaches. Yet, NoSQL is just slowly making its way into Java EE and the related communities. Maybe with Java EE 7, one day.
Maybe this isn’t altogether fair or anything beyond just a rant, but sometimes I wonder whether, from this point of view, the enterprise Java crowd is up and ready to keep up with the pace at which the “rest of the world” moves on. Maybe it’s time to at least partly see there are tools just as interesting and powerful as the set of hammers provided by Java EE (even though they are good hammers).
Desktop? Web? iPad? Pen&Paper?
Another dispute I then and now either enjoy or start to perceive as rather annoying is, maybe also related to Java and its community, related to the question whether or not, in 2011, one should still care writing a desktop application while “everybody’s doing web”. Yes, some seem to argue right this way – desktop application development is pointless and waste of time while most of the things to be done is about to be done online and, eventually, on some mobile device where web is the only reliable and portable way of doing things anyway. This kind of reasoning, however, ain’t any better or worse than any reasoning outlining that web applications, in the end, are “just” something few really can afford and that, in the end, as soon as it’s about “heavy” lifting and more excessive data processing, one will be back to a desktop application in no time.
To me, it’s both crap. It’s a matter of use cases. There are good reasons and use cases to want desktop applications, and same way there are use cases and reasons to prefer pure web applications. Requirements should dictate which kind of approach to use, not political or technological or whatever other kinds of decisions. And, then, in the end, somehow I do not really want to bother that much. I want to be capable of building good, usable, scalable applications which even are usable to end users. I want to, about that, get to a point where “desktop” or “browser” is a distinction that doesn’t matter to me anymore throughout at least 95% of my application code (eventually let aside things like local desktop application integration and file- up- and download). Single Sourcing in Eclipse seems a right step into that direction, although this still leaves a lot to be improved. Maybe XWT could provide a solution for that, maybe not. Maybe in the end it comes down to something the “other way”, to using “rich client platforms” like GWT or Vaadin (originating in the web development environment) for deeper desktop integration all along with the set of features offered by newer browsers, in example thinks like
audio, video, canvas, storage in HTML5. Maybe we will even see some approach to expose Swing applications to the web without too much ado, similar to the HTML5 backend for GTK3. I am not sure.
The only thing, as far as this is concerned, is that I hope to eventually, one day, see an end of the reasoning promoting desktop applications because the favorite tool of the trade is a desktop framework (or, vice versa, for web). And, maybe, again a bit more of a desire to actually solve problems (fast, reliable, and in a good quality) by toolings available, and to accept specific problems not tools one grew accustomed to to recommend a specific solution. Which, again, requires tools to be easily fit together to fulfil right this purpose, but that’s another story. 😉