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

Jonathan Gibbons jonathan.gibbons at
Fri Oct 11 20:04:06 PDT 2013


There are different solutions here, depending on your level of aspiration.

You *can* run the "command-line" compiler in each of the following ways:, OutputStream, 
OutputStream, String...), PrintWriter)   // yes, 
this is a supported API

Either of these calls will get you the exact same functionality as the 
command line tool, javac.    You can call these methods repeatedly 
within the same JVM, so you get many of the performance advantages that 
you are looking for of running javac in a "hot" JVM.  If you don't 
stress your JVM too much, you can even run multiple calls of these 
methods in parallel.

There is also more advanced use of the compiler API, using getTask, 
etc.  You can certainly get more performance gains, using techniques 
like a shared file manager, but you'll have to work harder to convert 
your users' command line args into the API calls to use this API.  And, 
if your users require some unsupported options, you may not be able to 
use this solution.

-- Jon

On 10/11/2013 05:12 PM, Peter Niederwieser wrote:
> 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> 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
>>>> <mailto:pniederw at>> wrote:
>>>>> Hi compiler developers,
>>>>> I'm working on the Java compiler integration for the Gradle build tool
>>>>> ( <>). 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
>>>>> <>
>>>>> <>
>>>>> Creator, Spock Framework
>>>>> <>
>>>>> Join us at the GradleeXchange 2013, Oct 28th in London, UK:

More information about the compiler-dev mailing list