gwt-dev contains common java classes (like org.w3c.dom), causing conflicts

[butlnor]

I don't know the reasons why "gwt-dev.jar" contains a lot of "garbage", like the whole "org.w3c.dom", which causes conflict with Java 9+, since DOM is already present in JRE, and Java 9+ module system doesn't allow same packages in different JAR files.

Please make sure that gwt-dev.jar is build without such common libraries! It is completely wrong to pack stuff, that is already present elsewhere. Currently, I will have to strip those classes out of JAR file, but this means I will have a modified custom JAR file, so it will not work with other team members (unless we all use the same modified JAR).

[tbroyer]

Get the JARs from the Central Repository, they don't contain those classes. The JARs from the ZIP distribution are designed to be "easy to use" from simple scripts (including Ant without Ivy), so you don't have to list too many files in your classpath (also, I don't think GWT works with the module path / JPMS, but AFAIK even those fat jars work with Java 9+ as long as you only use the classpath).

[butlnor]

Hm, in Maven central repo, there is really a smaller file. But this is chaotic, having two different JAR files. Shoudn't it then be better to name the first one as "gwt-dev-full.jar"?

I understand, that sometimes it's better to include some 3rd party stuff, to simplify the building, but NOT including the common stuff like org.w3c.dom, which is already included in every JRE! It's ok to include things like Apache commons or similar, but not JRE things.

[butlnor]

Well, the one in central repo has too few classes... missing almost every 3rd party lib, so I have to add them manually.
I think the solution now it to use the JAR from ZIP, but remove all those wrong classes from it, that should never be there.

[niloc132]

We can look into removing this, as GWT only supports Java 11+ at this time.

That said, you can you describe the problem that this is causing, how you're able to use the gwt-dev.jar with JPMS? I would be very surprised to find that gwt-dev.jar's classes work when loaded from JMPS, with or without these types present. Especially for these types, gwt-dev.jar would need java.xml explicitly as a module dependency to use as you describe?

If there's a concrete benefit it probably makes sense to overhaul with #10011, as that will need lots of testing to be sure that shaded/uber jars behave as expected in all supported use cases. Including other dependencies also causes problems, so I don't like how comfortable GWT has historically been with this either.

[butlnor]

It was enough to strip out "org.w3c.dom". This seems to be the only problematic inclusion. Since JRE already contains those classes.

So, if you just omit org.w3c.dom, I think this will suffice.

[niloc132]

So that we can add some semblance of testing to this use case, can you describe or demonstrate how you're running, and give details for the problem that is happening? If this is a requirement of the tool, we need to be able to verify that the fix works.

Also, can you be specific about how you've used this in the past - is this a new project, or are you just now updating from Java 8 so that this is becoming a new problem?

[CrushaKRool]

If it helps, I can describe how this issue (albeit with other classes) causes problems in our use-case and requires us to modify the gwt-dev.jar as well.

In our setup, we use the GWT Eclipse Plugin, which ultimately uses the fully packaged JARs from the ZIP distribution instead of Maven Central.
The plugin will add its own Classpath Container with the contents of the GWT SDK to the Eclipse classpath. This GWT Classpath Container needs to come even before the Gradle Classpath Container because otherwise we would run into GWT compilation problems when starting the SuperDevMode, due to using a newer version of the ECJ compiler dependency than what is used by GWT.

But that means that all the older packaged classes from the gwt-dev.jar are shadowing the actual newer dependencies that we would get from Maven via Gradle. We ultimately have to remove the org/apache/tomcat/ and org/apache/commons packages from the JAR because they conflict with current versions of an embedded Tomcat (which we use to deploy GWT locally) and other Apache Commons dependencies such as Commons-Lang3 and Commons-IO. Without these modifications, we would eventually run into NoSuchMethodErrors when our code makes calls to methods that do not exist yet in the older class definitions included in the GWT SDK.

Note that this is only an issue during local development in Eclipse. When we build the actual distribution of our application via Gradle and reference only the necessary Maven dependencies without the gwt-dev.jar, everything works fine.
And in IntelliJ, it also seems to work out correctly (I think because they handle the classpath differently for local development than what Eclipse does).

[jnehlmeier]

@CrushaKRool The root cause is that you have a single project which contains the GWT/client code and server code. You then only have a single classpath for two very different things (Java -> JS compiler vs. server application).

That is why we recommend for long now that you should use dedicated projects (e.g. client, shared and server/webapp) so you have dedicated classpaths. Then you do not have these kind of issues at all. Given that you use Gradle it should be easy to split your project. The Getting Started tutorial has also been updated to reflect that.
The legacy project layout is ok for small demo projects but as soon as you start building your real app and require common libraries on server side the trouble begins.

[CrushaKRool]

@jnehlmeier We do have a project separation and are far from a small demo app. But I suspect the separation is in the wrong place then, because the "client" project also contains the GWT RPC servlets (using the dependencies provided in the GWT SDK) and the "server" project contains all code that is agnostic to GWT. We then have a "common" project that contains data classes used by both server and client, as well as some glue code that can delegate calls from the GWT servlet part of the client to the internal server.

It works like this for the most part, but at some points there are runtime dependencies on the client project from the project that is responsible for launching the embedded Tomcat during local development - at which point the GWT SDK bleeds into the classpath and caused conflicts with the Tomcat classes until we removed them from the JAR.

The structure grew like this for historical reasons from a Swing-based client before switching to GWT, but I guess it did not adapt the recommended project structure well enough.

Am I correct to assume that you would only use the GWT SDK in the client project and use regular Maven dependencies of GWT in the common/shared and server projects? I must admit that tbroyer's comment in this issue is the first time I even noticed that distinction.
I am also a bit fuzzy on which projects would contain which parts of GWT RPC in this architecture, since it's not really mentioned in the documentation there. E.g. is this how it would be supposed to be structured?

• RemoteServiceInterface -> shared
• RemoteServiceInterfaceAsync -> client
• RemoteServiceImpl -> server

In any case, it's not my intention to derail this topic. What we are using has been working fine for us for many years. We have just accepted these things as GWT limitations and gotten used to avoiding certain pitfalls during development. Although I wouldn't mind hearing that these limitations are just a consequence of our own architectural decisions.

[tbroyer]

You would use gwt-user and gwt-dev dependencies in the client project, and gwt-servlet/gwt-servlet-jakarta in the shared and server projects (and use Gradle's resolution rules to make gwt-user and gwt-servlet/gwt-servlet-jakarta "conflict" and prefer gwt-user in the client project, and gwt-servlet/gwt-servlet-jakarta elsewhere).
I haven't used the GWT SDK "ZIP" distribution for more than a decade 🤷 (haven't used IDE integrations for launching GWT tasks either)

Wrt where to put each part of GWT-RPC, it depends if you want to use different packages in the client and shared projects or not. I'd tend to put both interfaces in the shared project, even though the Async one is client-only.

You can have a look at https://github.com/tbroyer/gwt-maven-archetypes/tree/main/modular-webapp/src/test/resources/projects/basic-webapp/reference for an example using Maven, or https://github.com/tbroyer/gwt-gradle-example for a Gradle example (with a bit "involved" Gradle setup though, you can probably find other, simpler Gradle examples elsewhere though)

[jnehlmeier]

@CrushaKRool As far as I can remember the GWT Eclipse plugin has a feature to detect GWT SDK in the Maven dependencies. The Eclipse Plugin will then not add the GWT SDK with all the repackaged dependencies to your classpath. Instead it uses the Maven version. But I think that feature has never been implemented for Gradle projects (I use IntelliJ, so I don't know for sure right now).

Generally speaking it is better to launch SuperDevMode and GWT compiler using Gradle/Maven to avoid the GWT SDK fat jar provided by the Eclipse plugin. Other than that it is pretty much what you/Thomas said: gwt-user + gwt-dev for client projects, gwt-servlet for server projects and possibly shared projects if you need to. Also gwt-user and gwt-dev should never ever end up in your final *.war file, only gwt-servlet is meant to be deployed. So yes you would need to split the three GWT-RPC service interfaces/classes as you said.