Compiling without module identities

[Hal Hildebrand]

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:
>>
>> com.harkonnen.Foo
>> com.harkonnen.impl.FooImpl
>>
>> With dependencies on:
>>
>> org.arrakis.Spice
>>
>> 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  
>> like:
>>
>> java -classpath /Users/atreides -d /Users/harkonnen com/hakonnen/Foo
>
> Presumably, this would be:
>
> javac -classpath /Users/atreides -d /Users/harkonnen com/hakonnen/ 
> Foo.java
>
>> 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).