Re: [jdt-dev] Non-javac compiler support for '--release N'

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

I forgot to name my stake in this issue: The AspectJ compiler forks JDT
Core. Therefore, many AspectJ users who are not even conscious of the
fact that they actually use ECJ on steroids, would be affected by
breaking changes there, too. Unfortunately, I do not have a user account
and am thus unable to comment on JDK issues.
-- 
Alexander Kriegisch
https://scrum-master.de


Alexander Kriegisch schrieb am 22.03.2022 08:13 (GMT +07:00):

> How about bumping the JDK issue by commenting? Some (redundant)
> context information right in the ticket might help people screening
> issues for release planning,but not clicking on the mailing list
> thread. A short recap of the actual impact on ECJ, especially what
> would happen/break in case the file format is changed in a new Java
> release, might help motivate someone to actually tackle the issue. At
> least, it would not hurt IMO. Decisions in life are all about context,
> so let's provide some.
> 
> Maybe asking what additional information is required to move the issue
> forward or to at least get some feedback, would be a good idea as
> well.
> 
> 
> Stephan Herrmann schrieb am 22.03.2022 00:04 (GMT +07:00):
> 
>> Caution: the following illustrates the thorny road to disillusionment
>> :)
>> 
>> Some pointers from previous attempts:
>> 
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-December/012786.html
>> 
>> points to 
>> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-March/011736.html
>> 
>> last message in that thread points to 
>> https://bugs.openjdk.java.net/browse/JDK-8199521
>> 
>> which is not moving since its creation 4 years ago.
>> 
>> I believe ecj *must* implement JEP 247, but as you can see from the
>> links nobody seems to be interested in making this possible (in a
>> safe way). What's more: Oracle insists in the right to break existing
>> ecj implementation with each new release of JDK => using older ecj
>> with newer JDK is at the mercy of Oracle. Of course it's ecj that
>> get's blamed when things go wrong.
>> 
>> It simply isn't a level playing field.
>> 
>> best,
>> Stephan
>> 
>> 
>> On 21.03.22 17:07, S A wrote:
>>
>>> to summarize my question, how is a non-javac compiler expected to
>>> support the '--release N' option?
>>> 
>>> E.g. the Eclipse Java compiler utilizes the archive 'lib/ct.sym'
>>> that is available in the JDK distributions. As far as I'm aware, the
>>> structure of this archive has no official specification and  there
>>> is no guarantee that the current structure will remain stable. So
>>> are other compilers meant to use this archive, or was it added
>>> exclusively for javac?
>>> 
>>> You can e.g. see the class comment of the abstraction class that
>>> Eclipse uses:
>>> https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/util/CtSym.java
>>> 
>>> It's a somewhat lengthy attempt to describe the structure of the
>>> archive. Should we (Eclipse/JDT maintainers) request a specification
>>> for this file (that is adhered to)? Or are non-javac compilers meant
>>> to implement '--release N' "on their own"?
>>> 
>>> I ask as we already had some issues in Eclipse, with the use of
>>> ct.sym (if interested, see e.g.
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=562727 and the list of
>>> related tickets). It would be great to know the perspective of
>>> OpenJDK developers on the "external" use of ct.sym.
>>> 
>>> Sorry if this has been asked before, or if this is not the correct
>>> mailing list for the topic.