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

[Peter Niederwieser]

In Gradle we solved this problem by starting another compiler daemon whenever none of the current daemons matches compilation requirements (JDK version, memory settings, etc.). So we only ever use one compiler per JVM.

Cheers,
Peter

On Oct 12, 2013, at 11:46 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> On 10/11/2013 09:08 PM, Martin Buchholz wrote:
>> 
>> 
>> 
>> On Fri, Oct 11, 2013 at 5:45 PM, Peter Niederwieser <pniederw at gmail.com> wrote:
>> Martin,
>> 
>> thanks for chiming in. I'm not quite sure how your remark relates to what I said. While it's true that it isn't currently possible to point Gradle's compiler API integration to an external JDK, this will be possible in the future. And it's easy to add because we can already run compilation in a separate JVM. But unlike when using the command-line compiler, the same JVM can potentially be used for many compilation jobs, which can speed up builds significantly.
>> 
>> 
>> AFAIK, you can only run one version of a javac inside a given JDK, and if there's a version mismatch, then only via -Xbootclasspath/p:
>>  
> 
> An expert user could probably load different versions of javac into different classloaders, which would probably work. Most of javac's classes live in tools.jar; only a very few javax.* classes live in rt.jar.  But I'm not sure this could be set up in a reasonably general fashion.
> 
> -- Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20131016/3d4c5c53/attachment.html 
-------------- 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/20131016/3d4c5c53/signature.asc