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

[Gregg Wonderly]

> On Mar 28, 2023, at 4:13 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> 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.

Again, the supposition is that somehow users of software systems are always surrounded by version planning and management.  This is just not the case. People use software for its functionality not because the platform has certain features.  The platform is what enables software systems to be constructed and used.  When the platform changes it’s feature set or design and removes features or disables the default use of those features, that lack of backward compatibility, when unmanaged by the platform, creates havoc for users and software developers who are providing software systems in vertical markets or into communities of users who are not educated or knowledgable enough to understand what any of these words actually refer to. 

> 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.

Your supposition is again that somehow everyone has the benefit of having a guru or appointed party that manages all of their software and versioning needs.  I used the example of corporate users to draw on that environments “random” upgrade timelines.  Users get new machines as something fails or get new versions of software based on “bugs” or “risks” or other drivers that are completely unrelated to software development timelines of third party suppliers of software systems.

Suggesting that just because this has happened historically, that somehow it provides the relief to do it as well is the point I am trying to counter with my arguments here.

> 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.

Removing features and changing how the platform handles features such that software deployment or software systems have to change is the problem.  There are so many things that have been changed to no real advantage to developers.  Java 9 changes for “modularity” were really only targeted changes to try and manage people plugging into private APIs, because the public APIs were not providing needed features and it was difficult or impossible to use the platform without those changes.  This speaks to the ineffective nature of the platform management overall.  Historically, and I assert this over and over, because I was in the room where it happened, Sun was only interested in selling servers.  Oracle is again only interested in selling server/backend solutions and support.  The OpenJDK community is, in fact providing a great service to the community in maintaining JDK versions that avoid forcing the user into incompatible places.  

> 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.

I’ve done backend development with lots of different languages for decades.  I’ve been subjected to Windows versioning, Linux Versioning (Redhat ripping out support for SATA2/SAS controllers in RHEL/Centos 8, cutting the chain for many servers that could easily move to 8, but would require huge customization of the boot to load the driver into the RAM disk) and lots of other versioning things.  But, for a long time, I was on top of what was happening with Java because I was in the middle of things like the Jini community and the desktop communities.  But, it became so painful and unreconcilable if not impossible to deal with the way that Java was being managed, that I gave up.  I have 100,000s of thousands of lines of Java software that I’ve created all over the spectrum.  Yet, its impossible for me to continue to be in the Java communities because I can’t get users interested in Java apps because they are absolutely put off by the version management issues and trying to understand which version of the runtime will work and exactly how they can manage to keep that in place in their environment.

> 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.

I apologize for not including the work that the OpenJDK community does do.  It’s quite remarkable that there is that dedication.  I think that it reflects the same level of commitment I had to Java for some time.  It would be a great platform and a great place to do lots of software that would be portable.  However, the lack of attention to versioning across the portability landscape and the general problems created by continued change in platform behaviors that are not backward compatible are what create a huge problem for Java’s use in communities that are not commercial software systems.

> 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.

Sure these legacy systems are available.  But Java is not really helping the user with incompatible version changes.  You have the problem that Java version installs only happen when people know what to install.  You have the problems with non-elevated-privilege users can’t install new Java versions etc.  There are just so many ways that these types of changes break Java’s write-once-run-anywhere promise and continue to disable existing systems without any details about what actually happened to break things.

Gregg Wonderly