GWT, Java 17, jakarta.servlet, Eclipse, GWT plugin

[Bob Lacatena]

I am wrestling with a massive effort that has been one stumbling block after another. The core task is to convert a sadly monolithic and archaic app from Java 8 to Java 17.

My current subtask (maybe necessary, maybe not) is to convert everything to use jakarta.servlet rather than javax.servlet, but when I try to declare an import of com.google.gwt.user.server.rpc.jakarta.RemoteServiceServlet, Eclipse just keeps replacing it with the "original" (non-jakarta) path.

I was hoping I could solve this by renaming the gwt-servlet-jakarta.jar file as gwt-servlet.jar, and putting that in war/WEB-INF/lib, but it doesn't change the Eclipse behavior, AND it originally generated an error that the size of that jar did not match the SDK... but after a clean-build that problem (at least) went away.

But my underlying problem is that I have classes that need to extend the RemoteServiceServlet, and access the associated ServletContext, HttpServletRequest, SerializationException and other classes that must all be the jakarta (not javax) versions. 

I can go back to using javax (and I'm not at all certain that the Eclipse embedded Jatty server will use jakarta instead of javax, so maybe jakarta won't work locally anyway)... but then I have to solve a problem where GWT dev mode (with javax) gives me:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module gwt.user not found, required by com.xxxxx.myapp

Or do I have to move into a world where I stop using the so-convenient embedded Jetty and deploy to and run an external server?

Any advice on what to do (or, preferably, a deeper understanding of what is happening) would be greatly appreciated.

[Craig Mitchell]

I would recommend creating a new project with everything that you want to use, get it working how you like, then use that as a template on how you will upgrade your existing project.

For my project that I needed to upgrade from Java 8 to Java 17 (because Google App Engine dropped support for Java 8).  I decided I would go "all-in" and get it onto the latest of everything.  So I needed to switch to use Maven, switch to use a client/server/shared structure, switch to use my own server (I went with Undertow), and switch to use Jakarta.  I also decided to go with Spring Boot (as Google App Engine had examples for that), so I used https://github.com/NaluKit/gwt-maven-springboot-archetype to create a sample project, and used that as a guide on how to upgrade my existing project.  Oh, and I also switched from Eclipse to IntelliJ.

It was a big job and a lot of work, but now everything is running beautifully, so worth it in the long run.

[Wejden Mrabti]

hello!

@Craig it looks great what you have done!

