[jsr294-modularity-eg] Runtime model

[Bryan Atsatt]

OSGi bundles.

The static (dev-time) approach to mapping legacy classes into 
superpackages should be sufficient for 277 modules, since these modules 
will only run on Java 7.

However, OSGi bundles do not have this restriction. So a developer would 
have to create a special version of the bundle to run on Java 7; hence 
the build/support/distribution complexity.

If the superpackage mapping could be done dynamically, then the OSGi 
runtime can take the burden from the developer, layering a superpackage 
over the legacy classes only when on Java 7.

And, given such a facility, 277 may choose to use it rather than require 
new tooling.

// Bryan

Andreas Sterbenz wrote:
> Bryan Atsatt wrote:
>> Glyn and I both agreed that the use case is limiting external access to 
>> legacy classes in a module. Supporting this at runtime allows the 
>> unmodified legacy classes to continue to run in pre-Java 7 environments, 
>> thus simplifying build/support/distribution.
> 
> By "legacy classes in a module", do you mean JSR 277 module? Since JSR 277 
> is currently also targeted for JDK 7, a JSR 277 module will not run on JDK 
> 6 regardless of superpackages (unless potentially as a plain JAR file, 
> which would largely defeat the purpose of making it a module).
> 
> Or which other deployment mechanism are you thinking of?
> 
> Andreas.
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>