You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2005/05/10 09:40:39 UTC
Class Library Modularity [Was Re: State of the World]
Tom Tromey wrote:
>* com.sun.*. Those pesky java programmers often end up using unfree
> APIs. I'm not sure what Harmony could do here; maybe pressure Sun
> into make it much more difficult to do this?
>
Just to raise the point about class library modularity again, since it
is related to this comment. Access [and assumptions about access] to
these types of classes is problematic when trying to implement stronger
Java modularity mechanisms, such as is the case with the OSGi framework.
If it is possible to adopt a stronger modularity model, then it is
possible to eliminate these types of issues. As an example, libraries
packaged for OSGi in a bundle JAR file must explicitly list their
package import/export dependencies; thus, it is trivial for them to
ensure that implementation classes are not visible to the outside world.
It would be nice to see all of the libraries accompanying a JVM be more
module-like, with dependencies and contributions explicitly listed,
making it possible to statically and dynamically verify and deploy
various configurations of a Java platform.
I do not claim to be a Java spec expert, so I do not know what aspects
of these ideas are covered by the spec, but I do know that certain
assumptions made by the Sun implementation make it more difficult to
achieve module isolation (such as the assumption that JVM implementation
classes like sun.* and com.sun.* are available from any class loader,
including application class loaders, which results in the issue raised
above by Tom Tromey). If these things can be improved while remaining
J2SE compliant, then it is a step in the right direction.
-> richard
Re: Isolates support
Posted by Doug Lea <dl...@cs.oswego.edu>.
Francisco Vega wrote:
> Hi everybody,
>
> planning the development of a new virtual machine at this moment, it
> could be interesting to provide support for isolations.
This is probably off-topic, but...
1. The second (and hopefully final) public review draft of JSR121
will be available from http://jcp.org very soon.
2. If approved (it would go to vote sometime this summer), a reference
implementation and TCK will probably be out before the end of year.
3. It is reasonable to expect that Isolates will be a mandatory
part of J2SE as of 1.7 (J2SE7), but optional before then. Not
making it in as mandatory for either 1.5 or 1.6 led to these
hold-states until we decided to rework specs a bit
to make isolates supportable as a non-core package.
-Doug
Re: Platform Support
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On May 10, 2005, at 8:20 AM, Rivaaj Jumna wrote:
> Hi
>
> The JVM under discussion will obviously support multiple platforms,
> running
> under Linux, Windows, etc. Will it also support other platforms as
> in being
> "modular enough" to be composed to run on Pocket PC or cellphones
> (j2me) or
> is such support outside of the initial scope for this project?
Yes. One of the motivations is to reduce the amount of work someone
wishing to have a compatible version of J2SE on a "new" platform - be
it new hardware, new operating system, or even new kinds of
performance optimizations on existing platforms.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Platform Support
Posted by Rivaaj Jumna <ri...@gmail.com>.
Hi
The JVM under discussion will obviously support multiple platforms, running
under Linux, Windows, etc. Will it also support other platforms as in being
"modular enough" to be composed to run on Pocket PC or cellphones (j2me) or
is such support outside of the initial scope for this project?
Thanks
Re: Isolates support
Posted by Dalibor Topic <ro...@kaffe.org>.
Francisco Vega wrote:
> Hi everybody,
>
> planning the development of a new virtual machine at this moment, it
> could be interesting to provide support for isolations.
> I supose that most people will know the concept, but in short, the idea
> is to run several Java programs in parallel in one virtual machine (one
> OS process) and at the same time:
> - keep all the Java programs in separate and effective sandboxes
> - share the maximum resources (decompiled class code,etc)
Hi Francisco,
Yeah, isolation is pretty nice. There is already an implementation of
the APIs as Free Software since 2002, called JanosVM, and available at
http://www.cs.utah.edu/flux/janos/janosvm.html
"Unlike any available virtual machine, the JanosVM supports multiple,
separate processes (called "teams" in JanosVM) within a single VM. Based
on KaffeOS (and thus Kaffe), the JanosVM supports per-team separate
heaps, per-team garbage collection threads, inter-team thread migration,
safe cross-team reference objects, and a spiffy tutorial. Designed to
support asynchronous termination of uncooperative or malicious Java
bytecode applications, the JanosVM provides robust and scalable
multi-process support within a single virtual machine."
Some of that code has been merged back into Kaffe, but the largest chunk
that actually implements isolation remains to be merged in, volunteers
welcome :) Kaffe developer Patrick Tullman is on the JSR committee,
afaik, and Godmar Back, the author of KaffeOS, is active on the
isolation JSR mailing lists as well, afaik.
Kaffe is a bit odd that way, as a lot of exciting things exist in some
Kaffe fork somewhere, be it mixed-mode engines, isolation, efficient
jits or parallelized virtual machines. It's just merging everthing back
in that takes time. :)
cheers,
dalibor topic
Isolates support
Posted by Francisco Vega <fr...@yahoo.es>.
Hi everybody,
planning the development of a new virtual machine at this moment, it
could be interesting to provide support for isolations.
I supose that most people will know the concept, but in short, the idea
is to run several Java programs in parallel in one virtual machine (one
OS process) and at the same time:
- keep all the Java programs in separate and effective sandboxes
- share the maximum resources (decompiled class code,etc)
For an indeep discusion of benefits and a running example you can look
at http://research.sun.com/projects/barcelona/mvm/
There is also a JSR in process trying to determine a common basis for
this kind of functionality: JSR-121. In any case, it is not necessary to
comply to this JSR, because it is in some 'hold' state, but the ability
to run isolates is a lower layer that can be implemented without any
kind of JSR commitment.
Regards.
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Ricky Clarkson wrote:
>I might have misunderstood this thread, but it seems to have some
>relation to ivy, a dependency manager, see
>http://www.jayasoft.fr/org/modules/ivy/overview.php
>
>
Yes, this IVY does sound like it is related, but not quite the same
thing. IVY sounds like a component repository that you can use in your
own projects to describe your project's dependency on other projects. In
this case, IVY performs a build-time activity.
It appears that IVY allows you to specify dependencies on other JAR
files and then ensures that these JAR files are present when you build.
Without investigating it explicitly, how would IVY allow you to describe
what is exported from each of the individual JAR files (i.e., their
public API) and how would it enforce this visibility at run time?
I actually have a similar tool (but much simpler) to IVY, called OBR,
that performs deployment-time dependency management for package
dependencies for OSGi bundles. OBR is interesting, but it would not be
as interesting without the OSGi run time underneath of it.
So while tools like IVY and OBR are related to the issue, they are just
a part of it.
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by Ricky Clarkson <ri...@gmail.com>.
I might have misunderstood this thread, but it seems to have some
relation to ivy, a dependency manager, see
http://www.jayasoft.fr/org/modules/ivy/overview.php
On 11/05/05, Richard S. Hall <he...@ungoverned.org> wrote:
> Peter Donald wrote:
>
> > Richard S. Hall wrote:
> >
> >> However, while I agree that Sun's implementation does provide some
> >> modularity mechanisms, there seems to be two short comings:
> >>
> >> 1. The mechanisms themselves do not go far enough, they only provide
> >> minimal capabilities.
> >
> >
> > True but what more do you need at the runtime level?
>
> Well, I can think of one thing I would like, some way for the packages
> contained in a JAR file be able to inform the underlying runtime not
> only its external dependencies, but also what it provides (or what it
> exposes). Due to limitations in the Java visibility/protection rules,
> sometimes it is not possible to avoid making implementation API public
> because you are forced to declare classes/methods as public if you need
> to use them from more than one package.
>
> Of course, you could just put everything in the same package and use
> package protection, but that also defeats the purpose of trying to
> structure things into modules. So, for a module to be able to say that I
> export package "foo", but not "foo.FooImpl" would be very useful from my
> perspective. Then other packages inside the JAR are privy to
> implementation APIs, where packages outside the JAR are not.
>
> I also have lots of interesting ideas about dynamic deployment/updates
> too, but I am sure that these things would be extension to the platform
> as opposed to implementing a conforming J2SE platform. :-)
>
> -> richard
>
>
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Donald wrote:
> What you are asking for here is new language extensions - effectively
> an "assembly" or "jar" access specifier to go along with private,
> protected, public and package access. This would be very useful -
> particularly if different jars/assemblies were of higher importance in
> runtime. However it is not part of the Java standard and thus I
> suspect that best way to achieve this goal is go through the jcp process.
Well, I think that this is certainly one approach to implementing what I
am talking about, but certainly not the only way. Perhaps not even the
best way. Maybe it is better to have such module constructs outside the
language and part of the deployment/package layer. I don't know.
> You *could* implement this in Suns java by writing a custom
> ClassLoader and using Annotations but ... unless it is part of a
> standard somewhere it is unlikely to get broad adoption.
Well, this is exactly the kind of stuff that is being done with the OSGi
framework. So that is sort of where I am coming from.
> You can implement this in suns java. Just write your own ClassLoader
> to "hide" specified classes, set the ClassLoader as the bootstrap
> classloader and it is done.
Yes, this is basically the approach. Unfortunately, there are lots of
little "gotchas" in here, because if you hide the wrong classes, then
you end up getting Sun's JVM throwing exceptions at runtime because it
cannot find "sun.*" classes, for example.
It is hard to write code on Sun's JVM that is isolated from Sun's
private API because there is an implicit assumption that every class
loader leads back to Sun's impl classes and this assumption is required
by Sun's libraries to function. This is not true of all JVMs however.
> I would love get my hands on the platform to implement Isolate and
> Resource Managers as in Suns MVM (research JVM) as that would make
> writing scalable applications in java so much easier.
I agree. I think these technologies are looking really interesting.
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by Peter Donald <pe...@realityforge.org>.
Richard S. Hall wrote:
> Well, I can think of one thing I would like, some way for the packages
> contained in a JAR file be able to inform the underlying runtime not
> only its external dependencies, but also what it provides (or what it
> exposes). Due to limitations in the Java visibility/protection rules,
> sometimes it is not possible to avoid making implementation API public
> because you are forced to declare classes/methods as public if you need
> to use them from more than one package.
What you are asking for here is new language extensions - effectively an
"assembly" or "jar" access specifier to go along with private,
protected, public and package access. This would be very useful -
particularly if different jars/assemblies were of higher importance in
runtime. However it is not part of the Java standard and thus I suspect
that best way to achieve this goal is go through the jcp process.
You *could* implement this in Suns java by writing a custom ClassLoader
and using Annotations but ... unless it is part of a standard somewhere
it is unlikely to get broad adoption.
> Of course, you could just put everything in the same package and use
> package protection, but that also defeats the purpose of trying to
> structure things into modules. So, for a module to be able to say that I
> export package "foo", but not "foo.FooImpl" would be very useful from my
> perspective. Then other packages inside the JAR are privy to
> implementation APIs, where packages outside the JAR are not.
You can implement this in suns java. Just write your own ClassLoader to
"hide" specified classes, set the ClassLoader as the bootstrap
classloader and it is done.
> I also have lots of interesting ideas about dynamic deployment/updates
> too, but I am sure that these things would be extension to the platform
> as opposed to implementing a conforming J2SE platform. :-)
Fun parts ;)
I would love get my hands on the platform to implement Isolate and
Resource Managers as in Suns MVM (research JVM) as that would make
writing scalable applications in java so much easier.
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Dalibor Topic wrote:
> I think that would be pretty interesting, actually. One of the hard
> challenges so far for me has been efficient support for 'profiles'[1]
> in class libraries. What I have done in Kaffe is just a simple
> mechanism to select the classes to build as part of a profile, but
> that usually drags in a superset of an API due to implementation
> internals required by added methods in later versions of a class,
> rather then a minimal implementaiton of just the classes, methods,
> fields, and their transitive closure.
>
> My experiments with kaffe last year have shown me that it is possible
> to separate the class library into large chunks with certain ease,
> though unfortunately the maintenace of such a modular seperation is
> burdensome without tool support. From my cursory glance at the OSGi
> specs, it seems as the OSGi devs have put a good amount of though into
> dealing with the subject, so I'd be very interested to hear more about
> it, including about respective tools. :)
Yes, this is definitely something that could benefit from such a
packaging mechanism. If it were possible to chunk the class libraries
into modules, then without some mechanism to support/enforce this
encapsulation the exercise becomes somewhat pointless.
Some of the features I am talking about are already available in the
OSGi spec, but these ideas in general are definitely in the purview of
the OSGi framework and the work done around it. I have an experimental
release of Oscar that starts to deal with the issues we are discussing
here...these things are of interest to the OSGi Alliance Core Platform
Expert Group too.
I agree that these types of mechanisms require some sort of tooling
support. One area that I want to investigate more is the generation of
the module metadata by analyzing its byte code. There are already tools
that do this for the R3 OSGi spec, so it should be possible to extend
the approach to handle the metadata required for this type of
encapsulation stuff too.
Unfortunately, the tool support is still coming up from behind. Maybe
this will change now that Eclipse depends on OSGi as well.
> Yes, I agree. To give an example, an unfortunately common mispractice
> that leads to unportable source code written in the Java programming
> language is the abuse of runtime-specific classes by non-runtime code
> to get access to runtime-specific services. Being able to, with
> relative ease, make sure that modules of a class library only export
> the interfaces specified in the specs would be pretty useful to help
> people avoid writing implementation-specific code.
Exactly. This my thought too. Plus it ensures that the VM and standard
libraries themselves do not do practices that make it difficult to do
various deployment/management activities on top of the VM.
> Well, I am all ears. :) It would surely be interesting to be able
> dynamically update a runtime installation's class libraries, for
> example, or just it's JIT, if one can get the architecture right.
Yes, these are the sort of thoughts I was having too as other people
were having discussions about modular VM architectures.
> On a side note, I'd love to see such mechanisms work hand-in-hand with
> the native platform's package management, to avoid having to jump
> through multiple hoops to manage software.
This is another valid issue, but one that I have not given that much
thought to at this point.
> p.s. OSCAR already works on Kaffe & other GNU Classpath runtimes,
> right? I remember seing some mails from that direction :)
I am aware of users using Oscar on Kaffe, yes. I try to keep it pretty
neutral and try to fix issues if I get reports of difficulties.
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by Dalibor Topic <ro...@kaffe.org>.
Richard S. Hall wrote:
> Peter Donald wrote:
>
>> Richard S. Hall wrote:
>>
>>> However, while I agree that Sun's implementation does provide some
>>> modularity mechanisms, there seems to be two short comings:
>>>
>>> 1. The mechanisms themselves do not go far enough, they only provide
>>> minimal capabilities.
>>
>>
>>
>> True but what more do you need at the runtime level?
>
>
>
> Well, I can think of one thing I would like, some way for the packages
> contained in a JAR file be able to inform the underlying runtime not
> only its external dependencies, but also what it provides (or what it
> exposes). Due to limitations in the Java visibility/protection rules,
> sometimes it is not possible to avoid making implementation API public
> because you are forced to declare classes/methods as public if you need
> to use them from more than one package.
I think that would be pretty interesting, actually. One of the hard
challenges so far for me has been efficient support for 'profiles'[1] in
class libraries. What I have done in Kaffe is just a simple mechanism to
select the classes to build as part of a profile, but that usually drags
in a superset of an API due to implementation internals required by
added methods in later versions of a class, rather then a minimal
implementaiton of just the classes, methods, fields, and their
transitive closure.
My experiments with kaffe last year have shown me that it is possible to
separate the class library into large chunks with certain ease, though
unfortunately the maintenace of such a modular seperation is burdensome
without tool support. From my cursory glance at the OSGi specs, it seems
as the OSGi devs have put a good amount of though into dealing with the
subject, so I'd be very interested to hear more about it, including
about respective tools. :)
> Of course, you could just put everything in the same package and use
> package protection, but that also defeats the purpose of trying to
> structure things into modules. So, for a module to be able to say that I
> export package "foo", but not "foo.FooImpl" would be very useful from my
> perspective. Then other packages inside the JAR are privy to
> implementation APIs, where packages outside the JAR are not.
Yes, I agree. To give an example, an unfortunately common mispractice
that leads to unportable source code written in the Java programming
language is the abuse of runtime-specific classes by non-runtime code to
get access to runtime-specific services. Being able to, with relative
ease, make sure that modules of a class library only export the
interfaces specified in the specs would be pretty useful to help people
avoid writing implementation-specific code.
> I also have lots of interesting ideas about dynamic deployment/updates
> too, but I am sure that these things would be extension to the platform
> as opposed to implementing a conforming J2SE platform. :-)
Well, I am all ears. :) It would surely be interesting to be able
dynamically update a runtime installation's class libraries, for
example, or just it's JIT, if one can get the architecture right.
On a side note, I'd love to see such mechanisms work hand-in-hand with
the native platform's package management, to avoid having to jump
through multiple hoops to manage software.
cheers,
dalibor topic
p.s. OSCAR already works on Kaffe & other GNU Classpath runtimes, right?
I remember seing some mails from that direction :)
[1] Say 1.5, 1.6, Personal Java, ...
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Humberto S. N. dos Anjos wrote:
>Just to add a little note: C# (I'm not sure about the other .NET languages)
>deals with this issue by adding a new access modifier, internal, that makes
>the class/method/field/property visible by all classes in the same assembly.
>Could this behavior be emulated using solely the manifest file?
>
>
Interesting fact to know. Thanks.
This behavior can be partially implemented with manifest metadata.
Without giving it much thought, I would say that it wouldn't be possible
for the smaller granularity items (e.g., method, field, property), only
for classes.
Check back with me in a couple weeks, because when I find the time, this
type of class hiding is something that I will have implemented in my
OSGi implementation...I just need to find the time to do it. :-)
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Humberto S. N. dos Anjos" <h....@gmail.com>.
> > Woudln't it be great if this was addressed at the language level?
> > Something like declaring "friend" packages or something like that.
> > Then the public modifier would basically fulfil the need for this kind
> > of "provides" or "exposes" declaration?
Just to add a little note: C# (I'm not sure about the other .NET languages)
deals with this issue by adding a new access modifier, internal, that makes
the class/method/field/property visible by all classes in the same assembly.
Could this behavior be emulated using solely the manifest file?
_______________________
Humberto S. N. dos Anjos
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Dmitry Serebrennikov wrote:
>
>>
>> Well, I can think of one thing I would like, some way for the
>> packages contained in a JAR file be able to inform the underlying
>> runtime not only its external dependencies, but also what it provides
>> (or what it exposes). Due to limitations in the Java
>> visibility/protection rules, sometimes it is not possible to avoid
>> making implementation API public because you are forced to declare
>> classes/methods as public if you need to use them from more than one
>> package.
>
>
> Woudln't it be great if this was addressed at the language level?
> Something like declaring "friend" packages or something like that.
> Then the public modifier would basically fulfil the need for this kind
> of "provides" or "exposes" declaration?
This could certainly be one way to implement it, but I don't think we
are going to extend the JVM.
> Well, maybe not. If you package a few packages together into a new
> library, each package might have its public interface, but that
> doesn't mean you want those methods as part of your library interface
> too. So the need for "provides" declaration goes beyond the package
> visibility related limitations it seems.
Yes, there are subtle issues here. The benefit of using a JAR
manifest-based approach is that it works with legacy code and does allow
for easier composition of third-party libraries. In theory it may sound
like a good idea to really lock a module down so that outsiders cannot
access its internals, but maybe in reality it would not be good to
completely lock it down. For example, by using a JAR manifest approach,
it is possible for me to develop some extension to a third-party library
that uses its non-public API to improve performance. I could then
package this as a module to properly encapsulate it again. In this way,
I accept the responsibility of using non-public API, but we can still
protect others from accidentally using it.
So, perhaps having two views of a JAR file, one as just a library and
the other as a module, is more flexible. Just a thought.
> Doesn't Eclipse do something like this?
I don't know for sure, but I have heard reports that Eclipse plugins
expose all of their internals.
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by Dmitry Serebrennikov <dm...@earthlink.net>.
>
> Well, I can think of one thing I would like, some way for the packages
> contained in a JAR file be able to inform the underlying runtime not
> only its external dependencies, but also what it provides (or what it
> exposes). Due to limitations in the Java visibility/protection rules,
> sometimes it is not possible to avoid making implementation API public
> because you are forced to declare classes/methods as public if you
> need to use them from more than one package.
Woudln't it be great if this was addressed at the language level?
Something like declaring "friend" packages or something like that. Then
the public modifier would basically fulfil the need for this kind of
"provides" or "exposes" declaration?
Well, maybe not. If you package a few packages together into a new
library, each package might have its public interface, but that doesn't
mean you want those methods as part of your library interface too. So
the need for "provides" declaration goes beyond the package visibility
related limitations it seems.
Doesn't Eclipse do something like this?
-dmitry
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Donald wrote:
> Richard S. Hall wrote:
>
>> However, while I agree that Sun's implementation does provide some
>> modularity mechanisms, there seems to be two short comings:
>>
>> 1. The mechanisms themselves do not go far enough, they only provide
>> minimal capabilities.
>
>
> True but what more do you need at the runtime level?
Well, I can think of one thing I would like, some way for the packages
contained in a JAR file be able to inform the underlying runtime not
only its external dependencies, but also what it provides (or what it
exposes). Due to limitations in the Java visibility/protection rules,
sometimes it is not possible to avoid making implementation API public
because you are forced to declare classes/methods as public if you need
to use them from more than one package.
Of course, you could just put everything in the same package and use
package protection, but that also defeats the purpose of trying to
structure things into modules. So, for a module to be able to say that I
export package "foo", but not "foo.FooImpl" would be very useful from my
perspective. Then other packages inside the JAR are privy to
implementation APIs, where packages outside the JAR are not.
I also have lots of interesting ideas about dynamic deployment/updates
too, but I am sure that these things would be extension to the platform
as opposed to implementing a conforming J2SE platform. :-)
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by Peter Donald <pe...@realityforge.org>.
Richard S. Hall wrote:
> However, while I agree that Sun's implementation does provide some
> modularity mechanisms, there seems to be two short comings:
>
> 1. The mechanisms themselves do not go far enough, they only provide
> minimal capabilities.
True but what more do you need at the runtime level?
> 2. They are not used, nor is their use really encouraged.
They are used by a few container APIs (ie mandated in servlet spec and
it was proposed for EJB - not sure if it made it) but because there is
no real support in base runtime no one bothered to use them in regular apps.
> I won't deny that I have a biased point of view, but your point about
> the spaghetti code of the standard runtime is what I am trying to get
> at. It would be nice if Harmony defined some form of modularity
> (preferably a stronger form) and then followed the rules imposed by that
> modularity from the beginning to avoid getting into the spaghetti
> situation.
agreed. But I think that this spagetti-ness stems from the way it is
specified and is not really open to much modification in runtimes - I
could be wrong though.
> I, for one, though, think it is
> possible to do better.
I am sure it is - but someone has to sit down and figure out how ;)
---
Cheers,
Peter Donald
"The power of accurate observation is frequently
called cynicism by those who don't have it."
- George Bernard Shaw (1856-1950)
Re: Class Library Modularity [Was Re: State of the World]
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Donald wrote:
> Java already has the ability to define "Optional Packages"/Extensions
> that have similar features to OSGis bundles. For an overview check out
>
> http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
>
> You can declare the id/version/vendor for both the specification and
> implementation of a module. You can also declare dependencies on other
> modules. However given the spagetti that the standard runtime is it
> may not be entirely possible to do in a clean manner.
Yes.
However, while I agree that Sun's implementation does provide some
modularity mechanisms, there seems to be two short comings:
1. The mechanisms themselves do not go far enough, they only provide
minimal capabilities.
2. They are not used, nor is their use really encouraged.
I won't deny that I have a biased point of view, but your point about
the spaghetti code of the standard runtime is what I am trying to get
at. It would be nice if Harmony defined some form of modularity
(preferably a stronger form) and then followed the rules imposed by that
modularity from the beginning to avoid getting into the spaghetti situation.
I am not necessarily saying the OSGi framework should be used directly
(however, I do think that an OSGi-like layer on top of the JVM would
make Java much more appealing when compared to .NET/Assemblies/GAC), I
just hope that these ideas are considered from the beginning and not
tacked on in some web page somewhere, which no one ever reads...like the
above link.
So, if the decision is that existing modularity mechanisms are good
enough, that's fine...just use 'em. I, for one, though, think it is
possible to do better.
-> richard
Re: Class Library Modularity [Was Re: State of the World]
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
Richard S. Hall wrote:
> Just to raise the point about class library modularity again, since it
> is related to this comment. Access [and assumptions about access] to
> these types of classes is problematic when trying to implement
> stronger Java modularity mechanisms, such as is the case with the OSGi
> framework.
Java already has the ability to define "Optional Packages"/Extensions
that have similar features to OSGis bundles. For an overview check out
http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
You can declare the id/version/vendor for both the specification and
implementation of a module. You can also declare dependencies on other
modules. However given the spagetti that the standard runtime is it may
not be entirely possible to do in a clean manner.
--
Cheers,
Peter Donald
"Never interrupt your enemy when he is making
a mistake." - Napoleon Bonaparte (1769-1821)