Question about FileManagers in Jigsaw.

[Fredrik Öhrström]

2012-03-10 19:49, Jonathan Gibbons skrev:
> 1. no modules -- think of this as a legacy mode, similar to jdk 7 and 
> earlier
>
> 2. a single module -- you can refer to other modules, but you're only 
> compiling one -- in that case, all files written will be for the one module
>
> 3. multiple modules -- in that case, javac will use methods on the new 
> ModuleFileManager interface, such that it dynamically creates a Location 
> for each module. 
Thanks Jon!

When in multiple module mode, is it the intention that module names look
dns names in reverse?
Like packages, if company Foo that owns www.foo.com the it will
distribute their app under the
module name com.foo? (The jdk is of course special with its jdk.base,
jdk.corba etc etc)

Is there a safety check for the views declared inside a module, so that
the views have to be
module+"."+viewname? Thus the only views allowed for com.foo are com.foo.bar
com.foo.internal etc etc.

Can a single javac invocation handle both legacy non-module sources and
sources put into a module.

I.e.
javac -d bin src/com/foo/LegacyApp.java src/com.foo/com/foo/NewApp.java
src/com.foo/module-info.java

And can NewApp refer to/use LegacyApp?

I assume that implicit compilation works as before? Ie. even though
there are circular dependencies
between different modules, as long as you supply the sourcepath to the
entire source, javac will
resolve and compile the dependencies automatically?

Can -Xprefer:source be made smarter than it is today? We use
-Xprefer:source when compiling
some of the repositories in the OpenJDK because we need to link to the
new classes declared in source,
not the classes in the bootclasspath. However, when doing incremental
compiles, we really would
like to reuse the generated classes during the previous compile, not
recompile from source again.
Thus the option -Xprefer:nobootclasspath would be more valid?

//Fredrik