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

Erik Joelsson erik.joelsson at oracle.com
Thu May 21 09:42:36 UTC 2015


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



More information about the compiler-dev mailing list