Refactorability proposal...

[Adrian Brock]

Another issue would be how you handle the generated package
constraints.

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
JavaEE:[4.0.0, 5.0.0)
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.)
> 
> Proposal
> 
> 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 
> proposed
>         a solution here previously which I will re-post).
> 
> Rationale
> 
> 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
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx