jigsaw vs. jsr166 CVS

[Martin Buchholz]

I tried adding -Xoverride, but it didn't help.

--- build.xml 11 Sep 2015 18:43:46 -0000 1.177
+++ build.xml 11 Sep 2015 23:17:46 -0000
@@ -347,6 +347,7 @@
            fork="true">

       <include name="**/*.java"/>
+      <compilerarg value="-Xoverride:${src.dir}"/>
       <compilerarg value="-Xprefer:source"/>
       <compilerarg value="-XDignore.symbol.file=true"/>
       <compilerarg value="-Xlint:all"/>

I can see that the compiler is being invoked like this:
$ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"
...
    [javac] Compilation arguments:
    [javac] '-d'
    [javac] '/home/martin/jsr166/jigsaw/build/classes'
    [javac] '-classpath'
    [javac] '/home/martin/jsr166/jigsaw/build/classes'
    [javac] '-sourcepath'
    [javac] '/home/martin/jsr166/jigsaw/src/main'
    [javac] '-g:source,lines,vars'
    [javac] '-Xoverride:/home/martin/jsr166/jigsaw/src/main'
    [javac] '-Xprefer:source'
    [javac] '-XDignore.symbol.file=true'
    [javac] '-Xlint:all'
    [javac] '-Werror'
    [javac] '-Xdoclint:all/protected'
    [javac] '-Xmaxerrs'
    [javac] '1000'
    [javac] '-Xmaxwarns'
    [javac] '1000'

Maybe the problem is that the there is *nothing but* overriding source
files here.
Does javac check that its actual argument source files might be in the
Xoverride tree?

Can/should we make jsr166 files itself a sub-module of java.base?
Certainly, here in jsr166-developer-land, we act as if it were so.
We have independent source trees, binary artifacts, etc... must be a
module!?
(You might not allow carving up java.util along module boundaries, but the
reality as reflected in the bug system is that java.util contains portions
of several "modules")
(but oops ... circular dependencies ...)



On Fri, Sep 11, 2015 at 3:49 PM, Alex Buckley <alex.buckley at oracle.com>
wrote:

> Hi Martin,
>
> javac is compiling your classes (in the unnamed module) against all the
> named modules in the image. One of those named modules (java.base) contains
> the java.util package, so your code (in the unnamed module) cannot also
> contain that package. [That's not quite true but go with it for now.]
>
> What you want is the -Xoverride flag -- see the "Overriding module
> content" section of JEP 261. You'll have to rename 'main' to 'java.base'.
> Also note the open design issues around -Xoverride.
>
> Alex
>
>
> On 9/11/2015 1:51 PM, Martin Buchholz wrote:
>
>> Jigsawers:
>>
>> I tried to use jigsaw EA with jsr166 CVS for the first time.
>>
>> On a fresh jsr166 CVS checkout (
>> http://g.oswego.edu/dl/concurrency-interest/),
>> I did:
>>   ~/jsr166/jigsaw $ ant -v compile -Djdk9.home="$HOME/jdk/jigsaw-b80"
>>
>> and got:
>>
>>      [javac]
>> /home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:7:
>> warning: package exists in another module: java.base
>>      [javac] package java.util;
>>
>> and then more seriously
>>
>>      [javac]
>> /home/martin/jsr166/jigsaw/src/main/java/util/AbstractQueue.java:36:
>> error:
>> cannot find symbol
>>      [javac]     extends AbstractCollection<E>
>>
>> I was surprised by that -- we don't fiddle with the boot environment here.
>> Is it not allowed to compile sources for which class files are in the same
>> package but another module?  Alternatively, does the compile time
>> environment need to include all the sources for the packages being
>> compiled, i.e. do I need to add sourcepath for
>> jdk/src/java.base/share/classes?
>>
>> (Admittedly, developing jdk sources outside the jdk proper is a little bit
>> unusual)
>>
>>