Moment of Reflection

A little more than 20 years ago, I was getting my first taste of programming on my brother's Commodore 64. The only information available to me were a few books my brother had that contained code listings, written in BASIC, for a bunch of computer games. It was all the information I had available to me at the time. I must've read and re-read those books a million times...

About 15 years ago, I rediscovered the joy of programming and began looking at, and buying (when I could afford them), whatever books and magazines I could get my hands on at the local computer store that covered computer programming. Aside from the library, I didn't have many other avenues for information on the field of software development. And since going to college was a decidedly expense avenue for me at the time, these were my only options for learning.

Today -- after upgrading my Safari Books account a few weeks ago -- I now have immediate access to every book currently in their library, which has a total count of books somewhere in the 8,000 range, last I checked, and includes just about every book on software development that I might ever want to read.

And even when I can't find what I'm looking for on there, I have Amazon.com as backup for cases where the book I want isn't available via my Safari account.

And on top of that I have The Web/Internet, with any answer to just about any question I could think of being a mere Google away...

Technology is so cool sometimes...

Java IDE Performance

An interesting discussion popped up on DZone last week. In a discussion of this link on DZone, the author of the post in question mentioned the poor performance of most Java IDEs, and I think he has a valid gripe: Most (if not all) Java IDEs are performance hogs, sucking up a lot of CPU and RAM.

Before anyone gets all hot under the collar about their favorite IDE and starts flaming me, let me be clear: All of the major players in the Java IDE world -- Eclipse, Netbeans, and IntelliJ IDEA -- are fantastic pieces of software from a feature standpoint and I've used just about every one of them at one time or another, with Eclipse being the mainstay for my day-to-day work currently. Given the current state of the art in Java IDEs compared to my early days in Java development (late '90s) I will take what we have now without question.

But I don't think any Java developer out there can say that these IDEs don't suck up system resources like crazy. Regardless of the hardware I've run on, I still run into long load times, laggy auto-complete when I type, and just general slowness...to say nothing of memory consumption. And the larger a project gets, the worse the situation becomes.

As far as I can tell, performance is still an issue for most of the major IDEs in the Java development world.

Now, maybe it's not a terribly big deal for a lot of Java developers out there -- I don't see a lot of discussion about IDE performance in the Java community these days. Perhaps everyone's just learned to live with it. Or perhaps it's just an issue for those of us in software development that don't have the luxury of monster-sized Quad-Core systems with 8+ Gigs of RAM, and sporting a Solid-State Disk for maximum performance. In other words: All us lowly enterprise developers who are at the mercy of our IT departments.

At any rate, even if you're sporting the best development system money has to offer, odds are you've had to deal with IDE performance at some point or another when doing Java development. The question is what's causing all of our favorite IDEs to perform so poorly in terms of both speed and memory footprint?

A few thoughts come to mind...

Java
Of course, we can't have a discussion of performance without thinking of the underlying VM upon which the major IDEs run. Despite the heretical nature of the "Java is slow" argument within the Java community, this is certainly a valid argument to make here since all of the major players in this space are written in Java, as far as I can tell. We could spend days arguing over whether Java really is slow compared to native code (and there's been plenty of arguments about it since Java's inception), but the fact is that you are running bytecode in a VM, which no matter how you slice it is going to be slower than native code in a lot of cases. And given the relative size and complexity of the pieces of software in question, I think it's a valid point to consider when it comes to IDE performance.

Of course, a question I have here is this: Why aren't there any popular natively-compiled IDEs for Java? I know it flies in the face of Java's overarching premise of being platform-neutral, but wouldn't having some form of high-performance, compiled IDE be useful to developers? Couldn't the free software or open-source communities get something going along these lines, creating an open-source, natively-compiled Java IDE that could be ported to the various platforms?

Thinking about this further, Eclipse itself leverages the widget set of the underlying OS via SWT, which means it's effectively leveraging native code to improve performance already (and this was in fact a major motivation for SWT's creation to begin with), so why not just take it a step further and make a native-code IDE?

The closest thing I've ever seen to a resource-friendly IDE that wasn't written in Java is the Java Development Environment for Emacs (JDEE) which, despite being a nice and speedy environment to work in, is still somewhat lacking in its feature set and is a bit hard to just jump into for most developers -- especially when you need to learn Emacs in order to use it effectively.

Anyone that's familiar with Emacs, however, will point out something interesting here: The JDEE isn't a natively-compiled IDE either -- it's written in elisp -- which actually raises more questions about the possibility of whether the Java platform itself really is a performance problem or not. Since elisp is interpreted code, yet the JDEE performs exceptionally well, perhaps the whole interpreted code thing might not be such a big deal after all.

