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 >
