Dominokit tools release update

2024-01-30 Thread Vegegoku 
We are glad to announce the new releases of Dominokit tools :

*Domino-ui 2.0.0*
Find release notes here 
https://github.com/DominoKit/domino-ui/releases/tag/2.0.0

*Domino-history 1.0.3*
Find release notes here 
https://github.com/DominoKit/domino-history/releases/tag/1.0.3

*Domino-rest 2.0.0-RC1*
Moved to jakarta namespace, find release notes here 
https://github.com/DominoKit/domino-rest/releases/tag/2.0.0-RC1

We would like to remind you that you can now check our documentation for 
different DominoKit tools within our website :

*The documentation will be updated soon to include and match the new 
changes.*

- *Domino-ui documentation*
https://dominokit.com/solutions/domino-ui/v2/docs/getting-started

- *Domino-jackson documentation*
https://dominokit.com/solutions/domino-jackson/v1/docs/getting-started

- *Domino-rest documentation*
https://dominokit.com/solutions/domino-rest/v1/docs/getting-started

- *Domino-history documentation*
https://dominokit.com/solutions/domino-history/v1/docs/getting-started

Your feedback is welcome and please help us spread the knowledge

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/331e4089-b9ad-4de9-85fb-c8320ed9c3abn%40googlegroups.com.

Re: Is moving away from RPC a good idea?

2024-01-11 Thread Vegegoku 
The annotation on the POJO is not required at all, Domino-rest will auto 
generate the json-mapping classes if the jax-rs/jakarata resource 
consumes/produces a json even if the annotation is missing, so you can keep 
the POJO clean or only have Jackson compatible annotations. ;-)

On Thursday, January 11, 2024 at 11:35:05 AM UTC+3 Vassilis Virvilis wrote:

