More from the JEP 261 backlog

[Jan Lahoda]

Hi Stephan,

regarding ct.sym, my personal opinion: the format was never meant to be 
stable and publicly documented. The format is likely to change around 
JDK 36, if not earlier, when the current way to specify release version 
will run out.

For having an API, there's this filled:
https://bugs.openjdk.org/browse/JDK-8199521

It is likely possible to implement that, but I unfortunately can't 
promise it will be done in any specific release.

In any case, it is not clear to me if using any of the above is 
necessarily reasonable for ecj. Wouldn't it be more appropriate to 
bundle the historical data with ecj? That would seem to improve 
predictability, as a given version of Eclipse would only have to worry 
about one specific (and known) format - instead of being at the mercy of 
whatever ct.sym happens to be defined in the JDK used to run Eclipse.

Jan


On 18. 07. 24 14:16, Stephan Herrmann wrote:
> In thread "[module-imports] Importing java.se" Alex mentioned a 
> planned update to JEP 261. Now I wonder, if this is a suitable point 
> in time to ask again about another specification issue in this area.
>
> JEP 261 lists among the new features a compiler option "--release", 
> which was contributed by JEP 247.
>
> Now, JEP 261 is scope SE, but it "includes" JEP 247 which is declared 
> as scope JDK.
>
> Similar to the discussion in the other thread, this does not answer, 
> how a compiler which is not part of a JDK can possibly implement the 
> "--release" option.
>
> Back at the time, we (Eclipse) had shyly asked for a specification of 
> the format of file ct.sym. This specification was denied (it's 
> internal, subject to change), and also the idea to provide an API 
> instead didn't - to the best of my knowledge - bear any fruit.
>
> As a result the Eclipse compiler had to be based on reverse 
> engineering of existing ct.sym files, and more than once the resulting 
> heuristics were broken by changes in the file format.
>
> It seems that by now the file format has stabilized, so the easiest 
> solution might be to
> + provide a specification of that format, and
> + provide information for which JDK versions this format can be assumed
>
> Please remember, that the Eclipse compiler must as best as possible be 
> able to work with any released JDK out there, past and future.
>
> Most importantly, moving forward we'd appreciate some assurance that 
> our implementation will not be broken again by future internal changes 
> in OpenJDK.
>
> thanks,
> Stephan