[External] : Re: Disallowing the dynamic loading of agents by default

[Andrew Dinn]

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 <adinn at 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
>