JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version

Jan Lahoda jan.lahoda at oracle.com
Fri May 22 07:20:16 UTC 2015


On 22.5.2015 08:49, Erik Joelsson wrote:
>
> On 2015-05-21 21:59, mark.reinhold at oracle.com wrote:
>> 2015/5/21 12:01 -0700, jan.lahoda at oracle.com:
>>> This is a patch adding a new option, -platform, to javac.
>>>
>>> Patch for the top-level repository is here:
>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/
>>>
>>> Patch for the langtools repository is here:
>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/
>>>
>>> These changes also require additional langtools changes as their
>>> prerequisite:
>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/
>> Nice work -- I'm glad to see this coming in.
>>
>> What's the rationale for putting the symbol generator and all its data
>> in the top-level repo?  That'll add quite a bit of heft to a repo that's
>> always been intended to remain fairly lightweight.  Wouldn't it make
>> more sense for this code and data to be placed in the langtools repo?
>> Or is there some sort of build-bootstrapping issue here?
> Technically these files could go in any repo, it's only a question of
> where they best fit from a logical/maintaining point of view. I had not
> thought about the langtools repo before, I just thought that it didn't
> fit in the jdk repo so better put it in the top as it applies to all
> modules. But the user of this data is the compiler so langtools does
> make sense.

There has been a brief discussion on which repo to use some time ago, 
and top-level repo seemed reasonable. I am personally fine with the 
langtools repo, if that's preferred. (Langtools repo is often cloned and 
used standalone, so these standalone checkouts would be bigger, but 
probably not a big problem.)

Thanks,
    Jan

>
> /Erik
>


More information about the compiler-dev mailing list