<br><font size=1 face="sans-serif"><b>Bryan Atsatt <bryan.atsatt@ORACLE.COM></b></font><tt><font size=2>
wrote on 04/06/2007 20:21:29:<br>
<br>
> Stanley M. Ho wrote:<br>
> > Hi Bryan,<br>
> ><br>
> > I don't think I will have time to response to all your comments
this<br>
> > week, so my response would focus on the import-by-package discussion.<br>
> ><br>
> > First, the only import dependency we have consensus in this EG
so far is<br>
> > import-by-module-name (or import-by-superpackage-name), and this
was<br>
> > also what's in the EDR. That said, it is by no mean that we can't<br>
> > consider other import dependency granularities (e.g.<br>
> > import-by-package-name, or import-by-contract) in addition to<br>
> > import-by-module-name. I would like to focus this discussion
more on<br>
> > whether it makes sense for JSR 277 to support additional import<br>
> > dependency granularity, mainly import-by-package-name, and if
so, in<br>
> > what context.<br>
> ><br>
> > There are three cases we should consider:<br>
> ><br>
> > 1. 277 module imports another 277 module by package name<br>
> ><br>
> > I think our consensus so far is that this is nice-to-have or<br>
> > non-critical, given we already have support for import-by-module-name.<br>
> > To keep this discussion in focus, let's not dive into<br>
> > import-by-package-name v.s. import-by-module-name, and let's
assume<br>
> > there is no support for #1 for now.<br>
> <br>
> Agreed.<br>
> <br>
> ><br>
> > 2. OSGi module imports 277 module by package name<br>
> ><br>
> > As I discussed this with Richard in previous emails, majority
of the<br>
> > works for this fall under the OSGi framework if it wants to enable
this<br>
> > kind of wiring, but we could probably make the implementor's
life easier<br>
> > by provide the appropriate 277 reflective API if necessary.<br>
> <br>
> Yes, the API would be useful.<br>
> <br>
> ><br>
> > 3. 277 module imports OSGi module by package name<br>
> ><br>
> > If I understand you correctly, I think what you really want is
the<br>
> > support for this case, so the existing OSGi bundles can be leveraged
by<br>
> > 277 modules in a nature way.<br>
> ><br>
> > Let me say it up front that I don't oppose the idea of #3 in
the context<br>
> > of interoperability. If #3 is what you really want, I think where
we<br>
> > diverge is simply how to make it possible.<br>
> ><br>
> > Do you agree so far?<br>
> <br>
> Yes.<br>
> <br>
> ><br>
> > Bryan Atsatt wrote:<br>
> >> ...<br>
> >> I want 277 to explicitly expose the concept of import-by-package
through<br>
> >> appropriate APIs.<br>
> >><br>
> >> It would be very nice if the 277ModuleSystem implementation
itself<br>
> >> directly supports import-by-package (case #3). But this is
less critical<br>
> >> to me than case #4...<br>
> >><br>
> >> I want a 277ModuleDefinition to be able to import-by-package
an<br>
> >> OSGiModuleDefinition (i.e. a bundle exposed via the 277 APIs).
I believe<br>
> >> this case will be a particularly important one. By the time
SE 7 ships,<br>
> > ...<br>
> ><br>
> > As I described several emails back:<br>
> ><br>
> > > This doesn't mean supporting the notion of import
by package is<br>
> > > impossible. What OSGi will expose from its repository
is simply module<br>
> > > definitions, and module definition is basically an
abstraction.<br>
> > > Therefore, it should be possible to treat an OSGi
bundle as a module<br>
> > > definition, as well as to treat each exported package
in an OSGi<br>
> > > bundle a module definition as well. The dependency
supported in JSR<br>
> > > 277 is import-by-module. In the JSR 277 module system,
this is mapped<br>
> > > to import-by-superpackage. In the OSGi module system,
this can be<br>
> > > mapped to import-by-OSGi-bundle or import-by-package.
If other module<br>
> > > systems want to support different import granularity
or if OSGi<br>
> > > evolves to add new import granularity in the future,
this model should<br>
> > > still work.<br>
> ><br>
> > Rather than surfacing the import-by-package at the API level,
I think we<br>
> > can solve #3 by generalizing the import dependency concept as<br>
> > import-by-name, and this name can be mapped to superpackage-name
in JSR<br>
> > 277 and OSGi-bundle-name or OSGi-exported-package-name in OSGi
(i.e.<br>
> > exposing OSGi bundles and exported packages through implementing<br>
> > OSGiBundleModuleDefinition and OSGiPackageModuleDefinition).
I think<br>
> > this is also what you intended to say at one point (correct me
if I<br>
> > misunderstand you) by suggesting to change<br>
> > ImportDependency.getModuleName() into something like<br>
> > ImportDependency.getName().<br>
> <br>
> I believe we are now thinking along the same lines.<br>
> <br>
> I just sent an email on the topic of generalizing the import dependency<br>
> concept, with the subject "Import constraints". With the
approach I<br>
> suggest there, the distinctions between module-name and package-name
are<br>
> mostly transparent to the runtime (declarative support for package-name<br>
> is not addressed).<br>
> <br>
> That isn't to say that there aren't resolution issues to be worked
out<br>
> for package-name, but its a start.<br>
> <br>
> ><br>
> > We expect the module-aware compiler would somehow recognize the
import<br>
> > dependency defined in 277. In other words, if the OSGi framework
exposes<br>
> > the module definitions appropriately, you'll get the compiler
support.<br>
> > Since the import dependency is generic, the compiler and other
tools ed<br>
> > to do extra work to support other forms of import dependency.<br>
> <br>
> Yep. As I've said from the very beginning, I think the compiler is
going<br>
> to have to rely on the 277 runtime to resolve *external* (i.e.<br>
> non-source) dependencies. So as long as the runtime can deal with<br>
> package-name, the compiler will too.<br>
> <br>
> (Dependencies resolvable via included source will, I assume, just<br>
> *directly* resolve, without applying any constraint logic. That is,
if a<br>
> class refers to a class in another superpackage, and that class &<br>
> superpackage are available in the same compilation, the compiler will<br>
> simply select them without applying *any* constraints. This may be
too<br>
> simple of a model, but maybe it is sufficient.)<br>
> <br>
> ><br>
> > In case if the 277 module would like to import these OSGi exported<br>
> > packages using an OSGi-like resolution algorithm, it should be
possible<br>
> > for it to use a custom import policy (or import override policy
or maybe<br>
> > some new override mechanisms) to get the behavior it wants.<br>
> ><br>
> > Do you think this is a workable approach to address #3?<br>
> <br>
> I don't think custom code should be required; we need to make it easier<br>
> than that or it doesn't qualify as "first-class" citizenship,
at least<br>
> not to me :^).<br>
> <br>
> <br>
> I guess I am still missing something fundamental--I keep thinking
that<br>
> import-by-package is actually not so hard. There are three main components:<br>
> <br>
> 1. Declaration.<br>
> 2. Runtime infrastructure.<br>
> 3. Resolution algorithm.<br>
> <br>
> I'm pretty sure that #2 is easy (and covered in my "Import constraints"<br>
> thread).<br>
> <br>
> And we don't yet have *any* import declaration mechanism (yes, we're<br>
> assuming that this will be handled in 294, but it hasn't been brought
up<br>
> yet). I don't see this as a difficult issue either way. It would be<br>
> natural to have both import-by-name and import-by-package in<br>
> superpackages, if we have import at all. If we need to use annotations<br>
> instead, it is easy to have both types.<br>
> <br>
> So I can only assume that the *real* concern here is #3. And I can't<br>
> tell if this is a valid concern or not. I hope Glyn and Richard will<br>
> point out what I'm missing here...</font></tt>
<br>
<br><tt><font size=2>Sounds right to me. However, the JSR 291 support for
import-package is more subtle, and I would say was generally harder to
get right (over several versions and several years), than require-bundle
which was added fairly simply (despite the semantic rough edges, pointed
out in the spec.). Although JSR 277 has paid lip service to learning from
OSGi, the design is radically different in several ways:</font></tt>
<br>
<br><tt><font size=2>* dependencies expressed in metadata and code rather
than purely in metadata</font></tt>
<br><tt><font size=2>* split packages not allowed</font></tt>
<br><tt><font size=2>* shallow/deep validation to avoid class space inconsistency
rather than metadata expressing package dependencies and a system provided
resolver that aims to find a "best fit"</font></tt>
<br>
<br><tt><font size=2>so my feeling is that we've got a quite a lot of work
to do to support something equivalent to import-by-package. Of course,
it may turn out to be simpler than I expect...</font></tt>
<br><tt><font size=2><br>
> <br>
> What is the difference between selecting a ModuleDefinition based
on its<br>
> name, or selecting it based on its contents? Either way, "shallow"<br>
> validation must still occur.<br>
> <br>
> // Bryan<br>
> <br>
> ><br>
> > - Stanley<br>
> ><br>
</font></tt>
<br><tt><font size=2>Glyn</font></tt><font size=3 face="sans-serif"><br>
</font>
<br><font size=3 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
</font><font size=3 face="sans-serif"><br>
</font>
<br>
<br><font size=3 face="sans-serif"><br>
</font>