> First of all thanks for doing this work. It is hugely appreciated and 
> required in order to avoid GWT and GWT projects look like zombies in a dead 
> landscape.
>
> I am using RestyGWT and yes I also believe it uses Generators 
> (GWT.create() ?). I am facing a problem there since RestyGWT is deadish 
> itself.
>
> One of the reasons I abandoned GWT-RPC was Jsinterop. With Jsinterop you 
> can include and link to js libraries in the client. Some of them require 
> data from the backend e.g. datatables.net, d3 etc. GWT-RPC is not 
> compatible with them so I would need to use RequestFactory, which I never 
> liked or another framework. So why have two of them? Use one. Go to JSON. 
> RestyGWT was the only viable choice at the time.
>
> With Resty-GWT I can have my POjOs *without annotations*, and I can share 
> them between backend, frontend and other clients (non web). RestyGWT has 2 
> backends:
> - an older private jackson like (forked) implementation. That's the one I 
> use.
> - a newer gwt-jackson based one. This one never worked for me.
>
> Furthermore I have invested in RestGWT and I have some custom patches so 
> RestyGWT can transmit my generics.
>
> At this point domino-jackson and domino-rest looks like the way forward 
> but from a quick look require annotations in the POJO and this is something 
> that I would like to avoid.
>
> Just my 2 bits. Sorry if incoherent...
>
>
>
>
> On Wed, Jan 10, 2024 at 9:45 PM Michael Conrad  wrote:
>
>> You should investigate the DominoKit project. They have a much more 
>> up-to-date JSON/Jackson-ish implementation.
>>
>> Ref: https://github.com/DominoKit/domino-rest
>>
>>
>>
>> On 1/10/24 11:26, Christian Hebert wrote:
>>
>> Hi guys, I've seen the changes in the new release regarding jakarta 
>> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
>> is still based on the Servlet API 3.1. 
>>
>> Prior of seeing that change, I tried to move away from RPC calls and use 
>> http requests instead. I found a nice library called RestyGWT (
>> https://resty-gwt.github.io/) who can really simplify the process of 
>> handling json data from/to a Rest API.
>>
>> So I converted my GWT remote servlets to a Rest API, made a few minor 
>> changes in my client code and voilà, I was able to deploy it on a Jakarta 
>> Application server since there is no GWT involved on the server side 
>> anymore. 
>>
>> The last version of RestyGWT has been release in 2020 so I'm not sure how 
>> active this project is but from what I've seen it's enough for me.
>>
>> So, I would like to get your thoughts on that.  Would you go on that 
>> road? stick to RPC calls and wait for a version of GWT based on Jakarta? 
>> build your "own" GWT with the changes introduced in the vew version?
>> -- 
>> 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/8fa7dc19-2a15-442d-93b2-adebb947046cn%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-tool...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/156e77ff-25bd-4743-8798-0d0347d1866d%40newsrx.com
>>  
>> 
>> .
>>
>
>
> -- 
> Vassilis Virvilis
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/4fc34b98-5504-4981-a942-ae633f4b77e9n%40googlegroups.com.

Re: Is moving away from RPC a good idea?

2024-01-11 Thread Vegegoku 
Domino-rest is up-to-date well documented and in our next release 
-Currently available in the HEAD-SNAPSHOT- we are moving to jakarta 
namespace.

Full documentation can be found in our website 
here https://dominokit.com/solutions/domino-rest/v1/docs/getting-started

On Wednesday, January 10, 2024 at 7:26:04 PM UTC+3 Christian Hebert wrote:

> Hi guys, I've seen the changes in the new release regarding jakarta 
> servlets, which is great, it's a step toward jakarta but to this day,  GWT 
> is still based on the Servlet API 3.1. 
>
> Prior of seeing that change, I tried to move away from RPC calls and use 
> http requests instead. I found a nice library called RestyGWT (
> https://resty-gwt.github.io/) who can really simplify the process of 
> handling json data from/to a Rest API.
>
> So I converted my GWT remote servlets to a Rest API, made a few minor 
> changes in my client code and voilà, I was able to deploy it on a Jakarta 
> Application server since there is no GWT involved on the server side 
> anymore. 
>
> The last version of RestyGWT has been release in 2020 so I'm not sure how 
> active this project is but from what I've seen it's enough for me.
>
> So, I would like to get your thoughts on that.  Would you go on that road? 
> stick to RPC calls and wait for a version of GWT based on Jakarta? build 
> your "own" GWT with the changes introduced in the vew version?
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/b203501d-6b3c-4c77-ab6a-549be840a429n%40googlegroups.com.

DominoKit tools new releases

2023-12-10 Thread Vegegoku 
We are glad to announce the new releases of Dominokit tools :

*Domino-ui 2.0.0-RC5*
Find release notes here 
https://github.com/DominoKit/domino-ui/releases/tag/2.0.0-RC5
*Domino-ui 1.0.6*
Find release notes here 
https://github.com/DominoKit/domino-ui/releases/tag/1.0.6

*Domino-jackons 1.0.2 - 1.0.4*
The releases introduced a better way to do super sources that is compatible 
with GWT and J2CL, upgraded dependencies, moved to java 11 and introduces 
custom (de)serializers support.

*Domino-jackons 1.0.1 - 1.0.2*
The releases introduced a better way to do super sources that is compatible 
with GWT and J2CL, upgraded dependencies, moved to java 11 and fixes some 
minor issues.


We would like to remind you that you can now check our documentation for 
different DominoKit tools within our website :

- Domino-ui documentation
https://dominokit.com/solutions/domino-ui/v2/docs/getting-started

- Domino-jackson documentation
https://dominokit.com/solutions/domino-jackson/v1/docs/getting-started

- Domino-rest documentation
https://dominokit.com/solutions/domino-rest/v1/docs/getting-started

- Domino-history documentation
https://dominokit.com/solutions/domino-history/v1/docs/getting-started

Your feedback is welcome and please help us spread the knowledge

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/80c4c27d-3c43-47ce-be83-b1dcadd03cc0n%40googlegroups.com.

DominoKit has a new home

2023-10-31 Thread Vegegoku 
Exciting news — https://dominokit.com is live! Our new platform stands as a 
beacon of inclusion, unifying detailed documentation in one centralized 
location to empower and educate. We invite you to explore this collective 
reservoir of knowledge, designed to support and inspire. Please help us 
spread the word by sharing this resource with your network and beyond. 
Together, we can create a vast community of shared wisdom and resources.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/5b2037b4-d8d9-4fbd-9e7d-4e9d8f2c853en%40googlegroups.com.

Domino-ui 2.0.0-RC2 release

2023-09-11 Thread Vegegoku 
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-toolkit+unsubscr...@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.

DominoKit release 1.0.0

2023-07-19 Thread Vegegoku 
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+unsubscr...@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.

Re: Domino-ui 1.0.0-RC15 released

2023-01-13 Thread Vegegoku 
There was a regression issue in RC15 , the regression have been fixed and 
released 1.0.0-RC16
https://github.com/DominoKit/domino-ui/releases/tag/1.0.0-RC16
Sorry for the inconvenience regression

On Thursday, January 12, 2023 at 8:26:14 PM UTC+3 Vegegoku wrote:

> Domino-ui 1.0.0-RC15 have been released with lots of exciting features, 
> specially for data table including , column resizing, column pining, column 
> grouping, aggregation summary and more.., also lots enhancements, and 
> includes many bugs fixes. 
>
> To have an idea what we were working on since last release please take a 
> look at the release notes here 
>
> https://github.com/DominoKit/domino-ui/releases/tag/1.0.0-RC15 
>
> I would like to thank *Vertispan* for sponsoring the work on this 
> release. We can do more when we have people supporting our 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/11784e83-5e4a-4ad1-824c-283f809cd98en%40googlegroups.com.

Domino-ui 1.0.0-RC15 released

2023-01-12 Thread Vegegoku 
Domino-ui 1.0.0-RC15 have been released with lots of exciting features, 
specially for data table including , column resizing, column pining, column 
grouping, aggregation summary and more.., also lots enhancements, and 
includes many bugs fixes. 

To have an idea what we were working on since last release please take a 
look at the release notes here 

https://github.com/DominoKit/domino-ui/releases/tag/1.0.0-RC15 

I would like to thank *Vertispan* for sponsoring the work on this release. 
We can do more when we have people supporting our 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/dc9f1b5a-adf5-4f6f-a257-99294fea5507n%40googlegroups.com.

Domino-ui RC-11 released

2022-02-13 Thread Vegegoku 
Hi all
We are glad to announce that Domino-ui RC11 have been released with some 
new features, enhancements and bug fixes, find more about the release here
https://github.com/DominoKit/domino-ui/releases/tag/1.0.0-RC11

enjoy. :-)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/e5cca722-17ce-4a52-9cb6-de6ca68cc4bfn%40googlegroups.com.

Re: [gwt-contrib] Re: Goodbye IE 8–9 

2021-09-30 Thread Vegegoku 
I vote to even drop support for IE11. 

On Thursday, September 30, 2021 at 7:49:56 PM UTC+3 nilo...@gmail.com wrote:

> I've just filed https://github.com/gwtproject/gwt/issues/9739, where a 
> workaround exists in java.util.Date that nearly doubles the time it takes 
> to parse date strings and build date objects. This workaround exists for 
> IE8 and IE9, as all more recent browsers implement the same behavior as we 
> already would expect. Dropping support for those two browsers would 
> simplify the code required here
>
> From the age of this thread and the discussion so far, it sounds like 
> there is interest in keeping IE11 still, but no one has spoke up about IE10 
> or below. 
>
> Additionally, java.util.Random emulation was changed to require 
> Date.now(), which isn't available in IE8, so neither GWT 2.8.2 nor GWT 
> 2.9.0 are apparently compatible with IE8 anyway, at least in this small 
> way. This should give us some confidence (along with the lack of opposition 
> in this thread) that at least IE8 is definitely safe to drop.
>
> So, is there any objection at this time to dropping what remains of IE8, 
> IE9, and IE10 support from GWT? Then, we can reevaluate IE11 at some later 
> date, for GWT itself? Various migrated GWT modules have focused their 
> efforts on well-supported browsers, and are likely to only support IE11 by 
> accident anyway.
>
> On Friday, March 12, 2021 at 1:20:02 AM UTC-6 stuckagain wrote:
>
>> We still need IE11 support in the banking sector. We still have a 
>> majority of customers that use IE11 due to technical reasons (plugins 
>> needed for accessing secure token don’t install properly in Chrome without 
>> internet access amongst others).
>>
>> What do you mean with “next version of GWT” if that is 3.x then I don’t 
>> care at this point. We have been waiting for that release for a few years 
>> now. But 2.x releases should not drop IE11 support it is supposed to be a 
>> long-term supported version.
>> On 12 Mar 2021, 07:54 +0100, bernhar...@schubec.com <
>> bernhar...@schubec.com>, wrote:
>>
>> Hi all! 
>>
>> I think IE11 support should be dropped soon if it blocks (or makes it 
>> difficult) to implement new features in the next version of GWT.
>> I understand, that there are enterprises who still use IE11 internally, 
>> but developers who service such enterprises should use the current version 
>> of GWT, which is not going away. Nobody is forced to upgrade to the next 
>> version of GWT.
>>
>> Thanks,
>> Berni 
>>
>> tony.be...@gmail.com schrieb am Donnerstag, 11. März 2021 um 22:26:21 
>> UTC+1:
>>
>>> IE 11 is still widely used inside corporations, because it is the only 
>>> browser that supports Java applets, and applications such as Oracle 
>>> e-Business Suite still use applets extensively (for Oracle forms). While 
>>> that segment does not move very fast, it does not mean other unrelated 
>>> groups within the same corporation are not updating GWT regularly. It is 
>>> hard to generalize In a multinational company  with tens of thousands of 
>>> employees. 
>>>
>>> Regards
>>>
>>> Tony
>>>
>>> On Thu, Mar 11, 2021 at 9:49 AM Jens  wrote:
>>>
 Dropping IE 8-10 shouldn't really hurt. Companies that require it are 
 probably not upgrading GWT in a fast pace anyways.

 However I wouldn't drop IE 11 anytime soon. IE 11 itself is tied to the 
 lifecycle of Microsoft's operating systems, which means for Windows 10 it 
 is supported until 2025 (for now). So just because MS and Google drop 
 support for IE 11 in some/all of their products, the browser itself is 
 still generally supported by MS. So we should think twice before removing 
 IE 11 from a library such as GWT, even if it means to decline/revert 
 certain commits if they break IE 11. From own experience I have usually 
 seen something around 8% of IE 11 usage in GWT based apps. 

 However I am pretty sure more and more companies will announce dropping 
 IE 11 this year or next year. With MS and Google starting, this could 
 easily have a domino effect. However GWT also also strongly used 
 internally 
 inside companies so it might not have that much of an effect in that area.

 If we ditch IE 8-10 and only leaving gecko1_8 and safari, can't we kill 
 them both as well and put them together? Are there so many differences in 
 code between both? From my work migrating GWT code to elemental2/JsInterop 
 I had the feeling that only some minor stuff is different between both. So 
 there shouldn't be that much overhead in code size and performance doing 
 (cached) runtime checks instead.

 -- J.

 --
 You received this message because you are subscribed to the Google 
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to google-web-toolkit-co...@googlegroups.com.

>>> To view this discussion on the web visit

Creating Java frontend project using domino-cli

2021-06-17 Thread Vegegoku 
Hi
I would like to share with you a recording I made to show how we can create 
a Java frontend project using domino-cli

https://youtu.be/TIe2d69S1T4

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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/80fb5ab1-21b4-4836-9598-aa11c0ffc073n%40googlegroups.com.

DominoKit release announcement

2021-03-29 Thread Vegegoku 
Dears

DominoKit team are very happy to announce the first Dominokit toolset 
release candidate, it took us too long but it is finally here and all our 
tools are now available on maven center, 

the released supports *GWT 2.9.0* and *Java11*, find below a list of all 
tools and released versions :

domino-ui 
Release: *1.0.0-RC1*
Development: *HEAD-SNAPSHOT*

domino-rest 
Release: *1.0.0-RC1*
Development: *HEAD-SNAPSHOT*

domino-jackson 
Release: *1.0.0-RC2*
Development: *HEAD-SNAPSHOT*

domino-mvp 
Release: *1.0.0-RC1*
Development: *HEAD-SNAPSHOT*

domino-history 
Release: *1.0.0-RC2*
Development: *HEAD-SNAPSHOT*

domino-aggregator 
Release: *1.0.2*
Development: *HEAD-SNAPSHOT*

domino-slf4j-logger 
Release: *1.0.2*
Development: *HEAD-SNAPSHOT*

domino-keycloak 
Release: *1.0.0*
Development: *HEAD-SNAPSHOT*

domino-immutables 
Release: *1.0.0*
Development: *HEAD-SNAPSHOT*

Domino-cli  have also been updated 
to generate projects that use the new releases

You can download the CLI from the project releases 
 page

Your feedback and testing are very welcome.

With regards

DominoKit team


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/b46a97ce-75b7-49b9-8209-490b1b60f910n%40googlegroups.com.

Re: New Article "10 Best Java Frameworks to Use in 2021"

2021-03-10 Thread Vegegoku 
ublishedEvent.getHeader().getReference()).isEqualTo(
postedCheck.getReference());
assertThat(publishedEvent.getHeader().getEventType()).isEqualTo(CheckStatus.
REPRESENTED.getEventType());
assertThat(publishedEvent.getBody().getPayload()).isNotNull();
assertThat(publishedEvent.getBody().getPayload()).isSameAs(postedCheck);
}

