You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2005/12/23 14:09:34 UTC
Bootstrapping the classlibrary builds
As a follow-up to the recent discussion with Geir about repository
layout, I've been thinking a bit more about the componentization of the
class library, and in particular about how day-to-day development would
progress.
The 'interesting' attribute of the components is that there are circular
dependencies between some of them. For example, SECURITY depends upon
LUNI, and vice versa. I briefly discussed some options for resolving
the circularities earlier, but the point is that this is a bootstrapping
issue -- once we have implementations of SECURITY and LUNI then each can
be built independently against the compiled version of the others.
So I propose that we make a clear distinction between the initial
bootstrap build, and the subsequent component builds. The build.xml
that exists today (.../classlib/trunk/make/build.xml) invokes a 'global'
i.e. cross-component compilation to avoid circularities. The results
are put into .../trunk/deploy/jre/lib/boot.
I say we keep this build.xml as the bootstrap build, then create build
scripts within each component that build only that component against the
jre/lib/boot jars thereby giving localized builds. We can also write
the component build scripts to use the deployed JRE to run ant and the
compiler to be self-hosting!
Unless anyone objects or has a better idea I'll do the minor
restructuring of classlib required (likely next week now).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Dalibor Topic <ro...@kaffe.org>.
Rodrigo Kumpera wrote:
> 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?
I guess that depends upon the strategy chosen for the bundle, and the
number of implementations for each bundle.
cheers,
dalibor topic
SPIs and components (was: Re: Bootstrapping the classlibrary builds)
Posted by Tim Ellison <t....@gmail.com>.
Rodrigo Kumpera wrote:
> 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?
The short answer is that we get to choose. In either case, the SPIs
would be exported from the component so that others can extend it
whether they are playing the component game or not.
> BTW, as these are interfaces published by Sun/JCP, we could use classpath's.
Indeed, people can choose any compliant provider implementation, open or
not.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Rodrigo Kumpera <ku...@gmail.com>.
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....@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 <ge...@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.
>
Re: Bootstrapping the classlibrary builds
Posted by Rodrigo Kumpera <ku...@gmail.com>.
The source is attached. I've done some changes to compute
dependencies. So the result is a bit diferent.
On 12/28/05, Stefano Mazzocchi <st...@apache.org> wrote:
> 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.
>
> Nice! awesome job!
>
> (is the source-code of this program available?)
>
> --
> Stefano.
>
>
Re: Bootstrapping the classlibrary builds
Posted by Tim Ellison <t....@gmail.com>.
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 <ge...@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.
Re: Bootstrapping the classlibrary builds
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Nice! awesome job!
(is the source-code of this program available?)
--
Stefano.
Re: Bootstrapping the classlibrary builds
Posted by Rodrigo Kumpera <ku...@gmail.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 <ge...@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
>
Re: Bootstrapping the classlibrary builds
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Dec 29, 2005, at 6:00 AM, Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Geir Magnusson Jr wrote:
>>> Tim Ellison wrote:
>>>> 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...
>
> Right, if we don't consider runtime modularity support then we can
> package it up in to any shape and a monolith rt.jar would be just
> fine.
>
> Since OSGi is the main game in town at the moment for runtime
> support, I
> believe it makes sense to maintain the OSGi metadata (JAR manifests)
> alongside the components in the repository.
Sure - there's absolutely no harm there.
> Besides ensuring we don't
> unwittingly break the runtime model it allows us to break up the
> classlib development into manageable pieces with well-defined
> boundaries
> between them.
>
Makes sense, as long as it doesn't create really awful problems,
which it doesn't seem to.
> If JSR277 implies something different then we'll consider it at the
> time.
It probably will...
geir
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Bootstrapping the classlibrary builds
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>> 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...
Right, if we don't consider runtime modularity support then we can
package it up in to any shape and a monolith rt.jar would be just fine.
Since OSGi is the main game in town at the moment for runtime support, I
believe it makes sense to maintain the OSGi metadata (JAR manifests)
alongside the components in the repository. Besides ensuring we don't
unwittingly break the runtime model it allows us to break up the
classlib development into manageable pieces with well-defined boundaries
between them.
If JSR277 implies something different then we'll consider it at the time.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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
Re: Bootstrapping the classlibrary builds
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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.
>
>
>>So yes, I think that we definitely want to do OSGi as our default
>>packaging for our full implementation of J2SE, but that doesn't seem to
>>have to dictate on how we work with the code as class library
>>developers, does it?
>
>
> Life is easier if we layout the source code in modules too (rather than,
> say, mash it all together and make the modularity a package-time event)
> because we can get development time support from OSGi-aware tools like
> PDE that will 'smack' you for references outside the module definitions,
> compilation against the target directory, etc.
What is "PDE"?
>
>
>>We have the circular dep issue to tangle with
>>(which seems to go away if we do a bootstrap uber-compile/uber-jar) and
>>we can also offer other packagings of the classlibrary to work with
>>systems that don't do OSGi support.
>
>
> Agreed.
>
>
>>And we don't know how 277 is going to turn out - we hope for OSGi-ish,
>>but one never knows...
>
>
> Makes it kinda difficult to support then ;-) I say we cross that bridge
> when we get to it.
Right - the point is to not be exclusively OSGi based, because there are
reasonable motivations for making a rt.jar possible...
geir
>
> Regards,
> Tim
>
Re: Bootstrapping the classlibrary builds
Posted by Tim Ellison <t....@gmail.com>.
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?
> So yes, I think that we definitely want to do OSGi as our default
> packaging for our full implementation of J2SE, but that doesn't seem to
> have to dictate on how we work with the code as class library
> developers, does it?
Life is easier if we layout the source code in modules too (rather than,
say, mash it all together and make the modularity a package-time event)
because we can get development time support from OSGi-aware tools like
PDE that will 'smack' you for references outside the module definitions,
compilation against the target directory, etc.
> We have the circular dep issue to tangle with
> (which seems to go away if we do a bootstrap uber-compile/uber-jar) and
> we can also offer other packagings of the classlibrary to work with
> systems that don't do OSGi support.
Agreed.
> And we don't know how 277 is going to turn out - we hope for OSGi-ish,
> but one never knows...
Makes it kinda difficult to support then ;-) I say we cross that bridge
when we get to it.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>
>>>p.s. It is too bad that the OSGi bundles are so closely tied to the
>>>physical packaging of the code in JAR files -- but I don't see that
>>>changing anytime soon.
>>
>>That doesn't really matter to us, though, does it? Because it's a
>>packaging issue, out of the soup of compiled classes, we can produce a
>>build target that assembles the OSGi bundles. At the same time, we can
>>offer build targets that assemble into other things that people may want
>>(like an monolithic rt.jar).
>
>
> 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.
So yes, I think that we definitely want to do OSGi as our default
packaging for our full implementation of J2SE, but that doesn't seem to
have to dictate on how we work with the code as class library
developers, does it? We have the circular dep issue to tangle with
(which seems to go away if we do a bootstrap uber-compile/uber-jar) and
we can also offer other packagings of the classlibrary to work with
systems that don't do OSGi support.
And we don't know how 277 is going to turn out - we hope for OSGi-ish,
but one never knows...
>
>
>>So - does this mean we can reconsider our current organization strategy
>>of modules in the classlib part of Harmony? IOW, does it continue to
>>make sense to separate them? I think that the answer is still yes (with
>>some reorg like we were talking about last week)...
>
>
> I think the answer is still 'yes' as well -- it gives us the flexibility
> to package either way quite easily. IIRC the reorg is a minor directory
> rearrangement to make it look like the Maven2 standard directory layout,
> agreed?
I defere to you on this - you know what's needed to actually build what
we have at the moment. Does the maven2 standard layout work? what about
our multiple parallel native directories and tests? (I need to go look
back at the layout thread...)
>
>
>>Maybe the solution is to have a two-phase bootstrap compilation process.
>> Have a target that effectively makes rt.jar to avoid the cyclics, and
>>then use that rt.jar to make the modules. Once you have the modules, I
>>assume we can discard the rt.jar thingy. Unless we modify two at the
>>same time, in which case it's an easy fallback to the meta compile?
>
>
> Yes, we agree on the idea of a one-time 'bootstrap' build, which enables
> subsequent 'component' builds against the target.
>
> The bootstrap build can be either a monolith rt.jar, or a script like
> the current global build.xml that packages into the component bundles
> (by reference to a number of patternsets). The advantage of creating
> bundles from the start is that subsequent component builds don't have to
> differentiate between building against an rt.jar or against existing
> bundles.
That works. I don't really care about having an rt.jar - that was just
a mental device for me to explain what I was thinking. Then the
circular deps issue goes away?
>
> The bootstrap build would also require an existing 'javac'
> implementation, whereas subsequent component builds could be
> self-hosting using the Eclipse batch compiler [1]
Cool. I realize I don't know enough about the Eclipse compiler. I
didn't realize it could do partial builds.. :)
>
> [1]
> http://help.eclipse.org/help31/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm
>
> Regards,
> Tim
>
Re: Bootstrapping the classlibrary builds
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
>> p.s. It is too bad that the OSGi bundles are so closely tied to the
>> physical packaging of the code in JAR files -- but I don't see that
>> changing anytime soon.
>
> That doesn't really matter to us, though, does it? Because it's a
> packaging issue, out of the soup of compiled classes, we can produce a
> build target that assembles the OSGi bundles. At the same time, we can
> offer build targets that assemble into other things that people may want
> (like an monolithic rt.jar).
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 ...
> So - does this mean we can reconsider our current organization strategy
> of modules in the classlib part of Harmony? IOW, does it continue to
> make sense to separate them? I think that the answer is still yes (with
> some reorg like we were talking about last week)...
I think the answer is still 'yes' as well -- it gives us the flexibility
to package either way quite easily. IIRC the reorg is a minor directory
rearrangement to make it look like the Maven2 standard directory layout,
agreed?
> Maybe the solution is to have a two-phase bootstrap compilation process.
> Have a target that effectively makes rt.jar to avoid the cyclics, and
> then use that rt.jar to make the modules. Once you have the modules, I
> assume we can discard the rt.jar thingy. Unless we modify two at the
> same time, in which case it's an easy fallback to the meta compile?
Yes, we agree on the idea of a one-time 'bootstrap' build, which enables
subsequent 'component' builds against the target.
The bootstrap build can be either a monolith rt.jar, or a script like
the current global build.xml that packages into the component bundles
(by reference to a number of patternsets). The advantage of creating
bundles from the start is that subsequent component builds don't have to
differentiate between building against an rt.jar or against existing
bundles.
The bootstrap build would also require an existing 'javac'
implementation, whereas subsequent component builds could be
self-hosting using the Eclipse batch compiler [1]
[1]
http://help.eclipse.org/help31/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>
>>On Dec 25, 2005, at 5:13 PM, Tim Ellison wrote:
>>
>>>Stefano Mazzocchi wrote:
>>>
>>>
>>>>Maybe I'm missing something, but if A depends on B and B depends on A,
>>>>isn't the separation between A and B something to reconsider?
>>>
>>>I agree that we should be minimizing these circular dependencies, but if
>>>you make their avoidance a hard rule then you soon end up dragging lots
>>>of code into a single massive-component.
>>
>>Is that really true? The component can be a packaging artifact, can't
>>it? build a pile of class files in the easiest way possible, and then
>>package as you need to...
>
>
> That's what I'm saying really. So consider build-time and runtime
> separately.
>
> At buildtime such cyclical dependencies likely mean that you want to
> build everything together so that all references can be resolved, and
> package them up into separate bundles (=JARs). This means that the unit
> of compilation is a single massive component, and is the approach we
> have got at the moment in the classlib/trunk/make/build.xml.
>
> We should aim to have the components separate at runtime (those
> different bundles) otherwise we would end up back at a monolithic
> rt.jar. Now the rt.jar has some advantages, but if you want the runtime
> modularitity benefits of the OSGi framework then you have to go down the
> path of separate bundle JARs. Minimizing the dependencies between the
> bundles will enhance the benefits of the bundle componentization.
No doubt - but this just is something we have to sell to people later on.
>
> p.s. It is too bad that the OSGi bundles are so closely tied to the
> physical packaging of the code in JAR files -- but I don't see that
> changing anytime soon.
That doesn't really matter to us, though, does it? Because it's a
packaging issue, out of the soup of compiled classes, we can produce a
build target that assembles the OSGi bundles. At the same time, we can
offer build targets that assemble into other things that people may want
(like an monolithic rt.jar).
So - does this mean we can reconsider our current organization strategy
of modules in the classlib part of Harmony? IOW, does it continue to
make sense to separate them? I think that the answer is still yes (with
some reorg like we were talking about last week)...
Maybe the solution is to have a two-phase bootstrap compilation process.
Have a target that effectively makes rt.jar to avoid the cyclics, and
then use that rt.jar to make the modules. Once you have the modules, I
assume we can discard the rt.jar thingy. Unless we modify two at the
same time, in which case it's an easy fallback to the meta compile?
geir
Re: Bootstrapping the classlibrary builds
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> On Dec 25, 2005, at 5:13 PM, Tim Ellison wrote:
>> Stefano Mazzocchi wrote:
>>
>>> Maybe I'm missing something, but if A depends on B and B depends on A,
>>> isn't the separation between A and B something to reconsider?
>>
>> I agree that we should be minimizing these circular dependencies, but if
>> you make their avoidance a hard rule then you soon end up dragging lots
>> of code into a single massive-component.
>
> Is that really true? The component can be a packaging artifact, can't
> it? build a pile of class files in the easiest way possible, and then
> package as you need to...
That's what I'm saying really. So consider build-time and runtime
separately.
At buildtime such cyclical dependencies likely mean that you want to
build everything together so that all references can be resolved, and
package them up into separate bundles (=JARs). This means that the unit
of compilation is a single massive component, and is the approach we
have got at the moment in the classlib/trunk/make/build.xml.
We should aim to have the components separate at runtime (those
different bundles) otherwise we would end up back at a monolithic
rt.jar. Now the rt.jar has some advantages, but if you want the runtime
modularitity benefits of the OSGi framework then you have to go down the
path of separate bundle JARs. Minimizing the dependencies between the
bundles will enhance the benefits of the bundle componentization.
p.s. It is too bad that the OSGi bundles are so closely tied to the
physical packaging of the code in JAR files -- but I don't see that
changing anytime soon.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 25, 2005, at 5:13 PM, Tim Ellison wrote:
> Stefano Mazzocchi wrote:
>> Maybe I'm missing something, but if A depends on B and B depends
>> on A,
>> isn't the separation between A and B something to reconsider?
>
> I agree that we should be minimizing these circular dependencies,
> but if
> you make their avoidance a hard rule then you soon end up dragging
> lots
> of code into a single massive-component.
>
Is that really true? The component can be a packaging artifact,
can't it? build a pile of class files in the easiest way possible,
and then package as you need to...
> Some of the API circularities are quite minimal. For example
> regular IO
> in the LUNI component depends upon NIO because, amongst a few other
> cases, java.io.FileInputStream.getChannel() returns a
> java.nio.channels.FileChannel which in turn may throw a
> java.io.IOException.
>
> I believe that the set of circular dependencies can be managed down
> to a
> small number, and the extra modularity gives greater flexibility.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
--
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
Re: Bootstrapping the classlibrary builds
Posted by Tim Ellison <t....@gmail.com>.
Stefano Mazzocchi wrote:
> Maybe I'm missing something, but if A depends on B and B depends on A,
> isn't the separation between A and B something to reconsider?
I agree that we should be minimizing these circular dependencies, but if
you make their avoidance a hard rule then you soon end up dragging lots
of code into a single massive-component.
Some of the API circularities are quite minimal. For example regular IO
in the LUNI component depends upon NIO because, amongst a few other
cases, java.io.FileInputStream.getChannel() returns a
java.nio.channels.FileChannel which in turn may throw a java.io.IOException.
I believe that the set of circular dependencies can be managed down to a
small number, and the extra modularity gives greater flexibility.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Bootstrapping the classlibrary builds
Posted by Stefano Mazzocchi <st...@apache.org>.
Tim Ellison wrote:
> As a follow-up to the recent discussion with Geir about repository
> layout, I've been thinking a bit more about the componentization of the
> class library, and in particular about how day-to-day development would
> progress.
>
> The 'interesting' attribute of the components is that there are circular
> dependencies between some of them. For example, SECURITY depends upon
> LUNI, and vice versa. I briefly discussed some options for resolving
> the circularities earlier, but the point is that this is a bootstrapping
> issue -- once we have implementations of SECURITY and LUNI then each can
> be built independently against the compiled version of the others.
>
> So I propose that we make a clear distinction between the initial
> bootstrap build, and the subsequent component builds. The build.xml
> that exists today (.../classlib/trunk/make/build.xml) invokes a 'global'
> i.e. cross-component compilation to avoid circularities. The results
> are put into .../trunk/deploy/jre/lib/boot.
>
> I say we keep this build.xml as the bootstrap build, then create build
> scripts within each component that build only that component against the
> jre/lib/boot jars thereby giving localized builds. We can also write
> the component build scripts to use the deployed JRE to run ant and the
> compiler to be self-hosting!
>
> Unless anyone objects or has a better idea I'll do the minor
> restructuring of classlib required (likely next week now).
Maybe I'm missing something, but if A depends on B and B depends on A,
isn't the separation between A and B something to reconsider?
--
Stefano.