Relationship to JSR 291 [was: Re: Bryan's comments]

[Stanley M. Ho]

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