> On May 15, 2023, at 8:56 AM, Ron Pressler <ron.press...@oracle.com> wrote:
> 
>> 
>> The issue is that release-specific code may need to use deep reflection to 
>> fix bugs or compensate for limitations in a specific set of JDK releases.
> 
> But mucking about with JDK internals requires the application’s approval as 
> it threatens integrity. 
> 

An important detail here, is that changes in the JDK which cause existing Jar 
files to stop working destroy the ability of apps to be deployed as a jar, and 
this breaks the “run anywhere” paradigm of Java.  It’s just not the case, at 
all, that Java applications are deployed in concert with a particular release 
of Java being released.  Jar files are completely different from executables 
which may be “32-bit” vs “64-bit” library linked.  Instead, we end up with all 
the problems that are just like Microsoft requiring compatibility “settings” on 
a .EXE for “Windows 95 compatibilty” or “Windows 98 compatibility” etc.  

The java app as a “service” focus of most of what the current JDK changes and 
development seem centered around is just not the only way/place that Java is 
used.

Gregg Wonderly

Reply via email to