On Mar 27, 2023, at 11:30 AM, Andrew Dinn <ad...@redhat.com> wrote:
> If this is pushed in jdk21 then anyone currently developing or upgrading an 
> app to target jdk21 will only have been able to test on jdk17-jdk20 where 
> they will not encounter the issue. So, his nly leaves them a small window to 
> detect that there will be a problem using agents in jdk21. When jdk21 arrives 
> this may force them to delay deployment or they may even deploy unaware that 
> the problem exists.
> 
> If this is pushed in jdk22 instead of jdk21 then anyone who upgrades from 
> jdk17 to jdk21 will not have a problem. Anyone working on an app for 
> deployment on jdk25 will have the opportunity to test on 3 non_LTS releases 
> which might manifest the potential agent problem before deployment.

This is, again, where the reality that some Java users live in is very 
different than what seems to be known my many decision makers here.  Most 
corporate users of Java don’t control when a particular version of Java is 
deployed into their environments.  It keeps being proposed, that somehow users 
are deploying a specific version of Java and getting an appropriate version of 
an application they use, all at one moment in time.  The supposition that Java 
is “deployed” with a particular software system that uses it, is summarily 
false.  Even Linux releases by Redhat for RHEL, Centos or even Fedora don’t let 
you pick any and every version of Java. Java applications, by the millions were 
written without needing any particular vision of Java, until a version broke 
something major like starting at Java2 (1.2) and then Java1.4 which need a 
dozen fixes and then Java 1.5 that broke huge numbers of desktop apps that did 
not that had not used volatile class values for so many things, including loop 
control values that kept loops from exiting.  Then we had 1.9 that almost went 
out the door disabling every single Spring app in existence.  And there are 
more and more things happening that just do not make much sense in the grand 
scheme of things.  

Overall Java is just not a safe place to take people for the first time.  Many 
have had horrid problems and given up on Java.  For Java1.2, Perforce invested 
huge time to try and create a new desktop app for their SCM system.  They got 
to the point of almost releasing a beta to testers and then summarily threw it 
all away because they just could not make it work for all the things that got 
broke in 1.2.  At my business, we have lots of each device applications where 
it would be a good thing to use, but because of the breakage and issues others 
have experience with Java over the years, their experiences cause them to just 
say no to anything Java.

Java is just randomly upgraded on peoples desktops in their view.  It gets 
replaced by the IT staff at most corps at unrelated moments that they start 
using a particular Java application.  Those corps and their IT staff have 
little to no knowledge of what every Java application is let alone how it might 
be dependent on features that are being changed at each release of the JDK/JVM. 

The end result is that it is a surprise, always for this class of user, which 
version of Java will be available and which application will break this time.

I still have lots of “jar” file applications that I share with others and they 
just double click on those to run them.  It’s that class of user that this Java 
upgrades happen with software updates/distributions process completely 
overlooks.  The Java licensing was always about you could not use Java as the 
sole application platform on a computer.  So, all kinds of “free” desktop apps 
(and applets and Java Web Start) applications were created and used by 
literally thousands of users that are completely out of sight.

I continue to see massive migration away from Java as the first choice for new 
applications amongst developers I talk to. It’s not being taught to most new 
developers I meet.  They hardly even know that Java exists or what it’s capable 
of.  Most developers seem to be taught web front end development tools or .net 
or golang or other languages besides Java for backend dev.

There seems to be little chance that Java will have a place in the landscape 
within the next 5 years or so as those who have used Java since the mid 1990s 
age out of the pool of active developers and are no longer influencing tech 
used.

What a sad tale the last 10 years of Java has been compared to what was 
possible 25 years ago, and should of happened…

Gregg Wonderly 

Reply via email to