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

[Jan Lahoda]

Hi Magnus,

On 21.5.2015 13:21, Magnus Ihse Bursie wrote:
> Hi Erik and Jan,
>
> Erik's modifications look much better to me.
>
> I'm just not entirerly satisfied with how this new symbolgenerator tool
> fits int our model. It's really a buildtool, similar to the other
> buildtools we have.
>
> First of all, the location is not really ideal. Compare with how the
> java build tools are stored, e.g.
> jdk/make/src/classes/build/tools/charsetmapping. Correspondingly, I
> believe the symbolgenerator should live in
> $TOP/make/src/classes/build/tools/symbolgenerator. This makes it clear
> that it's source code, leaves room for native build tools, and sets up a
> common package prefix (while build.tools.<foo> might not be ideal, it's
> the same as in the JDK build tools, so let's keep it).

Sure - I'll move it.

Thanks,
    Jan

>
> Second, and this is more of a open question, mostly directed at Erik,
> shouldn't we build the symbolgenerator tool at the buildtools phase? It
> might require slightly more work to adapt the buildtools system for the
> top level, but I believe it is much more in line with what we got.
>
> /Magnus
>
> On 2015-05-21 11:42, Erik Joelsson wrote:
>> Hello Jan,
>>
>> On the build changes there are some things I would like to change.
>>
>> * The creation of the ct.sym file should be done in a separate file,
>> with a separate top level target. The images target should just be
>> about linking and pulling things together, not actual
>> building/compiling of things.
>> * The calls to MakeDir are not needed.
>> * There are missing prerequisites in the rule for creating the symbols.
>> * The jar file creation should use the SetupArchive macro.
>> * Intermediate build files should be put into the $(SUPPORT_OUTPUTDIR).
>> * I think it makes sense to have the ct.sym file be part of the
>> exploded-image.
>>
>> Since this was quite a lot of changes, I took the liberty of
>> implementing them. Here is a webrev with my suggestion for build changes:
>>
>> http://cr.openjdk.java.net/~erikj/8072480/webrev.01/
>>
>> /Erik
>>
>> On 2015-05-21 09:01, Jan Lahoda wrote:
>>> Hi,
>>>
>>> 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/
>>>
>>> Overall, one can imagine '-platform N' to have the same effect as
>>> '-source N -target N -bootclasspath <APIs-for-N>'. The possible
>>> values for 'N' are pluggable in a limited way, though (see
>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java).
>>> Note that this patch only introduces N=7 and N=8, which correspond to
>>> Open JDK 7 and 8 GA.
>>>
>>> A tricky problem to solve is where to get the APIs for platform N.
>>> The proposal is to include history data in the textual format inside
>>> the OpenJDK repositories (the input data), process them at build time
>>> and create a lib/ct.sym file holding the data in the JDK image. javac
>>> running with the -platform option then compiles against the
>>> lib/ct.sym file. The input history data are placed
>>> <top-level-repository>/make/data/symbols (the sym.txt files). This
>>> patches only includes data for OpenJDK 7 and 8, and only for public
>>> APIs (more or less Java SE and JDK @Exported APIs).
>>>
>>> The size of the history data is currently ~6MB in the JDK checkout
>>> and ~650kB inside the .hg directory (the size could change
>>> significantly if additional classes/elements, like non-public API
>>> classes, would need to be included). The lib/ct.sym file is currently
>>> ~4.5MB.
>>>
>>> The ct.sym file is a zip file containing signature files. The
>>> signature files are similar to classfiles (so javac can read them as
>>> classfiles), but are missing some attributes, most notably the Code
>>> attribute. On the top-level, the ct.sym contains directories named
>>> "7", "78" and "8". When compiling for version 'N', the bootclasspath
>>> for that version is obtained by using directories which have 'N' in
>>> their name.
>>>
>>> The sigfiles for ct.sym are created by
>>> <top-level-repository>/make/tools/symbolgenerator/CreateSymbols.java.
>>> The same file can also be used to construct the sym.txt files.
>>> Concise instructions are part of the CreateSymbols.java.
>>>
>>> I am sending this as one review, as the changes together make one
>>> feature, but the langtools and top-level changes are independent to a
>>> great degree: the langtools changes add the "-platform" javac; and
>>> the top-level changes add the history data and ability to build the
>>> ct.sym file. If desired, these could be pushed and/or reviewed
>>> independently.
>>>
>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan
>>> Bateman and others who have provided advices and help on the matter
>>> before.
>>>
>>> Any insights/comments are wholeheartedly welcome.
>>>
>>> Thanks,
>>>     Jan
>>
>