Re: [jdt-dev] RFC - Withdrawing compiler support for older versions of J

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

Are you saying, you keep hearing this argument, but think it is somehow
invented? Like I said, I am just reporting what I see in the wild while
coaching clients. I have no stakes there, I do not make any decisions
there and do not need to defend anything. I see this kind of situation,
so I am reporting it and explaining why I understand it.

And no, maintaining legacy software by no means implies to not upgrade
an IDE or runtime JDK. Now speaking for myself as an AspectJ maintainer,
the product uses target 8, AJC can compile pure Java code (without
aspects) to as low as 1.3 (thanks to the ECJ fork), but yet I always
work with the latest JDK and the latest IDE version (IntelliJ Ultimate
in my case). There is no contradiction there whatsoever. And BTW, I
would love to use the latest Java language features and APIs (records,
text blocks, virtual threads and many more), but my impression is that
AspectJ users still love the fact that they can run their existing
applications on JDK 8 despite using the latest AspectJ and JVM versions.
That is because they, too, sometimes need to maintain existing software,
not just start green-field projects every other week. For now, I want to
keep it that way, even though it means less fun for me as a developer.
To remove support for targets older than 8 should be OK, though. I.e.,
in reality we are not far away from each other and from OpenJDK's
deprecation policy.

My point, from which the discussion strayed not due to my fault, was
that security is mostly pseudo argument pro/con deprecating target
bytecode levels in the compiler, because bytecode is just bytecode. Java
21 bytecode is not inherently safer or less safe than Java 8 one.

-- 
Alexander Kriegisch
https://scrum-master.de


Gunnar Wagenknecht schrieb am 28.03.2024 16:07 (GMT +01:00):

>> In my example I mentioned Java 8, not 1.1. That makes a difference,
>> not just concerning byte code verification. Anyway, what is the
>> upside? My experience in bank IT are long product lifecycles, and
>> there are many legacy products which are out of active development in
>> some kind of maintenance mode. The latter calls for stability. While
>> there are still occasional code changes (bugfixes, legally required
>> extensions etc.),
> 
> I keep hearing this argument. FWIW, if someone calls for stability
> they are likely staying on a stable IDE setup as well.Hence, they are
> not updating Maven, Tycho, Eclipse or any other development tool or
> component in such a setup. Thus, I think you can ignore this use case
> and argument in general.