Wednesday, July 26, 2023

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

Wrong thread. Sorry. Please ignore.

On Wed, 26 Jul 2023, 20:26 Vassilis Virvilis, <vasvir2@gmail.com> wrote:
Super sourcing is a hackish but very powerful tool.
I have used it to override some gwt widgets in order to expose or change some private methods.

Is this feature so difficult to be implemented? I mean at that point J2CL looked like a cool upgrade when Google was standing behind GWT. But since it took forever to be released as part of GWT one may wonder if it is really needed at this point.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAKbOjExhogkAdxekOyw8GajibTHy6PBzto3BhS8SYY03jd4_dQ%40mail.gmail.com.
Posted by at No comments:

Re: Partial super source? Possible?

I was specifically answering the J2CL part: you cannot use shadowing with J2CL, only with GWT.
More accurately, J2CL itself is rather low-level and will translate any file you give it; the "issue" here is rather the Closure Compiler (IIRC), that will error if it finds more than one file declaring the same Closure module (each Java class is translated to a Closure module).
You should however (IIRC and IIUC) be able to patch the Java Runtime Emulation (JRE) used by J2CL, similar to how you could patch it in GWT by using your own "fork" of the gwt-user.jar.

TL;DR: try hard to avoid using any class or method that's not part of the "built-in" emulation library. Refactor code to use an intermediate class (e.g. MyStringFormatter.format()) that you can then super-source. If compiling a third-party library, it might not be that bad of an idea to patch it (fork it) with that kind of refactoring.

I'll let Colin confirm though, as I've been away from J2CL for some time now.

On Wednesday, July 26, 2023 at 1:09:41 PM UTC+2 Bruno Salmon wrote:
Thanks Thomas. By "shadow" I was actually quoting you when you said: 

you cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String

In my previous reply, I was saying that I'm happy with this solution for my GWT app (whatever you call this method "shadow" or something else).

But my concern is now with J2CL (as I plan to move my GWT app to J2CL in the future).
I would like to know if this solution will also work with J2CL.
i.e. will I be able to provide my own implementation of String.format() if not emulated by J2CL?

On Tuesday, 25 July 2023 at 15:20:19 UTC+1 Thomas Broyer wrote:
On Tuesday, July 25, 2023 at 2:26:14 PM UTC+2 Bruno Salmon wrote:
The shadow super-source should work in my case, thank you.

 If later I want to move from GWT to J2CL, will I have a similar feature (ex: providing my own implementation of String.format() if not emulated) ?

IIRC, no: each source file must only appear once, so you cannot use shadowing.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/a363da30-f10b-4c47-8b37-bb5761958e78n%40googlegroups.com.
Posted by at No comments:

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

Super sourcing is a hackish but very powerful tool.
I have used it to override some gwt widgets in order to expose or change some private methods.

Is this feature so difficult to be implemented? I mean at that point J2CL looked like a cool upgrade when Google was standing behind GWT. But since it took forever to be released as part of GWT one may wonder if it is really needed at this point.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAKbOjExXCB6kGyFB6%3D9-iTHiRwgT1azo9Zqg_kJEa3DVwD62dw%40mail.gmail.com.
Posted by at No comments:

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

As noted in the post - we didn't get around to trying Domino REST. By the time we discovered it, we'd already made the decision to stick with GWT-RPC and move on to other work. It's possible we'd revisit that, but we'd probably want to see some worked examples of how to transition from GWT-RPC to Domino REST. We already burnt quite a few cycles digging into the depths of alternates only to find they came up short. So it's hard to justify going back there to do more of that at this stage when GWT-RPC still works.

On Tuesday, 25 July 2023 at 15:43:06 UTC+1 Michael Conrad wrote:
Did y'all test DominoKit? It is actively maintained and has a REST module. I'm curious if you did test it what shortcomings you may have run into.

On Tuesday, July 25, 2023 at 9:23:53 AM UTC-4 RobW wrote:
We got to a similar point. Looked in depth at moving the GWT front end to a REST API - but found two big drawbacks: 
  1. none of the frameworks we could find had async callback handling similar to GWT-RPC, with common interface classes client server side AND support JAX-RS subresources. RestyGWT got close apart from those last two points - there is a model with common client/server interfaces, but it doesn't support subresources. We found at least 1 other GWT REST toolkit that had exactly the same issue  - so it's clearly not a trivial one to solve.
  2. somewhat more serious than the first issue was that none of the GWT REST API frameworks looked to be that actively maintained, at least tracking their GitHub commits anyhow
So ultimately, although REST API an attractive route, GWT-RPC remains more practical for us in the near term.

Note - one we didn't explore in depth but may come back too was Domino Kit, which has a REST API component. That did look more actively maintained and perhaps is a way forward.

On Monday, 24 July 2023 at 18:50:38 UTC+1 Ralph Fiergolla wrote:
That is, as long as I stay within GWT there is no need to change (and loose type checking and convenience). I will happily stay with GWT RPC then!

R

Jens <jens.ne...@gmail.com> schrieb am Mo. 24. Juli 2023 um 18:24:

I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Depends on your situation of course. If you want to use your existing backend with other clients written in other languages then GWT-RPC is a bad fit. While the wire format of GWT-RPC is documented, you still need to write the client code to generate it. Also GWT-RPC supports inheritance which other languages you want to use might not support. Other JS based RPC solutions as well as general purpose solutions like gRPC typically do not support inheritance.

GWT-RPC will already be annoying if you decide to have some portions of your app being written in a different framework since it is easier to find developers for that framework, e.g. angular, svelte, react, whatever. You would then need to define a JS api that calls into GWT code so these frameworks can talk to your GWT-RPC backend (or you need to provide new endpoints in your backend that do not talk GWT-RPC).

-- 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-tool...@googlegroups.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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/692de019-081b-4612-ba19-a9dd3783ac5dn%40googlegroups.com.
Posted by at No comments:

Re: Partial super source? Possible?

Thanks Thomas. By "shadow" I was actually quoting you when you said: 

you cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String

In my previous reply, I was saying that I'm happy with this solution for my GWT app (whatever you call this method "shadow" or something else).

But my concern is now with J2CL (as I plan to move my GWT app to J2CL in the future).
I would like to know if this solution will also work with J2CL.
i.e. will I be able to provide my own implementation of String.format() if not emulated by J2CL?

On Tuesday, 25 July 2023 at 15:20:19 UTC+1 Thomas Broyer wrote:
On Tuesday, July 25, 2023 at 2:26:14 PM UTC+2 Bruno Salmon wrote:
The shadow super-source should work in my case, thank you.

 If later I want to move from GWT to J2CL, will I have a similar feature (ex: providing my own implementation of String.format() if not emulated) ?

IIRC, no: each source file must only appear once, so you cannot use shadowing.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/cd1e2396-afe8-47b6-8b37-5a5ca4459eb6n%40googlegroups.com.
Posted by at No comments:

Tuesday, July 25, 2023

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

Did y'all test DominoKit? It is actively maintained and has a REST module. I'm curious if you did test it what shortcomings you may have run into.

On Tuesday, July 25, 2023 at 9:23:53 AM UTC-4 RobW wrote:
We got to a similar point. Looked in depth at moving the GWT front end to a REST API - but found two big drawbacks: 
  1. none of the frameworks we could find had async callback handling similar to GWT-RPC, with common interface classes client server side AND support JAX-RS subresources. RestyGWT got close apart from those last two points - there is a model with common client/server interfaces, but it doesn't support subresources. We found at least 1 other GWT REST toolkit that had exactly the same issue  - so it's clearly not a trivial one to solve.
  2. somewhat more serious than the first issue was that none of the GWT REST API frameworks looked to be that actively maintained, at least tracking their GitHub commits anyhow
So ultimately, although REST API an attractive route, GWT-RPC remains more practical for us in the near term.

Note - one we didn't explore in depth but may come back too was Domino Kit, which has a REST API component. That did look more actively maintained and perhaps is a way forward.

On Monday, 24 July 2023 at 18:50:38 UTC+1 Ralph Fiergolla wrote:
That is, as long as I stay within GWT there is no need to change (and loose type checking and convenience). I will happily stay with GWT RPC then!

R

Jens <jens.ne...@gmail.com> schrieb am Mo. 24. Juli 2023 um 18:24:

I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Depends on your situation of course. If you want to use your existing backend with other clients written in other languages then GWT-RPC is a bad fit. While the wire format of GWT-RPC is documented, you still need to write the client code to generate it. Also GWT-RPC supports inheritance which other languages you want to use might not support. Other JS based RPC solutions as well as general purpose solutions like gRPC typically do not support inheritance.

GWT-RPC will already be annoying if you decide to have some portions of your app being written in a different framework since it is easier to find developers for that framework, e.g. angular, svelte, react, whatever. You would then need to define a JS api that calls into GWT code so these frameworks can talk to your GWT-RPC backend (or you need to provide new endpoints in your backend that do not talk GWT-RPC).

-- 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-tool...@googlegroups.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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/16623367-e3d6-46ad-9c0f-7cd02e7a496fn%40googlegroups.com.
Posted by at No comments:

Re: Partial super source? Possible?



On Tuesday, July 25, 2023 at 2:26:14 PM UTC+2 Bruno Salmon wrote:
The shadow super-source should work in my case, thank you.

 If later I want to move from GWT to J2CL, will I have a similar feature (ex: providing my own implementation of String.format() if not emulated) ?

IIRC, no: each source file must only appear once, so you cannot use shadowing.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/78192c92-2ac3-4602-beea-1010591573d6n%40googlegroups.com.
Posted by at No comments:

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

We got to a similar point. Looked in depth at moving the GWT front end to a REST API - but found two big drawbacks: 
  1. none of the frameworks we could find had async callback handling similar to GWT-RPC, with common interface classes client server side AND support JAX-RS subresources. RestyGWT got close apart from those last two points - there is a model with common client/server interfaces, but it doesn't support subresources. We found at least 1 other GWT REST toolkit that had exactly the same issue  - so it's clearly not a trivial one to solve.
  2. somewhat more serious than the first issue was that none of the GWT REST API frameworks looked to be that actively maintained, at least tracking their GitHub commits anyhow
So ultimately, although REST API an attractive route, GWT-RPC remains more practical for us in the near term.

Note - one we didn't explore in depth but may come back too was Domino Kit, which has a REST API component. That did look more actively maintained and perhaps is a way forward.

On Monday, 24 July 2023 at 18:50:38 UTC+1 Ralph Fiergolla wrote:
That is, as long as I stay within GWT there is no need to change (and loose type checking and convenience). I will happily stay with GWT RPC then!

R

Jens <jens.ne...@gmail.com> schrieb am Mo. 24. Juli 2023 um 18:24:

I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Depends on your situation of course. If you want to use your existing backend with other clients written in other languages then GWT-RPC is a bad fit. While the wire format of GWT-RPC is documented, you still need to write the client code to generate it. Also GWT-RPC supports inheritance which other languages you want to use might not support. Other JS based RPC solutions as well as general purpose solutions like gRPC typically do not support inheritance.

GWT-RPC will already be annoying if you decide to have some portions of your app being written in a different framework since it is easier to find developers for that framework, e.g. angular, svelte, react, whatever. You would then need to define a JS api that calls into GWT code so these frameworks can talk to your GWT-RPC backend (or you need to provide new endpoints in your backend that do not talk GWT-RPC).

-- 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-tool...@googlegroups.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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/169620a5-7a0b-4927-b22b-ac1d8a26ffc6n%40googlegroups.com.
Posted by at No comments:

Re: Partial super source? Possible?

The shadow super-source should work in my case, thank you.

 If later I want to move from GWT to J2CL, will I have a similar feature (ex: providing my own implementation of String.format() if not emulated) ?

On Friday, 21 July 2023 at 16:34:23 UTC+1 Colin Alworth wrote:
I don't use String.format() a lot, even in the normal JVM, but based on the Javadoc it looks like we could add the format method, and delegate to a java.util.Formatter, but then leave that unimplemented by default. Then, downstream applications could more easily add that, without having to worry about keeping the rest of String.java up to date?

Note also when trying to do anything beyond simple %s replacement, the java.util.Locale type exists in GWT emulation, but offers no instance methods outside of toString.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#format(java.lang.String,java.lang.Object...)


On Friday, July 21, 2023 at 4:38:24 AM UTC-5 Thomas Broyer wrote:
GWT standard emulation is "just" super-source itself. You cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String (copy from GWT and patch; and make sure it appears before GWT's emulation in the source path – i.e. IIRC make sure the <super-source> comes before any <include> that would bring com.google.gwt.emul.Emulation). This means you'll have to update your version whenever GWT updates its own.
But only ever do this for an application, never for a library!

On Thursday, July 20, 2023 at 1:46:15 PM UTC+2 Bruno Salmon wrote:
hi,

If GWT emulates a Java class but not all methods, is it possible to provide a complement as a super source?

For example, can I provide a super source for String.format() while keeping other String methods emulated by GWT?

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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/e9c73b85-e300-4b69-ac27-abaa66fbe865n%40googlegroups.com.
Posted by at No comments:

Monday, July 24, 2023

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

That is, as long as I stay within GWT there is no need to change (and loose type checking and convenience). I will happily stay with GWT RPC then!

R

Jens <jens.nehlmeier@gmail.com> schrieb am Mo. 24. Juli 2023 um 18:24:

I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Depends on your situation of course. If you want to use your existing backend with other clients written in other languages then GWT-RPC is a bad fit. While the wire format of GWT-RPC is documented, you still need to write the client code to generate it. Also GWT-RPC supports inheritance which other languages you want to use might not support. Other JS based RPC solutions as well as general purpose solutions like gRPC typically do not support inheritance.

GWT-RPC will already be annoying if you decide to have some portions of your app being written in a different framework since it is easier to find developers for that framework, e.g. angular, svelte, react, whatever. You would then need to define a JS api that calls into GWT code so these frameworks can talk to your GWT-RPC backend (or you need to provide new endpoints in your backend that do not talk GWT-RPC).

-- 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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/ab08b131-3904-49b1-8920-b924c7b31c9an%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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CACwwWxPMRKL%2Bk%3DBK-0P-e5xxykonSp7PAvMU0yQZdf1U6nzf6A%40mail.gmail.com.
Posted by at No comments:

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb


I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Depends on your situation of course. If you want to use your existing backend with other clients written in other languages then GWT-RPC is a bad fit. While the wire format of GWT-RPC is documented, you still need to write the client code to generate it. Also GWT-RPC supports inheritance which other languages you want to use might not support. Other JS based RPC solutions as well as general purpose solutions like gRPC typically do not support inheritance.

GWT-RPC will already be annoying if you decide to have some portions of your app being written in a different framework since it is easier to find developers for that framework, e.g. angular, svelte, react, whatever. You would then need to define a JS api that calls into GWT code so these frameworks can talk to your GWT-RPC backend (or you need to provide new endpoints in your backend that do not talk GWT-RPC).

-- 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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/ab08b131-3904-49b1-8920-b924c7b31c9an%40googlegroups.com.
Posted by at No comments:

Friday, July 21, 2023

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

Having readable network messages is very useful for debugging.

It's also easy to include more data in a GWT RPC messages than you really need unless you're careful with it.

Regards,
Paul

On Fri, 21 Jul 2023, 15:43 Ralph Fiergolla, <ralph.fiergolla@gmail.com> wrote:
I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Thomas Broyer <t.broyer@gmail.com> schrieb am Fr. 21. Juli 2023 um 12:34:


On Friday, July 21, 2023 at 11:38:59 AM UTC+2 petr...@o3enterprise.com wrote:
We have one deployment of a GWT app where there is a Fortiweb firewall that blocks every GWT RPC call because it recognizes every call as a Java Method Injection attack. This seems to be caused by the presence of the pattern "java.lang." in the messages from the client to the server like the following:

My idea is to convince the firewall administrator that these are false-positives as these calls are part of the GWT RPC mechanism that does not allow arbitrary java code execution on the server side.

Is my reasoning correct or am I not worried enough?

Your reasoning is correct. But you can also obfuscate type names to prevent triggering the WAF: https://github.com/gwtproject/gwt/blob/main/user/src/com/google/gwt/user/RemoteServiceObfuscateTypeNames.gwt.xml 
(disclaimer: I haven't used RPC for more than 10 years)

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/40bf5948-5d59-4d47-8686-7b1db98e80fdn%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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CACwwWxPGRqV2pBTq4iPr4mmbE%2Bb38sxzAZuN%3D__z%2BemUACS5%3Dw%40mail.gmail.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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CAGHNWNLxJj2xtR6HGZG6R9m20LPpwwFaO%2B1BEGrvouvQK_vbcQ%40mail.gmail.com.
Posted by at No comments:

Re: Partial super source? Possible?

I don't use String.format() a lot, even in the normal JVM, but based on the Javadoc it looks like we could add the format method, and delegate to a java.util.Formatter, but then leave that unimplemented by default. Then, downstream applications could more easily add that, without having to worry about keeping the rest of String.java up to date?

Note also when trying to do anything beyond simple %s replacement, the java.util.Locale type exists in GWT emulation, but offers no instance methods outside of toString.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#format(java.lang.String,java.lang.Object...)
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Formatter.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Locale.html


On Friday, July 21, 2023 at 4:38:24 AM UTC-5 Thomas Broyer wrote:
GWT standard emulation is "just" super-source itself. You cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String (copy from GWT and patch; and make sure it appears before GWT's emulation in the source path – i.e. IIRC make sure the <super-source> comes before any <include> that would bring com.google.gwt.emul.Emulation). This means you'll have to update your version whenever GWT updates its own.
But only ever do this for an application, never for a library!

On Thursday, July 20, 2023 at 1:46:15 PM UTC+2 Bruno Salmon wrote:
hi,

If GWT emulates a Java class but not all methods, is it possible to provide a complement as a super source?

For example, can I provide a super source for String.format() while keeping other String methods emulated by GWT?

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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/86163e40-07e8-47de-9ce9-4abfd81df242n%40googlegroups.com.
Posted by at No comments:

Re: GWT compilation issue with jdk 17

There is community work underway to update GWT-RPC itself to use jakarta.servlet packages, and the same idea could be applied to gwtplatform. Unfortunately, the gwtplatform.com domain is still owned, so any fork could not take over the groupid, but would need to pick a new one, which might cause some irritation when upgrading. I do see that the domain is scheduled to expire next year, but that probably isn't long enough to wait. It might be possible to contact the former owners to get permission for this work to be published as well. If you take that route, I'd be interested in being involved.

I've used the eclipse transformer before, and personally found it to be more trouble that it is worth.


On Friday, July 21, 2023 at 8:03:56 AM UTC-5 NIKITAH wrote:
Thank you Thomas for your guidance .

On Friday, July 21, 2023 at 6:25:36 PM UTC+5:30 Thomas Broyer wrote:
On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:
Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 9.0 ?

None!

Repeating myself here: 
  • GWTP is long dead; at least one year before the Javax/Jakarta mess was even announced (except for one never-released commit in Sept. 2018)
Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or migrate away from legacy/abandoned libs and frameworks that lock them to Java EE.

Now paraphrasing myself, you have to either:
  • stay on Jakarta EE 8 (or earlier Java EE)
  • rewrite the whole thing to remove GWTP
  • transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse Transformer

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c27903b8-a23b-4d9b-bc75-465e53b1d1ean%40googlegroups.com.
Posted by at No comments:

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb

I think I asked the question before: as a long-term GWT-RPC user, what would be the benefit of moving to some other RPC protocol/mechanism?

Thomas Broyer <t.broyer@gmail.com> schrieb am Fr. 21. Juli 2023 um 12:34:


On Friday, July 21, 2023 at 11:38:59 AM UTC+2 petr...@o3enterprise.com wrote:
We have one deployment of a GWT app where there is a Fortiweb firewall that blocks every GWT RPC call because it recognizes every call as a Java Method Injection attack. This seems to be caused by the presence of the pattern "java.lang." in the messages from the client to the server like the following:

My idea is to convince the firewall administrator that these are false-positives as these calls are part of the GWT RPC mechanism that does not allow arbitrary java code execution on the server side.

Is my reasoning correct or am I not worried enough?

Your reasoning is correct. But you can also obfuscate type names to prevent triggering the WAF: https://github.com/gwtproject/gwt/blob/main/user/src/com/google/gwt/user/RemoteServiceObfuscateTypeNames.gwt.xml 
(disclaimer: I haven't used RPC for more than 10 years)

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/40bf5948-5d59-4d47-8686-7b1db98e80fdn%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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CACwwWxPGRqV2pBTq4iPr4mmbE%2Bb38sxzAZuN%3D__z%2BemUACS5%3Dw%40mail.gmail.com.
Posted by at No comments:

Re: GWT compilation issue with jdk 17

Thank you Thomas for your guidance .

On Friday, July 21, 2023 at 6:25:36 PM UTC+5:30 Thomas Broyer wrote:
On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:
Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 9.0 ?

None!

Repeating myself here: 
  • GWTP is long dead; at least one year before the Javax/Jakarta mess was even announced (except for one never-released commit in Sept. 2018)
Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or migrate away from legacy/abandoned libs and frameworks that lock them to Java EE.

Now paraphrasing myself, you have to either:
  • stay on Jakarta EE 8 (or earlier Java EE)
  • rewrite the whole thing to remove GWTP
  • transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse Transformer

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/53d30f6a-4d0b-4411-9e78-4eb987d1f0e7n%40googlegroups.com.
Posted by at No comments:

Re: GWT compilation issue with jdk 17



On Friday, July 21, 2023 at 12:51:32 PM UTC+2 NIKITAH wrote:
Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 9.0 ?

None!

Repeating myself here: 
  • GWTP is long dead; at least one year before the Javax/Jakarta mess was even announced (except for one never-released commit in Sept. 2018)
Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or migrate away from legacy/abandoned libs and frameworks that lock them to Java EE.

Now paraphrasing myself, you have to either:
  • stay on Jakarta EE 8 (or earlier Java EE)
  • rewrite the whole thing to remove GWTP
  • transform GWTP to Jakarta EE 9+ with the help of tools like Eclipse Transformer

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/bb903f74-9480-49f9-b600-6f7dec5648d0n%40googlegroups.com.
Posted by at No comments:

Re: GWT compilation issue with jdk 17

Yes , we are using  jakartaee-api : 9.0.0 . So can you please suggest which version of gwtp-dispatch-rest-*.jar will be compatible with Jakarta 9.0 ?

On Friday, July 21, 2023 at 3:58:59 PM UTC+5:30 Thomas Broyer wrote:
Two things:

  • using JDK 17 doesn't mean you have to use Jakarta EE 9+, Java EE 8 / Jakarta EE 8 should still work just fine. You may have also changed your server to a Jakarta EE 9+ version, but that's (almost) independent from using JDK 17
  • GWTP is long dead; at least one year before the Javax/Jakarta mess was even announced (except for one never-released commit in Sept. 2018)
Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or migrate away from legacy/abandoned libs and frameworks that lock them to Java EE.

On Friday, July 21, 2023 at 11:52:55 AM UTC+2 NIKITAH wrote:

Just FYI , I've already tried with  gwtp-dispatch-rest-1.6.jar and facing the same issue  " The import javax.ws.rs.core.HttpHeaders cannot be resolved" .
As , we are aware in jdk17 we are using Jakarta API means  HttPheaders is now moved to jakarta.ws.rs.core.HttpHeaders . 
So , wanted to know if there is any gwtp-dispatch-rest jar with JDK 17.

On Thursday, July 20, 2023 at 3:11:38 PM UTC+5:30 NIKITAH wrote:
Hi , 

I am trying to compile GWT with JDK17.
As per https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 , I came to know that GWT2.10.0 is compatible with JDK17 and hence I updated the same in my project .

Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
[ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be resolved
[ERROR] Line 95: HttpHeaders cannot be resolved to a variable

Can someone please help and let me know which version of gwtp-dispatch-rest-*.jar is compatible with JDK 17 .

Thanks in advance .

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/52e3013d-813a-4156-ac8a-82bde21af7b9n%40googlegroups.com.
Posted by at No comments:

Re: GWT RPC call recognized as a Java Method Injection by Fortiweb



On Friday, July 21, 2023 at 11:38:59 AM UTC+2 petr...@o3enterprise.com wrote:
We have one deployment of a GWT app where there is a Fortiweb firewall that blocks every GWT RPC call because it recognizes every call as a Java Method Injection attack. This seems to be caused by the presence of the pattern "java.lang." in the messages from the client to the server like the following:

My idea is to convince the firewall administrator that these are false-positives as these calls are part of the GWT RPC mechanism that does not allow arbitrary java code execution on the server side.

Is my reasoning correct or am I not worried enough?

Your reasoning is correct. But you can also obfuscate type names to prevent triggering the WAF: https://github.com/gwtproject/gwt/blob/main/user/src/com/google/gwt/user/RemoteServiceObfuscateTypeNames.gwt.xml 
(disclaimer: I haven't used RPC for more than 10 years)

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/40bf5948-5d59-4d47-8686-7b1db98e80fdn%40googlegroups.com.
Posted by at No comments:

Re: GWT compilation issue with jdk 17

Two things:

  • using JDK 17 doesn't mean you have to use Jakarta EE 9+, Java EE 8 / Jakarta EE 8 should still work just fine. You may have also changed your server to a Jakarta EE 9+ version, but that's (almost) independent from using JDK 17
  • GWTP is long dead; at least one year before the Javax/Jakarta mess was even announced (except for one never-released commit in Sept. 2018)
Legacy projects should stay on "legacy" Java EE (or Jakarta EE 8), or migrate away from legacy/abandoned libs and frameworks that lock them to Java EE.

On Friday, July 21, 2023 at 11:52:55 AM UTC+2 NIKITAH wrote:

Just FYI , I've already tried with  gwtp-dispatch-rest-1.6.jar and facing the same issue  " The import javax.ws.rs.core.HttpHeaders cannot be resolved" .
As , we are aware in jdk17 we are using Jakarta API means  HttPheaders is now moved to jakarta.ws.rs.core.HttpHeaders . 
So , wanted to know if there is any gwtp-dispatch-rest jar with JDK 17.

On Thursday, July 20, 2023 at 3:11:38 PM UTC+5:30 NIKITAH wrote:
Hi , 

I am trying to compile GWT with JDK17.
As per https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 , I came to know that GWT2.10.0 is compatible with JDK17 and hence I updated the same in my project .

Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
[ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be resolved
[ERROR] Line 95: HttpHeaders cannot be resolved to a variable

Can someone please help and let me know which version of gwtp-dispatch-rest-*.jar is compatible with JDK 17 .

Thanks in advance .

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/fb2910fb-7cf9-4dc8-b9b9-f6c661f51e9cn%40googlegroups.com.
Posted by at No comments:

Re: GWT compilation issue with jdk 17


Just FYI , I've already tried with  gwtp-dispatch-rest-1.6.jar and facing the same issue  " The import javax.ws.rs.core.HttpHeaders cannot be resolved" .
As , we are aware in jdk17 we are using Jakarta API means  HttPheaders is now moved to jakarta.ws.rs.core.HttpHeaders . 
So , wanted to know if there is any gwtp-dispatch-rest jar with JDK 17.

On Thursday, July 20, 2023 at 3:11:38 PM UTC+5:30 NIKITAH wrote:
Hi , 

I am trying to compile GWT with JDK17.
As per https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 , I came to know that GWT2.10.0 is compatible with JDK17 and hence I updated the same in my project .

Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
[ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be resolved
[ERROR] Line 95: HttpHeaders cannot be resolved to a variable

Can someone please help and let me know which version of gwtp-dispatch-rest-*.jar is compatible with JDK 17 .

Thanks in advance .

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/ef930587-59f1-4307-a56a-f4a668ff6c75n%40googlegroups.com.
Posted by at No comments:

Re: Partial super source? Possible?

GWT standard emulation is "just" super-source itself. You cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String (copy from GWT and patch; and make sure it appears before GWT's emulation in the source path – i.e. IIRC make sure the <super-source> comes before any <include> that would bring com.google.gwt.emul.Emulation). This means you'll have to update your version whenever GWT updates its own.
But only ever do this for an application, never for a library!

On Thursday, July 20, 2023 at 1:46:15 PM UTC+2 Bruno Salmon wrote:
hi,

If GWT emulates a Java class but not all methods, is it possible to provide a complement as a super source?

For example, can I provide a super source for String.format() while keeping other String methods emulated by GWT?

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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/853444d3-8f18-483a-82f6-0bd0eaa55acbn%40googlegroups.com.
Posted by at No comments:

GWT RPC call recognized as a Java Method Injection by Fortiweb

We have one deployment of a GWT app where there is a Fortiweb firewall that blocks every GWT RPC call because it recognizes every call as a Java Method Injection attack. This seems to be caused by the presence of the pattern "java.lang." in the messages from the client to the server like the following:

7|0|7|https://host/app/app_gui/|BD9331DABCA5012FC56F3600DF03415F|com.app.gui.client.Bridge|getClientConfiguration|java.lang.St ring/2004016611|john|ADMINISTRATOR|1|2|3|4|2|5|5|6|7|

My idea is to convince the firewall administrator that these are false-positives as these calls are part of the GWT RPC mechanism that does not allow arbitrary java code execution on the server side.

Is my reasoning correct or am I not worried enough?

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2e3678f0-8846-4a5c-a113-746383473e07n%40googlegroups.com.
Posted by at No comments:

Thursday, July 20, 2023

Partial super source? Possible?

hi,

If GWT emulates a Java class but not all methods, is it possible to provide a complement as a super source?

For example, can I provide a super source for String.format() while keeping other String methods emulated by GWT?

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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7c05e220-edc7-4d5e-b95a-a6f3d36246d8n%40googlegroups.com.
Posted by at No comments:

GWT compilation issue with jdk 17

Hi , 

I am trying to compile GWT with JDK17.
As per https://www.gwtproject.org/release-notes.html#Release_Notes_2_10_0 , I came to know that GWT2.10.0 is compatible with JDK17 and hence I updated the same in my project .

Now, facing issue with gwtp-dispatch-rest-1.4.jar like : 
[ERROR] Line 24: The import javax.ws.rs.core.HttpHeaders cannot be resolved
[ERROR] Line 95: HttpHeaders cannot be resolved to a variable

Can someone please help and let me know which version of gwtp-dispatch-rest-*.jar is compatible with JDK 17 .

Thanks in advance .

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2ceb6af2-82fb-4f19-882b-849d2e1ce671n%40googlegroups.com.
Posted by at No comments:

Wednesday, July 19, 2023

Re: DominoKit release 1.0.0

Thanks!!! That is amazing!

On Wed, Jul 19, 2023 at 2:21 PM Vegegoku <akabme@gmail.com> wrote:
We are thrilled to announce the first major release of DominoKit toolset :

  • domino-jackson : 1.0.0 Generate JSON mappers that works for both client and server side, works with both GWT/J2CL.
  • domino-history : 1.0.0 A wrapper around browser history state API that allow you to work smoothly with browser URL for routing, works with both GWT/J2CL.
  • domino-rest : 1.0.0 Generate REST API clients from jax-rs interfaces and use them to make REST calls from browser to server or JVM to server, works with both GWT/J2CL.
  • domino-ui : 1.0.0 Build rich web user interfaces using java and use a large set of feature rich components to make building apps easier. demo here, works with both GWT/J2CL.
  • domino-mvp : 1.0.0 All in one framework that combines DominoKit toolset to control your app pages life-cycle and routing, works with both GWT/J2CL.
  • domino-cli : 1.0.0 CLI tool to create new GWT/J2CL projects that uses DominoKit tools.

With this milestone we are already set to start a new development cycle to bring more tools and features to DominoKit tools set.

I also would like to thank everyone who supported us through the years to get to this point. and special thanks to Vertispan for sponsoring a large portion of the work.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7b022b17-efe5-4a9a-87af-32c26a41914en%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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CA%2BkiFsczVGt52tnNvSGi%3DbhwqOnjB3wB0o%2BC0oAQDB2kpSA_vg%40mail.gmail.com.
Posted by at No comments:

Saturday, July 15, 2023

Re: Experiences with Kotlin/JS?

Also would like to hear from someone with some deep experience with it for a good comparison.  However, my 2 cents from what I've seen...

Good integration and you get the basics of Kotlin to JS compilation, plus easy to use JavaScript interoperability.

You need to include a 1.3Mb kotlin.js library file with your project which isn't ideal.  And if you want to use extra features, like the kotlin html-js lib, you also need to add those, which further increases the JS download size.

Probably a good choice for connecting a Kotlin project to a JS project, or if you just need some simple JS for your Kotlin project.  If you needed more features, GWT would be a better choice (with its UIBinder, RPC, ...).

I agree with your comments about J2CL.

Personally, I'm more excited about Java to WASM compilations that will hopefully be more supported now WASM is getting garbage collection.

On Friday, 14 July 2023 at 11:37:22 am UTC+10 ji...@jinq.org wrote:
I'm a long-time GWT user, but I've recently been tempted by the siren songs of Kotlin/JS. Does anyone have any experience with it? Is it worth migrating to?

How large is its JS output compared to GWT? Is the code output reliable and mature? How is the debugging? How is the JS interop? I've read that there might be semi-automated methods of converting Java code to Kotlin--how have people found that? I don't use many of the GWT libraries, so I can easily rework that aspect of the code. Can I stay with Eclipse-Maven or will I have to move to IntelliJ-Gradle? 

Every time I look at J2CL, it just seems like it went too deep down the Google rabbit-hole and is completely divorced from modern JavaScript practices, so I've been curious about other possible future migration paths for my GWT code.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/72563d2b-75df-4db5-a9f3-6b1cf5051d3fn%40googlegroups.com.
Posted by at No comments:

Thursday, July 13, 2023

Experiences with Kotlin/JS?

I'm a long-time GWT user, but I've recently been tempted by the siren songs of Kotlin/JS. Does anyone have any experience with it? Is it worth migrating to?

How large is its JS output compared to GWT? Is the code output reliable and mature? How is the debugging? How is the JS interop? I've read that there might be semi-automated methods of converting Java code to Kotlin--how have people found that? I don't use many of the GWT libraries, so I can easily rework that aspect of the code. Can I stay with Eclipse-Maven or will I have to move to IntelliJ-Gradle? 

Every time I look at J2CL, it just seems like it went too deep down the Google rabbit-hole and is completely divorced from modern JavaScript practices, so I've been curious about other possible future migration paths for my GWT code.

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/8a5f6c91-98f6-4fd2-9785-d112d04b5faan%40googlegroups.com.
Posted by at No comments:

Wednesday, July 12, 2023

Re: GWT 3rd party framework for Grid layout

Sorry, i think i need get some more clarity in my query. Tables(grid) and graphs are already developed using GWT where as now the plan is to create a dashboard using those components as similar to following link https://codesandbox.io/s/draggable-resizable-dashboard-zf3hx. Here the challenge is arranging those components. on the dashboard user can move the components and arrange and re-size them. actually i am looking a 3rd party framework for arranging layout functionality in a grid manner. following link https://codesandbox.io/s/draggable-resizable-dashboard-zf3hx components we can move and arrange it and its been created in react. looking for a similar one.

Sorry for the confusion and thanks Eric & Rafat your inputs.

Thanks,
Vinod

On Wednesday, July 12, 2023 at 10:54:02 PM UTC+5:30 Rafat J. Al-Barouki wrote:
You can check domino UI

https://github.com/DominoKit/domino-ui

Best regards,
Rafat Al-Barouki
Co-Founder
Dominokit

On Wed, Jul 12, 2023, 10:12 AM vinod kumar <vinod...@gmail.com> wrote:
Hi All,

I am looking for a 3rd party framework which provides Grid layout option where we can arrange the components(table, graph etc...) in a column or row format (eg: https://codesandbox.io/s/draggable-resizable-dashboard-zf3hx). Please share such framework details.

Thanks,
Vinod

--
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/612b375c-4ea6-471f-a03f-5064d762af50n%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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/7f84b3e6-d380-4a55-b411-5febda9573c7n%40googlegroups.com.
Posted by at No comments:

Re: GWT compilation error with JDK 11

Thanks for the information. The compilation problem has already been resolved. thanks, Jenny

On Wednesday, July 12, 2023 at 8:32:20 AM UTC-5 RobW wrote:
I can't comment on the Eclipse plugin side of things, because we don't use those. But I can confirm that basic GWT 2.9/2.10 compilation works fine under Java 11 - that's our main Java platform now. I do recall some migration notes in the GWT 2.9 or 2.10 release notes we had to take care over, but I don't think those were Java version specific. More a case of changes in GWT packaging.

On Tuesday, 11 July 2023 at 23:47:37 UTC+1 Ying Jin wrote:
Ralph, thanks very much for your suggestion. I'll look into more of the approach to convert our gwt project to maven project.

BTW, I've found the solution to make the GWT plugin work again in my laptop to compile the GWT project.

I came across the following post when searching for the error related to webappcreator.

After I removed the "classpath" system variable from my new laptop and moved the GWT SDK to the top of the build path, the GWT Compiler starts working to compile the GWT project.

https://topic.alibabacloud.com/a/exception-invocation-of-font-colorredcomfont-font-colorredgooglefont-gwt-user-font-colorredtoolsfont-webappcreator-failed-see-the-error-log-for-more-details_8_8_31771273.html

Cheers ,
Jenny


On Tuesday, July 11, 2023 at 12:45:24 PM UTC-5 Ralph Fiergolla wrote:

It should not be that hard actually: you probably have separated client, shared and server side classes following the standard package naming convention. That is, basically it will be sufficient to copy your source code to the according client/shared/server sub projects and you are done. Okay, devil is in the details, but I did the same with some legacy project and happily live ever after. Give it a try. Definitely better than spending more time on installing different eclipse versions and plug-ins.
Cheers
Ralph 
On Tuesday, July 11, 2023 at 6:51:11 PM UTC+2 Ying Jin wrote:
Ralph,

Thanks for your suggestion. However, one of our GWT project in production was developed long time ago and has very big codebase. I'm not sure how hard to convert it to Maven oriented project. It seems that we have to do lots of code refactoring 
in order to separate client side and server side code and other configuraitons. 

thanks,
Jenny

On Monday, July 10, 2023 at 11:59:01 PM UTC-5 Ralph Fiergolla wrote:
Hi Jenny!
With all these issues related to out-dated Eclipse plug-ins I would strongly suggest switching to the new GWT Maven plug-in instead. Follow the instructions https://github.com/tbroyer/gwt-maven-archetypes/ to create a project that you can easily import into the most recent Eclipse (or any other IDE) subsequently. I don't see much support for Eclipse plug-ins coming… I learned it the hard way too but am now happily working the Maven way. 
Bon courage!
Ralph 
On Monday, July 10, 2023 at 7:25:41 PM UTC+2 Ying Jin wrote:
Hi Colin,

I posted this issue on the gwt plugin site below, but there is no reply yet.


In addition, I've tried to install other version of Eclipse such as Eclipse 4.18 (2020-12) with a new workspace. After I installed GWT plugin 3 from market place and tried to create a sample gwt web application project 
as described below in gwt site, I got the error " Invocation of com.google.gwt.user.tools.WebAppCreator failed. See the error log for more details."  It seems to me this current market place gwt plugin didn't work as I didn't use our project at all
and followed the tutorial below.


Is there a way to get a working GWT plugin for Eclipse which can work with JDK 11?

Your help is much appreciated!
Jenny
On Tuesday, July 4, 2023 at 12:43:05 PM UTC-5 Colin Alworth wrote:
If the class can't be found, something is wrong with your gwt-dev, or the gwt-dev isn't on the classpath, or more details from the error message will indicate why the Compiler class couldn't be loaded.

Please file a bug with more details (logs, full error message, other details about differences between the working computer and non-working computer) at https://github.com/gwt-plugins/gwt-eclipse-plugin/ so contributors there can take a closer look?

On Sunday, July 2, 2023 at 2:28:44 PM UTC-5 jiny...@gmail.com wrote:
I tried to reinstall Eclipse again and GWT 3 plugin again from Eclipse market, downloaded and reinstalled gwt 2.9 for the project, however, I still encountered the error below.
It is so weird, the project configuration in eclipse works in my old laptop, not in the new one though it both has windows 10 installed.

Error: Could not find or load main class com.google.gwt.dev.Compiler

eclipse-jee-2020-06-R-win32-x86_64
GWT Plugin 3.0
gwt-2.9.0

Please see attached for the java build path dialog in eclipse.

Any idea about resolving this error? Please help shed some light on this problem.

Your help is much appreciated!
Jenny


On Friday, June 16, 2023 at 3:25:42 PM UTC-5 Ying Jin wrote:
Thanks for your reply. Please see attached for the GWT lib specified in the java build path in Eclipse. I tried to compile it with JDK 8 and it didn't work either. 
The same project configuration in Eclipse worked in my old laptop, but not in my new laptop. The Eclipse in the new laptop is a copy of the Eclipse installed in the old laptop.

In addition, I also tried to  copy the "gwt-dev.jar" from the old laptop to the new one, but the compilation still gave me the following error.

Error: Could not find or load main class com.google.gwt.dev.Compiler

The project was compiled by using GWT->Compile option provided by the GWT Plugin installed in Eclipse.

Version: 2020-06 (4.16.0)
GWT Plugin version: 3.0

Your help is greatly appreciated!

thanks,
Jenny
On Friday, June 16, 2023 at 12:33:18 PM UTC-5 Colin Alworth wrote:
GWT 2.9 should support running on Java 11, both running on JDK 11 and compiling Java 11 sources.

Without other information, it sounds like there is a problem with your copy of gwt-dev.jar - the jar might be corrupt, or somehow not on your classpath?

Can you verify that the jar is present and correct, and share more specifics of how you are building?

On Thursday, June 15, 2023 at 6:00:43 PM UTC-5 jiny...@gmail.com wrote:
Hello,

I tried to compile our GWT 2.9 project with JDK 11, but encountered the following error:

Error: Could not find or load main class com.google.gwt.dev.Compiler

Caused by: java.lang.ClassNotFoundException: com.google.gwt.dev.Compiler

BTW, the Eclipse version is  Version: 2020-06 (4.16.0). 

Please help shed some lights on this issue.

thanks,
Jenny

--
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 on the web visit https://groups.google.com/d/msgid/google-web-toolkit/32d79081-9455-44dd-8ad5-9b669060ef66n%40googlegroups.com.
Posted by at No comments:
Subscribe to: Posts (Atom)