@bob I am working on same migration acutally, It looks that the embedded Jetty in GWT DevMode has been deprecated in GWT 2.11 due to classloader issues and other complexities. To avoid these problems, you can try  transition to a dedicated servlet container like Jetty or Tomcat for both development and production. You can deploy your war file using Docker or a Maven plugin. Ensure that your development environment is set up to deploy to this dedicated servlet container instead of using the embedded Jetty. You can check the updated GWT Getting Started Guide  (https://www.gwtproject.org/gettingstarted-v2.html )for detailed instructions on setting up your project and development environment, making the transition from Java 8 to Java 17 smoother.

[tim_mac...@yahoo.co.uk]

This might help: its a different solution to the issue Craig dealt with.
Its an extension of the gwt multi-module sample with an embedded Jetty,
for Java 11 without Spring.
https://github.com/timmacp/AppEngineGwt/tree/main

[Jens]

1. You do not have to use Jakarta if you want to migrate to Java 17. You can very well stay on javax and first make the JDK transition work

2. GWT's embedded Jetty is always javax because it is version 9.4.xx. The use of GWT's embedded Jetty is officially deprecated and you should use your own Jetty installation (local, docker image, maven/gradle plugin, ...). This is especially true if you want to use Jakarta.

3. GWT 2.11 publishes *-jakarta dependencies that you can use once you start moving to Jakarta.

4. GWT Compiler only supports source level 11 so far

I use Java 11 for GWT client side code and Java 21 + javax for server side code. Needless to say that I have split client, shared and server code into their own projects. This is the recommeneded project layout these days because it gives you dedicated classpaths for each project and the option to use different JDK versions.

-- J.

[Thomas Broyer]

On Wednesday, June 12, 2024 at 11:27:27 AM UTC+2 Jens wrote:

Needless to say that I have split client, shared and server code into their own projects. This is the recommeneded project layout these days

 * checks notes *

I've been advocating for it for more than 12 years now, and had been using it for nearly 2 years already at the time. Java 8 would be released more than 2 years later.

(and note that this is –in terms of filesystem layouts– mostly due to how build tools like Maven and Gradle work, also IDEs if you want smooth integrations –although I'm sure IntelliJ IDEA could adapt to many layouts–; this can be entirely different with Ant or Make, and definitely is different with tools like Bazel/Buck/Pants/etc. Anyway the crux is to understand what you're doing, and why you're doing it, which means understanding how things work: classpaths, build classpaths, GWT Compiler, GWT DevMode/CodeServer, build tools, IDEs, etc.)

[Bob Lacatena]

Thanks for all the replies.  None of them directly addressed my needs, but in combination they all provided enough understanding to help me make some decisions:

Clearly the GWT plugin/installed Jetty are not Jakarta-ready.  I could try to update and rebuild the plugin to make it so (maybe), but I'm so overwhelmed with other chores that I can't afford having that turn into another rabbit hole.  It's easier/safer/wiser to go back to javax.

That still does not solve my larger problem of getting the web app to run... but it seems that must be unrelated to which servlet-api I use, so again, goodbye Jakarta-servlet.

I think I recognized it myself, but the advice to move to away from the embedded Jetty seems unavoidable, as it is deprecated.  It's just so darn convenient.  I also have never found clear examples on how to set to that up, what the pitfalls may be, how it will work, etc.  I'm sure I can figure it out... it's just not something I want to diverge into doing (but it seems at this point I must). 

MEDIUM ASK: Can anyone point me to better documentation or a tutorial or a how-I-did-it-blog post on getting that set up?  Like I said, I can figure it out, I'm sure, but I'd rather do it the quick/easy/no-wasted-time way.

The suggestion of breaking GWT into separate projects has some merit, as part of my entire problem is that, as I said in my intro, I am dealing with a massive, monolithic project that tries to do everything alll in one package.  In general, it would be wise to refactor that into multiple projects (not only around GWT, but other things like the build process, report generation, image generation, the Swing desktop app, and other facets).  Sadly, everything is so intertwined, and there is so much code, that doing so will be a massive effort, and this is just one of many high-pressure/short-timeframe projects on my plate, so I'm going to need to find the best/least-effort path in refactoring to make things work (with a longer-term project of continually refactoring things out).

I may consider falling back to an earlier version of Java, maybe 11, but I'm unsure if that will help.

I may also be having the problem because to solve many of my dependency conflicts I created a module-info.java file for my project.  I don't actually need to treat it as a module, except that the side effects of using "requires" within the module-info file solve those conflicts, and I can't otherwise solve the problem that, for example, GWT and Ant both define a BuildException class (among other myriad name conflicts).  But again... that problem can be at least sometimes solved by breaking the code up where conflicts occur (which again is off the time to due time/effort/budget conflicts).  Moving all of the GWT code to one project, or to three (client/shared/server), and the build code (Ant tasks) to another, and other code to other places, could help... 

An alternate option might be to rewrite the entire build process to use Maven or Gradle (many other, newer, smaller projects here use Gradle), but again... that's a massive detour that I'll take if I must, but it seems possible that this upgrade effort will wind up getting shelved before I have time to do that.

SMALL ASK: Could GWT rename its BuildException class to GwtBuildException, to better support the twilight world of leaving Java 8 without entirely moving to modules?

Anyway, thanks for all the helpful input.  The main points of "don't use jakarta yet", "abandon embedded Jetty", and "refactor your disastrously monolithic kaiju into something realistic" all help.

That said... I'd still like to at least have a better understanding as to why I get "Error occurred during initialization of boot layer", "java.lang.module.FindException: Module gwt.user not found, required by com.xxxxx.myapp" when the GWT container is in the class path, as well as if I explicitly add the gwt-user.jar to the path in the Run Configuration or into WEB-INF/lib (like get-servlet.jar).

[Colin Alworth]

> Clearly the GWT plugin/installed Jetty are not Jakarta-ready.  I could try to update and rebuild the plugin to make it so (maybe), but I'm so overwhelmed with other chores that I can't afford having that turn into another rabbit hole.  It's easier/safer/wiser to go back to javax.

If you mean the dev mode app server, there is no plan to do that _in gwt itself_, but there is an extension point in GWT that would let you do it yourself. Someone else has been thinking about building a small ecosystem around this in the issue tracker, but I haven't seen any movement here - see the discussion at https://github.com/gwtproject/gwt/pull/9866. We could easily have a jetty-12 impl, letting you run either jakarta or javax servlets, or switch to other servlet containers, and control as much or as little of the setup as you want.

If you mean a particular plugin that you use with GWT, there are so many possible plugins out there, we can't guess which one isn't working for you. Most should be able to let you run your own external server though, or specify your own server using the -server argument (and implement it yourself, as linked/discussed above).

> MEDIUM ASK: Can anyone point me to better documentation or a tutorial or a how-I-did-it-blog post on getting that set up?  Like I said, I can figure it out, I'm sure, but I'd rather do it the quick/easy/no-wasted-time way.

If using maven, check out the modular-webapp archetype for a very light example, at https://github.com/tbroyer/gwt-maven-archetypes/. If not, please give us more detail about what you are using (or intend to use).

> SMALL ASK: Could GWT rename its BuildException class to GwtBuildException, to better support the twilight world of leaving Java 8 without entirely moving to modules?

GWT doesn't have a BuildException class - can you give the fully qualified class name of the type that is irritating you? I see that Ant has such a class, and Gradle too, might you be thinking of one of those?

[Bob Lacatena]

@Colin, thanks for getting back to me on this.  I couldn't reply right away because my wife was getting cataract surgery; it's not that this wasn't important.

> If you mean a particular plugin that you use with GWT...

I'm using the Eclipse GWT 4.0.0 plugin you guys recently completed (using the updated build, to fix the "support Eclipse 2024-03" issue; thanks for that).  I think in your lingo I therefore mean the dev mode app server.  I might look into that myself to get jetty-12 implemented, but for now I've abandoned jumping to jakarta as "a bridge too far" and am trying to solve my issues another way (likely by grumbling, rolling up my sleeves, and refactoring the mess the way it should have been done to start with, and the way I would have demanded had I worked here when it was first bungled).

> If using maven... [I'm not]... If not, please give us more detail about what you are using (or intend to use).

After further investigation, much of my issues around this seem to be that the. appropriate java command to run the web app (or Jetty itself) is not being assembled correctly by either Eclipse, the GWT plugin, or both.  There are various options that are needed and are not properly set.  That said, even if I do/can get that working, I don't think that's the right approach.  As you're going to deprecate the embedded Jetty server, I should do whatever is needed there to run my own external server(s).  That's what's unclear to me.  There are ancient references to it in the documentation at gwt.project.org, but I'm unclear on what is really needed.  Do I need to set up and run a code server with my own Jetty or Tomcat local installation?  If so, how is that set up?  Or do I need to run my own app server (again, either Jetty or Tomcat).  The web app setup is obvious (I think... or are there special runtime parameters to direct it to the proper code server port?).  Forgive my ignorance on this, but if this is the path forward for GWT in general, I'd really like to see some clear documentation on how to set this up or at least what it is going to look like (in general, no specifics, obviously it should involve thinking and work on my part). Last note: I am assuming the code server will be easier to get working with Java 17 modules because it will (in my case) have less jar dependencies, as it only needs them for shared and client code.  That said... I might need to run both externally to get it all sorted out.  Again, my own thinking on this isn't that clear because I'm not in the weeds enough on what the plugin is really doing and how things work under the hood.

To give a shorter, more direct answer: I want to develop code in Eclipse in Java 17, and be able to run the code server and web app any way possible, so that GWT code compiles/recompiles as needed, and the web app can be accessed in the browser, and I can do iterative test-code-test-code development on a daily basis.

> GWT doesn't have a BuildException class

This was my bad.  When I got the conflict I assumed it was something in gwt-dev.jar related to GWT, but upon further investigation (unpacking the jar), I see that the conflict is caused because the ant BuildException.class file is embedded in the get-dev.jar (and possibly because the package/path is com/google/gwt/thirdparty/apache/ant/BuildException.class rather than Ant's org/apache/tools/ant/BuildException.class.  A recurring problem in upgrading to Java 17 comes from class name/version exceptions that are now verboten.  My current solution of getting Ant out of this project will have to do (as it's better architecture anyway, and should have been done by my predecessors on day 1, i.e., don't bundle custom Java ant tasks with the application code).

[Jens]

> If using maven... [I'm not]... If not, please give us more detail about what you are using (or intend to use).

After further investigation, much of my issues around this seem to be that the. appropriate java command to run the web app (or Jetty itself) is not being assembled correctly by either Eclipse, the GWT plugin, or both.  There are various options that are needed and are not properly set.  That said, even if I do/can get that working, I don't think that's the right approach.  As you're going to deprecate the embedded Jetty server, I should do whatever is needed there to run my own external server(s).  That's what's unclear to me.  There are ancient references to it in the documentation at gwt.project.org, but I'm unclear on what is really needed.  Do I need to set up and run a code server with my own Jetty or Tomcat local installation?  If so, how is that set up?  Or do I need to run my own app server (again, either Jetty or Tomcat).  The web app setup is obvious (I think... or are there special runtime parameters to direct it to the proper code server port?).  Forgive my ignorance on this, but if this is the path forward for GWT in general, I'd really like to see some clear documentation on how to set this up or at least what it is going to look like (in general, no specifics, obviously it should involve thinking and work on my part). Last note: I am assuming the code server will be easier to get working with Java 17 modules because it will (in my case) have less jar dependencies, as it only needs them for shared and client code.  That said... I might need to run both externally to get it all sorted out.  Again, my own thinking on this isn't that clear because I'm not in the weeds enough on what the plugin is really doing and how things work under the hood.

To give a shorter, more direct answer: I want to develop code in Eclipse in Java 17, and be able to run the code server and web app any way possible, so that GWT code compiles/recompiles as needed, and the web app can be accessed in the browser, and I can do iterative test-code-test-code development on a daily basis.

Traditionally GWT SDK only had the class com.google.gwt.dev.DevMode. It is responsible to launch classic dev mode (the one that does require an obsolete browser plugin) or SuperDevMode together with an embedded servlet container, by default Jetty. SuperDevMode is implemented in class com.google.gwt.dev.codeserver.CodeServer and DevMode basically calls this class if you request it to launch SuperDevMode (which is the default behavior). Class DevMode has a parameter "-noserver" which skips starting Jetty and assumes you have your own server and deployment running. Because we advocate running your own servlet container, e.g. Jetty/Tomcat/..., it is enough to just launch CodeServer yourself. However you could also continue to use class DevMode and replace the embedded Jetty with your own implementation using DevMode -server your.impl.of.ServletContainerLauncher. Your own implementation could then be based on Jetty 12 for example (and possibly jakarta)

Personally I use Gradle and have a task that just launches CodeServer by executing a command line. I am pretty sure you could also write a similar ANT task using your current ANT setup. The command line looks like 

com.google.gwt.dev.codeserver.CodeServer -sourceLevel 11 -strict -failOnError - bindAddress 0.0.0.0 -port 9876 -style PRETTY -XmethodNameDisplayMode ABBREVIATED -workDir /client-project/build/gwt/work -launcherDir /client-project/build/gwt/war -src /shared-project/src/main/java -src /shared-project/src/main/resources com.example.MyGwtModule

The classpath should contain gwt-user/gwt-dev/gwt-codeserver, all compile-time dependencies you need for GWT compilation as well as classes + sources + resources related to your GWT UI and DTOs. You would need to use ANT fileset/dirset/files to include/exclude only the files of your single project that are relevant for GWT compilation. Once you have that set of files figured out you can run GWT CodeServer in isolation via ANT with its own GWT focused classpath and you should not have any trouble with other dependencies that you need on the server only.

Once you have that running, you need to decide how you want to run a servlet container. Personaly I use Docker + docker-compose + Jetty image + shell script.

 

[Craig Mitchell]

It's when you see crazy long command lines like that, you start to appreaciate Maven (or Gradle).  The same command in Maven is "mvn gwt:codeserver -pl *-client" (yes, I know you see still need to setup the launcherDir, warDir, etc in the pom.xml files, but that seems much easier than one huge command line).

[Dyllan Sowers]

Does anyone have an example of how to setup the embedded server with dev mode, or even better, super dev mode? I'm upgrading a large Gradle-based enterprise application from Spring 5 to Spring 6 and migrated from javax to jakarta and have had constant issues from Jetty's compatibility problems. 

Any pointers would be a tremendous help. I'm currently trying to use tomcat-catalina-10.1 as the embedded server but have not been able to get it to start properly. 

[Michael Conrad]

You might want to look into using Gradle Gretty plugin for the container service in combination with starting up SuperDevMode via command line.

--
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/e391c8f6-c957-481a-bd83-8f9cf1803353n%40googlegroups.com.

​

[Dyllan Sowers]

Thanks for the suggestion, Michael. Do you know of any examples of anyone successfully doing this? I've found one older example but have been running into issues trying to port it over to a more recent Jetty plugin and Gradle version. https://github.com/libgdx/libgdx/blob/master/tests/gdx-tests-gwt/build.gradle 

[Dyllan Sowers]

I should elaborate, the main issue I'm running into is having to do with upgrading to Spring 6 / Jakarta Servlet 6. I'm trying to use either Tomcat 10.1 or Jetty 11 to launch the container service with Gradle tasks and the org.docstr.gwt:1.1.30 plugins and org.gretty:4.1.6 plugins with GWT 2.12.1. I've tried many different combinations of configurations and plugins, but ultimately run into this error every time: 
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/ContextHandler$Context

[Michael Conrad]

Are you using gradle :appRun or gradle :farmRun?

Is your project split up into top level + server + shared + client? or just client? or all merged together?

We also use the “farm” option in the top level project to launch backends + frontends on the same instance of TomCat each with its own context path based on war name.

-Mike

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/279d54a8-834b-40c5-8f0e-3bc23ee54a7bn%40googlegroups.com.

​

[Dyllan Sowers]

I've very recently been exposed to GWT, so I apologize if any of the following doesn't make sense. 

The project is split up, with the GWT XML at the top level alongside the SpringBootApplication launcher class and client and server packages. The application itself is launched with Spring's bootRun + Tomcat, and historically developers used GWT's integrated Super Dev jetty servlet with Eclipse and IntelliJ's GWT plugins. The 'org.docstr.gwt' version '1.1.30' Gradle plugin was being used to compile and launch super dev, and I would like to continue to use it to compile since attempting to compile directly with Gradle tasks invoking the SDK fails without any helpful information. I've determined that is a class path size issue, and the v1 org.docstr.gwt Gradle plugin sets up the class path in a way that works much better with this project (it's multi-Gradle-module and gargantuan, I'd rather not delve into that). 

Is what I need to do to launch the server the way it typically is (with Tomcat) and then invoke the com.google.gwt.dev.codeserver.CodeServer class via a Gradle task? Or com.google.gwt.dev.DevMode with superDev enabled and noServer? 

I have not gotten anything else to work yet. Any recommendations are greatly appreciated. 

[Jens]

Is what I need to do to launch the server the way it typically is (with Tomcat) and then invoke the com.google.gwt.dev.codeserver.CodeServer class via a Gradle task? Or com.google.gwt.dev.DevMode with superDev enabled and noServer? 

There is no real difference. DevMode was the main class used to start GWTs development mode which did start an embedded servlet container and a GWT development server. The classic GWT development server required a browser plugin but browsers changed their APIs and it does not work anymore (unless you use an ancient browser). Thus SuperDevMode was introduced and implemented in a dedicated main class called CodeServer.

Today the DevMode class basically allows you to choose one of four combinations:

- launch servlet container: yes or no (if yes, the default is Jetty 9.4.x or you can provide a custom launcher class to start any servlet container)

- launch classic GWT development server or launch GWT SuperDevMode

The DevMode class can be useful in IDEs to start both processes in one go but in general I would recommend using CodeServer directly and then figure out the best way to manage the server deployment of the project (IDE managed, build tool managed, manually managed local installation, docker container). Since you use Gradle a general recommendation is to have at least two gradle modules, one for GWT code and one for server code. The reason is that you then have two separated classpaths and GWT dependencies do not conflict with server dependencies.

-- J.

​

[tekkyru]

When I switched to Gradle I had to leave GWT plugin behind on advice of other users here, and it was good. Finally I have decoupled classpaths of my app, GWT, GWT plugin and Jetty (latter 2 are never used anymore).

For that I have created a GWT dev server launch task for my configuration: Gradle, Eclipse, GWT, Tomcat. It can be sub-optimal (to say the least) as it was my first Gradle project.

I have my webapp project in Eclipse, I have set up the Eclipse Tomcat server for it, I launch it normally (run or debug) and I launch this Gradle task as an Eclipse external tool (or could be done from console):

gradlew.bat gwtCodeServer -PworkspaceDir=${workspace_loc}

The quoted task unfortunately is not runnable as is, it's an excerpt from a complex project. I hope it can give ideas or even be adjusted to be runnable from your build script.

Please note the gwtToolsClasspath at the end:

 - it's not provided by default, I'm sorry I cannot provide a workable state for this post now, 

it's a configuration that refers GWT tools and all your GWT-related java and resources (as GWT compiler looks them up in classpath).

At least it includes 

    "${gwtPomBase}:gwt-dev:${gwtVersion}"
    "${gwtPomBase}:gwt-codeserver:${gwtVersion}"

--------------------------------------------------------

task gwtCodeServer(type: JavaExec) {

    description = 'Run the GWT code server for Super Dev Mode'
   
    def workDir = "$buildDir/tmp/gwt"
   
    mainClass = 'com.google.gwt.dev.codeserver.CodeServer'
   
    jvmArgs = ['-Xmx1g', '-Dfile.encoding=UTF-8']
   
    doFirst {
    def wspServerPluginDir = file(project.getProperty("workspaceDir") + "/.metadata/.plugins/org.eclipse.wst.server.core")

    if(!wspServerPluginDir.isDirectory()) {
    throw new GradleException("Not a directory: ${wspServerPluginDir}\n"
    +"Workspace referenced by 'workspaceDir' project dir does not exist "
    +" or it has no 'org.eclipse.wst.server.core' configured yet")
    }
    
   
def webAppDirs = []
    file(wspServerPluginDir).eachFileMatch groovy.io.FileType.DIRECTORIES, { new File(wspServerPluginDir, "${it}/wtpwebapps/${rootProject.projectDir.name}").isDirectory() }, {
    webAppDirs.add it
    }

if(webAppDirs.size() == 0) {
throw new GradleException("Webapp ${rootProject.projectDir.name} is not yet deployed, publish it in Tomcat at least once")
} else if(webAppDirs.size() > 1) {
throw new GradleException("There are several webapp dirs deployed for same webapp ${rootProject.projectDir.name}, inconsistent state")
}
   
def gwtTargetDir = "${webAppDirs[0]}/wtpwebapps/${rootProject.projectDir.name}"
    args = []
    args += ['-launcherDir', gwtTargetDir, '-workDir', workDir]
    args += ['-logLevel', 'INFO', '-style', 'DETAILED',  '-sourceLevel', '17', '-port', '9876']
    args += [__INSERT_MODULE_NAME__]
   
    println "Run GWT Code Server: " + args
    classpath.from gwtToolsClasspath
        file(workDir).mkdirs()
    }
}

[Dyllan Sowers]

Is it correct to say that I have to have a separate class path specifically for running SuperDev so that Jetty will function properly? Or is there some way to launch Super Dev without interacting with Jetty at all? My application compiles and launches just fine with Tomcat 10.1 + Spring 6, but Super Dev won't launch due to compatibility issues with Jakarta Servlet 6 and Jetty 9. 

Unfortunately, it's very difficult for me to configure a separate class path specifically to run Super Dev with a lower servlet spec due to the size of this application and intertwining of client and server classes. It quite honestly might be faster to just try and upgrade the Super Dev code to use a new version of Jetty that works with Jakarta 6. 

[tekkyru]

Yes SuperDev can work without Jetty (well, without at least explicitly using it), you don't need it at all.

The web app should be developed and debugged in real environment, and Eclipse WTP platform allows for just that, selecting your brand of the webapp server. No need for an inaccurate substitute.

SuperDev can and should be launched as separate application then there will be no JAR mess. Then your web app will not be aware of the SuperDev app at all, about its classpath, web server it uses, etc.

A browser will load the javascript code generated by the SuperDev from your java sources on the fly, from the SuperDev running as a standalone web app (Jetty or whatever, used to deliver the transpiled code to browser).

The Javascript code (compiled from your java sources) will communicate to your own server (configured in Eclipse) through GWT calls.

[Dyllan Sowers]

Turns out my issue was from a version mismatch between different versions of Jetty being pulled onto the class path and the CodeServer class was bombing out from missing methods that were removed in the newer Jetty versions. Hard forcing Gradle to take the exact versions of all the Jetty dependencies that GWT uses fixed the problem. 

Thank you for helping me get through this! 

[Colin Alworth]

What you're trying to do is supported, and we're working on ways to make it easier - the trick is that you need to keep the jetty-for-your-app on a classloader separate from the jetty-for-devmode. Discussed above is ways to keep them in entirely different JVMs (which is the best way to do this), but GWT DevMode has long since has ServletContainerLauncher which lets projects define their own factory for starting up the app container, as separate from what the compiler will serve its own output.

A new project that aims to provide easily wrapped servlet containers in their own classpath can be found at https://bitbucket.org/upperlimit-public/gwt-devmode-server/src/main/ (with more discussion at https://groups.google.com/g/google-web-toolkit-contributors/c/7jvGVaiSUdI). From that thread, preliminary artifacts have been published that could allow you to use Jetty 11 (with jakarta.servlet), for example by adding this to your client project's classpath:
io.bitbucket.upperlimit-public:GWT-DevMode-server.impl.Cargo.installed.Jetty11.jakarta:0.0.11

Then, start DevMode with -server net.upperlimit.tools.GWT.DevMode.server.impl.Cargo.installed.Jetty11.jakarta.DevModeServerLauncher added to your arguments.