Re: java.time support

[Leon Pennings]

Hi Jasper,

besides the fact that you don't need to worry for java.util.Date until the 
year 292278994, there is always the possibility to implement your own value 
object for a Date in GWT.
You can also use 3 party custom Date implementations too, as long as you 
include the source for the GWT compiler, and as long as that implementation 
is based on GWT supported building blocks.

rg,

Leon.

Op woensdag 9 oktober 2024 om 18:26:28 UTC+2 schreef Colin Alworth:

> On the server, java.util.Date is unaffected as Jens pointed out - it is 
> not backed by a 32-bit int, but a 64-bit int. Your swing and web 
> implementations will be able to use java.util.Date beyond 2038:
>
> Here's plain Java, using jshell to demonstrate that this will work with 
> much larger dates than a decade away:
>
> jshell> new java.util.Date(Long.MAX_VALUE)
> $1 ==> Sun Aug 17 01:12:55 CST 292278994
>
> As he also pointed out, you _can_ use java.time using the linked package, 
> but the java.time APIs are not very conducive to emulation in the browser, 
> so any emulation will always be a subset of the full possible functionality 
> that a regular JVM has.
> On Wednesday, October 9, 2024 at 10:08:42 AM UTC-5 blackh...@gmail.com 
> wrote:
>
>> So web is not going to be worried, but... :) 
>> We have user interfaces for both thick (swing) and web using dates and 
>> now we need to use java.util.Date as this is supported by GWT.
>> Is there a way to use anything else than java.util.Date that is supported 
>> by GWT? 
>>
>> Op wo 9 okt 2024 om 16:51 schreef Jens :
>>
>>> Here is a link about the year 2038 problem: 
>>> https://en.wikipedia.org/wiki/Year_2038_problem
>>>
>>>
>>> Ah ok, thats where you are coming from.
>>>
>>> JavaScript/ECMAScript defines that JavaScript Date supports exactly 
>>> 1 days before and after unix epoch. This gives us a maximum year of 
>>> 275760 that JavaScript Date can currently represent.
>>>
>>> Java itself uses a long to represent millis since epoch in 
>>> java.util.Date. Because long is 64 bit the maximum year that java.util.Date 
>>> can represent is 292278994.
>>>
>>> JavaScript: 275760
>>> Java: 292278994
>>>
>>> Since GWT emulates java.util.Date using native JavaScript Date the max 
>>> year in GWT code is the one of JavaScript.
>>>
>>> In any case year 2038 shouldn't be a problem, thats why I asked. You can 
>>> easily verify it in browser console using
>>>
>>> var millis = Date.parse("2040-06-01");
>>> var date = new Date(millis);
>>> console.log(date);
>>>
>>> -- 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.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/google-web-toolkit/c195f5e8-1927-43a7-8796-634c56e20d84n%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/94413017-4940-4332-a8eb-64ee097baaf7n%40googlegroups.com.

