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

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

I was thinking for a while about whether I should reply at all or not,
because there is danger of straying too far off topic. But FWIW, here is
my answer to your question:

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.),
the maintainers wish to avoid changing development parameters like
compiler source/target levels, even if the code maybe runs on a recent
JVM. Imagine an application with millions of lines of code (LoC), in
which the compiler now targets 17 instead of 8, just because someone
fixed a bug and used a new Java language element or API like virtual
threads. 50 LoC determine compilation for 50 million LoC. Is that so
smart?

Don't get me wrong, I am not actually advocating developing new software
on an old language standard or not upgrading software which still is
under major active development. In those cases, I am all in for
upgrading compiler levels or using recent ones to begin with, because
quite probably the trade-off is positive. But chances are that legacy
applications which are just kept running until something better replaces
them would yield a negative trade-off.

Me just being a hobby developer - I have been an agile coach for the
last 18 or so years in my day-time job - I simply report what I see at
various big IT companies or departments across industries and how I
judge it. Near end-of-life software is a reality, and even though I
think refactoring is an underrated development practice and many
rewrites would be unnecessary, if developers would hone their ability to
work with code written by others more thoroughly, it is not happening on
a broad scale, i.e. decisions need to be made what to do with legacy
software. Not unnecessarily changing compilation parameters just because
it gives us that bubbly (and false) feeling of being more up-to-date
when using compiler target 17 for an application with source level 8, is
one of the things I see as an upside. It is just a detail, but a pretty
important one. The legacy application can still run on a recent JVM with
regular security fixes, better JIT and GC etc.

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


Timothy Spear via jdt-dev schrieb am 28.03.2024 15:09 (GMT +01:00):
> 
> If you are running JRE 17, why are you limiting the source code to Java
> 1.1?
> What value does compiling to an older version of Java provide? In fact I
> have found multiple SAST/DAST tools which flag the code as a problem if
> compiled to EOL versions of Java. And like you stated earlier, there has
> been and likely will continue to be very minimal breaking changes in the
> language.
> 
> So what is the upside? Besides, demonstrating running a Java version of
> PacMan written in Swing 0.1
> 
> 
> Tim
> 
> 
> On Thu, Mar 28, 2024 at 9:49 AM Alexander Kriegisch via jdt-dev
> <jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> > wrote:
> 
>> I do not follow. Compiling to target 8 or 1.5 does not mean to actually
>> run the code on JDK 5 or 8. I know dozens of legacy applications in bank
>> IT running on JDK 17 or 21, but e.g. maintained as source/target 8. I
>> understand that you are encouraging the JDT Core team to drop older
>> compile targets, and I acknowledge that there are good reasons to do so,
>> but security is none of them in this context.
>> 
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>> 
>> 
>> Timothy Spear via jdt-dev schrieb am 28.03.2024 14:43 (GMT +01:00):
>> 
>> > I mostly work in the FinTech space. So cyber security is a significant
>> > concern; which also means not being able to use a Java version which
>> > is EOL.
>> >
>> > I am not sure what is the correct metric, maybe support one release
>> > past EOL.... With this in mind, I would rather see some sort of
>> > policy/guideline instead of approaching it on an ad-hoc basis.
>> _______________________________________________
>> jdt-dev mailing list
>> jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> 
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>