Compiling without module identities
hal.hildebrand at gmail.com
Tue Feb 3 12:25:56 EST 2009
Yes. Sorry for the typos ;)
On Feb 3, 2009, at 8:58 AM, Richard S. Hall wrote:
> Hal Hildebrand wrote:
>> What I was proposing is that the java compiler be extended to know
>> about the additional distinction of the module in the class path.
>> For example here is my module:
>> With dependencies on:
>> So, the scenario is that we want to compile Foo and FooImpl
>> separately, and somehow make use of a module private method on Foo
>> from FooImpl. Foo has dependency on Spice, FooImpl has dependency
>> on Foo. The dependency Spice, being in a separate module, will
>> have been previously compiled and is rooted in the directory /Users/
>> atreides. To accomplish this, I posit the idea of the module class
>> path that the java compiler now knows about. Let's say that the
>> new flag is "-moduleClasspath". So, the compilation of Foo looks
>> java -classpath /Users/atreides -d /Users/harkonnen com/hakonnen/Foo
> Presumably, this would be:
> javac -classpath /Users/atreides -d /Users/harkonnen com/hakonnen/
>> To compile FooImpl:
>> java -classpath /Users/atreides -d /Users/harkonnen -
>> moduleClasspath /Users/harkonnen com/hakonnen/Foo'
> And this would be:
> javac -classpath /Users/atreides -d /Users/harkonnen -
> moduleClasspath /Users/harkonnen com/hakonnen/FooImpl.java
>> Because the Spice is obtained from outside the moduleClasspath, the
>> compiler knows that it is *not* in the current module being
>> compiled. Because FooImpl *is* on the moduleClasspath, it knows
>> that it is in the current module being compiled. Thus, FooImpl can
>> use a module private method on Foo, but cannot use any module
>> private methods on Spice.
> Sounds reasonable.
> -> richard
>> In this example, it's important to realize that the *only* source
>> code that will be compiled is source that is in the current
>> module. Thus, the question as to "what module any source code is
>> in" has exactly one answer: "the current module".
>> It is also important to note that the additional "module class
>> path" is needed only to handle two edge cases of compilation:
>> 1. libraries in the OSGi bundle class path
>> 2. separate compilation of a module's source files
>> I believe that the probability of #1 is far higher than the
>> probability of #2, given my experience in creating modular code, as
>> well as what I've seen in large scale commercial development here
>> at House Harkonnen and other corporations. Consequently, if you're
>> doing what comes naturally to developers compiling modules - i.e.
>> compiling the entire source of the module - then you would not need
>> any additional class path at all. The compiler knows that any
>> source it is compiling is a module and any dependency it finds from
>> the class path is considered to be in another module (can be
>> multiple modules as it does not matter to the semantics).
More information about the jsr294-modularity-observer