Java compiler API not supporting non-standard options such as -XDignore.symbol.file?

[Peter Niederwieser]

David, Jon,

thanks for yours answers. It's not that *I* want or need to use internal JDK APIs, but that Gradle needs to support whatever the JDK command-line compiler supports. (We can't tell our users "when you switch from (say) Ant to Gradle, you need to refactor your codebase and can no longer use internal JDK classes". We've even had someone building the JSR-166 project with Gradle and running into this problem.) Therefore, what I'm really after is to have *all* command-line compiler options work as-is with the compiler API (no matter which JDK implementation/version is used). Is it conceivable for the compiler API to be improved in such a way? Otherwise, Gradle will always have to offer a fallback to the command-line compiler integration, which will complicate life for our users and means that some of them won't be able to benefit from any of the advantages that our compiler API integration brings (first and foremost significantly faster build time).

Cheers,
Peter

On Oct 12, 2013, at 1:40 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> @David, note that -XD... is a javac flag, not a JVM flag.
> 
> That being said, all javac options beginning -XD are non-standard, undocumented and unsupported.
> 
> The javac behavior to use the internal symbol file for the platform classes is just the default behavior. If you explicitly set the PLATFORM_CLASS_PATH to be used for the compilation, then you should bypass the default behavior to try and use the symbol file.   Having said that, I would be remiss if I did not discourage you and your users from using internal JDK API. The warnings generated by javac regarding the use of internal API are there for a reason ...
> 
> -- Jon
> 
> On 10/11/2013 03:44 PM, David M. Lloyd wrote:
>> Perhaps it doesn't work because the compiler API doesn't actually start a JVM up, so it's meaningless to pass options to the JVM?
>> 
>> Try just setting the "ignore.symbol.file" system property to true in that process.
>> 
>> On 10/11/2013 05:06 PM, Peter Niederwieser wrote:
>>> Anyone? Do you have a public issue tracker where I can submit this?
>>> 
>>> Peter
>>> 
>>> On Oct 7, 2013, at 3:35 AM, Peter Niederwieser <pniederw at gmail.com
>>> <mailto:pniederw at gmail.com>> wrote:
>>> 
>>>> Hi compiler developers,
>>>> 
>>>> I'm working on the Java compiler integration for the Gradle build tool
>>>> (http://gradle.org <http://gradle.org/>). Our main way of interacting
>>>> with the Java compiler is the Java compiler API. Among other things,
>>>> this allows us to have a long-running compiler process that can be
>>>> reused over time, which is considerably faster than forking a new
>>>> compiler every time.
>>>> 
>>>> I've noticed that the Java compiler API seems to silently ignore some
>>>> of the options supported by the (Oracle JDK) command-line compiler. A
>>>> concrete example is -XDignore.symbol.file=true, which some Gradle
>>>> users need in order to be able to compile against internal JDK classes
>>>> (e.g. com.sun.image.codec.jpeg.JPEGCodec). Is this a known issue, or
>>>> is it even a feature (perhaps because -XDignore.symbol.file is a
>>>> non-standard option)? To achieve the best possible compiler
>>>> integration in Gradle, it would help a lot if the compiler API
>>>> accepted exactly the same options as the corresponding command-line
>>>> compiler.
>>>> 
>>>> Thanks for any insights.
>>>> 
>>>> Cheers,
>>>> Peter
>>>> 
>>>> -- 
>>>> Peter Niederwieser
>>>> Principal Developer, Gradleware
>>>> http://www.gradle.org <http://www.gradle.org/>
>>>> http://www.gradleware.com <http://www.gradleware.com/>
>>>> Creator, Spock Framework
>>>> http://spockframework.org <http://spockframework.org/>
>>>> 
>>>> Join us at the GradleeXchange 2013, Oct 28th in London, UK:
>>>> http://skillsmatter.com/event/java-jee/gradle-exchange-2013
>>> 
>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131012/3f43ac75/signature.asc