harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricky Clarkson <ricky.clark...@gmail.com>
Subject Re: Class Library Modularity [Was Re: State of the World]
Date Wed, 11 May 2005 12:50:48 GMT
I might have misunderstood this thread, but it seems to have some
relation to ivy, a dependency manager, see

On 11/05/05, Richard S. Hall <heavy@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

View raw message