Suggestion on upgrading gwt-2.6.1 to latest

[Ankit Singh]

Hi,

We have a project with mixed architecture of client + shared + server (RPCs). with following configurations:

1.  gwt-2.6.1

2.  gwt4nb plugin

3. jdk 1.8

4. gxt 3.1.1 (sencha)

5. payara web server 

6. netbeans 18

We want to upgrade the project in the latest version of GWT. we request you to please suggest on the followings:

1. gwt version we must choose?

2. how will we achieve client debugging (as currently we are using gwt4nb-plugin for the same.)?

3. Which open-source IDE we should opt?

4. Suitable jdk version?

5. Alternative of sencha (as it is paid now, and we are only limited to its grid control).

6. Should we continue with payara? 

7. Do we require splitting of client, shared, server in separate projects or we should continue the same architecture (as this is a quite big project).

 

[Colin Alworth]

GWT 2.6 is just over a decade old - while Java 8 didn't exist at the time it was first released, I see you're still using it. Latest GWT is 2.12, and requires a minimum of Java 11. The first step then is probably to update GWT as high as you can without breaking other things, then update Java to some recent version, then update GWT to latest.

GWT 2.6 supported an early version of Super Dev Mode - assuming that is what you were using, the way to use it has changed a bit, but is still present. No browser supports legacy Dev Mode (which used a browser plugin), so if you were using that, you'll need to set up some new dev guidelines for how to debug your application.

GXT 3 has always been paid, but at that time they were still releasing GPL versions, so that is what you are using. It is likely to have problems running with newer than about GWT 2.8, but the fix is easy (and since it is GPL, you can edit that yourself, just change the broken call to getResourceMap().get... with .getResource... ).

I've never used netbeans except as an experiment, and can't really help there. I pay for my own IDEA ultimate version, though not for the GWT support - you can either use the community edition, or Eclipse with the GWT plugin, but will need to make your own decision.

One other topic not mentioned - a project from that era is likely using ant, and probably should be updated to Maven or Gradle.

Quick recap using your numbering:

1. Aim for GWT 2.12, but you probably need to pause briefly at GWT 2.11 until you can drop Java 8.

2. Super Dev Mode - you do not need a browser plugin for this or specific IDE tools (unless you want them), just anything that can debug JS with sourcemaps to show the original Java.

3. Up to your own preferences, requirements - anything that can edit Java and understand your project setup should suffice.

4. Aim for Java 21+, but wait until you are using GWT 2.11, and then figure out what it is going to take to get your server updated too - likely that will be a bigger hurdle.

5. Actively developed UI toolkits I'm aware of include DominoUI and DnComponents

6. Payara still exists and is maintained. There are other good choices too. Without understanding your server code or requirements, one can't easily answer this. Odds are, updating the server is going to be a bigger task than updating the client.

7. Separation is a good idea, but not absolutely required. There are many benefits you will see here, from avoiding many classes of bugs, to faster compilation. As you consider your build system, also consider if this is some tech debt that can be paid down now and help your project going forward.

Please email me off-list at co...@vertispan.com if you're looking for more guidance or assistance - our company regularly helps with projects like this, keeping existing projects alive by updating them without requiring a total rewrite with each platform shift.

[Neil Aggarwal]

> Actively developed UI toolkits I'm aware of include DominoUI and DnComponents

 

Interesting. I checked those out and neither of them seem to have a canvas
widget.  Did I miss it?

 

Thank you,

 Neil

 

--

Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com

We offer 30 year loans on single family houses!

[Colin Alworth]

I think the important question should be "what do you expect in a canvas widget"? If all you want is "the same calls JS can make", just working with the raw DOM element and its context will get you everything you need, and you can easily embed that into any other widget toolkit.

GXT 3 and others (lienzo? I'm sure I'm forgetting something else) also offered some vector drawing abstraction on top of canvas that allowed persistent, animated lines/shapes/etc. That can get complex/opinionated/expensive, and many users would just want to use the raw context2d or webgl directly via elemental2.

[Neil Aggarwal]