Re: [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads

[Leon Pennings]

I've seen the request to host static webcontent (i.e. html/css/js) on a 
separate server many times before. Especially with dedicated infrastructure 
teams.
The trick is to have mvn build a separate jar with only the static content 
and unzip that on the target webserver.
It's been a while since I last did this though.

Still I'm quite interested why we've never run in similar compilation 
issues despite having quite a larger set of frontend code as stated in this 
thread. Can someone explain? I expect it might have something to do with 
the fact we only use a single RPC call? 
The RPC is used as transport only for a command pattern implementation of 
the communication between front and backend. The Rpc basically implements a 
CommandSink in the UI code and a CommandSource on the server. 
Hence we always only needed a single rpc.

Op dinsdag 1 oktober 2024 om 06:48:50 UTC+2 schreef Frank Hossfeld:

> Besides that the plugin does not provide this functionality - as Greg 
> already mentioned - you will run into security issues, while hosting the 
> client on one server and the server part on another (CORS). (OK, you might 
> find a workaround with some fanzy server configuration, but it's risky) If 
> you really want to do this, you can use the artifact as designed and use 
> the server module of your client service as proxy that calls the other 
> server. In this case you can use the artifact as designed and there is no 
> need for disabling CORS and so.
>
> Craig Mitchell schrieb am Dienstag, 1. Oktober 2024 um 02:51:40 UTC+2:
>
>> Running multiple servers with different functionality, is outside the 
>> scope of the Spring Boot + GWT archetype.
>>
>> Spring Boot + GWT archetype gives you one server codeline, Ie: One WAR or 
>> JAR.  You can can replicate and load balance it nicely (I do this with this 
>> architecture in the Google Cloud).  I suspect this is actually what you 
>> want.
>>
>> However, If you really want to run multiple servers that have different 
>> functionality (Ie: Create multiple different WARs or JARs), you'll need to 
>> create your own services.  How you do this is up to you, but the Spring 
>> Boot + GWT archetype will be able to call these services no problem.
>>
>> On Monday 30 September 2024 at 11:09:30 pm UTC+10 viny...@gmail.com 
>> wrote:
>>
>>> Hi FRANK,
>>>
>>> We have gone through the link provided by you "Spring Boot + GWT 
>>> archetype: https://github.com/NaluKit/gwt-maven-springboot-archetype";
>>>
>>> We want to host client on different server-machine and server will be 
>>> hosted on another server-machine. We cannot find how will we achive the 
>>> same with the architecture provided above. 
>>>
>>>
>>>
>>> On Friday, September 27, 2024 at 1:55:26 PM UTC+5:30 Frank Hossfeld 
>>> wrote:
>>>
 Regarding point 7:
 In addition to what Jens said, here you'll find an artifact creator for 
 a Spring Boot + GWT archetype: 
 https://github.com/NaluKit/gwt-maven-springboot-archetype

 Also, I would like to add:
 to prepare the project, running 'mvn clean compile'  is all you need to 
 do to prepare the project for testing.
 After the 'mvn clean compile' command is executed, start the codeserver 
 and wait until you see the URL of the codeserver in the terminal window! 
 After the URL is printed, the Spring Boot application can be started. This 
 is necessary, because the codeserver has to create the launcherDir before 
 Spring Boot is startet. Otherwise Spring Boot will not publish the content 
 of the launcherDir and the project will not work.

 Jens schrieb am Donnerstag, 26. September 2024 um 18:49:22 UTC+2:

> Now! our WAR is compiling (single permutation) in 10.25 mins only. We 
> are testing our application workflow as many of the differedJS files are 
> greater than 1 mb. We'll try to reduce the size. 
>
>
> Sounds way better and you can likely decrease the required Java heap 
> now as well. You had A LOT of split points. Personally I use split points 
> more like one per menu item of the first or second level menu, depending 
> on 
> the size of the application. Grouping menu items behind a single split 
> point can also make sense, e.g. user vs. admin menu items or based on 
> other 
> usage patterns. Occasionally I use split points for a feature like 
> rendering charts that could be split away until needed. 
>
>
>
> Whereas GWT 2.6.1 upgradation is concerned, we would like to say, yes! 
> we are actively developing the application and are intrested in upgrading 
> GWT 2.6.1. But there are some issues which are required to be addressed. 
> Many time earlier we have planned the upgradation, but dropped the idea 
> due 
> to not having the clear answers on bellow mentioned points. 
>
> *1.* Which version of GWT we should move to? As many of the latest 
> technologies are rolling arround and GWT in i

Re: Autogenerate IDs for eatch widget

[Leon Pennings]

There are ways to get id attributes on elements working even just for test, 
but that will not work efficiently for testing purposes. 
As id's need to be unique within the html, you have manage this for 
instance with a counter. If you do not keep them unique you'll be in a 
world of html behavior fun. 
When you write your tests on a specific Id, the moment you add a widget 
somewhere in the user click path going up to the panel you want for test, 
your id will be higher then expected for the test. So it will fail and 
you'll need to fix ids. Very maintenance intensive.

Best to set an attribute on your element named 'data-xxx' (xxx as 
whatever you like) with a functional value. For instance if it's a value in 
a table, set the corresponding DB id, name or anything that identifies that 
row and is reusable.
data-x is also ignored by screen readers and the like - so no need to 
remove them from prod html. And there is no need to keep them unique in all 
your html - so you can't break behavior.

It's quite easy to do, and it'll work wonders for your setup & maintenance 
of playwright or selenium testing.

Op dinsdag 6 februari 2024 om 12:59:45 UTC+1 schreef Sebastian Bota:

> Thank you very much for your response
>
> On Tuesday 6 February 2024 at 12:03:38 UTC+2 Jens wrote:
>
>> Nothing that I am aware of. Also I think you need some naming conventions 
>> for your debug ids anyways which makes automatic generation difficult. 
>> Otherwise it will be difficult to write and later understand the UI test if 
>> debug ids are generic like input-0, input-1, input-2. You also need to 
>> verify if any of your widgets might already use an ID because of CSS 
>> styling or element selection using document.querySelector(). This would 
>> break if you override the ID.
>>
>> Every widget has onAttach/onDetach/onLoad/onUnload methods you can 
>> override. You could copy GWT's Widget class into your own source code (keep 
>> the original package) or give all your widgets a common super class and 
>> adjust the code to set a debug id. But I think you will quickly realize 
>> that generating stable but unique debug IDs on that abstract level will be 
>> difficult. Also widgets usually want debug ids on some internal meaningful 
>> elements as well, which you do not know at that abstract level.
>>
>> -- J.
>>
>>
>> Sebastian Bota schrieb am Dienstag, 6. Februar 2024 um 09:15:33 UTC+1:
>>
>>> Hello everyone. 
>>> I have a GWT application and for testing purposes ( using external UI 
>>> testing tools ) i need that each widget to have an ID set. i know it is 
>>> possible by using ensureDebugID(), but this approach will take forever to 
>>> change in my project and is very error prone.
>>>
>>> So my question, is there any way i can set an ID to each widget 
>>> automaticly ?
>>> Perhaps some kind of hook, so when a widget is added to DOM i can set 
>>> the ID.
>>> This id will be only used in test, not in production.
>>>
>>> Thank you very much for any suggestions.
>>> BR,
>>> Sebastian
>>>
>>

-- 
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/c37a971a-ea12-4fa4-a926-103afefa3e2bn%40googlegroups.com.

Re: Is moving away from RPC a good idea?

[Leon Pennings]

I think moving away from gwt-rpc is a bad idea. 
A big advantage of GWT is that I can code everything in java and do not 
have to serialize anything to and from text.
That to me is one of the usp's of GWT.
Going from java -> json -> java (or gwt java), is like trying to have a 
complex conversation between 2 Dutch guys, but with a German translator in 
between. 




Op donderdag 11 januari 2024 om 16:20:32 UTC+1 schreef Vassilis Virvilis:

> Hi Vegegoku,
>
> Thanks for clearing that up.
>
> At some point I will definitely try the domino-rest/jackson.
>
> For now I dread the time I will eventually be forced to port my current 
> setup.
>
>
> On Thu, Jan 11, 2024 at 5:13 PM Vegegoku  wrote:
>
>> 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
  
 

Re: Strategies for dealing with large number of languages?

[Leon Pennings]

All,

Same as Ralph, we've always been using a custom Translator class (since 
2009/2010 or so).
so for instance .setText(Translator.translate("Submit"))

