Steve Jobs had some bad stuff to say about Java and Jonathan Schwarz has responded as part of his most recent interview with Scoble. If you haven’t heard any of this before, get the scoop here.
Now, whether or not you agree with Jobs on his stance in respect of Java and the iPhone, he is right on one thing: Java is getting heavyweight. And it’s not because of the language or even the platform but the way in which it’s all delivered to the desktop, server etc.
It comes as a monolithic package, all or nothing. You can extend it via classpath or whatever as you wish but there’s something deeply wrong with this picture……
And that is the fact that Java is designed to be dynamically extensible not monolithic and static as is the prevailing pattern pursued by Sun’s JDK development team and the world of J2EE. Remember, Java in it’s early days was all about code-downloading and dynamic extension. Yet, all of those leading the Java masses seem to insist on ignoring this fact and continuing to build structures that are perhaps even less dynamic than C++ with shared libraries?
Worse, we’ve tried to fix this sort of thing by adding support for scripting languages etc “because Java isn’t dynamic”. And we’ve got all these static compile time constructs we’ve added when perhaps a better solution would be better support at runtime to trap and fix these problems.
We’ve been dropping the ball for a long time - we’ve ignored a core construct of Java and now we’re complaining about the consequences. To Schwarz, Sun and the Java masses, stop leading Java down the path of static, ever-larger, monolithic bloatware. Go back to Java’s core, fix it and start building again. If you need help with understanding what might need doing, go read this paper then go talk to OSGi and the Jini community.
Entries (RSS)
January 21st, 2007 at 7:53 pm
Isn’t this what all of the new modularity JSRs are supposed to address?
January 21st, 2007 at 7:57 pm
Hi Curt,
I think the modularity JSRs will help a little (though I fear we may get a homebrew solution rather than OSGi) but it doesn’t address the other half of the problem which is the need to revise the classloader model some and start producing tools, frameworks, platforms etc that exploit dynamic class loading more thoroughly.
If you’re particularly interested, I’d suggest you read the paper I mention in the posting and pay particular attention to sections 2.3 and 4.0 which discuss how classloaders are currently serving too many purposes and the problems it can cause.
January 21st, 2007 at 8:25 pm
The problem isn’t going to be solved with either JSR or the OSGi (though clearly one is superior and the other is NIH) but the big problem is that the J2SE install (or whatever it’s called these days) has been bloatware since about Java 1.3. What’s really needed is to split the JVM core from the rest of the packages — much like the Harmony VM from harmony.apache.org — into different bundles which can then have dependencies on each other, and not mandate that it’s an all-or-nothing thing. That way, the VM can evolve at a different speed than the core libraries can, and if the VM can load any class library, this kind of thing becomes irrelevant, because an application can ship the libraries that it both needs and has been tested with.
January 21st, 2007 at 8:38 pm
Hi Alex,
Agreed - something like Perl’s CPAN maybe? What you talk about is exactly the sort of thing I had in mind when I wrote the posting. I have a suspicion that to do it right might mean doing the module thing and addressing the classloader problems but I’d admit to not having thought that through in detail.
January 21st, 2007 at 10:00 pm
I think that OSGi could actually address the JVM as well as application code. Obviously all of it would mean some major changes to the core JVM spec, but that is inevitable if anyone wants to really address classloader deficiencies. I just blogged about re-working the core JVM to be OSGi based here:
http://blog.organicelement.com/2007/01/21/osgi-perfect-for-java-on-the-iphone-steve/
but I didn’t get into great detail. As far as something like CPAN… OSGi has a draft spec for a bundle repository that would allow you to list bundles from a remote repository and select them for download and installation (all at runtime of course) or possibly auto-install bundles (like optional JVM components) upon installation of application code with unsatisfied dependencies. I am not sure about Equinox and Knopflerfish, but the Apache Felix project has an implementation here: http://cwiki.apache.org/FELIX/osgi-bundle-repository-obr.html
I think to some extent that the future of Java almost requires something like this.
February 7th, 2007 at 5:22 pm
[…] Once again, Java was built for this not monolithic, static applications, why is it so hard? Because we’ve not done anything to sort out issues with classloaders and remote code-loading or delivery of classes in .jars in a long, long time. […]
February 18th, 2007 at 2:54 pm
[…] Hmm: And that is the fact that Java is designed to be dynamically extensible not monolithic and static as is the prevailing pattern pursued by Sun’s JDK development team and the world of J2EE. Remember, Java in it’s early days was all about code-downloading and dynamic extension. Yet, all of those leading the Java masses seem to insist on ignoring this fact and continuing to build structures that are perhaps even less dynamic than C++ with shared libraries? […]