cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Help us improve the PTC Community by taking this short Community Survey! X

Eclipse JDK8 to JDK11 Issue: Package is accessible from more than one module

VC_9391477
3-Newcomer

Eclipse JDK8 to JDK11 Issue: Package is accessible from more than one module

When trying to compile the Windchill Customizations (developed originally using JDK 8/Windchill 11) using JDK 11 (Windchill 12) we are getting compilation issues due to several packages being accessible from multiple modules.

 

For ex: org.w3c.dom package is now included in jdk11 jar by default (Module Path), but is also present in ie3rdpartylibs, xmlParserAPIs and dom4j jars (Class path).

 

We understand that JDK 11 is enforcing a modularity check to ensure the same package is not referenced in multiple jars. However it is also understood that module-info.java is not necessary to be configured for JDK 8 to 11 migration. As long as the relevant jars are added to the classpath, the code should be able to compile using JDK 11 as well.

 

How does PTC handle these issues when working with JDK 11 and Eclipse (version 4.16)?

 

VC_9391477_0-1599513136249.png

 

ACCEPTED SOLUTION

Accepted Solutions

Thanks for the reply.  Very informative.

The problem that I'm facing isn't that a package exists in multiple JARs.  The conflict that I'm running into is where a package in one of the JARs is also included in the JDK distribution.  For instance org.w3c.dom is in the WEB-INF/lib/ie3rdpartylibs.jar and is also provided in jdk11 (Corretto).  I wasn't aware that there was a way to resolve this without removing that package from ie3rdpartylibs.jar.  There are other packages in ie3rdpartylibs.jar that we need, so I need to leave that on my classpath.

 

Dan

View solution in original post

9 REPLIES 9
aacciano3
14-Alexandrite
(To:VC_9391477)

I am really interested about this issues.

@VC_9391477 

Have you found a solution?

@wsaad , maybe you can help us or point out to the correct reference?

It seem there are really only 2 options here ...

  1. Set compiler compliance to 1.8.  This results in a warning that the compiler (11) and compliance (1.8) are mismatched.
  2. Repackage PTC provided JAR files to remove the duplication.

I not a fan of hiding problems, but I'm going with option 1 for now and hoping PTC will clean up the JAR files in a future release.

avillanueva
22-Sapphire II
(To:DC_8714414)

Another option:

I experienced similar issue when updating from java 8 to java 11. Steps below helped me,

  • Right click Eclipse project > Properties > Java Build Path
  • In Libraries tab, remove all the external jar files under Modulepath and add them under Classpath (you can just select all the jars and drag them under Classpath)
  • Click Apply and Close

Note: JRE System Library will remain under Modulepath.

DKWc
15-Moonstone
(To:avillanueva)

Thanks.
It solved for me.

Hi,
the srcLib folder is intend to deliver all dependencies used to build Windchill including their transitive dependencies.

The ie3rdPartylib and the wc3rdPartyLib are sub sets built using either infoenginejars.xml or windchill3rdPartyJars.xml ant script located inside the srclib folder. Those ant scripts are intend to merge some single jars coming from the srclib into one uber-jar and strip of duplicates.

Thus, you should remove your duplicates from the classpath to get rid of your conflicts. Also, you could use one of the common dependency management solutions like gradle or maven to manage your jars. PTC does not deliver their codebase and transitive dependencies by such a dependency management solution outside PTC itself. Therefore, you have to install maven (nexus or jfrog artifactory) or gradle on your local infrastructure and deploy all your necessary dependencies on your own.

If a dependency is missing, deploy it from out of the srclib to maven/gradle server and extend your class path or maven dependencies for your project.

Best regards,
Tiemo Vorschuetz - INNEO Solutions

Thanks for the reply.  Very informative.

The problem that I'm facing isn't that a package exists in multiple JARs.  The conflict that I'm running into is where a package in one of the JARs is also included in the JDK distribution.  For instance org.w3c.dom is in the WEB-INF/lib/ie3rdpartylibs.jar and is also provided in jdk11 (Corretto).  I wasn't aware that there was a way to resolve this without removing that package from ie3rdpartylibs.jar.  There are other packages in ie3rdpartylibs.jar that we need, so I need to leave that on my classpath.

 

Dan

aacciano3
14-Alexandrite
(To:DC_8714414)

Dan,

 

I recall reading somewhere that JDK Corretto is not supported on the client side and you will still have to use the oracle one.

I am not sure if this is your use case though.

 

Antonio

PTC acknowledged and addressed this issue with a workaround in CS348994,  https://www.ptc.com/en/support/article/CS348994?source=search

avillanueva
22-Sapphire II
(To:DC_8714414)

So, my intern and I just spent some time banging heads against the wall on this issue due to "org.xml.sax" package. We had import for SAXException in our code just for exception handling. The ant script that is downloadable from CS348994 does not resolve this conflict so needs modification. I guess the reason why PTC has not closed on a severe SPR was because they realized there was more work to do. In the end, we removed the reference to work around the issue but here is what I think needs to be done.

 

The conflict is in the ie3rdpartylibs.jar file and this package also exists in Amazon Corretto JDK 11.  The exclusions section needs to have "org/xml/sax/**/*" added. 

 

<target name="ie3rdparty" description="Creates/distributes Windchill eclipse JARs">
<jar destfile="${lib.dir}/ie3rdpartylibs.jar" zip64Mode="as-needed">
<zipfileset src="codebase/WEB-INF/lib/ie3rdpartylibs.jar" excludes="javax/xml/**/*,org/w3c/dom/**/*,META-INF/*.RSA,META-INF/*.SF"/>
</jar>
</target>

 

Now, we did not know what this ant script would, if it modifies the existing jar files on the server. It does not, those remain as they were. It creates 5 new jar files with the conflicting packages removed. Those you can copy off and use in Eclipse for compilation. They will replace any original jar files like  ie3rdpartylibs.jar so you can remove them and avoid this issue.

Announcements

Top Tags