GWT error

[Gerard]

I tried to run a gwt application already exists and works but i get this error .

Can you help me please !!!!

the error:

 java.lang.UnsatisfiedLinkError: D:\workspace\workspace\project\project\gwt-framework\lib\swt-win32-3235.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1807)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
    at java.lang.Runtime.load0(Runtime.java:770)
    at java.lang.System.load(System.java:1003)
    at org.eclipse.swt.internal.Library.loadLibrary(Library.java:132)
    at org.eclipse.swt.internal.win32.OS.<clinit>(OS.java:18)
    at org.eclipse.swt.widgets.Display.<clinit>(Display.java:125)
    at com.google.gwt.dev.GWTShell.<clinit>(GWTShell.java:301)
Exception in thread "main" 

//////////////////////////////////

and i get this window also: 

could not find the main class: com.google.gwt.dev.GWTShell. Program will exit.

[mmo...@gmail.com]

I am still trying to get code server running for our application that I am porting from GWT 2.7 to GWT 2.10.

 

I am currently stuck with an error in a commercial GWT widget library that our project uses (GXT v4.0.2). The code generated by that library contains a bug: it contains a GWT.create(…)-call where the argument is an interface and not a class.

 

What’s most annoying is that the offending piece of code that is generated by that library is in a private method that is never called. So it’s a completely useless piece of code but it stall the GWT compilation of that class!  ☹

 

Strange enough the GWT 2.7 compilation seems to have ignored this error – the code that calls the GXT library is from 2015(!) and has worked OK so far.

 

With GWT 2.10 the “normal” compilation (with failOnError=false) also works and I can deploy and run that code.

 

But when I try to execute the application in development mode on a local Tomcat then the compilation that is triggered in code server by the first UI request yields this:

 

…

[INFO] The code server is ready at http://127.0.0.1:9876/

[INFO] GET /recompile/ZHStRegisterJPWeb

[INFO]    Job ch.zh.ksta.zhstregisterjp.ZHStRegisterJPWeb_1_0

[INFO]       starting job: ch.zh.ksta.zhstregisterjp.ZHStRegisterJPWeb_1_0

[INFO]       binding: gxt.device=desktop

[INFO]       binding: gxt.user.agent=chrome

[INFO]       binding: user.agent.os=windows

[INFO]       Compiling module ch.zh.ksta.zhstregisterjp.ZHStRegisterJPWeb

[INFO]          Ignored 6 units with compilation errors in first pass.

[INFO] Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.

[INFO]          [ERROR] Errors in 'gen/ch/zh/ksta/zhstregisterjp/client/company/view/FristrerstreckungEditor_FristrerstreckungUiBinderImpl.java'

[INFO]             [ERROR] Line 141: Rebind result 'com.sencha.gxt.data.shared.LabelProvider' must be a class

[INFO]          Unification traversed 168367 fields and methods and 13829 types. 13766 are considered part of the current module and 13766 had all of their fields and methods traversed.

[INFO]       [ERROR] Compiler returned false

[INFO]       [WARN] recompile failed

[INFO]       [WARN] continuing to serve previous version

 

 

Is there *any* possibility to convince the code server to ignore that issue and continue compiling and then serving the code?

 

I tried to contact the company producing this library. Apparently there exists a newer version of that library and I wanted to know whether that would solve our issue, but they did not respond so far.

 

I also found not location to download that newer .jar from. So my only option seems to be to convince the GWT compilation to ignore that issue. Only: how?

[Jens]

I am currently stuck with an error in a commercial GWT widget library that our project uses (GXT v4.0.2). The code generated by that library contains a bug: it contains a GWT.create(…)-call where the argument is an interface and not a class.

Actually GWT.create() usually takes an interface and during GWT compilation that interface is either replaced by a class using GWT rebind rules stored in any *.gwt.xml file or a GWT generator will be executed (also defined in *.gwt.xml file) which generates a class that implements that interface. Maybe you can find that rebind rule in any *.gwt.xml file provided by GXT and then you might see why it fails to replace that interface with a concrete class. You should be able to add your own custom rebind rules then to fix the issue.

