harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: Harmonizing on modularity
Date Mon, 23 May 2005 07:52:49 GMT
Hi Renaud,

Renaud BECHADE wrote:
> >I think this discussion soon gets into a java language/system debate,
> >because one could argue why we need to do this tight bundling between
> >the bunch of classes in rt.jar and the vm version. For instance: Why do
> >I have to wait for JVM 6 to fix that bug in Swing, which I need now in
> >my implementation. On the other hand this "expected behavior" is what
> >makes Java very appealing to integrators. ....
> You are kind of pinpointing subtle incompatibilities that /will/ exist and
> require some packaging effort to get users well... use the VM with ergonomic
> perception ("it just works"). If we consider an OS parabola, this is just
> like FreeBSD vs. Linux: both are POSIX and you should not patch code to have
> it run on the other (you can even run Linux ELF code on FreeBSD), but in
> practice some adaptations are required (for instance on my machines the
> Sun-Linux-JDK crashes with a great facility...). Hence FreeBSD has its own
> ports system.

Sure these are minor issues. But on the other hand Java is more than an
operating system. In current operating systems, the developer works with
3rd party libs most of the time. The only direct access to posix stuff
is through core libraries which don't change much. The java runtime
packages many things - from java.lang.String to Swing to Xalan and
Xerces. So I wouldn't say that rt.jar makes the java runtime - rt.jar is
just a packaging model suitable to Sun. One could take other directions
towards that. But to remain copatible (and thus be competitive) one has
to make sure that it works like in rt.jar. Java's way of binary
compatibility makes this easier than it is in C/C++ for instance.

-- Jakob

View raw message