Greeg,
I won't respond point by point to your comments as I cannot see any
great value in doing so. I really only want to make one general comment
about your account below, which is that you appear to me to be relaying
your own experience as a desktop Java user and universalising it to all
users and uses of Java. While I acknowledge that you are correct to
state that there can be problems with maintaining a consistent desktop
setup for Java I'll counter that with two important qualifying arguments
which undercut your account.
Firstly, the problems that you describe are general ones that apply when
it comes to software configuration management for a highly user-specific
and often, in consequence, highly variable environment like a desktop.
They are not problems that are specific to Java or other language
runtimes. Even within that category many runtimes, especially language
runtimes, suffer from problems with installed version mismatches and in
many cases these have been notably far worse problems than Java (as for
example the Python 2/3 fiasco mentioned by Andrew Haley). However, that
is not to say that the problem lies with the runtime itself.
Version management problems cannot simply be resolved by preserving Java
(or any other deployed software) in aspic. At least some minimal level
of upgrade of a runtime like Java is needed to deal with emerging
security and critical functional problems. However, in the longer term
any platform will also need to incorporate larger scale modifications in
order to cater for the continuous, dramatic change that we have seen and
continue to see in all hardware and operating systems. Java has not
stood still over the last 25 years for very good reasons.
Your reply suggests that you are unaware of the reality that those who
manage non-desktop deployments plan very carefully around this need to
adapt deployments to updates. Your lament that (your and others')
desktop management does not include such provision may reflect the
reality of some (but definitely not all) individuals or organizations.
However, that lack of provision attests not to any failing on the part
of the developers of Java but rather to a lack of organization,
understanding and adequate preparation for *necessary maintenance* on
the part of those responsible for managing said desktops.
Which brings us to the second point: your complaint omits to allow for
the enormous efforts that Java developers perform to enable Java users
to rely on and profit from exactly the sort of continuity that you
misguidedly claim Java does not provide. We are currently maintaining
reliable, secure and bug free versions of jdk8, jdk11, jdk17 which allow
users to continue to run applications that were originally deployed many
years ago and will do so for many years to come. Indeed, as with many
other large-scale, organized open source software infrastructure
projects, this is the primary focus of the OpenJDK team. The number of
people involved in maintaining legacy releases of Java to support
existing users far outweighs those involved in developing new releases
and new features.
Users who put in the work needed to manage the configuration of their
desktop environments can easily use these legacy releases to maintain
their own desktop applications. It's not a free lunch -- admins of the
desktop systems need to have at least a moderate understanding of how to
configure their systems in order to maintain applications that rely on a
specific Java platform release. However, to claim that the OpenJDK devs
have not made this possible, worse to claim that Java has actually
poisoned the well for desktop users, is a ridiculous and ignorant assertion.
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
On 28/03/2023 04:34, Gregg Wonderly wrote:
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
