|
I'm not totally sure, because I haven't tried to migrate wonder to 17 yet, but I think
it's possible. With regards to compiling ERExtensions with Java 17, I did that, saw your error, and corrected it on ERExtensions:
I
updated the /pom.xml file to source/target 17 instead of 1.8.
I
added an exclusion to JavaWebObjects in the same file, excluding com.webobjects/JavaXML.
I deleted the WOWebServicePatch.java, because I don't want to drag in Apache Axis with
all its vulns for something nobody uses anyway. I removed the reference to it in ERXApplication.
In ERExtensions/pom.xml, I added dependencies for javax.servlet/servlet-api/2.5 and xerces/xerces/2.4.0.
I would probably do this in the parent IRL and manage the dependencies there, but for this quick test, that's what I did.
And now ERExtensions compiles without error in eclipse. There are a few other projects
that have compile errors and need some repair for a full Java 17 patch to be attained. Some are really old and I don't know if anyone even cares about them anymore.
From: WebObjects & WOnder Development <webobjects-dev@wocommunity.org> on behalf of Aaron Rosenzweig <aaron@chatnbike.com>
Sent: Monday, December 12, 2022 11:47 AM
To: WebObjects & WOnder Development <webobjects-dev@wocommunity.org>
Subject: [WO-DEV] Re: duplication in frameworks: ERExtensions, javaeoaccess
Thanks Ramsey but now I’m more confused.
Can we compile for Java 17 compliance or not? Before it sounded like you said it wasn’t possible but now it sounds like you are saying it is possible.
I tried to take one WOnder project, ERExtensions, and make it compile for java 17 but I couldn’t get it to work in Eclipse. Files like ERXApplication.java complain: The package org.w3c.dom is accessible from more than one module: <unnamed>, java.xml
I’m not adding a module-info.java or trying to force it in any way to have extra jigsaw JMPS bells and whistles. If I make it compile for java 1.8 (like the .project file does in WOnder) then it’s happy. Change it to java 17 compliance and it
fails.
In our own app, where we include things like “com.webobjects.eoaccess.EOAttribute” I get: The package com.webobjects.eoaccess is accessible from more than one module: ERExtensions, javaeoaccess
I only tried creating a module-info.java to see if that could buy us anything but I don’t think it can.
I’m looking at your docker project right now. You mentioned it earlier but I didn’t understand and still don’t really. I’m not wanting to use docker right now… but maybe your point is that this is a simple WO app using Java 17 that happens to
be in docker. I’m looking around the project in GitHub that you made and see that it is pretty simple, like a proof of concept. Thank you. Is it possible that it’s so simple that there aren’t any conflicts with duplicate package definitions in different jars?
Have you been able to do this with an large/real project?
If Java 17 compliance is possible, what am I missing to be able to do it in Eclipse?
Did you have a chance to look at
It uses Java 17, and it works
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.
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.
>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.
[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.
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.
|