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 Thu, 29 Dec 2005 13:57:54 GMT
One thing is not clear to me with this modularity thing is where the
SPIs/AWT Peers fit in. Will the default implementation live within the
bundle that containts the API or on it own?

BTW, as these are interfaces published by Sun/JCP, we could use classpath's.

Rodrigo

On 12/29/05, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Good stuff Rodrigo.
>
> We did a similar experiment, then went through the list and made some
> 'gut feel' groupings/splits of these dependencies.
>
> i.e., it probably wouldn't be useful to have multiple components for,
> say, JNDI (would somebody really want an alternative implementation of
> javax.naming.event independently of the remainder of JNDI ?)  and it
> probably would be helpful to split apart, say, Swing and AWT into
> separate components and manage the dependencies between them.
>
> The set of components we ended up with was proposed a while ago on the
> wiki[1], but it's certainly open for debate.
>
> [1] http://wiki.apache.org/harmony/ClassLibrary
>
> Regards,
> Tim
>
>
> Rodrigo Kumpera wrote:
> > 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.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
> >>
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>

Mime
View raw message