How to set -XDignore.symbol.file=true on some compiles in multi-project build

Old Forum Archive
1

The JSR166 jar has to be built with the compiler option:

-XDignore.symbol.file=true

set. I used to do this in Gradle with the statement:

compileJava.options.compilerArgs = [ ‘-XDignore.symbol.file=true’ ]

However this hasn’t worked for a long time, which means I have not been building the evolving JSR166 jar and uploading to Maven Central Snapshots. The JSR166x, JSR166y, Extra166y, and JSR166e jars all build and test fine without this option. However without the JSR166 jar, the JSR166TCK cannot be run and so there is no validation for any of the jars.

I have a suspicion, but no data or evidence, just a gut reaction, that the problem might stem from when the whole Java compilation system of Gradle was revised a few months back.

So what is the way of ensuring that this symbol is set during compilation of the JSR166 jar, but none of the others.

I am using a multi-project Gradle build, one project for each of the jars. The mainline repository is the CVS repopsitory Doug Lea holds, but I am using Git for all this and my mirror fork is available at git://git.codehaus.org/jsr166-mirror.git

I don’t use forums, so if anyone has any information about the above please email me at russel@winder.org.uk. Thanks.

2

It’s a known problem. From what I can tell, the JDK compiler API doesn’t support the ‘-XDignore.symbol.file’ flag. (It also doesn’t support some other options like ‘-sourcepath’.) The only solution I’m aware of is to fall back to Ant mode (‘compileJava.useAnt = true’).

3

Using that leads to:

Dynamic properties are deprecated: http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html Deprecated dynamic property: “useAnt” on “task ‘:jsr166:compileJava’”, value: “true”.

and it still doesn’t set the required option as noted above. Looks like Gradle has become too opinionated to be useful :frowning:

EDIT: Actually it does seem to set the option in the report of what is happening but since there is no feedback as to the actual command used to compile (as there used to be) it is not clear what is actually happening.

4

It’s ‘compileJava.options.useAnt’.

5

A very important ‘option’ there :slight_smile: OK, that is now doing the needful, but… This will not work with JDK8 for me only with JDK7.

6

OK, now I am worried. I have to use this property to get JSR166 to build. There is no way of setting it in the Gradle compiler and yet:

The CompileOptions.useAnt property has been deprecated and will be removed in the next version of Gradle. There is no replacement for this property.

So what is the replacement to achieve the functionality goal?

7

You are always worried. :slight_smile: ‘useAnt = true’ will stay around at least until Gradle 2.0, which is nowhere near. Meanwhile, we should probably reach out to the Java compiler folks and ask them why it is that certain Java compiler options don’t work with the Java compiler API. Do you happen to know a list or person to contact?

8

:slight_smile:

'fraid not. Doug using Ant and me using Gradle just know that JSR166 will not build without this option.

9

We have contacts. But we should first try the public list: http://mail.openjdk.java.net/mailman/listinfo/compiler-dev

10

We should also change our deprecation message. I wrote about this to the dev list.

11

You can try what we do in disruptor build (https://github.com/LMAX-Exchange/disruptor) and fork the compiler and provide the executable.

Then you can pass the compiler args willy-nilly.

12

That rather sound like admitting that Gradle cannot do the job. If true, then Gradle needs fixing.

13

The folks on the jdk-compiler-dev list confirmed that the Java compiler API doesn’t support certain non-standard options such as ‘-XDignore.symbol.file’. (I don’t know which, if any, other options are affected.) They suggest the following solutions: * Use ‘javax.tools.JavaCompiler.run(InputStream, OutputStream, OutputStream, String…)’, which behaves exactly like the command-line compiler. The same is true for JDK5’s ‘com.sun.tools.javac.Main.compile(String…, PrintWriter)’, which is a supported API that won’t go away. The drawback of this approach is that we can’t use any of the advanced features that the compiler API offers, such as providing our own file manager. (Currently we aren’t using any of these features. I’ve heard that IDEA 12 uses them to speed up compilation.) * Put effort into translating user arguments such as ‘-XDignore.symbol.files’ into API calls. I’m still trying to get feedback on how this would work for this particular case.

See here for the archived mailing list thread: http://mail.openjdk.java.net/pipermail/compiler-dev/2013-October/007588.html