JEP 247: Compile for Older Platform Versions

[joe darcy]

Hello,

On 5/4/2015 3:39 AM, Jan Lahoda wrote:
> 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.

The simplest way to implement -platform would be to shove ct.sym/rt.jar 
files for each supported release into the JDK. For space reasons, both 
in the installed image and in our source code repository, that was not 
the chosen approach.

Note that a simple annotation-based system cannot easily represent all 
the possible version-specific information about a type. Consider:

* In JDK 9, a class introduced in JDK 7 is retrofitted to implement an 
interface from JDK 8. (This sort of transformation has happened.)
* Annotations which impact compilation, like @Deprecreated, are added or 
removed.

It is a non-goal of this effort to create yet-another big interface for 
Java programmers to rely on beyond the API which is being supported.

-Joe