> "what do you expect in a canvas widget"

 

I am not exactly sure.  This is all a bit new to me.

 

When I look at the canvas class in GWT, it does not have
methods to support zoom so I would have
to write my own code for that functionality.

 

Looking at the canvas class in SmartGWT, it has methods
for zoom so I can let the library handle it.

[Colin Alworth]

If you want "zoom controls", that won't work nicely with a raster format like canvas, unless you either are ready to draw everything in waaay too much detail so that zoom works at all, or have some hooks to redraw at each zoom (which... no longer would be about "drawing", but about managing what is visible, what is clipped out of view, etc?). Or, you want a vector graphics tool, either like SVG, or some abstraction on top of canvas that rasterizes your set of infinite-precision lines/shapes to the canvas at each frame.

The only zoom I see in smartgwt's canvas is "zoom overflow" settings, which looks to be more about browser zoom level (controlled by the user, outside the page) than zooming in to your own view. If that is specifically what you are after, I _believe_ you can simplify that down to just correctly handle hdpi, as a distinct operation from overflow? https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Optimizing_canvas#scaling_for_high_resolution_displays shows that this is pretty straightforward to manage? It has been a few years since I worked on low-level canvas operations, but I think that is the common setup to need, depending on how you want to handle a user trying to zoom in this way (e.g. "let the user zoom like they would an image" vs "try to stop them from changing the actual format" vs "try to scale only text, but keep absolute positions the same", etc).

If I were designing/picking a drawing tool, I'd want a lot more clarity on exactly what is required, because there's a lot of wiggle room in what these terms could mean.

[Tim Macpherson]

Was or is there a GWT library for SVG ?

I ended up using D3 though 3 or 4 JsInterop classes, D3 was what I needed for reactive diagrams.

Yahoo Mail: Search, Organize, Conquer

--
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/61482f4a-db23-4b0d-83c4-342902cf5ba8n%40googlegroups.com

.

[Colin Alworth]

I don't know about Lienzo, but GXT charts (as of 3.0) supported VML and SVG out of the box, then I added a Canvas/context2d implementation around GXT 3.1 or so. 

SVG isn't awful to work with, it is mostly just raw DOM manipulating, plus the excitement of building paths.

D3 is pretty well liked too, I'd have no qualms about suggesting it either.

Canvas tends to be (much) faster to draw a given frame, but must be redrawn for any changes, as changes are additive. SVG gives access to dom elements and lets you listen to mouse/etc events, which can be easier than building your own intersection checking. YMMV, measure before you cut, etc.

[Neil Aggarwal]

> The only zoom I see in smartgwt's canvas is "zoom overflow" settings

 

I am sorry, I was not clear in my earlier message.  Their DrawPane class

has a method called setZoomLevel.

 

They posted a demo of it:

https://smartclient.com/smartgwt/showcase/?autotest=showcase#zoom_and_pan

 

I have no idea how it works, I don’t need to.

 

I used it in my app and it is working well.

[Craig Mitchell]

> When I look at the canvas class in GWT, it does not have methods to support zoom so I would have to write my own code for that functionality.

You use the canvas context:

Canvas myCanvas = Canvas.createIfSupported();
myCanvas.getContext2d().scale(2, 2);

🙂

[Neil Aggarwal]

> myCanvas.getContext2d().scale(2, 2);

Colin says doing that will pixelate the view.  Is that correct?

[Colin Alworth]

Neil, I'm not sure where I appeared to have said that. The last link I gave provided a way to calculate the values that might be passed instead of the 2s there, but 2 is a reasonable value for HDPI situations. In 1x situations it will use about 4x the memory required by being too-high of resolution, but it will at least zoom in a little without being blurry. If you're going to hardcode it rather than compute it, you could do worse.

[Neil Aggarwal]

> Neil, I'm not sure where I appeared to have said that.

 

I am sorry, I did not intend to put words in your mouth.

That was my understanding from your previous email stating
that  canvas is a raster format.  I misinterpreted your statements.

 

I apologize for that.

[Colin Alworth]