The Translator loads all labels and puts them in mem based on the language 
preference of the user. So only 1 set of language labels in mem.
Works like a charm and never had a problem.
The translations are on the server side in the db so that a superuser can 
manage translations.

rg,

Leon.

Op donderdag 4 januari 2024 om 09:55:26 UTC+1 schreef Ralph Fiergolla:

Hi! 
Since a big part of our string content comes from database records anyway, 
we decided to go without any static texts but use dynamic labels. Initial 
concerns about performance and memory footprint have proven to be 
unfounded. That is, despite working in the context of European Institutions 
we go with a single static language and avoid the compile time performance 
bottleneck of having a large number of permutations. 
Cheers,
Ralph 

On Thursday, January 4, 2024 at 1:29:08 AM UTC+1 Alexander Bertram wrote:

Hi there,
We have been using GWT to build our product for a very long time. Recently, 
we've faced a new challenge as we've steadily been increasing the number of 
supported translations of the application to support a global audience. 
We're up to 24 languages, and could conceivably hit 40 in the coming year.

With all of these languages, come more permutations! We've stripped away 
browser-specific permutations, but we do have a mobile version of the app, 
which means that we have 2 x 24 permutations = 48.

So far, we've addressed this problem by increasing the size of the VM that 
builds the app, but even with 16 vCPUs it takes 10-12 minutes to build the 
app. I'm experimenting with increasing to 32 vCPUs, but so far I can't get 
the build time to drop linearly.

