Comments on: Heavyweight Bout: Jobs vs Java http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/ Sat, 05 Jul 2008 08:27:34 +0000 http://wordpress.org/?v=2.3.3 By: The Cave » Blog Archive » Java: Go Back To Your Roots http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-293 The Cave » Blog Archive » Java: Go Back To Your Roots Sun, 18 Feb 2007 12:54:28 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-293 [...] 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? [...] […] 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? […]

]]> By: Pragmatic Dictator » Blog Archive » Ignoring Java’s Roots Again http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-244 Pragmatic Dictator » Blog Archive » Ignoring Java’s Roots Again Wed, 07 Feb 2007 15:22:25 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-244 [...] 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. [...] […] 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. […]

]]> By: Chris Custine http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-204 Chris Custine Sun, 21 Jan 2007 20:00:40 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-204 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. 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.

]]> By: Dan Creswell http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-203 Dan Creswell Sun, 21 Jan 2007 18:38:05 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-203 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. 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.

]]> By: Alex Blewitt http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-202 Alex Blewitt Sun, 21 Jan 2007 18:25:23 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-202 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. 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.

]]> By: Dan Creswell http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-201 Dan Creswell Sun, 21 Jan 2007 17:57:05 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-201 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. 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.

]]> By: Curt Cox http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-200 Curt Cox Sun, 21 Jan 2007 17:53:43 +0000 http://www.dancres.org/blitzblog/2007/01/21/heavyweight-bout-jobs-vs-java/#comment-200 Isn't this what all of the new modularity JSRs are supposed to address? Isn’t this what all of the new modularity JSRs are supposed to address?

]]>