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