Anyone else out there using alternate strategies? Is it worth trying to 
create some sort of distributed cache from the intermediate files the 
compiler writes out? Load translations dynamically at runtime instead? Or 
just through more hardware at it :-)

Just curious to hear what others are doing?

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-toolkit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit/40e79634-d41e-4ddb-8f5c-0d702bcbd1f1n%40googlegroups.com.

Re: running gwt server code on apache

[Leon Pennings]

You can deploy the web application on tomcat and use mod_proxy on apache2 
to forward https (or http if required) to tomcat on 8080 (or another port 
if required)

Op woensdag 8 november 2023 om 18:31:19 UTC+1 schreef dav...@googlemail.com:

> hi Ed
>
> Yes understood and most of  the "app" is GWT produced javascript, part of 
> a web page, which I've always run on apache2 and don't really want to 
> change that for the ip address supplying servelet which is a recent 
> addition. I already also run  a backend tomcat with an AJP connection to 
> apache2 for a couple of  java coded apps. So is setting up the WEB-INF 
> directory of my GWT "app" separately in tomcat the preferred way to do this 
> or at least a possibility?
>
> Prior to adding  the server code the WEB_INF directory was not needed by 
> apache2 I believe, rather just the javascript, directory. so that does 
> appear to be a reasonable way to go?
>
> David
>
> On Wednesday, 8 November 2023 at 12:31:36 UTC Ed wrote:
>
>> jetty is application server while apache2  is a web server.  tomcat is 
>> the apache app server.
>>
>> On Wed, Nov 8, 2023 at 4:48 AM 'dav...@googlemail.com' via GWT Users <
>> google-we...@googlegroups.com> wrote:
>>
>>> On my development machine I test my code in jetty. The client code calls 
>>> a server to get the client ip address. This works fine and I see a server 
>>> at localhost:8080/foo/bar as I expect. If I browse to it I get a 405 as GET 
>>> request are not allowed, but that's not a problem as it does the job it's 
>>> supposed to do ie pass request address back to client code.
>>>
>>> It does not work in production were the code is run on apache; the 
>>> server is not created as on jetty, so that's not unexpected. I first 
>>> suspicion was that modsecurity is preventing the creation of the server, 
>>> but that proves to be not so. I also see the same failure over http as over 
>>> https.
>>>
>>> I have a pretty basic apache2 setup on debian (apart from adding 
>>> modsecurity) and the site config is pretty bog standard for both http and 
>>> https. I'm guessing I need to tweak something somewhere to allow the server 
>>> to be created?
>>>
>>> -- 
>>> 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/6aafe876-bff0-4b02-86f2-239e94201324n%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/685dc5d5-db0c-4423-b667-598a44bcd10an%40googlegroups.com.

Re: Convert Existing GWT Backend to SPRING BOOT

[Leon Pennings]

In addition to previous poster -> yes you can keep on using the GWT RPC. 

The things I had to change in order to keep it working when packaging the 
spring boot jar, was;
1 - to make sure Spring Boot runs the servlets (enough on the web for that)
2 - to make sure the gwt compile ends up in de classes folder before the 
.jar is created 
3 - to make sure the servlet can access the .gwt.rpc file to validate the 
servlet calls. 
Normally that is available to the servlet from the war package, but since 
it's a jar with Spring boot you need to make some changes;
For that I had to override the RemoteServiceServlet method;

@Override
protected SerializationPolicy doGetSerializationPolicy(HttpServletRequest 
request, String moduleBaseURL, String strongName) {
  return SerializationPolicyLoader.loadFromStream(new 
ClassPathResource("classpath:yourLocation/" + 
strongName+".gwt.rpc").getInputStream(), null);
}

So the changes are quite limited and not as much Spring boot specific, but 
more the oddities of changing the package format from a .war to a .jar
That was all -> runs like a charm
Op maandag 5 december 2022 om 23:00:26 UTC+1 schreef lofid...@gmail.com:

