[jsr294-modularity-eg] Superpackage defining class loader
Andreas.Sterbenz at Sun.COM
Thu Apr 26 03:42:05 EDT 2007
Glyn Normington wrote:
> VERSION MISMATCH USE CASE
> A large development team constructs a superpackage A containing two
> nested superpackages B and C. B and C are developed by distinct
> subteams. Suppose the developers of B have included an unexported
> general utility class org.apache.foo.Util early on in the project.
> Later, the developers of C also realise independently that they can save
> time by reusing org.apache.foo.Util, but they pick up a later version
> and include it as an unexported class of C.
Note that at the language level you cannot have multiple types of the same
name today. Adding superpackages to the language does not change that. See
my message Re: Nested superpackages from 4/23
> * the strawman gives the impression that B and C can see the classes
> directly contained in A and that B and C can see each other's exported
> contents. Please correct me if I've misunderstood.
That is correct.
> It would seem much cleaner to develop B and C as top-level superpackages
> each wrapped in their own deployment module. This would avoid internals
> clashing, as B and C would be loaded by distinct class loaders. I can't
> think of a practical example where bundling B and C together in A to
> produce a large, monolithic superpackage would make a lot of sense, and
> I've worked on a lot of large projects.
I agree. In your example B and C appear to be loosely coupled so it makes
sense to have them as separate top-level superpackages (and deployment
modules) regardless of all other issues.
That is a fine answer. It also addresses the issue we were discussing in
this thread: is there a use cases where it is necessary to load a spkg
file and its class files using different class loaders? This example is no
such use case, so we should stick with current proposal that a
superpackage should be defined by a single classloader.
> Are there any specific examples where it would make more sense to use
> nested superpackages than separate deployment modules?
Nested superpackages are not a replacement for deployment modules, they
solve a different issue. I can certainly show an example from the code I
am most familiar with (part of the core of the JDK) to make the
explanation from the mail I sent yesterday more concrete. The issue
remains the same:
Without nested superpackages we cannot achieve the same level of
information hiding. Given that information hiding is the problem this JSR
was created to address, this is not an something we can just set aside.
More information about the jsr294-modularity-eg