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