> Hi All, 
>
> you don't have to move GWT RPC to REST and JSON when you want to move the 
> backend to Spring Boot. GWT RPC is just a servlet which you can register in 
> Spring Boot.
>
> Here are some examples of the standard GWT Demo StockWatcher but 
> implemented using Spring Boot with GWT RPC and REST JSON:
>
> https://github.com/lofidewanto/stockwatcher
>
> (1) This example shows how to integrate the GWT RPC servlet to Spring Boot 
> using @WebServlet: 
> https://github.com/lofidewanto/stockwatcher/blob/master/stockwatcher-springboot-webapp/stockwatcher-springboot-webapp-server/src/main/java/stockwatcher/GreetingServiceImpl.java
>
> (2) This example shows to integrate the GWT RPC servlet to Spring Boot, 
> but I think doesn't work so far. I could take a look if you want to.
>
>
> https://github.com/lofidewanto/stockwatcher/blob/master/stockwatcher-springboot/stockwatcher-springboot-server/src/main/java/stockwatcher/WebConfig.java
>
> Cheers,
> Lofi
>
> Michael Joyner schrieb am Montag, 21. November 2022 um 16:50:29 UTC+1:
>
>> *Are you using gwt-RPC ?*
>> Yes! we are using GWT-RPC & currently having a single WAR of near about 
>> 500mb, having CLIENT-SHARED-SERVER in a same project.
>>
>> You can still have everything in a master parent project that builds the 
>> final WAR with all the client JS and SERVER classes in the same war.
>>
>>
>> *You'll need to switch to JSON for data transport.*
>> Is there any drawback of switching to JSON in GWT, such as impact on 
>> performance etc.
>>
>> You lose easy polymorphism for models, they will require an extra set of 
>> annotations at the very least if you have polymorphism as part of your DTO 
>> setup.
>>
>>
>> *You'll need to use something like DominoKit REST.*
>> We found one RestyGWT , but not sure about 
>> its final impact as we haven't applied it yet. any suggestions...
>>
>> RestyGWT is effectively defunct. Stick with a modern GWT3 compatible 
>> approach such as DominoKit.
>>
>>
>>
>> *It would be also be best to split the project into three projects. An 
>> API project, a shared code project, and a UI project.*
>> We cannot get why keeping *SHARED CODE *as a separate project is best. 
>> We are not having any library of GWT on server side. So except MODELS, what 
>> are the other stuffs we can have in SHARED CODE PROJECT.   
>>
>> In this case SHARED CODE is really just the MODELS and INTERFACES and 
>> possible the REST Interface.
>>
>>
>> *If you are using gwt-RPC then IMHO there will need to be a big 
>> refactoring change at the very least*
>> This is where we are stuck & looking for the solution with a minimum 
>> change and should be stable but unable to figure out yet. 
>>
>> I don't think you can accomplish this with a large project with minimum 
>> of change unless the client API calls are fully abstracted away (or can be) 
>> so that code could be replaced with a different class.
>>
>>
>> On Monday, November 21, 2022 at 7:37:33 PM UTC+5:30 Michael Joyner wrote:
>>
>>> There are a lot of factors to consider.
>>>
>>> Are you using gwt-RPC ? You'll need to switch to JSON for data transport.
>>>
>>> You'll need to use something like DominoKit REST (
>>> https://github.com/DominoKit/domino-rest)  for the data transport layer.
>>>
>>> It would be also be best to split the project into three projects. An 
>>> API project, a shared code project, and a UI project.
>>>
>>> If you are using gwt-RPC then IMHO there will need to be a big 
>>> refactoring change at the very least.
>>>
>>>
>>> On 11/21/22 08:19, viny...@gmail.com wrote:
>>>
>>>
>>> We are having a huge project already running successfully on GWT. 
>>>
>>> But for some reasons we are planning to move our backend to SPRING-BOOT 
>>> keeping front end in GWT. 
>>>
>>> Is there any way we can do it easi

Re: Compatibility of GWT 2.10.0 with GXT 2.3.1.a

[Leon Pennings]

>From what I gathered, packages have been renamed from **.google.** to 
**gwtproject** or smth.
So without a gxt update to cover for the new packages, I doubt you can 
upgrade your project.

