Sunday, October 26, 2025

Re: @JsFunction producing ClassCastException

Oh I see !!
@Jens
Yes but I thought  it was just a convenient way to define the formatter for both cases at the same time:
  • single value slider 
  • range slider
Screenshot 2025-10-27 at 09.37.57.png

But since in my code, Slider and RangeSlider are 2 different classes, I thought I could be more specific and define only the appropriate formatter for each case.
But @Colin is right! Even in the case of a Range slider, sometime the library calls the formatter function with a single value (I have no idea why, it does not make sense to me but anyway).

So I've change my FormatterCallback as follow (thanks @Colin)
@JsFunction
@FunctionalInterface
public interface FormatterCallback {

/**
* Returns the formatted tool-tip text to be displayed.
*
* @param value the slider value
* @return the formatted tool-tip text to be displayed.
*/
String formatTooltip(Any value);
}

and define then like that :
formatterExample.setFormatter(any -> {
  if (any instanceof JsNumber) {
    return "Current value: " + any.asDouble();
  }
  return null;
});

rangeFormatterExample.setFormatter(any -> {
  if (any instanceof Range) {
    Range range = (Range) any;
    return "Range: [" + range.getMinValue() + ", " + range.getMaxValue() + "]";
  }
  return null;
});
Le samedi 25 octobre 2025 à 22:30:46 UTC+8, Jens a écrit :
The default formatter in bootstrap-slider looks like

formatter: function(val) {
if (Array.isArray(val)) {
return val[0] + " : " + val[1];
} else {
return val;
}
}

IMHO a strong indication that you must use Any or Object and the formatter then needs to check how to format the input. Only if you can guarantee that the component will always call the function with an array you can use a <Range> generic.

-- J.

Colin Alworth schrieb am Freitag, 24. Oktober 2025 um 17:06:40 UTC+2:
Switching to manual testing in your pom lets me run the test in a real browser, with breakpoints enabled.
diff --git a/pom.xml b/pom.xml
index 39c43269..58bd6671 100644
--- a/pom.xml
+++ b/pom.xml
@@ -108,6 +108,10 @@
           <inherited>true</inherited>
           <configuration>
             <sourceLevel>1.8</sourceLevel>
+            <testArgs>
+              <arg>-runStyle</arg>
+              <arg>Manual:1</arg>
+            </testArgs>
           </configuration>
         </plugin>
       </plugins>

The emulated stack trace experience isn't very much fun, but after a time it is possible to see that the function is being called with an array, [5, 10] from inside bootstrap itself - but the bootstrap code specifically shows that it is only passing the 0th element, as this._state.value[0]. 

