Received-SPF: pass
 receiver=post.selbstdenker.com; client-ip=209.85.214.178; envelope-from=recurve@cocoanutstech.com
From: Aaron Rosenzweig <aaron@chatnbike.com>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Java 17? Half or Full? 
Message-Id: <A11DF1A3-32AB-4DDD-84BC-C86C6A4C33D5@chatnbike.com>
Date: Sat, 10 Dec 2022 10:42:42 -0500
To: WebObjects & WOnder Development <webobjects-dev@wocommunity.org>

This is both a topic for both pure NeXT/Apple WO as well as a WOnder.=20

Your WO deployments, are they on Java 17? Are they half or full Java 17? =
Please chime in.=20

In our case, at present, we are developing and deploying on a Java 17 VM =
but using Java 1.8 (version 8) compliance. I call this =E2=80=9CJava 17 =
Half"

Definitions:
Java 17 Half -> Developing and deploying on Java 17 but using Java 1.8 =
compliance.
Java 17 Full -> Not only using a Java 17 VM but also targeting v17 =
compliance and using JPMS (Java Package Management System) which was =
introduced with Java 9.=20

PHB -> =E2=80=9CSo I was golfing with my buddies and found out they are =
all using Java 17 *sealed* classes. This is so cool and will =
revolutionize our codebase. I want you to start using it immediately. It =
was introduced with Java 17. I=E2=80=99m so glad we are on a 17 VM.=E2=80=9D=
=20

Me -> =E2=80=9CCan=E2=80=99t do it=E2=80=9D

PHB -> =E2=80=9CWhy not? You told me we went to Java 17 over a year =
ago.=E2=80=9D

Me -> =E2=80=9CWe did and are on Java 17, but we compile for Java 1.8=E2=80=
=9D

PHB -> =E2=80=9CThat=E2=80=99s no good. We need to be fully modern. We =
need to be able to use new constructs as they emerge. Why are we =
compiling for Java 1.8 ? Is it a problem with WOnder?=E2=80=9D

Me -> =E2=80=9CBecause our core frameworks are closed source, from =
NeXT/Apple, our hands are somewhat tied. That=E2=80=99s part of the =
problem. The other part is that class loading changed dramatically with =
Java 9 onward and broke a lot of things for many people. Because we =
leverage so much from Apple and WOnder, we pretty much are stuck. Our =
frameworks are stuck in java 8 compliance and therefore so are we=E2=80=9D=
=20

Definitions:
Old Class loader -> Java 1.8 (version 8) and older.=20
New Class loader -> Java 9 and newer.=20

The new class loader tries to avoid =E2=80=9CJar Hell=E2=80=9D but =
that=E2=80=99s something we actually enjoyed about the old class loader. =
What Oracle saw as a weakness and sought to fix, Sun saw as a strength. =
It=E2=80=99s causing us trouble right now with going Java 17 Full. =
Here=E2=80=99s an example.=20

Consider a jar named =E2=80=9Canimals_v1.jar=E2=80=9D that has classes =
for birds and other creatures. Imagine that there is also a newer =
=E2=80=9Canimals_v2.jar=E2=80=9D Let me diagram them below in =
pseudocode:

animals_v1.jar:
com.acme.Duck.speak()

animals_v2.jar:
com.acme.Duck.speak()
com.acme.Duck.hasFeathers()

Suppose you are using the old class loader and somehow had both jars in =
your class path. It matters which jar is first because the first one =
wins when there are multiple definitions in the class path for =
=E2=80=9Ccom.acme.Duck=E2=80=9D. You could have a situation where things =
compile but at runtime there=E2=80=99s a failure because we can=E2=80=99t =
ask =E2=80=9ChasFeathers()=E2=80=9D and it=E2=80=99s situations like =
these that Oracle considered a design flaw or =E2=80=9CJar Hell.=E2=80=9D=20=


In our case, we considered this functionality of the old class loader a =
strength. As long as we are careful, we can avoid the pitfalls but also =
do clever patching of closed source Apple frameworks like so:

Apple java frameworks:
com.apple.NSArray

WOnder java frameworks:
com.apple.NSArray

By putting WOnder=E2=80=99s frameworks first in the class path, and =
being careful to not remove needed functionality of NSArray, we can =
=E2=80=9Coverwrite=E2=80=9D Apple's implementation with an improved one =
while letting the rest of Apple=E2=80=99s code work directly with our =
NSArray replacement. Unfortunately this breaks the new class loader. =
It=E2=80=99s not allowed. Cannot have NSArray defined in more than one =
named place. Even if we take WOnder out of the equation, we still have =
problems with Apple=E2=80=99s JavaXML framework where it redefines W3C =
and DOM objects that java.xml named module natively defines in modern =
Java.=20

If we want to compile for modern java on new VMs what can we do? I=E2=80=99=
m no expert, so correct me if I=E2=80=99m wrong, but I=E2=80=99m trying =
to make sense of what our options are. There is no easy path. There is =
no set of simple VM arguments or anything magic that takes a small =
amount of effort. We=E2=80=99d have to do something like TreasureBoat =
where we take ownership of the private libraries. We can=E2=80=99t =
surgically replace a few objects in the private libraries anymore by =
class path ordering and I don=E2=80=99t think Aspect-Oriented =
Programming nor Dependency Injection can save us here either. We also =
now have conflicts in pure Apple libraries with what is currently =
built-into Java.=20

How long are we ok using modern VMs but compiling for 1.8? =E2=80=9COK=E2=80=
=9D meaning functional but not allowed to use new Java language =
features.=20

2026 is when Amazon stops supporting 1.8 JVMs
2030 is when Oracle stops supporting 1.8 JVMs

I could not determine when javac compliance level support might be =
dropped for Java 1.8 on modern VMs. That said, I guess it would be at =
least until 2030 when Oracle no longer provides 1.8 VM support. It might =
last longer than that=E2=80=A6 perhaps 2040. Hard to say. Lots of people =
are struggling with JPMS (Java Modules) in similar situations as us. =
Such as this quote: "Your program might even have a dep on some jar that =
was compiled under jdk4 and the author and source are nowhere to be =
found (or went out of business a decade ago)... and suddenly it breaks =
under java9. Things like that are largely what prevented mass adoption =
of jdk9 immediately.=E2=80=9D

We might be able to be creative by taking jars from multiple frameworks, =
putting them in one modularized framework, and exposing something for a =
modern java app. I=E2=80=99m not clear that would work but maybe. I =
think there are Apple frameworks which conflict with named module =
java.xml which likely cannot be worked around. This guy did something =
like this for his legacy frameworks (not WO): =
https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-sp=
lit-packages-dependencies=20

In closing, I don=E2=80=99t think it=E2=80=99s possible without =
rewriting closed-source Apple libraries and also rewriting WOnder to =
target compliance level beyond 1.8. Is there anyone building with =
compliance level beyond 1.8?=20=