No problem - I wanted to be sure I didn't make a mistake, since I haven't myself used canvas "in anger" in many years, and only loosely keep track of resources and advice on it.

SmartGWT's "Draw" examples make the API look very similar to the GXT "draw" packages - it isn't really a raster API at all, but a vector API that just happens to be built on top of a canvas implementation. 

My recollection is that for fewer than around 1k-10k drawn items, SVG is faster and simpler to understand than canvas, and canvas's benefits only start kicking in when the DOM gets too heavy to manipulate quickly each frame. Looking briefly at the example page you shared a few weeks ago, if you were interested in getting into the low level details of how to do the drawing, your case perhaps could stand being remade in plain SVG - always high resolution. The benefits may be mostly for your own understanding rather than any real observed performance improvements from running the page (that said: dropping SmartGWT would appear to drop almost 8mb of JS out of your 9+mb page).

[Leon Pennings]

I would not use the scale functionality as it applies to the whole canvas. 

I'd prefer to apply an adapter pattern for determining actual coordinates on the canvas. 

Then you can still have a toolbar, location display or slider for the zoom factor in it's normal proportions and just have the actual content you want to show in a different scale. 

Op donderdag 6 februari 2025 om 13:33:12 UTC+1 schreef Colin Alworth:

[Craig Mitchell]

> I would not use the scale functionality as it applies to the whole canvas.

Whatever works for your project is best, however, the scale only applies when you set it.  And you can always reset it.  Eg:

// Save the current state

context2d.save();

// Apply zoom

context2d.scale(xxx, xxx);

// Draw zoomed stuff

...

// Reset the zoom

context2d.restore();

This also lets browsers use the GPU to render (although, I'm not actually sure if the scaling is done on the CPU or the GPU).

[Colin Alworth]

I'm sorry if my message confused the two kinds of 'zoom' being discussed here - there's the one where the pixels on the physical monitor don't match the pixels of your display (this covers both HDPI and ctrl +/-), and there's the one where the user clicks the + icon (drawn on the canvas) to make everything inside a specific rectangle bigger.

The context2d.scale() method can do both, but I was mostly referring to the first, adapting to the user's current monitor+settings at any given time. Note that in this context, scale() does _not_ make things blurry when you zoom, but effectively multiplies all your coordinates by the scale. The canvas "height" and "width" (the "actual size" in the link's code sample) are what makes things blurry or super precise.

In the second case, scale() can still be totally appropriate, especially if coupled with a "panning" feature, or if data is updating. Odds are very high that in those cases, the parts of the canvas outside the "rectangle" aren't moving - all the various controls, the rectangle itself. Avoiding redrawing whatever you can each frame is important for performance. Or, you can just adjust your coordinate system when projecting on to the canvas, multiplying by your current zoom factor for each position - as above, it is doing the same thing.

While we're discussing it, clipping (with save/restore or without) still also be helpful to conserve rewrites too - if you had a single canvas element, you would clip to inside the rectangle, clear, and redraw only what is in there - save() and restore() are a valid way of handling that, or just reapply state at each pass. If you're careful, you could even just redraw a subset of the rectangle's contents - solve for which items actually changed (doing some intersection math), and clip+clearRect just that section, then redraw just what is in there. If you "draw" a little outside the clip in any of these cases, no big deal - it will get clipped out (but you'll still pay for the code to run, it just won't have any overdraw).

If you think about this like "partitioning" the drawing area with clip, there are two other ways to partition too - you can "tile" canvases, selectively redrawing their entire contents if they are affected, and you can "layer" them, using transparency to enable lower layers or higher layers to remain intact when other layers need to be cleared and repainted. Tiling can also work with non-homogenous blocks - the "rectangle" above could be one canvas, and the "controls" could be in their own.

[Leon]

@Craig - If you draw everything on the same canvas, the zoom/scale works on everything on that canvas. it limits what you can do with that canvas. If you want to scale or zoom everything, yes then it doesn't matter. So yes you are right, it depends on the project.

@Colin - With multiple layers I would also need multiple canvas's and overlay them right? 

