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

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

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.
-- 
Alexander Kriegisch
https://scrum-master.de


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:
>> Hi all,
>>
>> 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.
>>
>> Best regards and thanks,
>> Simeon
>>
>> _______________________________________________
>> jdt-dev mailing list
>> jdt-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev
>