Alan, thanks for that pointer. I succeeded at building jsr166 and running
tests with it after beating ant into submission.
People *will* write code to distinguish between a pre-module and
post-module JDK by inspecting the filesystem.
Here's one implementation in ant:
<local name="modules"/>
<condition property="modules">
<available file="${jdk@{compile-target}.home}/jmods" type="dir"/>
</condition>
Then we can have conditional ant code like this:
<compilerarg value="-Xbootclasspath/p:@{classes}"
unless:set="modules"/>
<compilerarg value="-Xoverride:${build.classes.dir}"
if:set="modules"/>
It's not just a matter of "porting to jigsaw". There seems to be no way of
deploying jsr166 CVS as a directly deployable software artifact as we have
been doing with -Xbootclasspath/p. To use -Xoverride, there must be an
exploded directory. It would be convenient if -Xoverride was usable with
an equivalent jar file (jsr166.jar). But y'all are trying to make module
overriding possible, not convenient?!
javadoc does not seem to have any support for -Xmodule, so I don't know how
to fix the "docs" target.
The fundamental disconnect is that from a developer point of view, jsr166
CVS contains an independently developed "module" with binary deployable
artifacts, but jigsaw disagrees about its module-ness, and that can
probably not be fixed because of circular dependencies between
java.util.concurrent and the rest of java.base?
On Fri, Sep 11, 2015 at 9:47 PM, Alan Bateman <alan.bate...@oracle.com>
wrote:
>
> On 12/09/2015 00:30, Martin Buchholz wrote:
>
>> I tried adding -Xoverride, but it didn't help.
>>
>> You'll need to use javac -Xmodule:java.base to compile the classes, then
> use -Xoverride at run-time. As it happens, there is an example that
> compiles and uses an development version of CHM here:
>
> http://openjdk.java.net/projects/jigsaw/quick-start#xoverride
>
> Hopefully it won't too much to get the build.xml to do this.
>
> -Alan
>
