As Sun and IBM haggle over the terms of open-sourcing Java, I think it's important to note: if they're trying to jumpstart more widespread development of Java applications on the server, they are barking up the wrong tree.
The reason is simple -
Python. The scripting language is already in widespread use, is object-oriented, is proven to scale moderately well (Marc Andreessen's Opsware wrote the entirety of the first version of their product in it), and is more friendly to the realities of most Linux deployments than Java - that is, it can run fine on cheap hardware with a finite amount of RAM.
Over breakfast this morning, Andreessen pretty much summed up what I'd been thinking over the past few days. He talked about how Linux had usurped Unix workstations as the developer desktop, and how developers started prototyping in Python and Perl. "And they get it done in a week, and it works...and they say, 'Why do we need to move this over to something else, exactly?'"
Java (specifically J2EE) is good at things like dealing with large number of transactions, dealing with application state, and stuff like that. But, a significant majority of applications on the Web don't necessarily generate enough of a transaction load to justify the penalties you have to pay with Java - a big memory footprint, more complicated software configuration issues, and (let's face it) somewhat more complicated than a scripting language. Java carries a lot of baggage with it to make the bytecode compiler happy that "agile" languages like Python and Perl (especially Perl) don't worry about. If they *really* need performance, they'll write it in what Linux developers invariably resort to for such a task: C.
That doesn't mean that there isn't a place for Java in the world of Linux developers. It just means that place is a little tighter than the Java-ites might be accustomed to. Without a real niche in rapid prototyping, and without a real performance advantage, Java is sort of a happy medium - or an unhappy one, depending on how you look at it. Scripters will turn to Java reluctantly when they hit the top end of performance for things like database calls, because Java is at least less crufty than C. Faint praise, for sure.
This is one of the reasons that people are excited about
Groovy. Groovy's proponents claim that it , like Python, is an "agile" language. It seems suited to rapid prototyping, and since it's built specifically for the Java Virtual Machine, there's no need to rebuild applications in Java to make them scale better later.
But for people to prototype on top of the JVM, the JVM has to be on their machine. Thus the desire to get Java open-sourced so it ends up on Linux distributions.
There's just one problem: why would anybody pick an untested language on a relatively memory-heavy virtual machine to prototype on when they can just pop out Python bits that run without one? Especially when they can get by pretty much without the JVM in the first place?
Well, there are those things that you get from Java - application state, database connection pooling, lots of messaging and transactional support - that you don't get from Python. But the thing is, you don't
have to saddle yourself with developing the whole application in Java just to get those things. And, no matter how good Groovy is, I doubt anybody is going to convince Python, Perl and Ruby developers that life is all goodness and light over on the JVM, and they should just take the red pill and get it over with.
The answer for Java is not
just to take it open source. The answer is also to show open-source developers that Java plays nice with their favorite tools.
One place where Java can get immediate traction is on the desktop. Right now, desktop development on Linux is in the Land of C: while Gnome's got some scripting support, it's still not exactly what desktop developers on other platforms are used to. And Java 2 Standard Edition fully implemented on Linux would mean that tools written elsewhere would be all set to rock and roll on Linux. But Java could also act as a front-end builder for scripted components.
But for server applications, the best thing that the Java community can do to win the hearts and minds of open source developers is to expose Java to their existing tools.
And guess what? That means contributing to Python.
That's because the most obvious routes to integration between Python and Java--like SOAP, for example--aren't fully cooked yet in Python. ( SOAP::Lite for Perl is most of the way there, so Perl is less of a concern.) The
Java/Python Interface (JPI) was another potential way of wiring these two worlds up, but the project seems to have gone dark.
Regardless of what's out there in bits and pieces now, if there was some good, open-source, standardized reference implementation of a means for Python to invoke the Goodness of Java components without actually having to recode in Java, there might be a whole lot more reason for the open source community to embrace Java.
So, Groovy is a great first step. But for Java to really get past the awkward pause in its relationship with open source developers, those keeping the Java flame have to get over themselves and the whole "not invented here" mindset that has locked them in thus far. Architectural purity is great. But pragmatism is better.
Subscribe to Open Source Magazine Email News Alerts
Subscribe via RSS