We wrote a single adapter widget that uses a single canvas. This adapter widget knows what the zoom level is. Objects that are drawn on that widget of a certain type get zoomed, whilst others of a different type do not. It is super simple and easily explained to new devs. Everyone on the team can add views or objects and the type determines how these are displayed. Even devs without exact knowledge of how the canvas works can develop and maintain objects to be displayed.

I guess it's also a development style/preference thing. If you code the view of the canvas in a single class or single method, the solution is likely to have to rely more on the technological capabilities of the canvas. Working with an adapter then does not really make a lot of sense. 

If you have more of an OO style of development, you express more in functional blocks. Then you have to rely less on the technical capabilities as you can translate what needs to be done on the basis of what your objects are before you hit the canvas. Then the zooming/scaling happens in the object, not on the canvas so to speak.

So the required functionality of the canvas remains fairly basic.

performance wise, I've done fully animated person relation networks and animated dashboards in large canvases for nearly a decade now. 

We've never ran into any performance issues. 

That being said, I think the views and on-screen actions we used were somewhat limited when compared to developing a game with full world rendering or something similar. 

 

Did I already say I love this gwt group? It makes me think a lot more about what I am doing and why I am doing it. 

Plus the input from the GWT devs usually give me insights I haven't thought about before or didn't know existed.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/E3P4xZ8SFCg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0e1b79f7-fa2e-482f-899b-65c5e9ca3e72n%40googlegroups.com.

[Colin Alworth]

@Craig - If you draw everything on the same canvas, the zoom/scale works on everything on that canvas. it limits what you can do with that canvas. If you want to scale or zoom everything, yes then it doesn't matter. So yes you are right, it depends on the project.

This isn't true, it only applied on the operations that take place while it is set. You can call scale(1, 1) to go back to 1:1, or you can use the save()/restore() that Craig mentioned. You can also clip to keep the zoomed content within certain bounds.

@Colin - With multiple layers I would also need multiple canvas's and overlay them right? 

Correct - each would have its own frame buffer, and could be cleared/drawn independently.

 

We wrote a single adapter widget that uses a single canvas. This adapter widget knows what the zoom level is. Objects that are drawn on that widget of a certain type get zoomed, whilst others of a different type do not. It is super simple and easily explained to new devs. Everyone on the team can add views or objects and the type determines how these are displayed. Even devs without exact knowledge of how the canvas works can develop and maintain objects to be displayed.

I guess it's also a development style/preference thing. If you code the view of the canvas in a single class or single method, the solution is likely to have to rely more on the technological capabilities of the canvas. Working with an adapter then does not really make a lot of sense. 

If you have more of an OO style of development, you express more in functional blocks. Then you have to rely less on the technical capabilities as you can translate what needs to be done on the basis of what your objects are before you hit the canvas. Then the zooming/scaling happens in the object, not on the canvas so to speak.

So the required functionality of the canvas remains fairly basic.

I don't make these suggestions lightly - if you are happy with how canvas performs and the quality of the output, then you may well never need them, but it can be fun to know they exist.

I don't much care about OO vs FP styles for this - building an API around these features should be straightforward within whatever paradigm you prefer. For most projects we ended up with roughly two layers of abstractions - the "shapes that get drawn on the screen via canvas commands" abstraction (iterate through "shapes", respect their "z-index" or other relative positioning, capture clicks and figure out which "shape" was clicked on, redraw only changed "shapes" and those that intersect them, etc), and the "business logic drives what shapes to draw" abstraction ("I want a pie chart in the corner, compute slices based on data", "these buttons over here control those axes", "Labeled items in the legend will drive which stars/circles in the chart are highlighted when hovered"). It feels natural to someone who is used to working with a DOM (esp SVG), and can handle thousands of items without much trouble.

Zoom can appear at either level here - multiple coord systems, or make the "zoom" part of the "shape" API. You're totally correct that scaling need not happen at the "canvas level" - while the MDN link I gave seems to imply that, it really is just trying to make it easier for the developer to not need to think about one more "layer" of ways that their data needs to be transformed. From a certain perspective, you might want to just have a transform matrix that you apply to each shape, and compose your zoom-because-zoom-widget, translate-because-panning, rotate, etc operations all at that level, and just apply the transform once when drawing (or even apply to the coords before you call in to canvas). None of it matters as long as the math is correct.

