Compiling without module identities

Hal Hildebrand hal.hildebrand at oracle.com
Tue Feb 3 11:53:01 EST 2009


Note the horrendous typos in the example below.  "java" should  
obviously be "javac".

Apologies.

On Feb 3, 2009, at 8:24 AM, Hal Hildebrand wrote:

> So Richard Hall suggested that I make a detailed proposal of what  
> I'm talking about so that hopefully it will make the issue more clear.
>
> In my experience of developing modular code, I never compile more  
> than the module in question.  I do this by mapping Maven projects  
> onto the produced OSGi bundle, one for one.  But this can also be  
> easily done with Ant, Make or any other build tool.   Thus, I'm  
> assuming that the *only* source code that will be compiled is to be  
> of a particular module, regardless of whether the source being  
> compiled is of the full module or a subset of the module.  The  
> reason is quite simple.  If I compile the source of more than one  
> module, then I'm adding more work to my life by having to sort out  
> the resulting class files into their individual modules.  Divvying  
> up a mess of class files into separate jars is something that we  
> used to do in our builds here at House Harkonnen, and that process  
> actually caused a great deal of pain, as the splitting up of the  
> compiled code is hard work - especially hard to automate in a large  
> build. We spent a lot of effort to reorganize the source code and  
> compilation such that we didn't have to perform this step - i.e.  
> effectively modularizing the code.  Organizing your source and  
> compilation by module is considered best practice and besides the  
> positive benefits, doing so is known to prevent other nasty things  
> like circularities in your code.
>
> So, if we can agree that any source we are currently compiling is  
> from a single module, then the issue is how to treat the  
> dependencies.  The dependencies of the compiled source fall into two  
> categories:
>
> additional classes that are in the same module
> the dependencies of the module (aka the "imports", in OSGi slang)
>
> 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
>
> To compile FooImpl:
>
> java -classpath /Users/atreides -d /Users/harkonnen - 
> moduleClasspath /Users/harkonnen com/hakonnen/Foo'
>
> 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.
>
> 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:
>
> libraries in the OSGi bundle class path
> 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).
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090203/8e529897/attachment.html>


More information about the jsr294-modularity-observer mailing list