> On Mar 28, 2023, at 4:13 AM, Andrew Dinn <ad...@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