If you need more power, odds are you can find pretty quickly where the "unnecessary" O(n^2) or O(n lg n) operations are taking place (sorted insertion by z-index, solving for intersections, etc), and can do a better job partitioning "shapes" or go all out and drop down to just "business logic drives canvas commands" where it is required.

 

performance wise, I've done fully animated person relation networks and animated dashboards in large canvases for nearly a decade now. 

We've never ran into any performance issues. 

That being said, I think the views and on-screen actions we used were somewhat limited when compared to developing a game with full world rendering or something similar. 

 

Did I already say I love this gwt group? It makes me think a lot more about what I am doing and why I am doing it. 

Plus the input from the GWT devs usually give me insights I haven't thought about before or didn't know existed.

If you can stand the stream of discussion, you may also enjoy https://matrix.to/#/#gwtproject_gwt:gitter.im. It tends to be more conversational, and can get into the weeds in unrelated topics like this.

[Leon]

I can see where you say a developer familiar with the DOM is more likely to work with on the canvas api directly.

And yes, the more technical options the better. Sure. 

But I do not see how you can say that an OO vs procedural or functional approach is not that relevant? OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart. In what way do you think that this difference not relevant?

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/c66862dd-bcfc-4516-b2bf-c5dc17a73deen%40googlegroups.com.

[Craig Mitchell]

> OO vs procedural/functional is quite the different design approach. I would even say that those are worlds apart.

Tell that to the React creators, that switched the framework from OO to functional.  😝

[Leon]

Switching to functional is the current trend I guess. Now you can argue whether or not it's smart to change design approach because it's a trend. As a framework - probably yes as you get higher adoption rates. 

As an application developer probably not - as it just creates extra maintenance for when the next trend comes around.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/7299cb42-a00a-415a-b6a6-c8718ce1f9ddn%40googlegroups.com.

[Colin Alworth]

Sorry if I was unclear - FP vs OO vs whatever really shouldn't matter. I only brought it up because you mentioned "OO style" driving some choices. The nature of the Canvas APIs shouldn't need to drive how you use them, until you are so starved for performance that you can't afford any indirection at all.