@Test
public void givenValidCheck_whenExecute_thenShouldSendMessageToBank() {
Check postedCheck = postCheckUseCase.execute(validCheck);
assertThat(publishedCheck).isEqualTo(postedCheck);
}

private UserDecisionLog getLastUserDecision(Check validCheck) {
return validCheck.getUserDecision().get(validCheck.getUserDecision().size() - 
1);
}

I have seen tests that way far more code just doing  *ArgumentCaptor*  or 
*When(..).then(...) 
*.. etc than any actual testing code.. it could go wildly bad...
I had to write tests in both styles to convince myself.. but I believe this 
will remain a topic with a debate. 
On Wednesday, March 10, 2021 at 5:56:20 PM UTC+2 gardella...@gmail.com 
wrote:

> Hi Vegeoku,
>
> Could you please elaborate on this?
>
> *IMHO tests should help you improve the design of your code, Mockito is 
> the opposite of that, Once I converted some test cases to use manually 
> writing test doubles (spies, fakes, stubs) instead of Mockito to show the 
> other guy how it reduced the code in the test and improves the design. 
> Mockito makes it super easy to look away from design issues.*
>
> Thanks,
> Juan
>
> P.S. Amazing thread.
>
> On Wed, 10 Mar 2021 at 12:47, Josselin Bardet  wrote:
>
>>
>>
>> Le mer. 10 mars 2021 à 16:42, Vegegoku  a écrit :
>>
>>>
>>>>
>>>> Spring: I think the thing I dislike the most about Spring is what many 
>>>> people like about it: it's an entire, wide, and fat, ecosystem. You can 
>>>> hardly use one piece of Spring without using everything else; I mean, each 
>>>> Spring piece builds on top of another Spring piece, so it's basically an 
>>>> all-or-nothing. I also fear that people doing mostly Spring won't know how 
>>>> to do things without it (like most big/fat framework actually). 
>>>>
>>>
>>>
>>> That does really summaries it about spring, also I hate how it is being 
>>> overused for simple projects,  Like sucking this huge ecosystem just 
>>> because we need dependency injection or want to talk to the database (JPA 
>>> -> spring data) and it ends up building a huge complexity instead of 
>>> simplifying things.. (Tests for example), I once want to contribute to a 
>>> project that was using spring to find out that I had to inject a single 
>>> bean into 500+ other classes using the constructor where even the arguments 
>>> were not arranged to make this any easier and while doing that I had to 
>>> fight merge conflicts .. it is overrated and overused .. and I pretty sure 
>>> that most of spring project developer relay too much on mocking to make the 
>>> tests faster or avoid such dependency injection hell.
>>>  
>>>
>>
>> Spring is well tested and works well, can handle your transctions, can 
>> help you to make AOP, can make dependency injection, etc...
>> Spring is for me a killer feature, I can't imagine making a project, even 
>> simple, without using it.
>>
>> I don't think nowadays there is a good reason to "optimize" and don't use 
>> spring
>>
>> -- 
>>
> 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/CAHDmNXFaUH815r4kDm64HPqDSnqErtPP41tsSHmT%3Dt%2BirNco%3Dg%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/google-web-toolkit/CAHDmNXFaUH815r4kDm64HPqDSnqErtPP41tsSHmT%3Dt%2BirNco%3Dg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/605271a7-3edf-4fac-bd8c-f91602854c47n%40googlegroups.com.

Re: New Article "10 Best Java Frameworks to Use in 2021"

2021-03-10 Thread Vegegoku 
Even if it is opinionated, please give us Gradle GWT archetype. :-)

On Wednesday, March 10, 2021 at 5:25:47 PM UTC+2 t.br...@gmail.com wrote:

>
>
> On Wednesday, March 10, 2021 at 4:13:03 PM UTC+1 pavel@gmail.com 
> wrote:
>
>> We had the same problem with maven but at the end, maven's multi-module 
>> project and profiles helped to solve *hack around* it.
>>
>
> There, fixed it for you 
>
> Also see https://www.cloudbees.com/blog/maven-profiles-and-maven-way and 
> https://blog.soebes.de/blog/2013/11/09/why-is-it-bad-to-activate-slash-deactive-modules-by-profiles-in-maven/
>  
> among others, by prominent Maven PMC members.
> (and yet, gwt-maven-archetypes use a "dev" profile 路, but it's know to be 
> kind of hackish in places due to Maven and jetty-maven-plugin's limitations)
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/1c53eebc-6a90-4026-b2ee-791067cb83b9n%40googlegroups.com.

Re: New Article "10 Best Java Frameworks to Use in 2021"

2021-03-10 Thread Vegegoku 


On Tuesday, March 9, 2021 at 6:28:01 PM UTC+2 t.br...@gmail.com wrote:

> On Tuesday, March 9, 2021 at 4:10:44 PM UTC+1 aka...@gmail.com wrote:
>
>> BTW,  
>> @Thomas you didn't start a flame war it was just a flame, I got to learn 
>> few things from this conversation so why not flame the rest of the list? 
>>
>
> Really? Let's go.
>
> Spring: I think the thing I dislike the most about Spring is what many 
> people like about it: it's an entire, wide, and fat, ecosystem. You can 
> hardly use one piece of Spring without using everything else; I mean, each 
> Spring piece builds on top of another Spring piece, so it's basically an 
> all-or-nothing. I also fear that people doing mostly Spring won't know how 
> to do things without it (like most big/fat framework actually). 
>


That does really summaries it about spring, also I hate how it is being 
overused for simple projects,  Like sucking this huge ecosystem just 
because we need dependency injection or want to talk to the database (JPA 
-> spring data) and it ends up building a huge complexity instead of 
simplifying things.. (Tests for example), I once want to contribute to a 
project that was using spring to find out that I had to inject a single 
bean into 500+ other classes using the constructor where even the arguments 
were not arranged to make this any easier and while doing that I had to 
fight merge conflicts .. it is overrated and overused .. and I pretty sure 
that most of spring project developer relay too much on mocking to make the 
tests faster or avoid such dependency injection hell.
 

> I'm a no-framework guy; I think each library should be usable on its own 
> (good for it if it provides adapters to make it easier to use within a 
> particular framework, I won't care), and Spring is the exact opposite.
>

Not trying to advertise here, but I want to emphasize this point, I built 
dominoKit this way as each lib can actually be used alone then the only one 
that combines them as a framework is domino-mvp, this has proven to be a 
good decision in terms of adoption, development, and maintenance.

 

>
> Maven: well, Maven is so utterly broken as a scalable build tool… They're 
> finally talking about Maven 4 bringing breaking changes to the "build POM" 
> (as opposed to the "deployed POM" you use from repositories), but as long 
> as they'll keep that linear lifecycle, and project model being mutable (and 
> mutated!) during build execution, it'll be a big no-go for me. If you need 
> to learn one build tool, let it be Gradle, not Maven.
> (fwiw, I'm migrating all projects at work from Maven to Gradle; I'm being 
> *asked* to migrate them, because it makes things so much more usable and 
> enjoyable!)
>

I am a maven guy who really wants to learn Gradle, I used it few times for 
very small projects, but something is blocking me from going deep not sure 
how to explain it, but I always feel confused when I am trying to do 
anything with Gradle, everything is explained in so many different ways 
that I no longer understand what is the right thing to do. recently started 
to study how to use Gradle to simulate my maven multi-level modules. didn't 
make much progress. I am using your GWT maven archetype-like structure 
which was a huge improvement for me, and would really love to see an 
example of how we achieve the same results with Gradle.
 

>
> Mockito: well, most of the time, you shouldn't use mocks. If you *need* 
> mocks, 
> it generally says more about the structure and testability of your code 
> than the readability of your tests. Of all mocking tools, indeed Mockito is 
> likely the best, but it's the kind of tools you shouldn't be reaching for 
> to being with.
>

IMHO tests should help you improve the design of your code, Mockito is the 
opposite of that, Once I converted some test cases to use manually writing 
test doubles (spies, fakes, stubs) instead of Mockito to show the other guy 
how it reduced the code in the test and improves the design. Mockito makes 
it super easy to look away from design issues.


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/f6ab821e-a474-492f-9369-48bfb6be5764n%40googlegroups.com.

Re: New Article "10 Best Java Frameworks to Use in 2021"

2021-03-09 Thread Vegegoku 
I don't like Hibernate/JPA because of the horror and terror it gave me 
during my career years. Yet 
Hibernate appeared in times when we were having a hard time dealing with 
database and SQL in java, mapping/parsing query results, or even 
constructing the queries themselves and I have seen it going wildly bad.
Hibernate then came with its benefits and problems .. (maybe too many 
problems) but it came first .. and was adopted by so many.. and it became a 
large part of Java ecosystem ..so large that you hardly find a project that 
talks to the database and not using hibernate.. (we would like to see more 
of this)
I am not sure but maybe hibernate was there around 2008 (the oldest version 
I checked in maven central) imagine by that we had JOOQ first ..or JDBI 
..or whatever suggested alternative... (I think most of them came after 
2010 checking the issue trackers on Github) .. imagine we had text blocks 
:-) way before hibernate came along.

Now you see projects using hibernate for no reason (especially with how 
easy it is being promoted by spring).. from using it for simple CRUD (can 
be replaced by one of the suggested solutions) or for the complex queries 
(which should be replaced with one of the suggested solutions) I think.

BTW,  
@Thomas you didn't start a flame war it was just a flame, I got to learn 
few things from this conversation so why not flame the rest of the list? 


On Tuesday, March 9, 2021 at 3:44:02 PM UTC+2 t.br...@gmail.com wrote:

> Main issues with JPA: the entity caches, and lazy-loading which makes 
> things work but are a PITA for performance (I've worked on a project where 
> each and every HTTP request causes between 10 and 30 SQL queries, only to 
> get the user's information and access rights; being so bad might very well 
> be caused by the app architecture too, as it also has N+1 issues on some 
> screens; but definitely JPA is to blame as well).
> (also, the Criteria API is 濫)
>
> On Tuesday, March 9, 2021 at 10:34:18 AM UTC+1 lofid...@gmail.com wrote:
>
>> @TBroyer: of course we are going to start a flame war for Hibernate ;-)
>>
>> "Hibernate" is the most searched word in Google 2021... OK, I mean "how 
>> to hibernate your PC" :-)
>>
>> I agree with @Gordan, it depends on the use case. Strangely enough, we 
>> have today ORM also on Android *Room* (
>> https://developer.android.com/training/data-storage/room) and iOS *Core 
>> Data *(https://developer.apple.com/documentation/coredata). So from the 
>> resources and speed point of view, it seems that they are just fine.
>>
>> Actually it's a pitty that the standard *SQLJ* (
>> https://en.wikipedia.org/wiki/SQLJ) did not get any further, I think it 
>> would be a good choice if you need SQL but need the "type and compile time" 
>> safety in Java.
>>
>> Cheers,
>> Lofi
>> Gordan Krešić schrieb am Dienstag, 9. März 2021 um 09:11:06 UTC+1:
>>
>>> On 09. 03. 2021. 08:29, Craig Mitchell wrote: 
>>> > 
>>> > Too late.  Flame war!  ;P  But seriously, what's wrong with using 
>>> Hibernate 
>>> > as JPA provider?  Okay, yes, there is nothing to learn, it does all 
>>> its 
>>> > magic behind the scenes, but is there something better?  Or maybe 
>>> using JPA 
>>> > is bad, and we go back to pure SQL?  I'm curious. 
>>>
>>> I did try various ORMs, including some for non-relational databases (but 
>>> then it's not an ORM, but... what?) but never figured out the benefits. 
>>> They 
>>> all demo well, but when I go past most basic usage, they always felt 
>>> more 
>>> like an obstacle than a tool. 
>>>
>>> Only case where I would agree using ORM saves time are projects with 
>>> high 
>>> number of tables compared to complexity of their usage (simple SELECTs 
>>> on 
>>> hundreds or thousands of tables). But, I don't have such a project in my 
>>> portfolio. 
>>>
>>> Can you name few other benefits? Type safety? "Compile-time checks" of 
>>> SQL 
>>> "queries"? I can see *some* benefits there, but hardly ones that 
>>> justifies 
>>> learning another, fairly complex, DSL on top of SQL. 
>>>
>>> From time to time I found a survey with question like "Which ORM do you 
>>> use?" and there are usually low-double-digits of percentages of users 
>>> who 
>>> claim to be using "raw JDBC with SQL". It gives me hope that I'm not a 
>>> lone 
>>> lunatic, but still, 80+% of users must know *something*, right? 
>>>
>>> So, if we assume that someone already knows SQL (and it's an 'if', I 
>>> know), 
>>> what would be the benefits of using ORM of any kind? 
>>>
>>> Bonus question: I've been looking for years for a most simplistic SQL 
>>> templating library, mainly for things like reusing WHERE clauses (i 
>>> usually 
>>> end up with fairly complex ones used in multiple queries), linking '?' 
>>> with 
>>> setters on PreparedStatements and things like that. I even wrote small 
>>> lib 
>>> because I was tired of experimenting, but I seriously doubt that I'm the 
>>> only one with this need and would instead like to contribute to

Re: Elemental2-compatible Activities (and Places)?

2021-03-06 Thread Vegegoku 

Domino-mvp is a framework of many things, but if you are just interesting 
on listening to URL changes and do some routing based on those changes in a 
simple way, then maybe you can try domino-history 
 (it is what domino-mvp use 
under the hood).
On Saturday, March 6, 2021 at 7:24:17 PM UTC+2 Gordan Krešić wrote:

> On 06. 03. 2021. 15:47, Frank Hossfeld wrote:
> > There are a few places where are the progress of the module update is 
> tracked:
> > 
> > 
> > 
> https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit#gid=0
>  
> > <
> https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit#gid=0
> >
> > 
> https://docs.google.com/spreadsheets/d/15WXfiklnTeqjRLI8gKj5iyGk7iDhnuQHGcpYJgpNlmQ/edit#gid=0
>  
> > <
> https://docs.google.com/spreadsheets/d/15WXfiklnTeqjRLI8gKj5iyGk7iDhnuQHGcpYJgpNlmQ/edit#gid=0
> >
> > https://github.com/FrankHossfeld/gwt-modules 
> >  (still in progress)
>
> Now... I found this on Twitter minutes ago and came here to post those 
> links... :)
>
> > And yes, the Activities module is not migrated yet.
>
> How about your own port mentioned in first sheet:
>
> https://github.com/FrankHossfeld/gwt-activity
>
> I can see it still references widgets, so definitely not a final port, but 
> if you are interested I can propose pull request based on my own port 
> which 
> uses elemental2.dom.HTMLElement instead of widgets. However, that should 
> be 
> up to a debate, because I believe more modular approach would be needed to 
> cover most use cases: widgets, elemental2's HTMLElement, elemento's 
> IsElement and possibly others.
>
> > If you are looking for J2CL/Elemental2 ready frameworks, take a look 
> here:
> > 
> > * dominokit/domino-mvp 
> > * nalukit/nalu   (Disclaimer: I am the
> > author)
>
> Seen both of them, but I'm porting existing project that has some 
> infrastructure (I'm trying not to exaggerate and call it a "framework" :) 
> ) 
> build on top of activities and places that I would like to reuse if 
> possible.
>
> -gkresic.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/46f11cde-1f9a-4af4-b2c4-06939e3d33den%40googlegroups.com.

Re: Abridged summary of google-web-toolkit@googlegroups.com - 2 updates in 1 topic

2021-01-23 Thread Vegegoku 
Rewrite in most cases is just a wrong step, doing it gradually may make it 
less expensive but it is still a very expensive approach, I have always 
been wondering why companies prefer a rewrite over hiring some experts to 
solve the issues, hiring an expert might look an expensive choice, but it 
is way cheaper than a rewrite, plus you can make your better by having an 
expert teaching them. also, I see the main issue with a rewrite is that you 
will still face issues and in many cases, you will be doing the same or new 
mistakes and then blame the technology again..and then start a new rewrite.

just a side note I have been working with GWT for more than 10 years, I 
never failed to debug any GWT application we had.



On Saturday, January 23, 2021 at 9:21:29 PM UTC+2 lofid...@gmail.com wrote:

> I'm sorry to hear your problem with debugging and daylight saving time... 
> In such case I would just take a paid / professional consulting like e.g. 
> Vertispan to solve my problems. It is more cheaper than trying 1000 hours 
>
> Anyway I found out that Angular programming model is very similar to GWT 
> with all those design patterns. In my experience with frameworks you always 
> have some problems (this happens also with Spring Framework), so I never 
> expect that everything works always smoothly  
>
> Good luck 
> Edson Richter schrieb am Samstag, 23. Januar 2021 um 16:00:39 UTC+1:
>
>> After fighting with no debug working on gwt (yeah, believe me, tryied 
>> everything) and fighting hard with missing date/time daylight savings time 
>> horror stories, we decided to move gradually to Angular+. It is easy to 
>> integrate both Angular and gwt modules (not components) on same page by 
>> using iframes. We will do that until everything is rewritten in Angular. 
>> Few thounds dialogs and hundred custom components are being rewritten by 
>> the team. And thanks to our architecture (encouraged by gwt), we have zero 
>> business rewrite.
>>
>> That's it, gwt is at the end of line here.
>>
>> Of course Angular presents many obstacles that we will overcome using OO 
>> patterns thanks to typescript, which is a elegant language for its purpose.
>>
>> Regards,
>>
>> Edson.
>>
>> Em sáb, 23 de jan de 2021 10:01,  
>> escreveu:
>>
>>> google-we...@googlegroups.com 
>>> 
>>>  Google 
>>> Groups 
>>> 
>>>  
>>> 
>>>  
>>> Today's topic summary 
>>> View all topics 
>>> 
>>>  
>>>
>>>- Our 10+ year journey with GWT (+ job opening) 
>>>
>>> <#m_3648253403906034295_m_5270867299907530605_m_-1350756301493578854_group_thread_0>
>>>  
>>>- 2 Updates 
>>>
>>> Our 10+ year journey with GWT (+ job opening) 
>>> 
>>>  
>>> RobW : Jan 22 05:13AM -0800 
>>>
>>> Similar decision process for us. After a lot of research into Vue, React 
>>> etc we decided the switch over and learning curve just didn't pay back. 
>>> Our 
>>> app scaffold in GWT is actually really solid, ...more 
>>> 
>>>  
>>> Jofrantoba : Jan 22 12:38PM -0500 
>>>
>>> Hi, Alexander.
>>> I'm jofrantoba. I'd like working but my english is basic.
>>> My best is the reading.
>>>  
>>> atte @jofrantoba 
>>> ...more 
>>> 
>>>  
>>> Back to top 
>>> <#m_3648253403906034295_m_5270867299907530605_m_-1350756301493578854_digest_top>
>>>  
>>> You received this digest because you're subscribed to updates for this 
>>> group. You can change your settings on the group membership page 
>>> 
>>> .
>>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/c4840868-7338-4b11-8718-edd08a3c4c4fn%40googlegroups.com.

Re: Our 10+ year journey with GWT (+ job opening)

2021-01-19 Thread Vegegoku 
I think TypeScript is here to stay and it might improve a lot, for Vue it 
is growing but maybe it is up to when the next framework show up, we xan 
also put the PWA in the picture and the multiplatform from a single source 
code base, WASM ..etc.. recently things were moving really fast that we 
could even expect some extreme changes in the coming years.

On Tuesday, January 19, 2021 at 6:26:38 PM UTC+2 lofid...@gmail.com wrote:

> @swas...
>
> 
> Yes, almost 10 years for me too and production application  running for 3 
> years.
> GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
> my next 10 years plan is  move to TypeScript + VueJS.
> 
>
> After 10 years, will we still be able to see TypeScript + VueJS? 
>
> Cheers,
> Lofi
> RobW schrieb am Dienstag, 19. Januar 2021 um 15:29:42 UTC+1:
>
>> Our web front end is on 15 years with GWT as of this year, and we're 
>> expecting 5 more with luck. So we'll hit the 20 year mark if all goes well
>>
>> On Tuesday, 19 January 2021 at 10:46:44 UTC aka...@gmail.com wrote:
>>
>>> I wonder if that will actually last for the next 10 years.
>>>
>>> On Tuesday, January 19, 2021 at 10:04:19 AM UTC+2 swas...@gmail.com 
>>> wrote:
>>>
 Yes, almost 10 years for me too and production application  running for 
 3 years.
 GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
 my next 10 years plan is  move to TypeScript + VueJS.
 On Monday, 4 January 2021 at 23:37:53 UTC+7 Alexander Bertram wrote:

> Nice to hear from everyone!
>
> Here's to the next ten years :-)
>
> Best wishes for 2021,
> Alex
>
> On Tuesday, December 22, 2020 at 10:22:08 AM UTC+1 Segun Razaq Sobulo 
> wrote:
>
>>
>> I've been using GWT for 7+ years (with appengine java backends) and 
>> actively looking for a job. I'll push my resume.
>>
>> Thanks
>> On Monday, 21 December 2020 at 15:24:19 UTC+1 aka...@gmail.com wrote:
>>
>>> We are in times where working remotly id actually a good option.
>>>
>>> On Monday, December 21, 2020 at 4:19:13 PM UTC+2 David Nouls wrote:
>>>
 Hi Alex,

 Same story here. I have been working with GWT since it first came 
 out. For our current project we again opted for GWT because we share a 
 lot 
 of code between client and server and productivity is high.

 I’m not available at the moment (maybe end of next year)… but 
 living in Belgium/Leuven I don’t think that is doable. Relocation is 
 not an 
 option. Good luck finding people, there are not a lot on the market.

 Groeten,
 David
 On 20 Dec 2020, 16:16 +0100, 'Alexander Bertram' via GWT Users <
 google-we...@googlegroups.com>, wrote:


 Dear all,  

 I hope this email isn't too off-topic, but I wanted to share an 
 opening for a job on our team with a large GWT component.

 https://jobs.bedatadriven.com/software-engineer

 The first version of our product, ActivityInfo, a data collection 
 and analysis platform for humanitarian relief, was built with GWT, GXT 
 and 
 Google Gears in 2009 and seriously would not have been possible 
 without 
 GWT. 

 In 2018, nearly 10 years later, we looked at the amazing js 
 ecosystem and considered moving to Typescript or Elm.

 Instead, we decided to keep the bits that we loved about GWT: the 
 typesafety, code-reuse with the server, i18n, code splitting, linkers, 
 and 
 the amazing compiler, and add SCSS for styles and our own port of 
 Preact + 
 rxJava-like reactivity for dom manipulation using Elemental2.

 Three years after the start of ActivityInfo 4.0 we couldn't be 
 happier with the choice, and are more productive than ever. 

 If you're an experienced GWT developer that would enjoy the 
 challenge of a working on a modern GWT codebase, I hope you'll 
 consider 
 joining our team!


 Best,
 Alex

 --
 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/46240bd9-f716-4448-a481-acfc87229f8fn%40googlegroups.com
  
 
 .



-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To

Re: Our 10+ year journey with GWT (+ job opening)

2021-01-19 Thread Vegegoku 
I wonder if that will actually last for the next 10 years.

On Tuesday, January 19, 2021 at 10:04:19 AM UTC+2 swas...@gmail.com wrote:

> Yes, almost 10 years for me too and production application  running for 3 
> years.
> GWT 2.6.1 + Eclipse 4.8.  Tomcat8 + MySQL5.7  + Java8 + JasperReport
> my next 10 years plan is  move to TypeScript + VueJS.
> On Monday, 4 January 2021 at 23:37:53 UTC+7 Alexander Bertram wrote:
>
>> Nice to hear from everyone!
>>
>> Here's to the next ten years :-)
>>
>> Best wishes for 2021,
>> Alex
>>
>> On Tuesday, December 22, 2020 at 10:22:08 AM UTC+1 Segun Razaq Sobulo 
>> wrote:
>>
>>>
>>> I've been using GWT for 7+ years (with appengine java backends) and 
>>> actively looking for a job. I'll push my resume.
>>>
>>> Thanks
>>> On Monday, 21 December 2020 at 15:24:19 UTC+1 aka...@gmail.com wrote:
>>>
 We are in times where working remotly id actually a good option.

 On Monday, December 21, 2020 at 4:19:13 PM UTC+2 David Nouls wrote:

> Hi Alex,
>
> Same story here. I have been working with GWT since it first came out. 
> For our current project we again opted for GWT because we share a lot of 
> code between client and server and productivity is high.
>
> I’m not available at the moment (maybe end of next year)… but living 
> in Belgium/Leuven I don’t think that is doable. Relocation is not an 
> option. Good luck finding people, there are not a lot on the market.
>
> Groeten,
> David
> On 20 Dec 2020, 16:16 +0100, 'Alexander Bertram' via GWT Users <
> google-we...@googlegroups.com>, wrote:
>
>
> Dear all,  
>
> I hope this email isn't too off-topic, but I wanted to share an 
> opening for a job on our team with a large GWT component.
>
> https://jobs.bedatadriven.com/software-engineer
>
> The first version of our product, ActivityInfo, a data collection and 
> analysis platform for humanitarian relief, was built with GWT, GXT and 
> Google Gears in 2009 and seriously would not have been possible without 
> GWT. 
>
> In 2018, nearly 10 years later, we looked at the amazing js ecosystem 
> and considered moving to Typescript or Elm.
>
> Instead, we decided to keep the bits that we loved about GWT: the 
> typesafety, code-reuse with the server, i18n, code splitting, linkers, 
> and 
> the amazing compiler, and add SCSS for styles and our own port of Preact 
> + 
> rxJava-like reactivity for dom manipulation using Elemental2.
>
> Three years after the start of ActivityInfo 4.0 we couldn't be happier 
> with the choice, and are more productive than ever. 
>
> If you're an experienced GWT developer that would enjoy the challenge 
> of a working on a modern GWT codebase, I hope you'll consider joining our 
> team!
>
>
> Best,
> Alex
>
> --
> 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/46240bd9-f716-4448-a481-acfc87229f8fn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/bb42927e-d36c-4ef2-8beb-5f1f424987bcn%40googlegroups.com.

Re: GWT built in History and HTML5 pushstate

2021-01-11 Thread Vegegoku 
I would suggest that you take a look at domino-history 


On Monday, January 11, 2021 at 2:17:25 PM UTC+2 Martin Nguyen wrote:

> Hi,
>
> We are using the GWT built in History which leads to the hashtag tokens. 
> This is leading to a problem when we are trying to redirect in a Microsoft 
> teams app.
>
> Is there a way for us to try removing that hashtag sign in the urls, are 
> there any up-to date libraries or implementation to go from History -> 
> HTML5 pushstate?
>
> Best regards
> Martin 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/a1a916a3-9a7c-4f24-a529-94ed933b2e54n%40googlegroups.com.

Re: Our 10+ year journey with GWT (+ job opening)

2020-12-21 Thread Vegegoku 
We are in times where working remotly id actually a good option.

On Monday, December 21, 2020 at 4:19:13 PM UTC+2 David Nouls wrote:

> Hi Alex,
>
> Same story here. I have been working with GWT since it first came out. For 
> our current project we again opted for GWT because we share a lot of code 
> between client and server and productivity is high.
>
> I’m not available at the moment (maybe end of next year)… but living in 
> Belgium/Leuven I don’t think that is doable. Relocation is not an option. 
> Good luck finding people, there are not a lot on the market.
>
> Groeten,
> David
> On 20 Dec 2020, 16:16 +0100, 'Alexander Bertram' via GWT Users <
> google-we...@googlegroups.com>, wrote:
>
>
> Dear all,  
>
> I hope this email isn't too off-topic, but I wanted to share an opening 
> for a job on our team with a large GWT component.
>
> https://jobs.bedatadriven.com/software-engineer
>
> The first version of our product, ActivityInfo, a data collection and 
> analysis platform for humanitarian relief, was built with GWT, GXT and 
> Google Gears in 2009 and seriously would not have been possible without 
> GWT. 
>
> In 2018, nearly 10 years later, we looked at the amazing js ecosystem and 
> considered moving to Typescript or Elm.
>
> Instead, we decided to keep the bits that we loved about GWT: the 
> typesafety, code-reuse with the server, i18n, code splitting, linkers, and 
> the amazing compiler, and add SCSS for styles and our own port of Preact + 
> rxJava-like reactivity for dom manipulation using Elemental2.
>
> Three years after the start of ActivityInfo 4.0 we couldn't be happier 
> with the choice, and are more productive than ever. 
>
> If you're an experienced GWT developer that would enjoy the challenge of a 
> working on a modern GWT codebase, I hope you'll consider joining our team!
>
>
> Best,
> Alex
>
> --
> 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/46240bd9-f716-4448-a481-acfc87229f8fn%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/02c8d017-e66c-4d25-8a10-a933eacde124n%40googlegroups.com.

Re: GWT history with push state

2020-10-19 Thread Vegegoku 
JSNI is deprecated, you can use the browser state API with pushState 
.
You can also check domino-history 
 which a lightweight wrapper 
around the pushState.

On Friday, October 16, 2020 at 7:40:39 AM UTC+3 Craig Mitchell wrote:

> As Tomas said, not directly with History.  It's simple JSNI though:
>
> public static native void updateURL(String newUrl) /*-{
> $wnd.history.pushState(newUrl, "", newUrl);
> }-*/;
>
> public static native void initialise() /*-{
> $wnd.onpopstate = $entry(function(e) {
> @com.blah.YourClass::yourMethodThatListensForUrlChange()();
> });
> }-*/;
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/b62e5e0c-3514-417e-a2d1-9253701e20efn%40googlegroups.com.

Re: Why Don’t You Use Java for Programming the Client-Side Web Apps on Web Browser?

2020-10-06 Thread Vegegoku 
I am in the same situation, But this is wrong. and it is not that hard to 
make any java developer work on GWT especially if they claim to know some 
frontend since that implies that they know HTML,CSS, JS which is more 
important than knowing GWT.

On Tuesday, October 6, 2020 at 3:47:35 PM UTC+3 David Nouls wrote:

> Let me start by stating that I totally agree that the GUI technology used 
> is not really that important. It is after all just cross compiled to the 
> browser platform. So knowledge of the platform is much more important.
>
> In the organisations that I work we mostly with contractors. People are 
> selected based on their prior experience with specific technologies because 
> we need people to be efficient very quickly. You really need to know the 
> frameworks very well because many GWT power features require some 
> experience and a different way of working than what people are used to.
>
> We do check for generic knowledge of programming, design or browser 
> features and most of the time that drives our decision to hire someone much 
> more than a deep GWT specific knowledge. But we often have people that 
> refuse our offer purely because it is GWT. The reason is that they see it 
> as a bad career move to work in a project that uses a framework that they 
> think is dead. I’m not making this up, we had this response many times. And 
> it makes sense from their point of view. Contractors need to stay relevant 
> in the market. CV's are filtered on buzzwords and technologies. I sometimes 
> feel anxious as well since I have many years of GWT knowledge, but I know 
> that all companies are looking for other frameworks and don’t care about 
> the arguments.
>
> In the backend the focus on frameworks is a bit less extreme because they 
> are all based on the same language and the frameworks like spring and EJB 
> are very old and well understood and part of a vibrant community. If you 
> are still depending on Struts and handcrafted SQL/JDBC on the server side 
> then you will probably meet the same resistance to hire people.
> On 6 Oct 2020, 14:21 +0200, Vegegoku , wrote:
>
> I am still don't know why people call the developer like this, GWT 
> developers, Angular developers, React developers...etc.. have we ever 
> called developers like `Spring developers`, `hibernate developers`, `Rest 
> developers` ..etc... I would say we have Java developers and JS developers, 
> developers belong to the ecosystem, not to the framework or the library. 
> GWT, for example, is just a compiler, you need people who know java and the 
> java echo system, not GWT, you can make them GWT familiar way faster than 
> you think, you don't even need them to know this is GWT it is just Java. I 
> have done this with few Java developers I showed them that I am building a 
> web application with java without telling them it was GWT and they were 
> impressed, they even built some small apps with the little information I 
> gave to them. The same goes for JS, if you have a developer who just knows 
> Angular, but does not know JavaScript or can't work with other JS 
> frameworks then that is not a good fit in the team. after all the Angular 
> is just like Spring it is one of the frameworks in the ecosystem. 
>
> Normally when I work with the fresh developers I ask them to build a 
> sample application using whatever JS framework they prefer, then I show 
> them that they can do it in Java without telling them it is GWT. and in 
> many times they feel WoWed. not implying that one is better but they get 
> wowed how they can do it in both, the good thing about those fresh 
> developers is that they don't have a previous preference of ecosystem over 
> the other, but in the other hand they don't know both ecosystems as they 
> should be.
>
>
>
> On Tuesday, October 6, 2020 at 12:21:21 PM UTC+3 David Nouls wrote:
>
>> Hi Lofi, 
>>
>> In my company we are the only group that is working with GWT to develop a 
>> new customer facing application. We have a few products in maintenance mode 
>> that are also using GWT. But most new developments are using Angular.
>>
>> The biggest problems we are facing with using GWT/Java for the client are:
>> - Lack of developers with GUI and GWT skills
>> - Lack of developers who are even willing to learn GWT.  GWT is seen as a 
>> dead technology after Google pushed it out.
>> - Management does not like us to keep on using GWT for the same reason.
>>
>> I managed to convince management to use GWT for our product because we 
>> have a long history of using GWT and we had experience before with the 
>> maintenance burdens of using JavaScript in the past. And we can deliver GUI 
>> changes quite quickly (in many cases m

Re: Why Don’t You Use Java for Programming the Client-Side Web Apps on Web Browser?

2020-10-06 Thread Vegegoku 
I am still don't know why people call the developer like this, GWT 
developers, Angular developers, React developers...etc.. have we ever 
called developers like `Spring developers`, `hibernate developers`, `Rest 
developers` ..etc... I would say we have Java developers and JS developers, 
developers belong to the ecosystem, not to the framework or the library. 
GWT, for example, is just a compiler, you need people who know java and the 
java echo system, not GWT, you can make them GWT familiar way faster than 
you think, you don't even need them to know this is GWT it is just Java. I 
have done this with few Java developers I showed them that I am building a 
web application with java without telling them it was GWT and they were 
impressed, they even built some small apps with the little information I 
gave to them. The same goes for JS, if you have a developer who just knows 
Angular, but does not know JavaScript or can't work with other JS 
frameworks then that is not a good fit in the team. after all the Angular 
is just like Spring it is one of the frameworks in the ecosystem.

Normally when I work with the fresh developers I ask them to build a sample 
application using whatever JS framework they prefer, then I show them that 
they can do it in Java without telling them it is GWT. and in many times 
they feel WoWed. not implying that one is better but they get wowed how 
they can do it in both, the good thing about those fresh developers is that 
they don't have a previous preference of ecosystem over the other, but in 
the other hand they don't know both ecosystems as they should be.



On Tuesday, October 6, 2020 at 12:21:21 PM UTC+3 David Nouls wrote:

> Hi Lofi,
>
> In my company we are the only group that is working with GWT to develop a 
> new customer facing application. We have a few products in maintenance mode 
> that are also using GWT. But most new developments are using Angular.
>
> The biggest problems we are facing with using GWT/Java for the client are:
> - Lack of developers with GUI and GWT skills
> - Lack of developers who are even willing to learn GWT.  GWT is seen as a 
> dead technology after Google pushed it out.
> - Management does not like us to keep on using GWT for the same reason.
>
> I managed to convince management to use GWT for our product because we 
> have a long history of using GWT and we had experience before with the 
> maintenance burdens of using JavaScript in the past. And we can deliver GUI 
> changes quite quickly (in many cases much faster than the teams using 
> Angular).
>
> But we do have a big problem finding GWT developers or finding people who 
> want to learn it. And that is a very big risk for a project.
>
> I know that there is active development going on in GWT and J2CL but, you 
> barely see blog posts about GWT or libraries being released for it.
> The gwtproject page is mostly stale, the documentation is mostly about old 
> API's. The more advanced features takes some time to find and learn.
>
> If you compare that with the constant release cycle and amount of 
> info/noise I see related to Angular and other Frameworks then it is 
> understandable that people have the impression that GWT is dead.
>
> On Thursday, September 24, 2020 at 9:02:18 PM UTC+2 lofid...@gmail.com 
> wrote:
>
>> I would like to know, what are the *obstacles* for you as *Java 
>> developers* not using *Java as programming language for writing Web 
>> browser apps*. Web browser apps are client-side and *not server-side* Web 
>> apps. 
>>
>>- Open discussion at https://bit.ly/HackerNewsTypeScriptJavaGWT
>>- Article at https://bit.ly/TypeScriptVsJavaGWT
>>
>> I would like to know from you... Java developers...
>>
>> Thanks, Lofi
>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/63232446-4222-4487-99eb-b54c59142323n%40googlegroups.com.

[gwt-contrib] Re: Resolving cycle dependency between gwt-safehtml & gwt-safecss

2020-06-26 Thread Vegegoku 
I see the merge of both into one as the simplest solutions, so +1 to the 
merge

On Thursday, June 25, 2020 at 11:14:46 PM UTC+3, Frank Hossfeld wrote:
>
> To prepare GWT for j2cl we need to move the modules out of GWT, replace 
> generators with ATP, etc. This is in progress and the first modules 
> (SNAPSHOT) are released.
>
> Migrating gwt-safehtml and gwt-safecss runs into a problem, cause 
> gwt-safehtml depends on gwt-safecss and gwt-safecss depends on 
> gwt-safehtml. This is a serious issue, cause one can not be build and 
> tested without the other. 
>
> To solve this issue, we are looking for solutions.
>
> One solution might be to move the tests out of gwt-safehtml. But then 
> gwt-safehtml needs to be build and deployed before the tests run and might 
> be deployed with failing tests. That looks like a bad solution.  At the 
> moment the idea is to move the sources and tests from gwt-safecss into 
> gwt-safehtml and delete gwt-safecss. This will remove the cycle dependency 
> between these two modules, but doing so, the module will be the first 
> module that contains two old modules in one new.
>
> Any other ideas how to solve this issue?
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/052a3925-34b5-4ee1-b84b-c49a47c82a49o%40googlegroups.com.

Re: Elemental2 and widgets

2020-06-26 Thread Vegegoku 
in most of the simple cases where you just wrap an element inside a widget 
like that, then you keep using the element as element not as a widget, 
things should work, but if you at some point needs a widget like 
interaction between wrapped widgets where the widget will expect a correct 
wiring of parent widget and a proper events sink you will face problems.

as for domino-ui, i would say you can just wrap as widgets only to append 
those domino-ui as elements, which means you will only treat them as 
widgets when you are appending them. other than that the gradual migration 
depends on how you would map your widgets to the domino-ui components, and 
how you split your views, and what mvp you use for example.

On Sunday, June 21, 2020 at 2:02:09 PM UTC+3, Gordan Krešić wrote:
>
> On 21. 06. 2020. 08:55, Vegegoku wrote: 
> > sorry, i meant to say : That will *NOT* do the required wiring 
> > 
> > On Saturday, June 20, 2020 at 1:55:20 PM UTC+3, Vegegoku wrote: 
> > 
> > That will do the required wiring to make elements behave like 
> widgets, 
> > it will not wire events correctly nor it will wire the 
> attach/detach, 
> > you can do it but it is not a simple task, thats why elemento moved 
> the 
> > issue the lib user instead of solving it in the lib itself. 
>
> Could you be a bit more specific? 
>
> So far, I've tested with only a very simple hierarchy: 
>
> RootPanel -> SimpleLayoutPanel -> [widget/Domino border] -> 
> GridLayout -> 
> other Domino elements 
>
> and I didn't see any problems, neither with event handling (click 
> listeners 
> on GridLayout children) nor with GridLayout.onDetached (didn't test 
> onAttached). 
>
> So, where I can expect problems to start manifesting? 
>
> Also, back to my initial question: ss there any "best practice" for 
> graduately migrating widget-based app to DominoUI? 
>
> -gkresic. 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/7042edb1-0c52-41a9-b367-7c50d4857575o%40googlegroups.com.

Re: Elemental2 and widgets

2020-06-21 Thread Vegegoku 
sorry, i meant to say : That will *NOT* do the required wiring

On Saturday, June 20, 2020 at 1:55:20 PM UTC+3, Vegegoku wrote:
>
> That will do the required wiring to make elements behave like widgets, it 
> will not wire events correctly nor it will wire the attach/detach, you can 
> do it but it is not a simple task, thats why elemento moved the issue the 
> lib user instead of solving it in the lib itself.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/9aec065a-9c96-446e-b154-40a80ab25074o%40googlegroups.com.

Re: Elemental2 and widgets

2020-06-20 Thread Vegegoku 
That will do the required wiring to make elements behave like widgets, it will 
not wire events correctly nor it will wire the attach/detach, you can do it but 
it is not a simple task, thats why elemento moved the issue the lib user 
instead of solving it in the lib itself.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/0618cfec-9da4-45ec-a8cb-847752f89f8eo%40googlegroups.com.

[gwt-contrib] Re: HashCode H$ property should be not enumerable

2020-06-12 Thread Vegegoku 
Most of our cliensts dropped support for ancient IEs, and we now only 
support IE11 and edge.

On Thursday, June 11, 2020 at 10:18:18 PM UTC+3, Colin Alworth wrote:
>
> Since the existing code is very similar to J2CL's code, it seems like a 
> reasonable change, provided it is indeed safe to drop support for IE8. At a 
> glance, I'm having trouble finding a recent statement describing whether or 
> not IE8 (and 9, 10) ought to be supported - since GWT is often used for 
> large long-lived applications, it can sometimes make sense to provide 
> support for browsers that might be officially unsupported, but still either 
> have a wide install base or where some other "extended support" is still 
> available.
>
> For example, from 
> https://docs.microsoft.com/en-us/lifecycle/faq/internet-explorer-microsoft-edge,
>  
> it appears that while IE8 and IE10 are no longer supported, IE9 is still 
> supported in some supported operating systems as the most recent browser. 
> However, there is still the note "To continue receiving IE 8 updates after 
> January 12, 2016, please contact your Microsoft Account Team.", suggesting 
> it is still possible to get IE8 support.
>
> This is contradicted somewhat by 
> https://docs.microsoft.com/en-us/deployedge/microsoft-edge-supported-operating-systems,
>  
> which says that the two OS versions (Win Server 2008 IA64 and SP2) which 
> support IE9 are no longer supported, suggesting that aside from some 
> specialized support contract, IE8, IE9, and IE10 should be considered dead.
>
> On Thursday, June 11, 2020 at 1:08:48 PM UTC-5, stockiNail wrote:
>>
>> Hi all,
>>
>> I was facing an annoying issue about the hashcode *$N* property, stored 
>> inside the java script object.
>>
>> I'm using GWT 2.8.2 but no JSNI implementation, only JSInterop objects.
>>
>> I'm writing an object (JsType native) in order to configure a chart for 
>> Chart.js. 
>>
>> @JsType(isNative = true, name = "Object", namespace = JsPackage.GLOBAL)
>>
>> Every property is the ID of another object.
>>
>> But unfortunately I got an error from Chart.js because it is scanning all 
>> properties keys to get the objects but it does not recognize the value of 
>> *$H*, being a number and not a object.
>>
>> scales: { 
>>   $H: 135, 
>>   x: {id: "x", _charbaId: 2, type: "category", axis: "x", display: true, …}, 
>>   y: {id: "y", _charbaId: 3, type: "linear", axis: "y", display: true, …} 
>> }
>>
>> It's clear that a hashcode must be stored therefore there is no way to 
>> remove it.
>>
>> Searching for a solution, I have found the *javaemul.internal.ObjectHashing* 
>> class which is managing the H$ property, I guess:
>>
>>  public static native int getHashCode(Object o) /*-{
>> return o.$H || (o.$H = @ObjectHashing::getNextHashId()());
>>  }-*/;
>>
>> I think the definition of H$ property must be changed, in order to define 
>> the property "not enumerable" (currently is writable, enumerable and 
>> configurable) using *Object.defineProperty()*, as it is reported 
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty.
>>
>> The *Object.defineProperty()* method is not supported into Internet Explorer 
>> 8 therefore if going to manage the hascode in this way, GWT will drop the 
>> support on IE8 as well.
>>
>> In the J2CL implementation, it looks like already aligned with my proposal:
>>
>>
>> /** 
>>   * Utility functions for setting and retrieving system level hashcodes. 
>>   */
>> class Hashing { 
>>/** 
>>  * Gets a hash code on the passed-in object. 
>>  * 
>>  * @param {*} obj 
>>  * @return {number} 
>>  * @public 
>>  */ 
>>  static $getHashCode(obj) { 
>> let o = /** @type {Object} */ (obj); 
>> return o.$systemHashCode || (Object.defineProperties(o, { 
>> $systemHashCode: {value: Hashing.$getNextHashId(), enumerable: false} }), 
>> o.$systemHashCode); 
>>  }
>>
>> Anyway, as workaround, I'm rewriting the hashcode property for this object, 
>> maintaining the same value but setting the property as not enumerale and it 
>> seems working.
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/c735b2fa-ec61-4140-925c-91b3c34b9679o%40googlegroups.com.