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

[Magnus Ihse Bursie]

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).

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
>