Refactorability proposal...

[Stanley M. Ho]

Hi Bryan,

I agreed that refactorability is indeed an important issue we need to 
address. That said, there are couple concerns I have related to step 1b. 
I'm not arguing against import-by-package at runtime; only against the 
transformation of import-by-module to import-by-package at compile-time.

A compile/build-time transformation from import-by-module to 
import-by-package could fundamentally be done in one of two ways.

First, it could involve analysis of the module's method signatures. The 
issue is that the analysis may not be accurate all the time (e.g. code 
that uses reflection, Class.forName(), etc.). The programmer will then 
be required do extra trial-and-error steps to fix up the dependencies in 
the metadata, and this is not acceptable.

Second, it could simply expand import-by-module as the set of exported 
packages in the imported module, then there is a problem when migrating 
from one version of an imported module to a newer one and the set of 
packages have changed. Suppose a core module in JDK 7 exports package P 
and the one in JDK 8 exports packages P and Q. If a module imports JDK 
7+ and is compiled against JDK 7, step 1b will transform the module to 
import only the packages that are known in the core module in JDK 7. 
When this module runs in JDK 8 or later, it will not see the new 
packages. This is problematic because many modules will compile against 
an older version of the JDK and want to call new API in newer JDK 
through reflection; in general, this situation applies to using other 
libraries as well. This will also cause problem in applications that 
involve weaving at runtime and the exact required packages are not known 
at compile-time.

There are some general problems with expanding modules to packages at 
compile/build-time, regardless of how the expansion is achieved.

First, there are modules (e.g. classpath module) that cannot logically 
have exported packages which are known at compile-time and at runtime, 
thus it would be impossible to perform the transformation in this case. 
(Technically, we can go through every JAR in the classpath in every 
launch to find out the exports of the classpath module at runtime, but 
this has huge startup performance impact.)

Second, it implies that people export packages but import modules. This 
will be hard to explain to beginners.

Last, but perhaps the most important, it means that unresolveable 
packages at runtime will generate error messages which the programmer 
must manually map back to imported modules and the transformation 
process implemented by a tool. The fundamental aim of a programming 
system should be to reduce the semantic gap between what a programmer 
sees in code and what a programmer sees at execution; the mapping from 
packages back to modules increases the semantic gap.

I accept that pushing module imports through to runtime makes it hard to 
"rewrite" a program (i.e. to refactor module members) but it makes it 
easy to "read" the program (in the sense of a small semantic gap between 
what imports are read/written and what imports are executed). A core 
Java principle has always been that reading is more important than 
writing, so we do not believe increased ease of refactoring on 
relatively rare occasions is worth complicating every single reading of 
a dependency.

I still think the refactorability problem you brought up is very 
important to address. That said, the proposed transformation seems to 
have many issues as an acceptable general solution.

- Stanley