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

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

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

PHB -> “So 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’m so 
glad we are on a 17 VM.” 

Me -> “Can’t do it”

PHB -> “Why not? You told me we went to Java 17 over a year ago.”

Me -> “We did and are on Java 17, but we compile for Java 1.8”

PHB -> “That’s 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?”

Me -> “Because our core frameworks are closed source, from NeXT/Apple, our 
hands are somewhat tied. That’s 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” 

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

The new class loader tries to avoid “Jar Hell” but that’s 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’s causing us trouble right now with going Java 
17 Full. Here’s an example. 

Consider a jar named “animals_v1.jar” that has classes for birds and other 
creatures. Imagine that there is also a newer “animals_v2.jar” 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 “com.acme.Duck”. You could have 
a situation where things compile but at runtime there’s a failure because we 
can’t ask “hasFeathers()” and it’s situations like these that Oracle considered 
a design flaw or “Jar Hell.” 

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’s frameworks first in the class path, and being careful to 
not remove needed functionality of NSArray, we can “overwrite” Apple's 
implementation with an improved one while letting the rest of Apple’s code work 
directly with our NSArray replacement. Unfortunately this breaks the new class 
loader. It’s 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’s JavaXML framework where it redefines W3C and DOM objects that java.xml 
named module natively defines in modern Java. 

If we want to compile for modern java on new VMs what can we do? I’m no expert, 
so correct me if I’m wrong, but I’m 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’d have to do something like 
TreasureBoat where we take ownership of the private libraries. We can’t 
surgically replace a few objects in the private libraries anymore by class path 
ordering and I don’t 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. 

How long are we ok using modern VMs but compiling for 1.8? “OK” meaning 
functional but not allowed to use new Java language features. 

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

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’m 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-split-packages-dependencies
 
<https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-split-packages-dependencies>
 

In closing, I don’t think it’s 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? 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to