There is one simple way to check, just update the GWT version in your 
dependency manager (maven or whatever you use) and you'll find out soon 
enough.
 
Op maandag 18 juli 2022 om 06:56:23 UTC+2 schreef priyako...@gmail.com:

> Hello Team,
>
> we use following jars in our application - 
> GXT .jar -2.3.1.a
> GWTx.jar -   1.5.3
> Log4j-gwt.jar - 1.0
>
> Wanted to know that will recent update of GWT 2.10.0 compatible with above 
> dependencies.
>
>

-- 
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/e1b1f376-70f4-4c6d-95ca-522caa85e1bcn%40googlegroups.com.

Re: URGENT: GWT build crash with out of memory

[Leon Pennings]

tbh, I've never worked with split points before. 
What would be the actual problem be if splitpoints are not used - besides 
from the initial load times?


Op vrijdag 1 april 2022 om 17:46:40 UTC+2 schreef nilo...@gmail.com:

> Split points are amazingly expensive to compute (in both CPU and memory) - 
> I would definitely remove all split points currently under 10KB, and 
> strongly consider removing all under 100KB, at least for an application of 
> that size. Odds are excellent that your 4043KB file is your "leftovers" 
> split point (you can confirm this by checking if the name of the file is 
> the largest number in that directory) - if so, it is quite possible that 
> removing other tiny split points will decrease the size of the leftovers 
> and increase the size of the other larger split points. It may increase the 
> initial download size as well, which could tell you that it could be wise 
> to carefully put some back, but taking care to merge related split points 
> (for example, using GWT.runAsync(Class, RunAsyncCallback) to tell the 
> compiler that more than one RunAsyncCallback should be merged as the main 
> file).
>
> Consider the order that your files must load in order for the application 
> to start up - first, the 1.7MB file loads, and the app is usable until the 
> first split point loads. Does that first split point load instantly? Does 
> more than one load right away before the app can be used? Consider merging 
> those split points, or entirely removing them, if they don't provide some 
> concrete benefit (like allowing the user to start logging in while the rest 
> of the app is still downloading, etc).
>
> Next, before the very first split point can be loaded, the "leftovers" 
> split point is loaded - the split point with the biggest number, in your 
> case this would be 756.cache.js (as of your last message). This must be 
> downloaded and run before any other split point can be loaded - if this is 
> your biggest one by a factor of of almost 10, it might not even make sense 
> to have more than a handful of split points, unless you can find a way to 
> bring that leftover size down, or possible merge it into the initial split 
> point.
> On Friday, March 4, 2022 at 8:08:11 AM UTC-6 viny...@gmail.com wrote:
>
>> First of all we are very-very thankful to VIE, FRANK & JENS for their 
>> valuable suggestions and are sorry for late reply. As we were busy in 
>> applying the solutions suggested by you people.
>>
>> *AS THE RESULT:-*
>> 1. As we have already using "*gwt.compiler.jvmargs=-Xmx61440m*" so we 
>> could not get what VIE mean to say.
>> 2. As per the suggestion of FRANK we change the logLevel and got the 
>> error details and found that some server side classes has been used eg:
>>  "*Line 18: No source code is available for type 
>> java.util.regex.Pattern; did you forget to inherit a required module?"*
>> *  We solved the bugs one-by-one BUT this also not resolved our 
>> primary problem*. 
>> 3. As per the suggestion of JENS
>>  3.1. We used  -optimize *BUT this also not resolved our primary 
>> problem*. 
>>  3.2. We tried to lower down the split points by 100. As we get near 
>> to 756 *.cache.js files. The code started to compile in 35-40 minutes. 
>> *   So! the split points were the culprit.*
>>
>>
>> *Now our war file is compiling in 30-40 minutes and we are planning to 
>> lower down the split points more.*
>>
>> *WE ARE VERY THANKFULL TO ALL OF YOU. AS YOUR VALUABLE SUGGESTION HAD 
>> SAVED US.*
>>
>> On Thursday, March 3, 2022 at 6:03:27 AM UTC+5:30 Jens wrote:
>>
>>> As already said the first thing you should do is to use -strict. This 
>>> makes sure GWT compiler does not ignore compile errors. Given you have 12 
>>> compile errors, you want to fix them first.
>>>
>>> Next it looks like you have a lot of split points if you have 856 
>>> *.cache.js files. Given that 817 of these files are less than 100kb and 
>>> these files are usually gzipped by the web server before transferring to 
>>> the client browser, you should try to reduce the amount of split points. I 
>>> could imagine that analyzing the code for split point calculation might be 
>>> the culprit.
>>>
>>> There is also an -optimize option for the GWT compiler with values 0 - 9 
>>> (0 = no optimizations, 9 = aggressive). I don't recall the default value 
>>> but if it is 9 then it will do an optimize loop on the code AST until the 
>>> AST does not change anymore. In rare cases this can end up in an endless 
>>> loop. Using -optimize 8 usually fixes the issue as the compiler will do at 
>>> most 8 optimize loops then. So you might want to try that as well.
>>>
>>> I have a compiled app that is roughly half the size of yours (about 15 
>>> MB) and it compiles fine with just 8 GB Ram. But it only has about 20 split 
>>> points.  Using 64GB seems overkill in your case. Maybe you could also try 
>>> making a heap dump and analyze it in Eclipse memory analyzer to see what i

