Embedded Jars and Java 17

[Bob Lacatena]

I've been working on a project for a while (posted a related problem some time back) to convert our massively complex software from Java 8 to Java 17.

Almost everything is done, but a recurring problem, one that just reared its head again this morning, as to do with jar conflicts.  [I am so angry with the Java architects for "fixing" the version problem in such an intractable, unmanageable way...]

The problem occurs when another jar (in this case gwt-dev.jar) embeds other class files (in this case org.apache.commons.io) that are otherwise used in our software.

Some questions:

1) What version of commons-io is it within gwt-dev.jar?

2) Is it all of the classes, or only the classes needed/referenced by gwt-dev code?

3) Has anyone else had this problem and found a good solution?

Approaches I am going to try are:

1) Match our commons IO version to the one in gwt-dev (this bothers me, because there may be a lot of recoding on my end) and remove the commons-io jar from our classpath.

2) If that doesn't work, then also rebuild the gwt-dev jar without the commons-io (this won't work until I match our commons IO version to the one gwt-dev.jar embeds).

3) Beg you to solve this problem for me somehow.

[Bob Lacatena]

Two important details I forgot.  This is happening in Eclipse, and the problem is that I get compile errors (probably because of conflicting signatures in the two versions of classes, but also possibly just in how it is resolving finding classes).

Often (not always), the command line compile works (I have not yet tested that in this case)... it's Eclipse that has the issue.

So maybe this is an Eclipse problem, but it's frequently triggered by the nature of the gwt-dev.jar in this case.

[Vassilis Virvilis]

I think that you aren't supposed to include gwt-dev.jar in any classpath (frontend or backend). It is required for compilation and super-dev mode.

I can understand the infighting with eclipse settings though and I sympathize...

    Vassilis

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/b2259293-b34e-48bb-9ae7-22425ebb9d69n%40googlegroups.com.

--

Vassilis Virvilis

[Colin Alworth]

Vassilis is correct - definitely avoid placing either gwt-dev.jar or gwt-user.jar on your server classpath. Ideally, one can do this by splitting your server and client classpaths (into separate projects) - eclipse should then keep jars for one out of the classpath for the other.

GWT currently uses commons-io 2.4 in the compiler itself. There are a number of out of date dependencies in the compiler, but as above, these should never be deployed to your server, and should only present a risk if you provide untrusted data to the compiler - that is, if your project's own source and dependencies are themselves untrusted.

[Bob Lacatena]

So, yeah, that's why it compiles fine on the build server and on my Mac from using javac / Java command line.  I don't have gwt-dev.jar in my class paths there.  And I don't have it explicitly in the Eclipse class path, but I am presuming it is implicitly there (and is the problem) because of course I have this:

<classpathentry kind="con" path="com.gwtplugins.gwt.eclipse.core.GWT_CONTAINER">
<attributes>
<attribute name="module" value="true"/>
</attributes>
</classpathentry>

Or am I making a bad assumption here... does the problem/conflict lie elsewhere?

Another data point... I did not have this problem last week.  I haven't looked at that project for a week or so, and when I updated it (pull from GitHub) this compile issue cropped up, but I can find no change anyone else made remotely related to this, and everyone else (on Windows, I'm on a Mac) does not have the compile problem.

Last data point... I let Eclipse apply updates this week, so it upgraded me to 2024-09 and who knows what else.

I hate this black-box stuff.  Worst problems in the world to try to fix... things where you can't entirely look under the hood (into what's actually going on in Eclipse) to see what is really going on.

[Bob Lacatena]

Okay, my bad.  I looked for one class but not necessarily the right one.  There is another culprit, log4j2 core, that is using a commons IO class (FileUtils), so that is likely the source of the problem.

Sorry for wasting your time... but thanks very much for the quick response, and if nothing else, giving me a wrist slap to make me look more closely at what I'm doing.  [I never made these kinds of mistakes when I was younger.]

[Colin Alworth]

To generally resolve cases like this, your IDE's build should be informed directly by your actual build files, rather than maintaining the IDE build separately. That ensures that the classpaths in the IDE directly match what the CI system or manual builds would produce, and keeps all developers on the same page, without the need for each to manually apply settings or check in build and IDE changes separately.

Build tools usually have their own features to hunt down transitive dependencies: mvn dependencies:tree, or gradle :dependencies would give you a hierarchical view of how transitive dependencies end up on your classpaths (though not, as you were initially suspicious of, how a class could be contributed from more than one jar).