Yes Aaron. I think you are correct.

My app is in Java 17 compliance mode. When I built the wonder frameworks I was using Java 17 and maven from the command line, not from within eclipse. I didn't do anything to enforce Java 17 compatibility mode so it could well be that wonder was built in Java 1.8 compatibility mode.

Tim

Thanks Tim, your comment is helping connect the dots in my brain but I’m not fully up to speed yet. 

Would it be a correct to say that anyone wanting to target Java 17 compatibility mode compilation, should wait until WOnder reaches the v8 milestone? 

I don’t see any “module-info.java” declarations anywhere, is that what’s coming with the WOnder v8 release? 

Are you sure you are compiling your WOnder frameworks with Java 17 compatibility mode using Maven? When I look at the pom.xml it has a JavaXML dependency which includes conflicts with the “java.xml” named module in Java 17. I don’t see how this could work unless it is compiling for Java 1.8 compatibility mode. 

Look at this file: https://github.com/wocommunity/wonder/blob/master/Frameworks/Core/ERExtensions/.settings/org.eclipse.jdt.core.prefs

Lines 14, 16, and 107 are forcing eclipse to build with Java 1.8 compliance

If we remove that, and go for Java 17 compliance, it won’t work. So Tim, I think your own app may be in Java 17 compliance mode but the frameworks are not built that way. 

On Dec 7, 2022, at 7:23 PM, D Tim Cummings <tim@triptera.com.au> wrote:

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 https://github.com/wocommunity/wonder/pull/998 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.

Tim

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/sun.security.action=ALL-UNNAMED

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 <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>

#############################################################
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>