But when I try to execute the application in development mode on a local Tomcat then the compilation that is triggered in code server by the first UI request yields this:

CodeServer has option -[no]failOnError. Have you tried that?

But I could imagine that this kind of error will still be reported because GWT wants to replace GWT.create() with new SomeClass() but does not know how to do it. If -nofailOnError does not work you have to try fixing the root cause of the issue as described above.

-- J.

[Frank Hossfeld]

IIRC you need to update a few classes of GXT to get it running with GWT 2.9.0+. And GWT 2.10.0 dropped the support for ie8, ie9 & ie10 which will also cause problems. 

[Michael Moser]

Thanks Frank Hossfeld and Jens for responding!

 

@Frank Hossfeld
Re.  «GWT 2.10.0 dropped the support for ie8, ie9 & ie10 which will also cause problems.»

I had indeed encountered that issue already very early while migrating our application from GWT2.7 to GWT2.10 and had fixed it by providing an own copy of the file

Core.gwt.xml (The orignal is in gxt-4.0.2.jar in folder com/sencha/gxt/core/)

 

in which I had replaced the header line

 

<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.7.0//EN"

    "http://gwtproject.org/doctype/2.7.0/gwt-module.dtd">

with this:

<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.10.0//EN"

    "http://gwtproject.org/doctype/2.10.0/gwt-module.dtd">

 

And I also commented away this section oft the file:

 

  <!-- Restrict the permutation explosion -->

<!--

  <set-property name="user.agent" value="ie8">

    <when-property-is name="gxt.user.agent" value="ie8" />

  </set-property>

  <set-property name="user.agent" value="ie9">

    <when-property-is name="gxt.user.agent" value="ie9" />

  </set-property>

  <set-property name="user.agent" value="ie10">

    <when-property-is name="gxt.user.agent" value="ie10" />

  </set-property>

-->

 

I had placed that modified file into our project’s  <web_module>\src\main\resources\com\sencha\gxt\core\Core.gwt.xml and for the compilation we are specifying user agent «safari» now (even though we are actually using Chrome and Edge as browsers). These changes had gotten me going and seem to work.

 

 

@Jens
Meanwhile I was able to get the thing compiling and working.

 

In one of our UIs my predecessors had defined some fields of a form as «LabelProvider» (i.e. as interface only).

I replaced those occurences with the concrete classes of the resp. fields (i.e. I made several fields into «IntegerLabelProvider» and one into a «StringLabelProvider») and that fixed the issue.

I didn’t know about those mapping or «rebind»-rules. I guess I still haven’t really encountered nor understood some of GWT’s «magic» but the mentioned changes got the compile error to disappear and got me going. But thanks of making me aware oft hat rebind mechanism! I’ll try to find some description and understand that better.

 

Re. the «-[no]failOnError»-option of code-server. I had indeed tried that and it didn’t change anything, i.e. it did not prevent the compilation from failing. Only the changes mentioned above then got me going here.

 

 

Cheers and thanks,

Michael

 

[Michael Moser]

As you might recall from earlier mails I am migrating a legacy application from GWT 2.7 to 2.10.

We got everything compiling, packaging and starting up and we can now also debug client-side using code server.

 

Now we are testing the application to see whether we encounter further surprises and – of course – we did:

 

When running the application we see quite a number of these messages in our log:

 

…

2023-02-21 16:55:04,065 [ERROR] [S:775AF6CF00607D3ADFDD1C44F143B9B9] [U:nsw] [T:http-nio-8080-exec-8] - [com.gwtplatform.mvp.client.ViewWithUiHandlers] uiHandlers are not set.  Did you call getUiHandlers() from your view's constructor?
2023-02-21 16:55:04,068 [ERROR] [S:775AF6CF00607D3ADFDD1C44F143B9B9] [U:nsw] [T:http-nio-8080-exec-9] - [com.gwtplatform.mvp.client.presenter.slots.LegacySlotConvertor] Warning: You're using an untyped slot!
Untyped slots are dangerous! Please upgrade your slots using
the Arcbee's easy upgrade tool at
https://arcbees.github.io/gwtp-slot-upgrader