Re: Performance Comparison GWT Transpiler with MacBook Pro M1 Pro processor

[Leon Pennings]

For around a 1000 euro, you can build a desktop that is faster compiling 
than any laptop.
And on linux the memory is used a lot more efficient than on a mac, so you 
need less.
That being said - I have a macbook when I travel. But in the office and at 
home I switched to working on desktops about 5 yrs ago. 



Op woensdag 12 januari 2022 om 09:12:42 UTC+1 schreef Shawn:

> I kinda like the Max 64GB.  I'm pushing 54GB used for eclipse (running an 
> appengine dev and GWT server) during a build.  My upload to google cloud is 
> slow so after the build I can easily start developing again while it's 
> deploying.
>
> I also use a ramdisk and set the GWT SuperDev mode to use that with  
> -workDir /Users/me/.tmpdisk/GWT_RAM_DISK.  Then build with an ant task and 
> add this to the gwtc java task for building.
>
>  *"/Users/me/.tmpdisk/GWT_RAM_DISK"*/>
>
>
> No benchmarks but probably the biggest benefit is debugging which I still 
> do in Eclipse via SDGB.
>
> I haven't been able to get Eclipse to run natively as macOS AArch64 
> 
>  is 
> only available from the 2021-12 version which just borks my project.  It 
> seems to be a conflict with the google-cloud-plugin I use for appengine.  
> Still 2021-09 with emulated Eclipse is a major improvement especially since 
> the dev server and build processes can be run natively.
>
> Anyway, 32GB on a pro ordered today is about a month to get delivery and 
> 64GB on a max is about two months.  I got a 64GB max with 32 GPUs (maybe I 
> can use those for machine learning) as it was the only way to get more than 
> 16GB of memory without waiting so long and I had to move suddenly and 
> couldn't bring my iMac.  
>
> On Tue, Jan 11, 2022 at 9:17 AM 'Frank Hossfeld' via GWT Users <
> google-we...@googlegroups.com> wrote:
>
>> No, sorry ... closed source. Yep, I agree with. Don't think, that the 
>> graphics CPUs will have an impact of the compile time.
>> So, the M1 Pro is a great choice for developers. Now I am waiting for the 
>> next Mac Pro ...
>>
>> Jens schrieb am Montag, 6. Dezember 2021 um 10:32:15 UTC+1:
>>
>>> I did some tests with one of my larger GWT projects. It takes 3:55 on my 
 "old" MacBook Pro 16" i9 2.4 GHz, 64 GB RAM. Same project build on a new 
 MacBook Pro M1 Max 64 GB takes roundabout 2:00. That's an incredible 
 improvement. 
>>>
>>>
>>> Is that project public? Then I would try it with my M1 Pro 32gb which is 
>>> IMHO the best value for developers, unless you do graphics stuff.
>>>
>>> -- 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.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/google-web-toolkit/c3bacc36-a959-4833-be07-6304e3f5705cn%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/b445df54-8a19-42db-8d02-dc28f3a5d159n%40googlegroups.com.