Architecture
This, of course, brings us to the subject of the underlying architecture upon which these IDEs are built. It is certainly possible that the architecture of the IDEs themselves are just lacking, making them inherently slow. And with the growing list of languages and technologies that many of them try to support, it makes it more likely that the underlying architectures of the various IDEs can only handle so many things before they begin to buckle under the weight of it all.

Based on my own look into the Eclipse RCP architecture, I'd have to say that this is certainly a possibility. It's designed to be as generic as possible and support a wide range of possible uses, and as a result may not be perfectly tuned for software development the way it once was. I haven't looked at the Netbeans architecture, and can only guess that it would face a similar situation as Eclipse in terms of design.

IntelliJ IDEA may be the one with the advantage in this regard as I don't see anything to indicate that it's tried to be anything more than a feature-filled IDE. But nevertheless, it's still trying to support a lot of uses, which can affect performance.

I'd also like to think that since most of the major Java IDEs have been around for a decade or more, they'd have at least some focus on performance in their respective architectures for at least part of that time and have kept that at the forefront of all of their design decisions. Still, there is the possibility (at least in the case of Eclipse and Netbeans) that they've overextended by trying to be too generic.

Java Project Complexity
Another possibility -- and one that I think warrants some attention -- is the very nature of most Java projects and their sometimes dizzying amount of complexity and the array of tools that can be required to easily navigate and maintain such projects.

When a "simple" web project is using the likes of Spring, with Hibernate linking the database, along with any number of JSPs, or perhaps even some GWT or other AJAX-like technology in the web pages, all tied together by a multitude of libraries, XML files, property files, i18n support, and various bits of technology, it's no wonder the IDE might start having spasms. There's a lot of parsing that has to go on.

Of course, this touches on a bit of the other two points -- if the IDEs are designed and architected right then they should be able to handle this sort of thing. But since these days a lot of these IDEs are not necessarily optimized for just one type of project, or even one type of language for that matter, this might not be something that's easily addressed.

Maybe the IDEs are a little over-generalized to support too many things at once...?

Etc...
I'm sure there's something else out there that I'm missing, so feel free to jump in and add in your own theories.

I don't really have any solutions here, just some thoughts about the current state of Java IDEs. I think all the development platforms we have now are great in their own ways, and give us plenty of options.

But I can't help but feel that maybe we've all just settled for what works, without thinking about if we could be getting more out of our IDEs in terms of performance. Have we just accepted that things are as good as they're going to get?

I actually managed to use the JDEE on a project a few years ago and found it immensely more productive compared to Eclipse -- aside from the production boost that I got just from using Emacs (which I do miss these days), the performance of the environment in general was considerably faster than Eclipse, and I felt that I was able to be a lot more productive on that project than had I been using one of the other popular IDEs.

Unfortunately, I had to abandon the environment when I switched to a web application project -- the JDEE doesn't do web app development very well from what I've seen. Nevertheless, I still miss the amount of productivity I had.

I guess the question is...does anyone else?

Maybe this is a case where a developer who hasn't explored Java outside of the popular IDEs, who has spent most (or all) of a career working with the likes of Eclipse and such, just doesn't know any better and thinks that Java development is as fast as it can be based on those environments -- They basically don't know what they don't know.

At any rate, I think this are all valid questions we should be asking: Can Java IDEs get any better on the performance side? Should we accept the current status quo? Would we be better served by a native IDE client?

I'm curious to know what other developers think about this.

A Long Slumber

The project I mentioned in a previous post a few months back -- the one where my team and I were faced with a complete rewrite as a result of some very bad decisions made long ago -- is going into hibernation as it were: It's being put on hold for at least a few years.

I'm not privy to the details, but as I understand the group we were developing the application for is going to undergo significant changes to their business processes -- not so much a reorganization as a complete reevaluation of how the group actually operates. This is part of a larger effort that's been underway for a while now to streamline the business as a whole (and began well before anyone was thinking about the economy), so the powers-that-be believe it doesn't make a whole lot of sense to try to continue to develop a new system while the business requirements will be changing not just beneath us but the end users as well.

