Saturday, September 4, 2010

My issues with Spring

One of the things I've had to come to turns with as a professional Java developer, is navigating the massive chaos of frameworks out there. It doesn't really matter which corner of the development stack we're talking, in Java we're sure there won't ever be just one official standard; if we're lucky, we can identify a state-of-the-art de-facto standard and if we're *truly* lucky, our choice will remain a good one for longer than a few years.

One of those de-facto standards appears to be Spring. There is little doubt, that IoC (Inversion of Control), or more specifically DI (Dependency Injection), can be a great tool to decouple concrete dependency layers. However, in my opinion Spring introduces just as many problems as it solves, and here's my take on why.

Everything and a Kitchen Sink
While Spring does address IoC/DI, it also does a gazillion other things as well - as evident by looking at the Spring maven repo. On one of the project I was on, my Maven POM ended up holding 15+ dependencies to Spring related technologies, leading me to categorize Spring as containing everything and a kitchen sink. Spring is so many things in one, that it's hard to fathom let alone explain the boundaries; there's Spring JDBC, Spring MVC, Spring Security, Spring Remoting, Spring AOP, Spring DI, Spring RESTfull and probably much more that. Each part may very well be useful in their own right, but one can not help but to be weary of this creeping featuritis.

Abstraction layer madness
Most of the frameworks we use, take the shape of some sort of abstraction layer shielding us from hairy details further down. However, from navigating a Spring projects various configuration files and Stack traces (btw. confirmed by Nasa of being visible from space), I get reminded of a short conversation between two luminaries within our industry.

Computer Scientist Butler Lampson is known to have said:
"All problems in computer science can be solved by another level of indirection"
.

Whereto David Wheeler supposedly responded wisely:
"...except for the problem of too many layers of indirection."
.

In other words, perhaps we should be careful not to get blinded by magic frameworks which, when everything gets added up, turns out to be as much a disadvantage as an advantage. In this day and age, arguably it's the frameworks rather than the programming languages, we spend the most time understanding - but where we should spend our time, is in solving our clients problems.

Configuration madness
The inventor of Java, James Gosling, is known to have said something along the line of
"Every configuration file ends up becoming a programming language"
Now, if you've dived into Spring, you know this is very much true. Inevitably you'll find yourself looking up documentation trying to figure out what XML to write, where to write it and in which order. There's a trend towards depending on intelligent IDE's in order to conquer this type of complexity, but honestly that feels more like treating the symptom rather than fixing the actual problem. This goes for annotations too btw. which is often abused as a type-unsafe embedded DSL sneaked in by language designers who gave up on trying to innovate by adding first-class language constructs.

Conclusion
No bashing of framework overuse can be complete, without a reference to the Hammer Story. While I understand that we do need frameworks and they can indeed help us solve many problems faster and better, Spring is one of those I just can't recommend. Perhaps it's just me and my interpretation of KISS, but since a picture says a thousands words let me end with one.




So if you're one of those who heard about Ioc and DI, but haven't quite made the jump yet, I urge you to try an alternative to Spring, one that does indeed reveal up front how deep the rabbit hole goes. Google's Guice is a good candidate, and it's a testament to its simplicity that it has been ported to other corners of Java i.e. Android.

Update: It seems even Maven is now using Guice.

Update: I had no idea that jotting down my experiences and associated feelings about Spring would cause such controversy. It's clear that Spring is working fine for many and/or is worth the extra complexity. For the record, I don't hate Spring but just find that perhaps we should question whether it's really needed before pulling in dependencies from left and right.

So take this for what it is; a developer questioning whether we can't solve our problems in more elegant and lean ways than what the Spring stack has to offer. I think that often we can. Although at the concrete level I primarily address Spring IoC/DI above, the mere vastness of Spring makes it impossible to go into every aspect even if I had the knowledge to do so. "Pick and choose what you need" is a valid argument of course, but for now I remain unconvinced. Try to imagine the state of your applications dependencies a few years from now. Or try to imagine adding a new green developer to your team and how hard it will be for him to become productive.

The one mantra that truly never failed me is to Keep It Simple Stupid.


Saturday, March 27, 2010

Android and task killers: Don't

There's an awful lot of misconceptions regarding Android and multitasking out there. When you read help forums and the issue of performance tweaking comes up, a very popular answer is to use a task killer to close unwanted apps. Even venerable tech people like TWiT's Leo Laporte appears to have acquired this habit. I reckon that these people have no idea how Android actually works and/or are making erroneous assumptions pulled over from the world of traditional desktop computing. In the best case, nothing happens when you kill an application except you spend time manually doing something that would otherwise have been done for you automatically at a later time. Worst case, you crash an application or get up too late tomorrow because your alarm didn't go off.

How Android does things
At an architectural level, applications running on Android are actually not supposed to halt its process in the traditional sense as we are used to from most desktop operating systems. When you switch to another application on Android, or use the back button, the previous application actually remains in memory but is just no longer active (though it's background services may be). It's up to the application and its author to play nicely in this environment. The vast majority of applications have no trouble doing so.

Only very few applications are so performance demanding, that they introduce a distinct exit button. This can be seen i.e. in the GPS navigation software CoPilot which engages many services and sensors on the phone, and is assuming that even if you require the use of another application (i.e. get a call), the navigation software should keep guiding you on your way. However, this exit button might as well be called "stop navigation services" but that would probably just confuse.



Why Android does it this way
At the usability level, I suspect Google liked being able to combine Cancel, Back and Exit into one physical button. To most people, the difference comes down to some fairly narrow semantics. Apple of course gets around this simply by not allowing multitasking altogether, probably driven by the desire to only have one button! At a more technical level, realize that DRAM memory cells in computers and smart-phones costs just as much in power/battery to keep alive, regardless of whether these cells are used or not. So in the world of Android, applications which you've used are considered likely candidates for use again later and hence, stays dormant in RAM. The Android operating system will manage these and in the case of low memory, will suspend and free up RAM for other purposes. Think of it this way, it's cheaper/faster to keep the application idle in fast RAM and just move a memory pointer to it when you want to use it again, than it is to load the whole application from scratch again from slow flash.

So why do people use task killers?
Apart from wrong assumptions that things works as on a PC, I suspect using too many applications (or rather, too many busy background services) and perhaps witnessing a small lag when Android is freeing memory, will get people to hunt for ways to shut down applications. A smart-phone does not have the same abundance of resources, so one must be careful when specifying settings for various synchronization services. So instead of killing an application, say i.e. the popular News Room app, go into the preferences and disable or tweak the background update service instead.

Conclusion
On a modern Android smart-phone, I have yet to see a real need for a task killer apart from shutting down Android Marked when changing carrier with Marked Enabler, but that's not performance related. And the few times I do need that, it's sufficient to do this using the stock Android option you can find by exploring Settings -> Applications -> Manage Applications, pick application and click "Force stop".



On my Nexus One here, after a day of using a bunch of applications I now have 26 running processes in 338MB of RAM, but still 48MB free. In essence, all the applications I use are loaded in RAM and ready for me to use - just as Google intended.

UPDATE:
Dianne Hackborn, a Google software engineer on the Android team explains it in detail here.

Monday, January 4, 2010

Android cubicle figure

So my girlfriend, who is very artistic, has been doing some special clay modeling lately. Since I'm the kind of guy who likes to have lots of geek cubicle stuff (even if I do not work in a cubicle), what better to ask for than an Android figure. And lo and behold, this time I got what I asked for... hope this is a good indicator for the new year.



Cute eh?