abrock at REDHAT.COM
Thu Jun 12 05:01:26 PDT 2008
Another issue would be how you handle the generated package
e.g. Suppose you a module JavaEE:4.0.0 that
contains packages javax.jms:1.1.0, javax.resource:1.5.0, etc.
I then declare a module constraint
i.e. I work with JavaEE4 but not JavaEE5
What do the package constraints resolve to for jms and jca
if we don't have a JavaEE5 module in the repository? :-)
JavaEE is not a very a good example since package versions
wouldn't change across a major release, but they could
in other cases or more general module version constraints.
On Tue, 2008-06-10 at 18:27 -0700, Bryan Atsatt wrote:
> (FYI: I've discussed this with Stanley but wanted to ensure it was
> visible to everyone.)
> 1. Eliminate runtime use of import-by-module in the JAM system:
> a. Support the (very convenient) import-by-module at the source level.
> b. jam tool transforms import-by-module to a list of
> import-by-package statements.
> 2. Add APIs to fully support import-by-package in the JAM system:
> a. Support Version annotation in package-info.java (or in
> module-info.java). If a
> package does not declare a version, it "inherits" that of the
> enclosing module.
> b. Add ImportPackage annotation with version constraints.
> 3. Add APIs to fully support import-by-package in the abstract framework:
> a. Add methods to Query to produce import-by-package nodes.
> b. Replace Query.getIndexableNames() with fully generic variants (I
> a solution here previously which I will re-post).
> Module refactoring is inevitable, particularly during the transition
> from the current, effectively flat class space to a fine-grained space
> provided by module systems. We have significant experience with this
> issue at Oracle (with the transition to our own module system), and OSGi
> best-practices for conversion include starting with everything in one
> bundle and then separating out pieces as experience is gained.
> A very common pattern, in our experience, is for developers to start
> with many extra jars in their initial module (a mini version of
> class-path hell). As that module is put into wider use, someone
> discovers that package X is also contained in their module, and that
> duplication either leads to runtime conflicts (very bad), or just plain
> footprint bloat. The obvious answer is to put package X in a separate
> module, and have everyone share it via imports.
> But... not so fast. If there are consumers of that module who import it
> by module name alone, then pulling X out of it will cause those
> importers to break. And if it is possible for your module to have been
> imported by *anyone* by name alone, then you are stuck: either you break
> them or you live with the incorrect granularity (which just isn't an
> option in the conflict scenarios). Not a happy choice.
> Originally, I had proposed to do away with import-by-module altogether,
> both to avoid this problem and to eliminate the conceptual disconnect.
> Your code does not today contain import statements that name *jars*, it
> names packages and/or specific classes in those packages. Why invent a
> new system that takes such a large step backwards?
> The answer is simply convenience. Imagine a module that contains 100
> packages and it is obvious that writing a single import statement is far
> easier than discovering and explicitly writing all the package imports.
> Yes, IDEs will likely mostly eliminate this issue, but it still makes
> sense to be able to do this by hand.
> This proposal is an attempt to maintain the convenience while adding the
> crucial ability to safely refactor: step 1b is the central idea.
> // Bryan
JBoss, a division of Red Hat
More information about the jsr277-eg-observer