JEP 247: Compile for Older Platform Versions
Jan Lahoda
jan.lahoda at oracle.com
Mon May 4 10:39:57 UTC 2015
Hi Remi,
Thanks for the comment.
On 2.5.2015 16:02, Remi Forax wrote:
>
> On 04/24/2015 12:30 AM, mark.reinhold at oracle.com wrote:
>> New JEP Candidate: http://openjdk.java.net/jeps/247
>>
>> - Mark
>
> Hi all,
> while i think the goal of this JEP is fine,
> i don't like the fact that the solution is based on ct.sym.
In JDK 8, the ct.sym was a jar file containing almost classfiles
(almost, because the classfiles did not have the Code attribute for
methods that require it).
In the -platform prototype(*), the ct.sym is also a jar file (albeit the
internal structure is different), and it also contains almost classfiles
similar to the JDK 8's ct.sym. To avoid confusion, the files use .sig
extension rather than the .class extension.
>
> We already have a format which is able to describe the public API of a
> class, it's the class file format, this format is already specified,
> well understood by existing tools, which is compact (pack200 ?), the
> only missing information is the version that add and/or remove a member
> (since and deleted since) that can be added as class file attribute.
Older versions of the prototype used an annotation to specify JDK
versions for which given element (field or method) was valid.
Eventually, this got replaced by a system, where, if a sigfile is the
same for versions M and N, the same sigfile is used for both, and when
they differ, there are two sigfiles. This is a simpler system, and the
resulting ct.sym is not much bigger.
Currently, the content of the ct.sym is very simple, and looks like this
(for ct.sym containing data for 7 and 8):
7/ //sigfiles for 7
78/ //sigfiles shared for 7 and 8
8/ //sigfiles for 8
Each for these directories contains sigfiles in their package structure.
To get the bootclasspath for version N, all directories that contain "N"
are used.
(*) The current -platform prototype is in branch "JDK-8058150-branch" in
the jdk9/sandbox forest.
What do you think?
Thanks,
Jan
>
> regards,
> Rémi
>
More information about the compiler-dev
mailing list