| This issue might be solved like explained here: https://stackoverflow.com/questions/53245628/jdk9-automatic-modules-and-split-packages-dependencies
We could possibly make a framework that includes ERExtensions along with the Apple frameworks and treat that as a single module.
It's not exactly the same situation. In the stackoverflow case, they had the same package path but different objects in each.
We have not only the same package path, but also the same Object.
Am I barking up the wrong tree? Any advice on how to reach Java 17 compliance for compiling?
The package com.webobjects.eoaccess is defined in both: ERExtensions, javaeoaccess
javaeoaccess is a framework from NeXT/Apple.
I believe ERExtensions recreated a distinctly apple package name so that we could replace Apple's _EOExpressionArray with a new one from Wonder.
This worked because if we load ERExtensions before JavaEOAccess.framework… in the class path, the first one wins. Old JVMs would happily take the first. While this is risky, it worked as long as we were careful (and sort of knew what Apple was doing). We did things like this because we didn’t own JavaEOAccess and basically “patched it” because we wanted an improvement that Apple didn’t provide. We could do better than Apple and this is how we did it, while letting the rest of the Apple plumbing continue working with particular object replacements.
This cannot work past Java 1.8 can it? If we are targeting Java 17 compliance, we are then using JPMS (Java Package Module System) aka “Java Modules” which won’t accept this type of patch.
In my application project, I created a module-info.java and placed these lines in it:
requires ERExtensions;
requires javaeoaccess;
We need both lines right? But this results in the the following unsurprising error:
The package com.webobjects.eoaccess is accessible from more than one module: ERExtensions, javaeoaccess
What am I missing? Are we stuck? Without being able to update the Apple jars directly, the old hacks cannot work in the new word of Java Modules. We’ve done this in many places including NSArray. Are we stuck living in Java 1.8 compliance with Java 17?
|