On Dec 11, 2022, at 9:14 PM, Ramsey Gurley <Ramsey.Gurley@practicemojo.com> wrote:

Did you have a chance to look at

https://github.com/nullterminated/wodocker

It uses Java 17, and it works

https://github.com/nullterminated/wodocker/blob/master/pom.xml#L77

I think the main confusion is thinking we have to use jigsaw post-java 8, but that's not a requirement. There's no module-info.java in that project, but it still works like WO always did.

Wonder can probably be updated similarly, but I see no need to cut off anyone still using 8 just so one of the three patches received a year can use a switch expression or something like that :) Maybe when JEP 182 kicks in and Java 8 can no longer compile with latest JDK, then there is more reason to update it. That said, I'm also not against updating to 17 or whatever the latest LTS happens to be if everyone loves that idea.

---

From: WebObjects & WOnder Development <webobjects-dev@wocommunity.org> on behalf of Aaron Rosenzweig <aaron@chatnbike.com>
Sent: Saturday, December 10, 2022 10:59 PM
To: WebObjects & WOnder Development <webobjects-dev@wocommunity.org>
Subject: [WO-DEV] Re: duplication in frameworks: ERExtensions, javaeoaccess

 

Thanks Ramsey, 

To be clear, your situation is that you develop and deploy on a Java 17 VM but you compile for Java 8 (1.8). This affords you a modern VM with any of the latest security and timestamp updates. It also affords you the use of Apple WebObjects and WOnder with little effort (besides the ALL-UNNAMED tweak). 

Did I get that correct (at least roughly?) 

I want to be clear about it because it’s easy for someone to say or hear “They are on Java 17” and not fully interpret what it means. I think all of us, if we are “on Java 17” are running in 1.8 compliance mode. 

On Dec 9, 2022, at 6:28 PM, Ramsey Gurley <Ramsey.Gurley@practicemojo.com> wrote:

>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 athttps://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.

---

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.