Hi there, we are “Java 17 None At All”. For development, we use javas 1.8-11 (actually a couple years ago I've tried 12, bumped into some problems — can't recall details, too long ago — and from then up to now, I stick with 11 or lower). Deployment is mostly 1.8, but there's one ancient Xserve which still runs a couple of not-too-important internally-used applications on a 1.6 :)
All the best, OC > On 10. 12. 2022, at 16:36, Aaron Rosenzweig via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > 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/ocs%40ocs.cz > > This email sent to o...@ocs.cz
_______________________________________________ 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