The bright side for the team is that we won't be getting pink slips: There's still plenty of work to be done elsewhere in the organization. Not a lot of people out there can say that, so I'm at least thankful in that regard. Of course, there's no guarantee my teammates and I will all be working on the same project, either (it's highly unlikely, as a matter of fact), but we'll still be in the office together...hopefully still picking each others' brains for vital info.

Another plus is that it'll give whomever picks this project back up ample time to reevaluate the choices we were making from a technology standpoint...as we ended up discovering another very bad decision made by our predecessors that trumped all the other bad decisions...

I already noted in the aforementioned post about our investigating Eclipse RCP, which we began to move forward with once we realized it was suited to our needs and would allow for a faster turnaround than the poorly designed, scratch-built system we had up to that point. Unfortunately (or fortunately depending on your point-of-view...), it came to the team's attention not long after moving forward with Eclipse RCP that due to choices that had been made in business infrastructure long ago we needed to provide a web application and not a desktop solution. This became pretty obvious to the team following a meeting with the infrastructure guys (and should have been obvious to those same guys that started work on this project years ago). By trying to create a desktop app we were effectively doing the programmer's equivalent of fitting a square peg into a round whole -- the infrastructure and policy decisions that were already in place screamed "Web Application" all over the place. And yet here we were trying to cobble together a desktop system.

Sometimes I wonder about the sanity of my colleagues in this industry...hell it's a wonder I'm not insane yet...

So another change in direction was needed...this time to a web application. Fortunately everyone involved in the project had web development experience and we had no trouble getting up and running again with a web app. In a lot of ways this made our work vastly easier, since there wasn't a steep learning curve that everyone had to overcome (as we had with Eclipse RCP).

The downside was that we had little time to evaluate options when moving to a web application -- we were forced to chose the path of least resistance and go with what everyone (or the majority at least) had experience with. In this case it was Spring MVC and Hibernate. Because we had already lost so much time up to that point -- with our evaluation and initial work using Eclipse RCP -- we just didn't have the luxury of check out the options available to us in the web development sphere (and lord knows there's plenty of options out there for web development...).

So at least in this regard the project being put on hold is a good thing: Whomever gets to pick things back up (hopefully one of us will still be involved) can take time to reevaluate the technology choices and will have plenty of opportunity to check out the options available. Heck, in a few years there might be some new super-cool technology that'll be even better than what's available now...who knows...

So, anyway, at this point the project has been shelved until the higher-ups get things in order. My coworkers and I have already started wrapping things up before we get tossed into some other project, which likely won't happen for a few weeks from the looks of it.

So we'll get some time to catch our breath, which is fine by me. All of this course changing, learning new technologies, and moving at breakneck speeds to get the project finished has left me thoroughly exhausted. My brain hurts from all the information I've been trying to cram into my head as quickly as possible over the past few months so it's a bit of a blessing that I'll get some downtime before moving on to the next project.

Of course, it's likely that I'll get to learn something else entirely for my next project as well...so the learning never really stops. That's what I like about software development: Never a dull moment. Well...not too many of them, anyway...

I'm already studying up on a few technologies now: Groovy and Grails in particular. I'll be looking at GWT as well soon, too. I've got a long list of stuff I want to catch up on. Fortunately I'm not in a big hurry to learn it all now.

But more than anything, I think I'll catch up on one thing I know I could use...

Sleep.

Spring Cleaning

OK, maybe more like early summer cleaning...but anyway...

The old blog layout just wasn't doing it for me, so I'm going to be messing around yet again.

I'll have more things to talk about soon as well.

My Growing Interest in Clojure

When I see stuff like this regarding Clojure, my interest continues to grow. 

Like the article says: This is pretty frickin' cool.

Geek Programming Humor

A funny retelling of the history of programming languages.

Clojure hits the 1.0 mark

I'm always exploring the world of alternative programming languages - both on the JVM and off. I might not get as much of an opportunity to put these languages through their paces in my normal day-to-day work (which is predominately Java development), but I like looking at programming from new angles, which learning other languages certainly helps with.

One language that'll definitely get you looking at things from a new angle is Clojure, which just hit 1.0 - Rich Hickey (the creator of Clojure) made the announcement today both in the Clojure Group on Google and on his blog.

Clojure's gotten a lot of buzz from the Lisp community (a good example being this post from lispy's series of Lisp50 notes), and I think even the Java community is starting to take notice as well since it is a JVM-based alternative to Java. Of course, the learning curve is a bit steeper for Clojure than other JVM-based langauges like maybe Groovy, but developers bold enough to learn something like Lisp will certainly want to give Clojure a try.

I looked at Clojure briefly last year sometime, and after sitting in on a talk given by Stuart Halloway (whose upcoming book on Clojure will probably be the go-to book for new users of the language -- like me -- for the forseeable future) at last year's Northern Virginia Software Simposium I've been eager to give Clojure another spin. Having a 1.0 version to play with makes me more eager than ever to give it another spin.

I hope that we see many good things -- and many new versions (but not too many :-) -- from the Clojure community in future.