Question about FileManagers in Jigsaw.

[Jonathan Gibbons]

On 03/12/2012 02:59 AM, Fredrik Öhrström wrote:
> 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)

No. No such recommendation has been made.  I think the expectation
is that the first component will be product-related, such as  "foo", "jdk",
"jtreg" 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.

There is currently no such requirement.

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

No.  The three modes I described earlier (no modules, one module,
many modules) are mutually exclusive.

> 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?

Yes.

> 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?

It sounds like you could fix that by changing the way your compiler
options are set up.  Move what you currently have on the bootclasspath
to the classpath, and set the bootclasspath to empty.  Then
-Xprefer:source will have the effect you desire.


> //Fredrik
>