Mailing List webobjects-dev@wocommunity.org Message #400
From: Ramsey Gurley <Ramsey.Gurley@practicemojo.com>
Subject: Re: [WO-DEV] duplication in frameworks: ERExtensions, javaeoaccess
Date: Fri, 9 Dec 2022 23:28:42 +0000
To: WebObjects & WOnder Development <webobjects-dev@wocommunity.org>
>If we are targeting Java 17 compliance

I don't really see any need for WOnder to go java 17 in source. There's not a lot of active development happening in Wonder, so it would be unnecessary work to do that and limit backward compatibility with those still using 8. I just care that it continues to build without errors using the latest java. That's what origin/master should do now.

As you pointed out, without access to source, it is getting harder and harder to drag WebObjects into the future.


From: WebObjects & WOnder Development <webobjects-dev@wocommunity.org> on behalf of Aaron Rosenzweig <aaron@chatnbike.com>
Sent: Saturday, December 10, 2022 6:37 AM
To: WebObjects & WOnder Development <webobjects-dev@wocommunity.org>
Subject: [WO-DEV] duplication in frameworks: ERExtensions, javaeoaccess
 
[You don't often get email from aaron@chatnbike.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

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?
#############################################################
This message is sent to you because you are subscribed to
  the mailing list <webobjects-dev@wocommunity.org>.
To unsubscribe, E-mail to: <webobjects-dev-off@wocommunity.org>
To switch to the DIGEST mode, E-mail to <webobjects-dev-digest@wocommunity.org>
To switch to the INDEX mode, E-mail to <webobjects-dev-index@wocommunity.org>
Send administrative queries to  <webobjects-dev-request@wocommunity.org>


Confidentiality Notice: This email, including all attachments and replies thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and are legally privileged. This information is confidential, and intended only for the use of the individuals or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this transmitted information is strictly prohibited. Please notify us if you have received this transmission in error. Thank you.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster