Re: Bloated software JDK 1.2

Andreas Krall <andi@complang.tuwien.ac.at> wrote
> We nearly finished the porting of the CACAO JVM from JDK 1.0.2 to JDK
> 1.2. CACAO loads the transitive closure of all referenced classes
> (which gives more room for optimizations if no dynamic class loading
> is used like class hierarchy analysis, elimination of sychronization
> for single threaded programs, more efficient run time type checking,
> ...). This scheme worked very well for the JDK library 1.0, but gives
> unnecessary high load times for JDK 1.2. We evaluated a small java
> program which reads a text file and transposes the lines (write lines
> in columns). The transitive closure of referenced classes was 78 in
> JDK 1.0 versus 614 in 1.2, 18 classes have been initialized at run
> time with JDK 1.0, 70 needed initialization in JDK 1.2. So I have two
> questions:


I had a similiar problem with Ghost (my PalmPilot virtual machine I
wrote a couple years ago) except I was dealing with 1.1, which was
pretty bloated at the time. 1.2 just makes the problem worse, mainly
b/c they added a bunch of new stuff then add API directly into Object,
Class, System to access it.


> 1) How can we force SUN to write leaner libraries.


What is the questions here: (1) How do we force Sun to implement their
legacy libraries efficiently or (2) how do we get Sun to redesign
their libraries to be more scalable without so many cyclic
dependencies? I don't think (1) or (2) are possible. They are running
into walls with what they currently have as they are trying to "scale
down" to smaller devices. Like that is going to be easy. This means we
will probably wind up with incompatable subsets eventually, no matter
how hard Sun thinks they are going to try. I'm ready to "fork" new
libraries all together just to suit the needs of my research. But then
of coures I will only concentrate on things that I think are important
(data structures, streams, systems levels stuff). But I think this
should be done with language changes anyways (fix some problems in the
language, create a better core API, if you are going to break legacy
code, you might as well go all the way!).


> 2) How are the efforts going on of developing open source Java libraries.


Well, I think Classpath is not around anymore. Their is Ninja RMI
which might be more scalable (in that I mean scalable down). Probably
this isn't the right newsgroup to get complete information, but I
don't really know what is the "right" newsgroup since the Java groups
are just a bunch of noise most of the time (though their are some
really sophisticated posters). This is really a API
design/implementation question that can't really be fixed through the
compiler (the compiler can only do so many hacks to fix bad design).


Sean

Return to the comp.compilers page.
Search the comp.compilers archives again.