In order to call the Java lambda with its generic arg, GWT inserts a typecheck for generics. Range is declared as "actually this is an Array", so GWT emulates that check with Array.isArray:
    Zz(($B = (ZB[b] = iD + oD,
    a) == null || (ZB[b] = iD + pD,
    Array).isArray(($B = (ZB[b] = iD + oD,
    a),
Again, this is nasty to read because of emulated stack traces - but 5 clearly fails that check.

I then added a `debugger` statement to the JSNI function, to see if it saw the same thing - it was actually called several times, first with 5, then 10, before finally the expected [1,2] array. When it received 5 and 10, the result returned was the useless string "Range: [undefined,undefined]".

Is it wrong for GWT to check the types here? It is causing you a headache for sure, but the lambda is clearly nonsense if you get a number instead of a range array. You could take something like Any or Object as the param and typecheck it, or maybe there's a different way to use bootstrap here to get the result you expect?



On Wednesday, October 22, 2025 at 3:39:28 AM UTC-5 freddy....@gmail.com wrote:
Hello,
I'm working on updating/migrating the gwtbootstrap3 library
  • updating all external Javascript libraries
  • migrating to JsInterop (get rid of jsni)
  • migrating to Bootstrap 5
But I'm facing an issue with the following @JsFunction

import jsinterop.annotations.JsFunction;

@JsFunction
@FunctionalInterface
public interface FormatterCallback<T> {
String formatTooltip(T value);
}

When I declare it with lambda it fails
// using @JsFunction
slider.setFormatter(range -> "Range: [" + range.getAt(0) + "," + range.getAt(1) + "]");

But if I declare it with JSNI it works
slider.setFormatter(rangeFormatter());

private native FormatterCallback<Range> rangeFormatter() /*-{
return function (value) {
return "Range: [" + value[0] + "," + value[1] + "]";
};
}-*/;

You can find the successful and the failing GWTTestCase here:


When I log in the console the 2 functions it looks like that

===JSNI===
ƒ (value_0_g$){
    return 'Range: [' + value_0_g$[0] + ', ' + value_0_g$[1] + ']';
  }

===JsFunction===
ƒ (){
    return samMethod_0_g$.apply(lambda_0_g$, arguments);
  }

Any idea how to resolve it?
thanks

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/65394e97-3b9a-4edb-a578-6872c6fa0d25n%40googlegroups.com.

Saturday, October 25, 2025

Re: @JsFunction producing ClassCastException

The default formatter in bootstrap-slider looks like

formatter: function(val) {
if (Array.isArray(val)) {
return val[0] + " : " + val[1];
} else {
return val;
}
}

IMHO a strong indication that you must use Any or Object and the formatter then needs to check how to format the input. Only if you can guarantee that the component will always call the function with an array you can use a <Range> generic.

-- J.

Colin Alworth schrieb am Freitag, 24. Oktober 2025 um 17:06:40 UTC+2:
Switching to manual testing in your pom lets me run the test in a real browser, with breakpoints enabled.
diff --git a/pom.xml b/pom.xml
index 39c43269..58bd6671 100644
--- a/pom.xml
+++ b/pom.xml
@@ -108,6 +108,10 @@
           <inherited>true</inherited>
           <configuration>
             <sourceLevel>1.8</sourceLevel>
+            <testArgs>
+              <arg>-runStyle</arg>
+              <arg>Manual:1</arg>
+            </testArgs>
           </configuration>
         </plugin>
       </plugins>

The emulated stack trace experience isn't very much fun, but after a time it is possible to see that the function is being called with an array, [5, 10] from inside bootstrap itself - but the bootstrap code specifically shows that it is only passing the 0th element, as this._state.value[0]. 

In order to call the Java lambda with its generic arg, GWT inserts a typecheck for generics. Range is declared as "actually this is an Array", so GWT emulates that check with Array.isArray:
    Zz(($B = (ZB[b] = iD + oD,
    a) == null || (ZB[b] = iD + pD,
    Array).isArray(($B = (ZB[b] = iD + oD,
    a),
Again, this is nasty to read because of emulated stack traces - but 5 clearly fails that check.

I then added a `debugger` statement to the JSNI function, to see if it saw the same thing - it was actually called several times, first with 5, then 10, before finally the expected [1,2] array. When it received 5 and 10, the result returned was the useless string "Range: [undefined,undefined]".

Is it wrong for GWT to check the types here? It is causing you a headache for sure, but the lambda is clearly nonsense if you get a number instead of a range array. You could take something like Any or Object as the param and typecheck it, or maybe there's a different way to use bootstrap here to get the result you expect?



On Wednesday, October 22, 2025 at 3:39:28 AM UTC-5 freddy....@gmail.com wrote:
Hello,
I'm working on updating/migrating the gwtbootstrap3 library
  • updating all external Javascript libraries
  • migrating to JsInterop (get rid of jsni)
  • migrating to Bootstrap 5
But I'm facing an issue with the following @JsFunction

import jsinterop.annotations.JsFunction;

@JsFunction
@FunctionalInterface
public interface FormatterCallback<T> {
String formatTooltip(T value);
}

When I declare it with lambda it fails
// using @JsFunction
slider.setFormatter(range -> "Range: [" + range.getAt(0) + "," + range.getAt(1) + "]");

But if I declare it with JSNI it works
slider.setFormatter(rangeFormatter());

private native FormatterCallback<Range> rangeFormatter() /*-{
return function (value) {
return "Range: [" + value[0] + "," + value[1] + "]";
};
}-*/;

You can find the successful and the failing GWTTestCase here:


When I log in the console the 2 functions it looks like that

===JSNI===
ƒ (value_0_g$){
    return 'Range: [' + value_0_g$[0] + ', ' + value_0_g$[1] + ']';
  }

===JsFunction===
ƒ (){
    return samMethod_0_g$.apply(lambda_0_g$, arguments);
  }

Any idea how to resolve it?
thanks

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/56927253-9d74-455d-af5f-518bf247b1b9n%40googlegroups.com.

Friday, October 24, 2025

Re: domino-rest | pulling in com.fasterxml.jackson.core:jackson-annotations:2.16.0 ?

I've finally got it to compile without trying to implement anything yet by:

```groovy
dependencies {
    implementation("org.gwtproject:gwt-user:2.12.2")

    annotationProcessor('com.google.dagger:dagger-compiler:2.51')
    implementation "com.google.dagger:dagger-gwt:2.51"

    annotationProcessor 'org.dominokit:domino-rest-processor:1.0.2'
    implementation('org.dominokit:domino-rest-client:1.0.2') {
        exclude group: 'com.fasterxml.jackson.core', module: 'jackson-annotations'
        exclude group: 'com.fasterxml.jackson.core', module: 'jackson-core'
        exclude group: 'com.fasterxml.jackson.core', module: 'jackson-databind'
    }
```

Is this an elemental issue, do I need to pin that to particular version?

-Mike

On 10/24/25 12:37, Michael Conrad wrote:
I'm suddenly getting a jackson annotation set that is too new for gwt 2.12 to be able to compile in my dependency chain?

Am I missing something? Or have something extra?

## error fragment

   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JsonSetter'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JsonSetter.java'
         [ERROR] Line 246: The method format(String, Nulls, Nulls) is undefined for the type String
   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JacksonInject'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JacksonInject.java'
         [ERROR] Line 170: The method format(String, Object, Boolean) is undefined for the type String
   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JsonIncludeProperties'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JsonIncludeProperties.java'
         [ERROR] Line 129: The method format(String, Set<String>) is undefined for the type String
   [ERROR] Aborting compile due to errors in some input files


## gradle fragment

dependencies {
    implementation("org.gwtproject:gwt-user:2.12.2")

    annotationProcessor('com.google.dagger:dagger-compiler:2.51')
    implementation('com.google.dagger:dagger-compiler:2.51')
    implementation('com.google.dagger:dagger-gwt:2.51')

    implementation 'org.dominokit:domino-rest-client:1.0.2'
    compileOnly 'org.dominokit:domino-rest-processor:1.0.2'
    annotationProcessor 'org.dominokit:domino-rest-processor:1.0.2'

## dependency graph

compileClasspath - Compile classpath for source set 'main'.
+--- org.dominokit:domino-rest-processor:1.0.2
|    +--- org.dominokit:domino-rest-shared:1.0.2
|    |    +--- javax.ws.rs:javax.ws.rs-api:2.1.1
|    |    +--- org.dominokit:domino-rest-jaxrs:1.0.2
|    |    +--- org.dominokit:domino-jackson:1.0.4
|    |    |    +--- com.google.elemental2:elemental2-core:1.2.1
|    |    |    |    +--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |    +--- com.google.jsinterop:base:1.0.1
|    |    |    |    |    \--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |    \--- com.google.elemental2:elemental2-promise:1.2.1
|    |    |    |         +--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |         \--- com.google.jsinterop:base:1.0.1 (*)
|    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0
|    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0
|    |    |    |         +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0 (c)
|    |    |    |         +--- com.fasterxml.jackson.core:jackson-core:2.16.0 (c)
|    |    |    |         \--- com.fasterxml.jackson.core:jackson-databind:2.16.0 (c)
|    |    |    +--- com.fasterxml.jackson.core:jackson-databind:2.16.0
|    |    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0 (*)
|    |    |    |    +--- com.fasterxml.jackson.core:jackson-core:2.16.0
|    |    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0 (*)
|    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0 (*)
|    |    |    \--- org.dominokit.i18n:gwt-datetimeformat:1.0.2

domino-rest | pulling in com.fasterxml.jackson.core:jackson-annotations:2.16.0 ?

I'm suddenly getting a jackson annotation set that is too new for gwt 2.12 to be able to compile in my dependency chain?

Am I missing something? Or have something extra?

## error fragment

   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JsonSetter'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JsonSetter.java'
         [ERROR] Line 246: The method format(String, Nulls, Nulls) is undefined for the type String
   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JacksonInject'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JacksonInject.java'
         [ERROR] Line 170: The method format(String, Object, Boolean) is undefined for the type String
   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JsonIncludeProperties'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JsonIncludeProperties.java'
         [ERROR] Line 129: The method format(String, Set<String>) is undefined for the type String
   [ERROR] Aborting compile due to errors in some input files


## gradle fragment

dependencies {
    implementation("org.gwtproject:gwt-user:2.12.2")

    annotationProcessor('com.google.dagger:dagger-compiler:2.51')
    implementation('com.google.dagger:dagger-compiler:2.51')
    implementation('com.google.dagger:dagger-gwt:2.51')

    implementation 'org.dominokit:domino-rest-client:1.0.2'
    compileOnly 'org.dominokit:domino-rest-processor:1.0.2'
    annotationProcessor 'org.dominokit:domino-rest-processor:1.0.2'

## dependency graph

compileClasspath - Compile classpath for source set 'main'.
+--- org.dominokit:domino-rest-processor:1.0.2
|    +--- org.dominokit:domino-rest-shared:1.0.2
|    |    +--- javax.ws.rs:javax.ws.rs-api:2.1.1
|    |    +--- org.dominokit:domino-rest-jaxrs:1.0.2
|    |    +--- org.dominokit:domino-jackson:1.0.4
|    |    |    +--- com.google.elemental2:elemental2-core:1.2.1
|    |    |    |    +--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |    +--- com.google.jsinterop:base:1.0.1
|    |    |    |    |    \--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |    \--- com.google.elemental2:elemental2-promise:1.2.1
|    |    |    |         +--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |         \--- com.google.jsinterop:base:1.0.1 (*)
|    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0
|    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0
|    |    |    |         +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0 (c)
|    |    |    |         +--- com.fasterxml.jackson.core:jackson-core:2.16.0 (c)
|    |    |    |         \--- com.fasterxml.jackson.core:jackson-databind:2.16.0 (c)
|    |    |    +--- com.fasterxml.jackson.core:jackson-databind:2.16.0
|    |    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0 (*)
|    |    |    |    +--- com.fasterxml.jackson.core:jackson-core:2.16.0
|    |    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0 (*)
|    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0 (*)
|    |    |    \--- org.dominokit.i18n:gwt-datetimeformat:1.0.2

domino-rest | pulling in com.fasterxml.jackson.core:jackson-annotations:2.16.0 ?

I'm suddenly getting a jackson annotation set that is too new for gwt 2.12 to be able to compile in my dependency chain?

Am I missing something? Or have something extra?

## error fragment

   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JsonSetter'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JsonSetter.java'
         [ERROR] Line 246: The method format(String, Nulls, Nulls) is undefined for the type String
   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JacksonInject'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JacksonInject.java'
         [ERROR] Line 170: The method format(String, Object, Boolean) is undefined for the type String
   Tracing compile failure path for type 'com.fasterxml.jackson.annotation.JsonIncludeProperties'
      [ERROR] Errors in 'com/fasterxml/jackson/annotation/JsonIncludeProperties.java'
         [ERROR] Line 129: The method format(String, Set<String>) is undefined for the type String
   [ERROR] Aborting compile due to errors in some input files


## gradle fragment

dependencies {
    implementation("org.gwtproject:gwt-user:2.12.2")

    annotationProcessor('com.google.dagger:dagger-compiler:2.51')
    implementation('com.google.dagger:dagger-compiler:2.51')
    implementation('com.google.dagger:dagger-gwt:2.51')

    implementation 'org.dominokit:domino-rest-client:1.0.2'
    compileOnly 'org.dominokit:domino-rest-processor:1.0.2'
    annotationProcessor 'org.dominokit:domino-rest-processor:1.0.2'

## dependency graph

compileClasspath - Compile classpath for source set 'main'.
+--- org.dominokit:domino-rest-processor:1.0.2
|    +--- org.dominokit:domino-rest-shared:1.0.2
|    |    +--- javax.ws.rs:javax.ws.rs-api:2.1.1
|    |    +--- org.dominokit:domino-rest-jaxrs:1.0.2
|    |    +--- org.dominokit:domino-jackson:1.0.4
|    |    |    +--- com.google.elemental2:elemental2-core:1.2.1
|    |    |    |    +--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |    +--- com.google.jsinterop:base:1.0.1
|    |    |    |    |    \--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |    \--- com.google.elemental2:elemental2-promise:1.2.1
|    |    |    |         +--- com.google.jsinterop:jsinterop-annotations:2.0.2
|    |    |    |         \--- com.google.jsinterop:base:1.0.1 (*)
|    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0
|    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0
|    |    |    |         +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0 (c)
|    |    |    |         +--- com.fasterxml.jackson.core:jackson-core:2.16.0 (c)
|    |    |    |         \--- com.fasterxml.jackson.core:jackson-databind:2.16.0 (c)
|    |    |    +--- com.fasterxml.jackson.core:jackson-databind:2.16.0
|    |    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.16.0 (*)
|    |    |    |    +--- com.fasterxml.jackson.core:jackson-core:2.16.0
|    |    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0 (*)
|    |    |    |    \--- com.fasterxml.jackson:jackson-bom:2.16.0 (*)
|    |    |    \--- org.dominokit.i18n:gwt-datetimeformat:1.0.2

Re: @JsFunction producing ClassCastException

Switching to manual testing in your pom lets me run the test in a real browser, with breakpoints enabled.
diff --git a/pom.xml b/pom.xml
index 39c43269..58bd6671 100644
--- a/pom.xml
+++ b/pom.xml
@@ -108,6 +108,10 @@
           <inherited>true</inherited>
           <configuration>
             <sourceLevel>1.8</sourceLevel>
+            <testArgs>
+              <arg>-runStyle</arg>
+              <arg>Manual:1</arg>
+            </testArgs>
           </configuration>
         </plugin>
       </plugins>

The emulated stack trace experience isn't very much fun, but after a time it is possible to see that the function is being called with an array, [5, 10] from inside bootstrap itself - but the bootstrap code specifically shows that it is only passing the 0th element, as this._state.value[0]. 

In order to call the Java lambda with its generic arg, GWT inserts a typecheck for generics. Range is declared as "actually this is an Array", so GWT emulates that check with Array.isArray:
    Zz(($B = (ZB[b] = iD + oD,
    a) == null || (ZB[b] = iD + pD,
    Array).isArray(($B = (ZB[b] = iD + oD,
    a),
Again, this is nasty to read because of emulated stack traces - but 5 clearly fails that check.

I then added a `debugger` statement to the JSNI function, to see if it saw the same thing - it was actually called several times, first with 5, then 10, before finally the expected [1,2] array. When it received 5 and 10, the result returned was the useless string "Range: [undefined,undefined]".

Is it wrong for GWT to check the types here? It is causing you a headache for sure, but the lambda is clearly nonsense if you get a number instead of a range array. You could take something like Any or Object as the param and typecheck it, or maybe there's a different way to use bootstrap here to get the result you expect?



On Wednesday, October 22, 2025 at 3:39:28 AM UTC-5 freddy....@gmail.com wrote:
Hello,
I'm working on updating/migrating the gwtbootstrap3 library
  • updating all external Javascript libraries
  • migrating to JsInterop (get rid of jsni)
  • migrating to Bootstrap 5
But I'm facing an issue with the following @JsFunction

import jsinterop.annotations.JsFunction;

@JsFunction
@FunctionalInterface
public interface FormatterCallback<T> {
String formatTooltip(T value);
}

When I declare it with lambda it fails
// using @JsFunction
slider.setFormatter(range -> "Range: [" + range.getAt(0) + "," + range.getAt(1) + "]");

But if I declare it with JSNI it works
slider.setFormatter(rangeFormatter());

private native FormatterCallback<Range> rangeFormatter() /*-{
return function (value) {
return "Range: [" + value[0] + "," + value[1] + "]";
};
}-*/;

You can find the successful and the failing GWTTestCase here:


When I log in the console the 2 functions it looks like that

===JSNI===
ƒ (value_0_g$){
    return 'Range: [' + value_0_g$[0] + ', ' + value_0_g$[1] + ']';
  }

===JsFunction===
ƒ (){
    return samMethod_0_g$.apply(lambda_0_g$, arguments);
  }

Any idea how to resolve it?
thanks

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/0f110384-2b90-4732-b85f-6a85d63bd8c8n%40googlegroups.com.

Re: Domino-ui 2.0.0-RC2 release

As I thought, I was being confused by stale information.

Meh.... is it just that the REST stuff is dated to 11 months ago as an RC2?

I'm getting to try and do a rip-replace on a multiple "somewhat convoluted" REST api client configuration from RestyGWT + CompletableFutures to this much cleaner annotation based approach and saw the RC2 as the last posted artifact to maven.

-Mike

On 10/24/25 10:32, Colin Alworth wrote:
On their releases page, the latest release is less than two months old, 2.0.5: https://github.com/DominoKit/domino-ui/releases/

On Friday, October 24, 2025 at 9:30:46 AM UTC-5 Michael Joyner wrote:
Is this still an active project? I don't see anything past this RC from two years ago...

On Monday, September 11, 2023 at 3:23:54 PM UTC-4 site manager wrote:
Congratulations on your release!

2023年9月12日(火) 0:19 Vegegoku <aka...@gmail.com>:
Dears,

Since before we released Domino-ui version 1.0.0 we have been cooking a new release for domino-ui that brings new features, enhanced APIs, themeing, and new components.
And we are already supporting the new version users to migrate from domino-ui version 1.0.0, We will later share a lot more details and documentation and discuss the changes we made to the new release.
and today we announce the new release 2.0.0-RC2 which brings enhancements and bug fixes from the first RC release of 2.0.0, You can check those enhancements and bug fixes here: https://github.com/DominoKit/domino-ui/releases/tag/2.0.0-RC2 

Also, domino-ui 1.0.0 is still supported, and today we released domino-ui 1.0.2 including bug fixes listed here: https://github.com/DominoKit/domino-ui/releases/tag/1.0.2
At the same time, we are releasing domino-ui cli 2.0.0-RC1, which will now create domino-ui 2.0.0 projects by default with a fallback option for 1.0.0, Find the release here: https://github.com/DominoKit/domino-cli/releases/tag/2.0.0-RC1

Finally, I would like to thank Vertispan (https://www.vertispan.com/) for sponsoring this work.

There will be some more exciting news in the near future. Enjoy Java and dominokit.
--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e4db3998-11df-46da-a7d3-9575c3fb9e69n%40googlegroups.com.
--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/ae0ed10d-1961-4ba4-92c1-0cd95fbed4b2n%40googlegroups.com.

Re: Domino-ui 2.0.0-RC2 release

On their releases page, the latest release is less than two months old, 2.0.5: https://github.com/DominoKit/domino-ui/releases/

On Friday, October 24, 2025 at 9:30:46 AM UTC-5 Michael Joyner wrote:
Is this still an active project? I don't see anything past this RC from two years ago...

On Monday, September 11, 2023 at 3:23:54 PM UTC-4 site manager wrote:
Congratulations on your release!

2023年9月12日(火) 0:19 Vegegoku <aka...@gmail.com>:
Dears,

Since before we released Domino-ui version 1.0.0 we have been cooking a new release for domino-ui that brings new features, enhanced APIs, themeing, and new components.
And we are already supporting the new version users to migrate from domino-ui version 1.0.0, We will later share a lot more details and documentation and discuss the changes we made to the new release.
and today we announce the new release 2.0.0-RC2 which brings enhancements and bug fixes from the first RC release of 2.0.0, You can check those enhancements and bug fixes here: https://github.com/DominoKit/domino-ui/releases/tag/2.0.0-RC2 

Also, domino-ui 1.0.0 is still supported, and today we released domino-ui 1.0.2 including bug fixes listed here: https://github.com/DominoKit/domino-ui/releases/tag/1.0.2
At the same time, we are releasing domino-ui cli 2.0.0-RC1, which will now create domino-ui 2.0.0 projects by default with a fallback option for 1.0.0, Find the release here: https://github.com/DominoKit/domino-cli/releases/tag/2.0.0-RC1

Finally, I would like to thank Vertispan (https://www.vertispan.com/) for sponsoring this work.

There will be some more exciting news in the near future. Enjoy Java and dominokit.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e4db3998-11df-46da-a7d3-9575c3fb9e69n%40googlegroups.com.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/ae0ed10d-1961-4ba4-92c1-0cd95fbed4b2n%40googlegroups.com.

Re: Domino-ui 2.0.0-RC2 release

Is this still an active project? I don't see anything past this RC from two years ago...

On Monday, September 11, 2023 at 3:23:54 PM UTC-4 site manager wrote:
Congratulations on your release!

2023年9月12日(火) 0:19 Vegegoku <aka...@gmail.com>:
Dears,

Since before we released Domino-ui version 1.0.0 we have been cooking a new release for domino-ui that brings new features, enhanced APIs, themeing, and new components.
And we are already supporting the new version users to migrate from domino-ui version 1.0.0, We will later share a lot more details and documentation and discuss the changes we made to the new release.
and today we announce the new release 2.0.0-RC2 which brings enhancements and bug fixes from the first RC release of 2.0.0, You can check those enhancements and bug fixes here: https://github.com/DominoKit/domino-ui/releases/tag/2.0.0-RC2 

Also, domino-ui 1.0.0 is still supported, and today we released domino-ui 1.0.2 including bug fixes listed here: https://github.com/DominoKit/domino-ui/releases/tag/1.0.2
At the same time, we are releasing domino-ui cli 2.0.0-RC1, which will now create domino-ui 2.0.0 projects by default with a fallback option for 1.0.0, Find the release here: https://github.com/DominoKit/domino-cli/releases/tag/2.0.0-RC1

Finally, I would like to thank Vertispan (https://www.vertispan.com/) for sponsoring this work.

There will be some more exciting news in the near future. Enjoy Java and dominokit.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e4db3998-11df-46da-a7d3-9575c3fb9e69n%40googlegroups.com.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/b250c1e5-6227-45df-b17e-332bbc949bedn%40googlegroups.com.

Wednesday, October 22, 2025

@JsFunction producing ClassCastException

Hello,
I'm working on updating/migrating the gwtbootstrap3 library
  • updating all external Javascript libraries
  • migrating to JsInterop (get rid of jsni)
  • migrating to Bootstrap 5
But I'm facing an issue with the following @JsFunction

import jsinterop.annotations.JsFunction;

@JsFunction
@FunctionalInterface
public interface FormatterCallback<T> {
String formatTooltip(T value);
}

When I declare it with lambda it fails
// using @JsFunction
slider.setFormatter(range -> "Range: [" + range.getAt(0) + "," + range.getAt(1) + "]");

But if I declare it with JSNI it works
slider.setFormatter(rangeFormatter());

private native FormatterCallback<Range> rangeFormatter() /*-{
return function (value) {
return "Range: [" + value[0] + "," + value[1] + "]";
};
}-*/;

You can find the successful and the failing GWTTestCase here:


When I log in the console the 2 functions it looks like that

===JSNI===
ƒ (value_0_g$){
    return 'Range: [' + value_0_g$[0] + ', ' + value_0_g$[1] + ']';
  }

===JsFunction===
ƒ (){
    return samMethod_0_g$.apply(lambda_0_g$, arguments);
  }

Any idea how to resolve it?
thanks

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/f5682bbf-baac-4d87-a7ac-bd4499a7abefn%40googlegroups.com.

Tuesday, October 21, 2025

Re: Effect of the omission of the symbolmap files on the stacktrace's line numbers

There is a known issue around chunking that can interfere with stack traces - https://github.com/gwtproject/gwt/issues/9931 - but I don't think that's the whole story of what's happening here (classnames still match the source file they came from, which suggests you aren't seeing it). That issue specifically happens if there are binding properties driving the use of sourcemaps, which means unconditionally enabling sourcemaps functions as a workaround, adding this to late in your .gwt.xml file:

<set-property name="compiler.useSourceMaps" value="true" />

Can you confirm that the three lines of XML only occur in build A and not B? Emulated sourcemaps are great for extremely accurate stack traces, but awful for runtime size and performance. Every line of JS ends up being wrapped in bookkeeping about what file, method, line number is currently being executed - pushing that on a stack, popping it when finished. Expect that to double or triple your output - and it still might have some slight errors/omissions (see below).

Without more information, I don't have anything else to offer about why the stack trace claims SomePanel.java has the error on line 645...

...but from your note at the bottom, some methods will be inlined by the compiler, which can interfere with the stack frames you expect to find. With emulated stack mode, you _could_ get more of that information, but it isn't a given. With native/strip mode, every extra method call added (helpers to make instance methods static that don't always work) or removed (inlined methods that get their contents shifted around and rewritten) can mean that the caller or callee can be lost. Looking at the compiled code might help to match up what changes were made as part of optimizing the app.

(Your email ends on an incomplete sentence, perhaps something was left out?)

On Tuesday, October 21, 2025 at 5:21:45 AM UTC-5 Nick Gaens wrote:
I have witnessed some - imo odd - GWT behavior regarding stacktrace accuracy that I cannot yet fully comprehend, so I am posting it here.

I have a GWT application of which the .gwt.xml file contains these three lines:

<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers" value="true"/>
<set-configuration-property name="compiler.emulatedStack.recordFileNames" value="true"/>

Also, I ensured a StringOutOfBoundsException to occur on a distinct screen by doing this:

GWT.log("123".substring(65));

in SomePanel.java on line 195.

To conclude, I made two release builds: 'build A' and 'build B'. A and B are identical, except for B not having any symbol maps present in the resulting file structure (they are manually removed post-compilation) before a distributable zip file is made. The omission of the symbol map files is an attempt to no longer enable end users to be able to view deobfuscated stacktraces directly in the browser's console or to perform deobfuscation manually offline.

When navigating to the broken screen of build A, the stacktrace that is printed to the browser's console is deobfuscated (duh) and - more importantly - 100% correct regarding file names and line numbers. Therefore, it's straightforward to pinpoint where any issue did occur in the original Java code.

When navigating to the broken screen of build B, the stacktrace that is printed to the browser's console is obfuscated, but ... wrong in terms of file names and line numbers... This is the stacktrace that was printed out in the browser's console in this occasion:

java.lang.StringIndexOutOfBoundsException: Index: 65, Size: 4
    at Unknown.qXf(Throwable.java:66)
    at Unknown.CXf(Exception.java:29)
    at Unknown.H3f(RuntimeException.java:29)
    at Unknown.bop(IndexOutOfBoundsException.java:29)
    at Unknown.wrp(StringIndexOutOfBoundsException.java:30)
    at Unknown.OKp(InternalPreconditions.java:487)
    at Unknown.pwf(InternalPreconditions.java:475)
    at Unknown.hbe(NavigationManager.java:287)
    at Unknown.kbe(NavigationManager.java:118)
    at Unknown.RPe(MainPanel.java:604)
    at Unknown.Ung(ValueChangeEvent.java:128)
    at Unknown.hog(GwtEvent.java:76)
    at Unknown._ng(SimpleEventBus.java:88)
    at Unknown.Ntj(History.java:68)
    at Unknown.Vng(ValueChangeEvent.java:43)
    at Unknown.FPe(History.java:77)
    at Unknown.Qae(Application.java:273)
    at Unknown.cbe(Application.java:269)
    at Unknown.wke(TablesDataManager.java:43)
    at Unknown.MWf(JsonRequestBuilder.java:164)
    at Unknown.Pog(Request.java:227)
    at Unknown.cpg(RequestBuilder.java:412)
    at Unknown.anonymous(XMLHttpRequest.java:329)
    at Unknown.Wag(Impl.java:299)
    at Unknown.Zag(Impl.java:351)
    at Unknown.anonymous(Impl.java:78)

Using GWT's com.google.gwt.core.server.StackTraceDeobfuscator and the according symbol map, I was able to deobfuscate this to:

java.lang.Throwable: java.lang.StringIndexOutOfBoundsException: Index: 65, Size: 4
        at java.lang.Throwable.Throwable(Throwable.java:69)
        at java.lang.Exception.Exception(Exception.java:36)
        at java.lang.RuntimeException.RuntimeException(RuntimeException.java:32)
        at java.lang.ArithmeticException.ArithmeticException(ArithmeticException.java:27)
        at java.lang.StringBuilder.StringBuilder(StringBuilder.java:41)
        at javaemul.internal.InternalPreconditions.checkCriticalState(InternalPreconditions.java:379)
        at com.example.client.panels.SomePanel.someMethod(SomePanel.java:645)
        at  com.example.client.NavigationManager.hideAllPopupMenus(NavigationManager.java:372)
        at  com.example.client.NavigationManager.navigateAbsentRequests(NavigationManager.java:457)
        at  com.example.client.panels.main.MainPanel$1.MainPanel$1(MainPanel.java:312)
        at com.google.gwt.event.logical.shared.ValueChangeEvent.ValueChangeEvent(ValueChangeEvent.java:100)
        at com.google.web.bindery.event.shared.SimpleEventBus.$doAddNow(SimpleEventBus.java:168)
        at com.google.gwt.event.shared.HandlerManager.$addHandler(HandlerManager.java:98)
        at com.google.gwt.user.client.History$HistoryEventSource.History$HistoryEventSource(History.java:62)
        at com.google.gwt.event.logical.shared.ValueChangeEvent.dispatch(ValueChangeEvent.java:127)
        at com.example.client.panels.main.MainPanel.$lambda$2(MainPanel.java:252)
        at com.example.client.Application.$successLogin(Application.java:220)
        at com.example.client.Application.$lambda$6$Type.Application$lambda$6$Type(Application.java:299)
        at com.example.client.client.datamanager.SomeDataManager.getSomeData(SomeDataManager.java:100)
        at  com.example.jsonrpc.client.JsonRequestBuilder$2.JsonRequestBuilder$2(JsonRequestBuilder.java:377)
        at com.google.gwt.http.client.Request.$cancel(Request.java:151)
        at com.google.gwt.http.client.RequestBuilder$1.RequestBuilder$1(RequestBuilder.java:408)
        at Unknown.anonymous(XMLHttpRequest.java:329)
        at com.google.gwt.core.client.impl.Impl.enter(Impl.java:313)
        at com.google.gwt.core.client.impl.Impl.exit(Impl.java:373)
        at Unknown.anonymous(Impl.java:78)

So the exception's message is still correct, but the line number where the faulty line of code is present (195) is nowhere to be found in the deobfuscated stacktrace. Also worth noting is that the exception caused by the faulty line of code in SomePanel.java is reached after a few successive method invocations, although the deobfuscated stacktrace doesn't include those in the stack: I expected to have multiple stacktrace elements to exist between the one mentioning SomePanel:someMethod and the one showing the StringIndexOutOfBoundsException happening, but they simply aren't there for some reason.

Can someone shed a light on why all of this is happening in the way it does?

Kind regards,
Nick

When the 

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/d2872e4b-ca50-4d21-9613-83e6af11dc14n%40googlegroups.com.

Effect of the omission of the symbolmap files on the stacktrace's line numbers

I have witnessed some - imo odd - GWT behavior regarding stacktrace accuracy that I cannot yet fully comprehend, so I am posting it here.

I have a GWT application of which the .gwt.xml file contains these three lines:

<set-property name="compiler.stackMode" value="emulated" />
<set-configuration-property name="compiler.emulatedStack.recordLineNumbers" value="true"/>
<set-configuration-property name="compiler.emulatedStack.recordFileNames" value="true"/>

Also, I ensured a StringOutOfBoundsException to occur on a distinct screen by doing this:

GWT.log("123".substring(65));

in SomePanel.java on line 195.

To conclude, I made two release builds: 'build A' and 'build B'. A and B are identical, except for B not having any symbol maps present in the resulting file structure (they are manually removed post-compilation) before a distributable zip file is made. The omission of the symbol map files is an attempt to no longer enable end users to be able to view deobfuscated stacktraces directly in the browser's console or to perform deobfuscation manually offline.

When navigating to the broken screen of build A, the stacktrace that is printed to the browser's console is deobfuscated (duh) and - more importantly - 100% correct regarding file names and line numbers. Therefore, it's straightforward to pinpoint where any issue did occur in the original Java code.

When navigating to the broken screen of build B, the stacktrace that is printed to the browser's console is obfuscated, but ... wrong in terms of file names and line numbers... This is the stacktrace that was printed out in the browser's console in this occasion:

java.lang.StringIndexOutOfBoundsException: Index: 65, Size: 4
    at Unknown.qXf(Throwable.java:66)
    at Unknown.CXf(Exception.java:29)
    at Unknown.H3f(RuntimeException.java:29)
    at Unknown.bop(IndexOutOfBoundsException.java:29)
    at Unknown.wrp(StringIndexOutOfBoundsException.java:30)
    at Unknown.OKp(InternalPreconditions.java:487)
    at Unknown.pwf(InternalPreconditions.java:475)
    at Unknown.hbe(NavigationManager.java:287)
    at Unknown.kbe(NavigationManager.java:118)
    at Unknown.RPe(MainPanel.java:604)
    at Unknown.Ung(ValueChangeEvent.java:128)
    at Unknown.hog(GwtEvent.java:76)
    at Unknown._ng(SimpleEventBus.java:88)
    at Unknown.Ntj(History.java:68)
    at Unknown.Vng(ValueChangeEvent.java:43)
    at Unknown.FPe(History.java:77)
    at Unknown.Qae(Application.java:273)
    at Unknown.cbe(Application.java:269)
    at Unknown.wke(TablesDataManager.java:43)
    at Unknown.MWf(JsonRequestBuilder.java:164)
    at Unknown.Pog(Request.java:227)
    at Unknown.cpg(RequestBuilder.java:412)
    at Unknown.anonymous(XMLHttpRequest.java:329)
    at Unknown.Wag(Impl.java:299)
    at Unknown.Zag(Impl.java:351)
    at Unknown.anonymous(Impl.java:78)

Using GWT's com.google.gwt.core.server.StackTraceDeobfuscator and the according symbol map, I was able to deobfuscate this to:

java.lang.Throwable: java.lang.StringIndexOutOfBoundsException: Index: 65, Size: 4
        at java.lang.Throwable.Throwable(Throwable.java:69)
        at java.lang.Exception.Exception(Exception.java:36)
        at java.lang.RuntimeException.RuntimeException(RuntimeException.java:32)
        at java.lang.ArithmeticException.ArithmeticException(ArithmeticException.java:27)
        at java.lang.StringBuilder.StringBuilder(StringBuilder.java:41)
        at javaemul.internal.InternalPreconditions.checkCriticalState(InternalPreconditions.java:379)
        at com.example.client.panels.SomePanel.someMethod(SomePanel.java:645)
        at  com.example.client.NavigationManager.hideAllPopupMenus(NavigationManager.java:372)
        at  com.example.client.NavigationManager.navigateAbsentRequests(NavigationManager.java:457)
        at  com.example.client.panels.main.MainPanel$1.MainPanel$1(MainPanel.java:312)
        at com.google.gwt.event.logical.shared.ValueChangeEvent.ValueChangeEvent(ValueChangeEvent.java:100)
        at com.google.web.bindery.event.shared.SimpleEventBus.$doAddNow(SimpleEventBus.java:168)
        at com.google.gwt.event.shared.HandlerManager.$addHandler(HandlerManager.java:98)
        at com.google.gwt.user.client.History$HistoryEventSource.History$HistoryEventSource(History.java:62)
        at com.google.gwt.event.logical.shared.ValueChangeEvent.dispatch(ValueChangeEvent.java:127)
        at com.example.client.panels.main.MainPanel.$lambda$2(MainPanel.java:252)
        at com.example.client.Application.$successLogin(Application.java:220)
        at com.example.client.Application.$lambda$6$Type.Application$lambda$6$Type(Application.java:299)
        at com.example.client.client.datamanager.SomeDataManager.getSomeData(SomeDataManager.java:100)
        at  com.example.jsonrpc.client.JsonRequestBuilder$2.JsonRequestBuilder$2(JsonRequestBuilder.java:377)
        at com.google.gwt.http.client.Request.$cancel(Request.java:151)
        at com.google.gwt.http.client.RequestBuilder$1.RequestBuilder$1(RequestBuilder.java:408)
        at Unknown.anonymous(XMLHttpRequest.java:329)
        at com.google.gwt.core.client.impl.Impl.enter(Impl.java:313)
        at com.google.gwt.core.client.impl.Impl.exit(Impl.java:373)
        at Unknown.anonymous(Impl.java:78)

So the exception's message is still correct, but the line number where the faulty line of code is present (195) is nowhere to be found in the deobfuscated stacktrace. Also worth noting is that the exception caused by the faulty line of code in SomePanel.java is reached after a few successive method invocations, although the deobfuscated stacktrace doesn't include those in the stack: I expected to have multiple stacktrace elements to exist between the one mentioning SomePanel:someMethod and the one showing the StringIndexOutOfBoundsException happening, but they simply aren't there for some reason.

Can someone shed a light on why all of this is happening in the way it does?

Kind regards,
Nick

When the 

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/66de6fea-89d3-489c-8667-c612224e7f59n%40googlegroups.com.

Thursday, October 16, 2025

Re: State of GWT?

The only hookup with css we have is in the <head> of the initial html: <link rel="stylesheet" href="css/styles.css" media="screen">. We use descriptive classnames in the GWT widget, table.addStyleName(Css.TABLE) for instance, whereby the Css class is an interface with just classnames. Then we have a unittest that checks that all defined classnames in this Css class are present in the styles.css. 

imo GWT should not concern itself with CSS. CSS is a mature ecosystem in its own right, with dedicated tools, editors, and experts. By keeping css external, we retain the ability to leverage that ecosystem fully.
Deep css integration is not one of the USP's for GWT. There is no direct problem this integration will solve and you are basically limiting some very powerfull options in your application. 
GWT, as a UI application framework, should focus on structure, behavior, and state — the object model — and not on how those objects are visually represented.

In larger organisations there are usually frontend designers and developers in house, by keeping css external, you can use it as a business case to incorporate the existing knowledge and make GWT an easier sell over Js frameworks. For smaller organisations the same still holds, as hiring a ux/html/css expert (or at the moment that can also be done using AI) can get you amazing results for your ui.

Even better: GWT is the only ideal 'glue' between a java ecosystem and existing frontend capabilities. Now hows that for a USP wrt to other UI frameworks.
Op donderdag 16 oktober 2025 om 02:14:04 UTC+2 schreef cbruno...@gmail.com:
Also to get around the GWT CSS weakness, I just inject a TextResource instead of using CssResource. 

On Wednesday, October 15, 2025 at 7:12:58 PM UTC-5 cbruno...@gmail.com wrote:
I second the comment about GWT and CSS. Its its only weakness. Otherwise its really the only real alternative if you dislike the npm universe and want static typing and build system. 

I use GWT and Spring Boot and make use of MVP and GWT-RPC (using gwt-servlet-jakarta). 

On Saturday, October 4, 2025 at 3:50:10 AM UTC-5 RobW wrote:
Very much our experience. We build commercial apps, and having used GWT for years we know it inside out, so we can build things fast. Yes, it's in maintenance mode, but that also means it's very stable and throws us zero curve balls. We've looked at other frameworks, but all seem to end up with way more code for similar sized solutions - and we're not JS experts, so working in a single Java codebase is way way more comfortable for us. We do divert into JSNI at times to wire in some libs (codemirror, gridstack etc). But we create minimal bindings for just the API calls we need.

On Friday, 3 October 2025 at 10:37:49 UTC+1 Frank Hossfeld wrote:
A few years ago, i was thinking about moving to React or vue. So I started some pocs to see how thinks work. At the end npm has loaded some malicious code on my computer. Spooky. That's is one of many reasons to stay with GWT. Next, I am familiar with GWT. I know the pitfalls and drawbacks. We'll use GWT, domino-ui, domino-rest, Nalu & Spring Boot and we are happy with it. So, starting a new project, that would be the tool stack. We build business software and get paid for transforming business needs into code. With that tool stack we can create well maintainable and stable software quite fast. We have an incredible low error rate and at least nearly no downtimes.    
 
 Jens is right, GWT is in maintenance mode. After GWT was handed to the community, all work is done by a few people (like Colin, Jens, Thomas, Ahmad, etc) without getting paid. Not sure, but I think, in case more people starts sponsoring the project (https://opencollective.com/gwt-project) this might change.

Craig Mitchell schrieb am Mittwoch, 1. Oktober 2025 um 06:48:31 UTC+2:
> Now I have to build one webapp prototype and I'm wondering if my GWT-fu can still be of any use. Could someone advise what would be the best way to use GWT in 2025?

If you want create a quick and easy webapp prototype, I recommend using https://github.com/NaluKit/gwt-maven-springboot-archetype to generate a framework based off Spring Boot.

IMHO: GWT's ability to shield you from needing to write JavaScript, is as strong as it has ever been in 2025.

On Tuesday, 30 September 2025 at 9:17:26 pm UTC+10 Jens wrote:
Generally GWT SDK is in maintenance mode which means there is no incentive to add new features to GWT. Most current work is done in the compiler, emulation and distangling code dependencies to eventually use maven/gradle instead of ant.

My main pain point with GWT today is actually CSS. CSS is moving pretty fast and GWT is stuck on an old Closure Stylesheets library. Beside that if you really just want to make a throw away prototype I think I would learn a different JS framework for making such prototypes because you simply have to type less code as in GWT with Java. But of course it also depends on the complexity of the prototype as well.


1. I remember GWT was in the process of splitting it into many (J2CL-compatible) submodules, but other than searching Maven Central, I can not find any list of them?

Many of them which are considered completed are available on github at https://github.com/orgs/gwtproject/repositories?language=&q=&sort=&type=all

Colin made a google sheet back in the days at https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit?gid=0#gid=0 but it might be outdated. I lost track about the status of not yet completed projects.


 
2. Is there any better way of integrating recent JavaScript libraries other than manually writing my own Elemental2 wrappers? I know Elemental2 bindings are auto-generated from Closure, so I'm hoping that there may be some tools that could generate them at least from TypeScript as well. Not that there were not efforts [5]. My prototype would have to work with maps and although I see that gwt-ol [6] is still maintained, I'm wondering what would be my options if I have to integrate with, for example, Windy API?

Personally I just write JsInterop by hand because most of the time you don't need 100% of the API of a third party JS library. Generated code can also be a bit clunky as seen in elemental2 . Beside the generator you mentioned I don't know any other TS -> JsInterop generator. The one of Google is Closure externs -> JsInterop. 

 
 
3. J2CL seems to remain Google's internal toy, right?

Well you can use it but personally I think you are right, it won't be very popular outside google. 


-- J.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/4f4f532b-ba04-4bd2-bf4a-b7480cd86bf9n%40googlegroups.com.

Wednesday, October 15, 2025

Re: Code Server fixed for Windows Users (now shuts down correctly)

Forgot to say, the reason for starting everything via a maven launcher, is so IntelliJ knows it's running, and the "Stop All" button works.

If you run things as an external tool, or shell script, IntelliJ doesn't know how to stop it.

On Thursday, 16 October 2025 at 11:16:07 am UTC+11 Craig Mitchell wrote:
Thomas fixed the code server for Windows users: https://github.com/tbroyer/gwt-maven-plugin/issues/110#issuecomment-3405235827

Thanks Thomas!

Thought I'd clean up my IntelliJ dev startup.  What I figured out is:
  1. Create a maven launcher for the codeserver.
  2. Create a maven launcher for your server.
  3. And you can create maven launches for thinks like your DB.
  4. Then create a compound launcher to start everything with one click.  IntelliJ also gives you a "Stop All" button to stop everything with one click.
Much easier!

To create a maven launcher for your DB, you use "exec-maven-plugin".  For example, I'm using Google App Engine, so I added this to my pom.xml:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>${exec-maven-plugin.version}</version>
  <executions>
    <execution>
      <id>start-datastore-emulator</id>
      <goals>
        <goal>exec</goal>
      </goals>
      <configuration>
        <executable>gcloud</executable>
        <arguments>
           <argument>beta</argument>
            <argument>emulators</argument>
            <argument>datastore</argument>
            <argument>start</argument>
            <argument>--use-firestore-in-datastore-mode</argument>
            <argument>--data-dir=local_db</argument>
          </arguments>
       </configuration>
     </execution>
  </executions>
</plugin>

Now I just create a maven launcher in IntelliJ "exec:exec@start-datastore-emulator" and it'll start my local DB.

If anyone has any tips for improving it, please let me know.

--
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-toolkit+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/764190b2-05e9-4617-93e2-2f41e41eea11n%40googlegroups.com.