I don't think it is fair to call it the current trend - to anyone. Java upped its FP game in Java 8, 10 years ago - and I don't think anyone will argue that Java ever gets to the party early, without years of deliberation. JavaScript is perfectly usable as a functional language (debatably more so than than Java even today, since we still need SAM interfaces and can't just pass functions directly) and has been for 30 years since it was first released.

React's strategy effectively required that they adopt a "stateless" paradigm, which lends itself very well to encouraging (ostensibly) pure functions for rendering, that accept the state/props as an argument.

[Leon]

Oh, but I agree, the nature of the GWT Canvas implementation is no driver at all in which methodology to use to implement your application. 

Which design approach should be used depends on what the development team masters best.

The advantage of an OO approach - which I was trying to make clear but obviously failed - is that you can have the model work out the required functionality before you need to draw it out on the canvas. It has many advantages, one of which - in this case - is that you need a lot less complex actions from the canvas itself. The reason is not for performance, but it's a complexity reduction basically. 

For that reason OO is very practical on the backend, but given the unique nature of GWT it makes it very practical on the frontend too. 

To me, that is one of it's USP's.

And we can agree to disagree on the FP. 

Whilst I can imagine that for script languages FP seems like a more natural fit, but for information systems where java shines, OO is the best fit. 

The FP adoption in java is not late to the party, but is more like Oracle following the trend trying to make java hip and luring the script developers to jump ship.

So yeah, for FP in Java I would say it is definitely following a trend.

But like I said, we can agree to disagree.

The funny thing about software development is that it is a field in which mastery of the tools is often seen as mastery of the craft.

Now try to explain that to a carpenter or a potter.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/778e24ce-c26e-4170-a346-755129440140n%40googlegroups.com.

[Ankit Singh]

We have almost upgraded to GWT-2.12.1, but we have few queries:-

1. We have to write @RemoteServiceRelativePath("/abc")  in our XYZ_Srv class. 

     Is there any way we can do it without writing @RemoteServiceRelativePath("/abc").  otherwise How can we make it not to be hardcoded but get the Class Name in it.

2. We have to put the Servlet in web.xml file like 

<servlet>
    <servlet-name>loginServlet</servlet-name>
    <servlet-class>com.demo.login.Login_SrvImpl</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>loginServlet</servlet-name>
    <url-pattern>/login</url-pattern>
  </servlet-mapping>

     How we can generate it dynamically as we have a large number of servlets to map so we want it to add in multiple file such that maintaining it will be easy. I mean Dynamic     ServletRegistration here. 

3. also currently we are having all the projects to be served under com.demo.packageName. Here we get duplicity as we have few packages with same name under different project or Custom libs.

    is it possible to have it like com.demo.project1.packageName, com.demo.project2.packageName

[Colin Alworth]

Just to confirm, these don't sound like update-related questions, but changes in the application you want to make along the way? I would personally advise fully completing the update (especially such a big version bump) before changing application behavior like this.

For #1, you can cast your *Async instance to ServiceDefTarget and set your own URL to access with setServiceEntryPoint(String) - relative or absolute, path is entirely up to you. This feature has been present since the initial GWT release.

#2 is a general servlet question, not related to GWT at all - the @WebServlet annotation is probably what you're looking for to decorate each servlet with its own URL, but you'll need to ensure that your servlet container supports this, has it enabled, etc. In theory you could also design your own tooling that finds these classes and generates a web.xml, but it will depend on exactly what pattern you expect, etc.

I don't understand exactly what #3 is asking. Is this for the module name and JS path that each gwt module is compiled to, the service url, or something different?

[Jens]

As Colin said you can use @WebServlet and enable configuration via annotation scanning in your servlet container. However if your application is large then scanning might slow your deployment down. If deployment time is not a concern then it is the easiest solution. There are additional annotations for other classes you normally add to your web.xml.

If you don't like class scanning during deployment time you can write an annotation processor that picks up all these @WebServlet annotated servlets and generates a class that registers them using the ServletContext API. Then you use that generated class in a custom ServletContextListener implementation to register everything. That ServletContextListener would then be the only entry in your web.xml. Alternatively, if you use Jetty as servlet container you can use Jetty's quickstart module to let it generate a web.xml by scanning your code once (as part of the build process).

-- J.

[Wejden Mrabti]

Hello!  

I am following your conversation because i am working on same issues :    

Migrating GWT/GXT project to GWT 2.10 + Java 11 + Jetty 9

Initial Context on Legacy project using:

• GWT 2.8.2

• GXT 2.3.1a-gwt22

• Embedded Jetty

• Java 8

Migration Goal

Update the project to use:

• Java 11

• GWT 2.10.1

• Jetty 9

• A custom-built GXT version compatible with GWT 2.10

Steps Already Completed 

1. GXT Recompilation and Installation

• Cloned the GXT 2.3.1a sources.

• Adapted the code to compile with GWT 2.10.1.

• Successfully built gxt-main-2.3.1a-gwt2.10.jar.

• Installed it locally using:

2. Maven Configuration Updated

• Switched to Java 11 using maven.compiler.source and target.

• GWT updated to version 2.10.1.

• Added the locally installed GXT dependency

3. GWT Module Inheritance Added
4. GXT Verification

• Confirmed GXT.gwt.xml is present inside the JAR (jar tf checked).

• JAR added to the Eclipse launch configuration (Run Configurations > Classpath).

Jetty Configuration Jetty 9 Already in Use

• Version confirmed: 9.4.52.v20230823 (via mvn dependency:tree).

• Dependencies have <scope>compile</scope> (not provided).

• jetty-server-9.4.52.v20230823.jar appears in the Eclipse classpath.

Current Blocking Issues

1. GXT Not Found at Runtime

When launching GWT DevMode: Unable to find 'com/extjs/gxt/ui/GXT.gwt.xml' on your classpath

Despite:

• The file being present in the JAR.

• The JAR being listed in the Run Configurations > Classpath.

• Proper inheritance in the .gwt.xml file.

2. Jetty Server Class Not Found

Tried using the argument:

-server org.eclipse.jetty.server.Server

ClassNotFoundException: org.eclipse.jetty.server.Server

Even though the JAR is present in the classpath, and Jetty 9 is confirmed to be in use.

So i need to understand

1. Why is GWT DevMode (or CodeServer) unable to find com.extjs.gxt.ui.GXT.gwt.xml, even though it is present and properly declared?

2. How can I resolve the ClassNotFoundException for org.eclipse.jetty.server.Server, despite Jetty 9 being correctly added?

3. Are there any special configurations or recommendations for running GWT 2.10 with Jetty 9 and Java 11 in Eclipse?

Important note: I do not want to switch to a Tomcat 9 deployment (war packaging) as a workaround. The current state of the project makes the packaging and deployment process extremely slow — over one hour just to build and deploy. Therefore, I need a solution that works using GWT Super DevMode and embedded Jetty

Thanks in advance for any help or suggestions.

__wejden

[Jens]

So i need to understand

1. Why is GWT DevMode (or CodeServer) unable to find com.extjs.gxt.ui.GXT.gwt.xml, even though it is present and properly declared?

2. How can I resolve the ClassNotFoundException for org.eclipse.jetty.server.Server, despite Jetty 9 being correctly added?

3. Are there any special configurations or recommendations for running GWT 2.10 with Jetty 9 and Java 11 in Eclipse?

- Ensure that you only have a single GWT SDK version in your classpath

- Ensure that your custom built GXT library also contains source files and not just the *.gwt.xml file. GWT needs source files for everything it should compile to JS.

- Ensure that your app compiles cleanly using GWT compiler. Generally always use -strict parameter and fix all errors that might show up. This verifies that your maven setup is correct and you only have issues with eclipse run configurations.

- Use -XshowSettings:properties as JVM parameter in your launch configuration and then check property "java.class.path" in console output. Is everything in the classpath correctly? Sounds like your classpath is still messed up even if you think it is not.

-- J.

[Colin Alworth]

#1 I think Jens covers it well - something is almost certainly wrong with your modified jar or how the classpath is built.

For #2, the "-server" argument lets you specify a com.google.gwt.core.ext.ServletContainerLauncher type, so org.eclipse.jetty.server.Server will not suffice. If you do not specify one, as of GWT 2.12 the old default of com.google.gwt.dev.shell.jetty.JettyLauncher (using a wrapped Jetty 9) is still used, which is what it sounds like you want anyway. This will change in the future, see https://github.com/gwtproject/gwt/issues/10057 and linked issues, If you're interested in something newer than the default Jetty 9, also see https://groups.google.com/g/google-web-toolkit/c/3dSoHpHD5jY/m/faAeQeJ-AwAJ and https://groups.google.com/g/google-web-toolkit-contributors/c/7jvGVaiSUdI.

Note that Jetty 9 sometimes doesn't behave nicely when it tries to scan your classpath - if it finds something that it can't understand while looking for annotations, it will break. This will result in an error something like
java.lang.IllegalArgumentException: Unsupported class file major version 64
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:199)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:180)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:166)
at org.objectweb.asm.ClassReader.<init>(ClassReader.java:287)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:932)
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:734)
... 6 more

The workaround discussed at https://github.com/gwtproject/gwt/issues/9433#issuecomment-250104877 may help here.

#3, nothing special should be required - besides the wrong instance passed to -server, what errors are you seeing?

Re your note: you should not need to deploy a complete war to tomcat for local development - the best way to think about this is "If I wasn't using GWT, how would I want to debug my server", then amend that slightly to permit SDM to change files in the same sort of way that you would either manually edit JS/HTML or you'd use a tool like npm/etc.