Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of kumpera@gmail.com designates
 64.233.162.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z7gzxt3r8CI6ULwXitQDGv75DqNUNgtJ/1Ouyypw5HFtZUalb8dykdZySiJy7d/uSga15WgtYtp2M7yTdiZk57TCZzp3U6bS9mcbGMcgGZcGqPQPrT6LgKOWUR4zfBkSLbcBpTa71t+I/2afD3vxrql8cCkrIKI0yazS8vcG/d8=
Message-ID: <8cca42d80512281335i13836c82o386d714eacc72a40@mail.gmail.com>
Date: Wed, 28 Dec 2005 19:35:01 -0200
From: Rodrigo Kumpera <kumpera@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: Bootstrapping the classlibrary builds
In-Reply-To: <43B2C8DE.1010601@4quarters.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43ABF70E.9040702@gmail.com> <43AF19A1.5050101@gmail.com>
	 <9DDE9268-562C-4C1D-8842-62A4BD2E33E3@4quarters.com>
	 <43B1A564.3060608@gmail.com> <43B1B4C0.3080208@4quarters.com>
	 <43B29FC3.3070108@gmail.com> <43B2A48C.6010703@4quarters.com>
	 <43B2AA60.8010704@gmail.com> <43B2B071.4070007@4quarters.com>
	 <43B2C8DE.1010601@4quarters.com>

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.applet]
[java.awt.color]
[java.awt.datatransfer]
[java.awt.im.spi]
[java.awt.print]
[java.math]
[java.nio]
[java.rmi, java.rmi.registry]
[java.rmi.activation]
[java.rmi.dgc]
[java.rmi.server]
[java.security.acl]
[java.sql]
[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]
[java.util.logging]
[java.util.prefs]
[java.util.regex]
[java.util.zip]
[javax.crypto]
[javax.crypto.interfaces]
[javax.crypto.spec]
[javax.imageio, javax.imageio.event, javax.imageio.metadata, javax.imageio.=
spi]
[javax.imageio.plugins.jpeg]
[javax.imageio.stream]
[javax.naming]
[javax.naming.directory]
[javax.naming.event]
[javax.naming.ldap]
[javax.naming.spi]
[javax.net]
[javax.net.ssl]
[javax.print, javax.print.event]
[javax.print.attribute]
[javax.print.attribute.standard]
[javax.rmi]
[javax.rmi.CORBA]
[javax.security.auth]
[javax.security.auth.callback]
[javax.security.auth.kerberos]
[javax.security.auth.login]
[javax.security.auth.spi]
[javax.security.cert]
[javax.sound.midi, javax.sound.midi.spi]
[javax.sound.sampled, javax.sound.sampled.spi]
[javax.sql]
[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,
javax.swing.undo]
[javax.swing.plaf.metal]
[javax.swing.plaf.multi]
[javax.swing.text.html]
[javax.swing.text.html.parser]
[javax.swing.text.rtf]
[javax.transaction]
[javax.transaction.xa]
[javax.xml.parsers]
[javax.xml.transform]
[javax.xml.transform.dom]
[javax.xml.transform.sax]
[javax.xml.transform.stream]

>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
huge.

Rodrigo

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.j=
ar.
> >>>> However, if we want to support runtime modularity including componen=
t
> >>>> versioning etc. then we will have to have a number of discrete bundl=
es.
> >>>> 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
>