…

 

These seem to have to do with GWTP (due to the «com.gwtplatform…» and tghe company name «arcbees» in the error message) but other than that it doesn’t really give us much of a clue as of what the issue is and where in our code to look. The tool-URL given in the error message «points to 404» so not much wisdom there,either. ☹

 

Does someone have an idea what the issue here is? And is there some flag or option to make this emit a bit more re. as to WHERE these «slots» are used (or misused)?

We are using the latest available version of GWTP, i.e. v1.6.

 

We also encounter exceptions like that below on the client side – no idea whether these have to do with the above or are a completely distinct issue:

 

…

[ch.zh.ksta.zhstregisterjp.client.base.ZHStRegisterJPBootstrapper] java.lang.ClassCastException
    at Unknown.Throwable_3_g$(ZHStRegisterJPWeb-0.js@8:305569)
    at Unknown.Exception_3_g$(ZHStRegisterJPWeb-0.js@18:305838)
    at Unknown.RuntimeException_3_g$(ZHStRegisterJPWeb-0.js@18:495939)
    at Unknown.new ClassCastException_2_g$(ZHStRegisterJPWeb-0.js@25:642638)
    at Unknown.checkCriticalType_1_g$(ZHStRegisterJPWeb-0.js@21:659164)
    at Unknown.checkType_1_g$(ZHStRegisterJPWeb-0.js@5:659420)
    at Unknown.checkType_0_g$(ZHStRegisterJPWeb-0.js@3:659413)
    at Unknown.castTo_0_g$(ZHStRegisterJPWeb-0.js@3:646)
    at Unknown.hasNoPendingActions_0_g$(ZHStRegisterJPWeb-0.js@10:5831)
    at Unknown.execute_11_g$(ZHStRegisterJPWeb-0.js@28:64804)
    at Unknown.$executeRepeating_0_g$(ZHStRegisterJPWeb-0.js@47:519622)
    at Unknown.runScheduledTasks_0_g$(ZHStRegisterJPWeb-0.js@13:519344)
    at Unknown.flushPostEventPumpCommands_0_g$(ZHStRegisterJPWeb-0.js@5:519441)
    at Unknown.execute_65_g$(ZHStRegisterJPWeb-0.js@24:519580)
    at Unknown.execute_64_g$(ZHStRegisterJPWeb-0.js@19:519317)
    at Unknown.apply_103_g$(ZHStRegisterJPWeb-0.js@28:519010)
    at Unknown.entry0_0_g$(ZHStRegisterJPWeb-0.js@16:519066)
    at Unknown.anonymous(ZHStRegisterJPWeb-0.js@14:519046)
    at Unknown.callback_0_g$(ZHStRegisterJPWeb-0.js@46:519368)

 

Since there is no line of our own code nor any for us recognizable identifier here: any idea anyone what the issue could be here and/or any hint on how to locate the origin of that error?

 

[Thomas Broyer]

On Thursday, February 23, 2023 at 10:51:53 PM UTC+1 mmo wrote:

We are using the latest available version of GWTP, i.e. v1.6.

Latest but 6 years old‼

…and the project hasn't seen any update since that date (except one change 18 months later –that's still 3 years and a half ago, and never released–, and cosmetic updates to the README: https://github.com/ArcBees/GWTP/compare/99827283111d1281e0b5def6223d4fb8894b6d9f%5E...master; there apparently was some changes between 1.6 and the master branch, but again never released in 6 years)

Christian Goudreau, Arcbees' founder, no longer works there since fall 2018 according to his LinkedIn profile; the company looks dead, like the GWTP project.