Mailing List Message #392
From: D Tim Cummings <>
Subject: Re: [WO-DEV] When add-exports ALL-UNNAMED is not enough (Java 17)
Date: Thu, 8 Dec 2022 10:23:28 +1000
To: WebObjects & WOnder Development <>
I am using Java 17 compatibility mode in eclipse 2022-09 and I use Java 17 in my deployment environments.

All my projects are maven based so I think that makes it easier. I don't have to build Wonder frameworks. However, I did try recently building Wonder frameworks in Java 17 using maven and did need to comment out ERProfiling and ERXiss in Frameworks/Misc/pom.xml to get the build to complete. I don't use those two frameworks so this was not a problem for me.

During the discussion on regarding updating wotaskd and JavaMonitor for Java 17 it was decided that Wonder 7.4 would stay compatible with Java 8 when it is released and the next version of Wonder (8?) would target Java 17 as the supported baseline.


On 8/12/22 08:42, Aaron Rosenzweig wrote:
Hi WOrriors,

I’m upgrading to Java 17 from Java 1.8 and have run into snags in my local Eclipse workspace. Perhaps you’ve struggled with this too?

In general, this VM argument is helpful but not enough: --add-exports java.base/

The issue has to do with changes from Java 1.8 and java modules.

I can use 1.8 compatibility mode with my workspace (from Java 17 VM) and there are no errors and no problems.

When I change to Java 17 compatibility mode, it falls apart.

My java apps are ok, but many of the WOnder frameworks don’t build anymore.

For example ERAttachment. I have this error: The package org.xml.sax is accessible from more than one module: <unnamed>, java.xml

To me that means that it is available in a system module “java.xml” and also in some old jar file… two places.

I clicked on ERAttachment (in WO Explorer pane) and then right click to do "build path" and then "configure build path." I then went to the last tab "Module Dependencies" clicked "java.xml" and then clicked "remove." It gave me warnings that other things use it but I did it anyway. Now the errors are gone for org.xml.sax.Attributes and similar imports. Yay!

I’m not done yet but I did similar things as follows:
• ERAttachment - remove java.xml
• ERRest - remove java.xml
• ERChangeNotificationJMS - remove java.naming
• ExcelGenerator - remove java.xml
• ERPDFGeneration - remove java.xml
• ERSelenium - remove java.xml
• ERXiss - remove java.xml
• DRGrouping - remove java.xml
• ERJaxWS - remove java.xml
• ERProfiling - lost cause? jdk.internal.loader is inaccessible so I closed the project in my workspace (and am not currently using it).

I’m still coming to grips with all this but I have following unresolved and possibly incorrectly stated questions:

1) Do most of us run with 1.8 compatibility in newer JVMs and leave it at that?

2) Do some of us run with newer VM compatibility modes (to access new features of Java) but then use “ALL-UNNAMED” hacks along with removing system module hacks like I was talking about above?

3) Do some of us use pre-built jars of Wonder and not build from source in our Eclipse projects to get around some of these issues? But if so, that means it’s not as nice to just dive into the source code and quickly trace / change things as we are working...

4) Should we consider putting WOnder frameworks into module friendly configurations? Or is that not possible because we need to support Java 1.8 too?

5) What is the best way to use Java 17 VM along with any new java syntax / functionality while still using WOnder frameworks?

Thanks to all for reading this far :-)
— Aaron
This message is sent to you because you are subscribed to
   the mailing list <>.
To unsubscribe, E-mail to: <>
To switch to the DIGEST mode, E-mail to <>
To switch to the INDEX mode, E-mail to <>
Send administrative queries to  <>

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster