Re: Relationship to JSR 291 [was: Re: Bryan's comments]
My aghast reaction to Andy's mail is that if we aren't solving this simple issue, what is it that we are solving? This use case is far more like what I would want in the real world. If we don't get something out of this JSR and the language JSR that approximates a runtime version of 'gem' (from the ruby camp) we might as well open up the next JSR for really solving the problems that we have. People want to import functionality, not packages, e.g. import ejb3, not org.hibernate.*, javax.ejb.*, etc. Sam On Jun 8, 2007, at 1:53 AM, Andy Piper wrote: At 00:53 08/06/2007, Bryan Atsatt wrote: I truly believe that the Java world will be far better served by having 277 support ONLY import-by-package! But there has been this background fear that import-by-package is somehow terribly complex. I can certainly believe that the union of all the OSGi features *does* result in a lot of complexity. Just to express a usage datapoint here. Having used OSGi for a while now I am finding import-by-package too hard to use in certain circumstances (but in general it is a nice flexible model), but its not an issue that import-by-name really fixes in my opinion. The basic issue is that to use something I am interested in the union of packages that make up the feature. I actually don't care about the individual packages. Take my current bugbear, cglib in Spring for example, to use this feature the *proxied* class bundle needs to import the following packages: net.sf.cglib.proxy, net.sf.cglib.core, net.sf.cglib.reflect, org.aopalliance.aop, org.springframework.aop.framework, org.springframework.aop, not an obvious set, nor a set of packages that I care much about. Worse, the proxied class does not know ahead of time that it needs to import these packages (this is I believe because cglib tries to create the proxy in the classloader of the proxied class by default). Ideally to solve this I would like two things: 1. The ability to express a feature in terms of its constituent packages. Note that import-by-name doesn't really help here since the actual packages are distributed across multiple modules. What I really want is some kind of feature module that exports these packages to you when you ask for the feature. 2. Some way of augmenting a module *after* the fact with a particular set of packages, so that the module doesn't need to do dynamic-import * everywhere. I don't think either if these is possible in OSGi right now (I would be happy to be corrected!). I don't think JSR 277 solves these either (but again I would be happy to be corrected). Just a datapoint from real-world usage. andy Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
[snip] Richard S.Hall wrote: My question below still stands. In general, it seems to me that resolution consists of: 1. Selection of candidate module/bundles based on import declarations. 2. Class space consistency validation (which may narrow the list if multiple choices, or result in a failure). I don't understand what possible difference it could make whether we use a module name or a package name to select candidates in step 1. Or even if some custom code makes that selection (though I'm not a fan of this either.) In general, I can say your two steps above are correct...Felix actually has what amounts to a two-pass resolve that does (1) from above in the first step and (2) from above in the second step. However, it turns out that (2) is actually quite difficult and difficult to do in an efficient way. Perhaps it is more difficult for the OSGi framework due to some of the sophistication of its model, e.g., package substitutability, fragments, split packages, package-level uses constraints, etc. All I know is that we are still finding cases that need to be clarified in the OSGi framework for this process... I won't say that I am disagreeing with you...if we can strip away some of the complexity of the OSGi model, then I am sure you could implement a reasonably straightforward resolver. Right, that is what I'm trying to get at here. I believe *very* strongly that import-by-name is a bad idea. Period. It is just plain wrong to do the equivalent of import foo.jar. We can do this already, with manifest Class-Path. Simply layering version support on it does *not* eliminate jar-hell! It is far too brittle, raising all kinds of maintenance issues. Under import-by-name, refactoring *requires* introducing a facade module to avoid breaking importers. And this facade module now becomes *another* product artifact to be managed: documented, maintained, distributed, deprecated, and ultimately perhaps removed. I truly believe that the Java world will be far better served by having 277 support ONLY import-by-package! But there has been this background fear that import-by-package is somehow terribly complex. I can certainly believe that the union of all the OSGi features *does* result in a lot of complexity. I just think that is almost entirely orthogonal to *this* domain, since we are not trying to expose all those other features. That won't necessarily help us in achieving interoperability, though. Absolutely; regardless of the outcome of the import-by-package issue, we still need to deal with exactly how the loaders can share classes and resources... // Bryan
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Hi Bryan, Bryan Atsatt wrote: ... Rather than surfacing the import-by-package at the API level, I think we can solve #3 by generalizing the import dependency concept as import-by-name, and this name can be mapped to superpackage-name in JSR 277 and OSGi-bundle-name or OSGi-exported-package-name in OSGi (i.e. exposing OSGi bundles and exported packages through implementing OSGiBundleModuleDefinition and OSGiPackageModuleDefinition). I think this is also what you intended to say at one point (correct me if I misunderstand you) by suggesting to change ImportDependency.getModuleName() into something like ImportDependency.getName(). I believe we are now thinking along the same lines. Good to know. I just sent an email on the topic of generalizing the import dependency concept, with the subject Import constraints. With the approach I suggest there, the distinctions between module-name and package-name are mostly transparent to the runtime (declarative support for package-name is not addressed). I will reply to that thread later. In case if the 277 module would like to import these OSGi exported packages using an OSGi-like resolution algorithm, it should be possible for it to use a custom import policy (or import override policy or maybe some new override mechanisms) to get the behavior it wants. Do you think this is a workable approach to address #3? I don't think custom code should be required; we need to make it easier than that or it doesn't qualify as first-class citizenship, at least not to me :^). The OSGi resolution algorithm has evolved significantly between R3 and R4, and it will likely continue to evolve in certain degree in future releases (Glyn/Richard, please correct me if I'm wrong). From this perspective, I don't think it makes sense to have build-in OSGi-like resolution algorithm in 277, because it will stick forever once 277 is part of the SE platform and cannot be evolve easily. I think it would makes more sense to allow OSGi-like resolution logic to be plugged into the 277 module which imports OSGi bundles/packages. We could argue whether it should be plugged in per-module in the form of custom import policy, or per-system(or per-repository?) in the form of import override policy, or maybe even have a new mechanism to allow certain class of modules (e.g. 277 modules importing OSGi modules, or 277 modules importing NetBeans modules, etc.) to always use a specific import policy automatically. But my point is that OSGi-like resolution logic is something that will need to evolve in the future and should not be built-in. I think if there is a way to plug in OSGi-like resolution logic into 277 module which imports OSGi bundles, it would still qualify as first-class citizenship to me. ;) And we don't yet have *any* import declaration mechanism (yes, we're assuming that this will be handled in 294, but it hasn't been brought up yet). I don't see this as a difficult issue either way. It would be natural to have both import-by-name and import-by-package in superpackages, if we have import at all. If we need to use annotations instead, it is easy to have both types. As we discussed (and I think you also agreed), we can make the import dependency to be generic with a name, and the name could be a module name (or a package name in the context of OSGi interoperability). We'll only need to have a single import-by-name either in the superpackage or in the form of annotation. - Stanley
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Bryan Atsatt [EMAIL PROTECTED] wrote on 30/05/2007 19:11:02:
Responses inline, and a few clarifications here (I was a bit tired when
I finished this last night :^)...
The main point I was trying to make is that resolution must occur within
a specific context, but I don't think my example APIs showed that well.
I was assuming that ImportResolver had a ModuleContext as a field, but
we can make this much cleaner and easier to understand by passing it as
an argument:
public abstract class ImportResolver {
public abstract Module resolve(ModuleDefinition def,
ModuleContext ctx);
}
And we can really tie this together by adding a convenience method to
ModuleContext:
public abstract class ModuleContext {
...
public Module resolve(ModuleDefinition def) {
return getImportResolver().resolve(def, this);
}
}
Now resolution becomes simply:
context.resolve(definition);
(I also left out any use of the ImportPolicy, as it isn't yet clear to
me that it should remain a separate type in this model.)
// Bryan
Glyn Normington wrote:
*Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59:
Andy Piper wrote:
At 23:19 25/05/2007, Stanley M. Ho wrote:
Anyway, it seems the EG consensus so far is to not add import
package
support. If any EG member disagrees, please speak up.
Well, it depends on what the solution for enabling
interoperation
with JSR 291 is.
Our requirement is that there must be a solution, if that
requires
import package, so be it. If not then not.
Exactly.
I think we can all agree that, at minimum, interoperation means
that
classes and resources are sharable *across* ModuleSystems at
runtime.
Which implies that *import dependencies must be resolvable across
multiple ModuleSystem instances*. (BTW, I think we should change
the
state name PREPARING to RESOLVING in 7.2.1.)
Agreed. We must avoid the trap of thinking that module system interop.
can be achieved by exposing class loaders (as loadClass will happily
load unexported classes).
So the open issue is the richness of the import language: must we
support only lowest-common-denominator, or can we do better without
over-complicating the design?
I for one would like to be able to have a single module express
dependencies on modules from both the same and different
ModuleSystems,
*using the standard semantics of each*. This may be reaching too
far,
but we should at least explore it seriously while we figure out
what
interop means here...
At this point, I feel that is likely to be reaching too far, but I'm
happy to play along and see what we can learn along the way.
BASICS
So far, we only know of two different import semantics:
module-name, and
package-name. For discussion, let's call these:
a. import-module
b. import-package
So, to start, we could:
1. Support declaration of both import types. If 294 supports
imports at
all, it should be relatively easy to support both, since a
superpackage
name is a module name, and it contains member package names.
(Compiler
support is clearly the critical issue here, but it will obviously
require use of the 277 runtime, so the import *type* should be
transparent to it.) At worst, we'd need two new annotation types.
A superpackage name is a deployment module name in the JSR 277 model
of
one superpackage per deployment module, but I don't see any reason why
a
JSR 291 deployment module should not contain more than one
superpackage.
So if 294 were to support import, then its import-module would really
be
a superpackage import rather than a development module import.
If we end up with nested superpackages, might it make sense to model
multiple superpackages by enclosing them in a single top-level one?
That is an option, but of course each nested superpackage has to name its
parent, so it wouldn't be possible to combine superpackages from
independent groups or sources without either modifying their superpackage
declarations or getting them to agree on the name of the parent
superpackage and code it themselves.
2. Provide API for both import types (e.g. ImportDependency has
getModuleName() and getPackageName() methods, one of which will
return
null on a given instance).
However, we know these are necessary but not sufficient. Leaving
aside
the resolution issue for a moment, support for import-package also
suggests that we:
3. Enable a single module to declare different versions for each of
its
member packages.
4. Enable efficient Repository lookup by package name.
I think these are relatively easy (but *could* be considered
optional).
We also need:
5. Standard Query types for lookup by module and package name.
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Bryan Atsatt wrote: Stanley M. Ho wrote: Glyn Normington wrote: *Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59: ... So the open issue is the richness of the import language: must we support only lowest-common-denominator, or can we do better without over-complicating the design? I for one would like to be able to have a single module express dependencies on modules from both the same and different ModuleSystems, *using the standard semantics of each*. This may be reaching too far, but we should at least explore it seriously while we figure out what interop means here... At this point, I feel that is likely to be reaching too far, but I'm happy to play along and see what we can learn along the way. I agreed with Glyn that this might be reaching too far. Before we dive too much into how to implement interoperability, I think one of the outstanding questions we should answer first is what degree of import interoperability we want to offer. There are four possibilities: 1. JSR 277 module imports OSGi module by module name 2. OSGi module imports JSR 277 module by module name 3. OSGi module imports JSR 277 module by package name 4. JSR 277 module imports OSGi module by package name Let's ignore the 294 issues and the module initialization issues for now to simplify this discussion. I think we all agreed #1 and #2 are important to support and the reflective APIs already enable these (of course, there are minor issues we still have to address as we evolve the APIs.) That said, it is unclear to me how important it is to support #3 and #4, so I think the first question for this EG is whether we want to support #3 and #4 at all. However, let's pretend #3 and #4 are important for this specific discussion. I think #3 is already possible since the OSGi framework could look up the appropriate module which exported the package in the repository, using the reflective APIs. Afterwards, the OSGi framework can then do the necessary wiring. Yes, the reflective APIs can be further refined to make it easier for the OSGi framework to query modules by exported package name from the repository, but this is a minor issue that we can address easily. #4 is a bit complicated, because there is no import-by-package semantic in the current module layer's APIs and I think we all agreed that we don't want to support this semantic directly in the module system defined by JSR 277. Not me. I do understand your point that this is more difficult, but I don't really care--it is our job to do the Right Thing here. Sure, if it is not feasible in the time frame we have, then so be it. But we haven't even tried! If we're forced to make a choice between the two models, I'd pick import-by-package with zero hesitation. OSGi has a lot of experience here, and we shouldn't ignore it. Import-by-name was added late in the game, and is now seriously downplayed, for good reason. Just for information, import-by-name (or module dependencies) was not added to OSGi R4 because they were thought to be widely needed or useful, adding them was always somewhat contentious which is why the R4 spec contained a section saying why you shouldn't use them (this section has been further expanded in R4.1). The main motivation for adding them was certainly legacy situation and for tightly coupled sub-systems. All in all, I agree with everything that Bryan is saying and I argued these same points early on; however, I was under the impression that we had long since lost that battle. Bryan, it is unclear to me whether your view is that we need to make sure that 277 supports other modules systems the use import-by-package or if you think that 277 should somehow directly support import-by-package (i.e., explicitly expose such concepts). - richard And Oracle has a lot of relevant experience as well, since the shared loader mechanism I created for our AS stack (shared libraries) supports only the import-by-name model. We have *lots* of shared-libraries (I've seen 100+ running simultaneously), used by many different components in the stack, in addition to customer applications. It is a tremendous pain when refactoring or even simple renaming has to be done (I hope to shift this implementation onto 277 to solve this problem, rather than inventing an interim approach). And this kind of change happens far more frequently than you probably expect. I don't want to repeat the same mistake here. Nor do I think that leaving a long trail of extraneous view modules behind for compatibility is a good solution. Worse still, if the 277 APIs don't support import-by-package, then the compiler won't support it either. If the compiler doesn't support it, then we've lost a golden opportunity to move to a better world, one in which packaging is irrelevant. We're supposed to be eliminating jar-hell here. Let's not simply replace it with module-hell. In this context, the question is really about what it would take to make #4 possible if we
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
On May 31, 2007, at 8:06 PM, Stanley M. Ho wrote: Hi Richard, Richard S.Hall wrote: I don't think I fully understand your concerns around exporting an entire package. As you mentioned, what's get exported in 277 module is in terms of classes and the information is in the module metadata, and I think we can probably determine the packages associated with these exported classes and treat these packages as exported packages from the OSGi perspective. There is no split package allowed in 277 module, so I think each of these exported packages would be an entire package. The point is that an OSGi exported package FOO specifically means that all public classes in the FOO package are accessible to importers. Such an export is not the same as a 277 module that just happens to export a class in its export signature from the FOO package. Without cracking open the module, there is no way to tell if its export signature contains all public classes from the FOO package (i.e., the entire package). - richard I think there is a misunderstanding here. Both JSR 277 and OSGi export all accessible classes in a package. JSR 294 changes what accessible means from public to exported public, and this affects 277 and OSGi in the same way. I don't think there is a conflict here. Perhaps so. I am operating off my [possibly dated] recollection that 277 modules explicitly list the classes that they export, which meant that they may expose arbitrary public classes from a package. If this is no longer the case, then this is fine. The point remains, all legacy OSGi dependencies on a package assume that all public classes are exported from that package. An OSGi dependency on a given package cannot be resolved to a 277 module whose exported public classes are not the same as all public classes in the specific package. - richard
Re: ClassLoader Deadlock fix was: Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Adrian [EMAIL PROTECTED] wrote on 25/05/2007 12:44:54: On Thu, 2007-05-24 at 11:00 +0100, Glyn Normington wrote: A better approach would be for the Java 7 platform to provide first class support for JSR 291. This boils down to standardising the experimental class loader deadlock fix ([1]) Fixing the deadlock just moves the problem. You'll still get ClassCircularityErrors when competing threads try to load classes using locks other than the classloader synchronization or they don't synchronize on the loadClass() or they release the lock during the classloading request to let others have a go (again to avoid the deadlock). This is because of the way the dictionary class determines whether a circular load is occuring. Although I haven't tried it with OpenJDK so maybe the dictionary class contains some other fixes to workaround the problem? The simple form of the problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4699981 has been fixed in recent JDKs, but spurious CCEs still exist in other cases. e.g. the testAbstractFactoryConcurrent() here: http://viewvc.jboss.org/cgi-bin/viewvc. cgi/jbossas/projects/microcontainer/trunk/classloader/src/tests/org/jboss/test/classloader/delegate/test/DelegateUnitTestCase. java?revision=62792view=markup will show CCEs in the log if you enable TRACE logging. 1445 TRACE [ClassLoaderManager] Run failed with exception java.lang.ClassCircularityError: org/jboss/test/classloader/delegate/support/b/TestFactoryImplementation at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) Some spurious CCEs were indeed fixed before the experimental deadlock fix was introduced, but there may be more to do to make this fix robust and complete. If you raise a sunbug for the above testcase, best to report it here so that class loader rearchitecture folks can take it into consideration for Java 7. Glyn Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Responses inline, and a few clarifications here (I was a bit tired when
I finished this last night :^)...
The main point I was trying to make is that resolution must occur within
a specific context, but I don't think my example APIs showed that well.
I was assuming that ImportResolver had a ModuleContext as a field, but
we can make this much cleaner and easier to understand by passing it as
an argument:
public abstract class ImportResolver {
public abstract Module resolve(ModuleDefinition def,
ModuleContext ctx);
}
And we can really tie this together by adding a convenience method to
ModuleContext:
public abstract class ModuleContext {
...
public Module resolve(ModuleDefinition def) {
return getImportResolver().resolve(def, this);
}
}
Now resolution becomes simply:
context.resolve(definition);
(I also left out any use of the ImportPolicy, as it isn't yet clear to
me that it should remain a separate type in this model.)
// Bryan
Glyn Normington wrote:
*Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59:
Andy Piper wrote:
At 23:19 25/05/2007, Stanley M. Ho wrote:
Anyway, it seems the EG consensus so far is to not add import package
support. If any EG member disagrees, please speak up.
Well, it depends on what the solution for enabling interoperation
with JSR 291 is.
Our requirement is that there must be a solution, if that requires
import package, so be it. If not then not.
Exactly.
I think we can all agree that, at minimum, interoperation means that
classes and resources are sharable *across* ModuleSystems at runtime.
Which implies that *import dependencies must be resolvable across
multiple ModuleSystem instances*. (BTW, I think we should change the
state name PREPARING to RESOLVING in 7.2.1.)
Agreed. We must avoid the trap of thinking that module system interop.
can be achieved by exposing class loaders (as loadClass will happily
load unexported classes).
So the open issue is the richness of the import language: must we
support only lowest-common-denominator, or can we do better without
over-complicating the design?
I for one would like to be able to have a single module express
dependencies on modules from both the same and different ModuleSystems,
*using the standard semantics of each*. This may be reaching too far,
but we should at least explore it seriously while we figure out what
interop means here...
At this point, I feel that is likely to be reaching too far, but I'm
happy to play along and see what we can learn along the way.
BASICS
So far, we only know of two different import semantics: module-name, and
package-name. For discussion, let's call these:
a. import-module
b. import-package
So, to start, we could:
1. Support declaration of both import types. If 294 supports imports at
all, it should be relatively easy to support both, since a superpackage
name is a module name, and it contains member package names. (Compiler
support is clearly the critical issue here, but it will obviously
require use of the 277 runtime, so the import *type* should be
transparent to it.) At worst, we'd need two new annotation types.
A superpackage name is a deployment module name in the JSR 277 model of
one superpackage per deployment module, but I don't see any reason why a
JSR 291 deployment module should not contain more than one superpackage.
So if 294 were to support import, then its import-module would really be
a superpackage import rather than a development module import.
If we end up with nested superpackages, might it make sense to model
multiple superpackages by enclosing them in a single top-level one?
2. Provide API for both import types (e.g. ImportDependency has
getModuleName() and getPackageName() methods, one of which will return
null on a given instance).
However, we know these are necessary but not sufficient. Leaving aside
the resolution issue for a moment, support for import-package also
suggests that we:
3. Enable a single module to declare different versions for each of its
member packages.
4. Enable efficient Repository lookup by package name.
I think these are relatively easy (but *could* be considered optional).
We also need:
5. Standard Query types for lookup by module and package name.
EXISTING DEPENDENCY RESOLUTION MODEL
The more interesting issue is dependency resolution. But this hasn't
been discussed in any real detail, so lets do so before talking further
about import-package. To simplify this discussion, I'm ignoring
bundled/custom import policies for now...
Resolution in the current spec is delegated to the associated
ModuleSystem instance (7.2.2 #8). While the details are not spelled out,
the expectation appears to be that
ModuleSystem.getModule(ModuleDefinition) must:
- Select an initial repository. Call
Re: Relationship to JSR 291 [was: Re: Bryan's comments]
Hi, Glyn Normington wrote: *Bryan Atsatt [EMAIL PROTECTED]* wrote on 30/05/2007 07:57:59: ... So the open issue is the richness of the import language: must we support only lowest-common-denominator, or can we do better without over-complicating the design? I for one would like to be able to have a single module express dependencies on modules from both the same and different ModuleSystems, *using the standard semantics of each*. This may be reaching too far, but we should at least explore it seriously while we figure out what interop means here... At this point, I feel that is likely to be reaching too far, but I'm happy to play along and see what we can learn along the way. I agreed with Glyn that this might be reaching too far. Before we dive too much into how to implement interoperability, I think one of the outstanding questions we should answer first is what degree of import interoperability we want to offer. There are four possibilities: 1. JSR 277 module imports OSGi module by module name 2. OSGi module imports JSR 277 module by module name 3. OSGi module imports JSR 277 module by package name 4. JSR 277 module imports OSGi module by package name Let's ignore the 294 issues and the module initialization issues for now to simplify this discussion. I think we all agreed #1 and #2 are important to support and the reflective APIs already enable these (of course, there are minor issues we still have to address as we evolve the APIs.) That said, it is unclear to me how important it is to support #3 and #4, so I think the first question for this EG is whether we want to support #3 and #4 at all. However, let's pretend #3 and #4 are important for this specific discussion. I think #3 is already possible since the OSGi framework could look up the appropriate module which exported the package in the repository, using the reflective APIs. Afterwards, the OSGi framework can then do the necessary wiring. Yes, the reflective APIs can be further refined to make it easier for the OSGi framework to query modules by exported package name from the repository, but this is a minor issue that we can address easily. #4 is a bit complicated, because there is no import-by-package semantic in the current module layer's APIs and I think we all agreed that we don't want to support this semantic directly in the module system defined by JSR 277. In this context, the question is really about what it would take to make #4 possible if we want to support it, and so far there are two different approaches we have discussed: a. Treat import-by-package separately from import-by-module in the reflective APIs and make the module layer fully aware of the import-by-package concept. b. Expose exported-package using the ModuleDefinition abstraction, and provide necessary hooks (e.g. consistency checking) for the module system to resolve this kind of dependency appropriately. The module layer is not aware of the import-by-package concept at all. New import dependency granularity could also be introduced in a similar manner in the future without requiring significant changes in the module layer. As Richard and I discussed in previous emails, it seems to make the most sense for JSR 277 to define the minimal set of features possible in the module layer to accomplish what needs to be accomplished to provide core modularity support in the Java platform. I think (b) follows this principle nicely while (a) does not. If we decide to support #3 and #4, then how we want to address #4 would impact our overall design significantly. Is there anyone in the EG provide good reasons why #3 and #4 are important to be supported? If so, is there anyone in the EG think (b) is not feasible at all and we should do (a) instead to support #4? Can you explain your rationale? RESOLUTION MODELS The current design requires that each ModuleSystem provide its own resolution logic, and that each definition will be resolved by its owning ModuleSystem. This model appears to provide flexibility for significant differences in implementation, but we really don't know enough at this point. Perhaps only an actual second implementation will tell us if this provides useful flexibility. In the existing module systems we are aware, e.g. OSGi and NetBeans, we already know their resolution logics are different from each other. Even if they are migrated/re-based to JSR 277 in the future, I think we should expect their resolution logic would remain the same to maintain backward compatibility with their existing modules/bundles. In other words, their resolution logic would still be different from each other. A phased approach would be particularly beneficial if the initial phase could be delivered as part of Java 7 and subsequent phases implemented strictly on top of Java 7. But getting the API right up front might be tricky unless we can spot some really good abstractions or prototype the later phases sufficiently well. Is that
