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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) > IBM Java technology centre, UK. >
