harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Bootstrapping the classlibrary builds
Date Thu, 29 Dec 2005 11:09:27 GMT
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