harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodrigo Kumpera <kump...@gmail.com>
Subject Re: Bootstrapping the classlibrary builds
Date Wed, 28 Dec 2005 21:35:01 GMT
Just for curiosity I've written a small program that enumerate all
graph cycles of packages dependencies in Java 1.4 (counting only
fields, methods and super types). This shows that for most packages
this won't be an issue and a packaging that have no cyclic dependencis
is possible.

Given the criteria that dependencies are: fields, super class,
interfaces and method return/exception/parameters, one could have the
following bundles:

[java.rmi, java.rmi.registry]
[java.io, java.lang, java.lang.ref, java.lang.reflect, java.net,
java.nio.channels, java.nio.channels.spi, java.nio.charset,
java.nio.charset.spi, java.security, java.security.cert,
java.security.interfaces, java.security.spec, java.text, java.util,
java.util.jar, javax.security.auth.x500]
[javax.imageio, javax.imageio.event, javax.imageio.metadata, javax.imageio.spi]
[javax.print, javax.print.event]
[javax.sound.midi, javax.sound.midi.spi]
[javax.sound.sampled, javax.sound.sampled.spi]
[java.awt, java.awt.dnd, java.awt.dnd.peer, java.awt.event,
java.awt.font, java.awt.geom, java.awt.im, java.awt.image,
java.awt.image.renderable, java.awt.peer, java.beans,
java.beans.beancontext, javax.accessibility, javax.swing,
javax.swing.border, javax.swing.colorchooser, javax.swing.event,
javax.swing.filechooser, javax.swing.plaf, javax.swing.plaf.basic,
javax.swing.table, javax.swing.text, javax.swing.tree,

>From that we can see that most of the GUI stuff should live in the
same package and the minimum set of classes for java.lang is not that


On 12/28/05, Geir Magnusson Jr <geir@4quarters.com> wrote:
> Geir Magnusson Jr wrote:
> >
> >
> > Tim Ellison wrote:
> >
> >> Geir Magnusson Jr wrote:
> >>
> >>> Tim Ellison wrote:
> >>>
> >>>> Sure, if you don't want the runtime effects of OSGi then you have
> >>>> flexibility to package the classes into any shape, including an rt.jar.
> >>>> However, if we want to support runtime modularity including component
> >>>> versioning etc. then we will have to have a number of discrete bundles.
> >>>> If OSGi has the ability to put multiple bundles into a single JAR ...
> >>>
> >>>
> >>> I thnk you are missing my point.  Sorry.  What I'm saying/asking is
> >>> about OSGi being one [of many possible] delivery "packagings" of the
> >>> class libraries.
> >>
> >>
> >>
> >> Can you think of any other runtime modularity systems that we should
> >> consider supporting?
> >
> >
> > Sadly "rt.jar" because I hope that other VMs will support our VM/lib
> > interface, and thus our classlib, and manybe not yet do OSGi.
> >
> Clearly I didn't read Tim's question.  Or if I did, I didn't answer it.
>          I don't consider rt.jar a runtime modularity system.  I was
> just thinking of packagings of the library...
> geir

View raw message