Re: Moving to jakarta from javax

Just one follow up note. Jakarta jars worked fine with Tomcat 9x. No problems making RPC calls. 

On Monday, September 30, 2024 at 6:39:02 AM UTC-7 Colin Alworth wrote:

The gwt-servlet-jakarta.jar is the one you want for using GWT-RPC in jakarta.servlet environments. Which classes that you need are not updated correctly?

The one (deliberate) omission I'm aware of is validation, but there is no server-side validation component for GWT. However, you may not be able to serialize validation types over gwt-rpc (though it is unlikely you were using this feature) though, since the built-in GWT implementation of validation is frozen at 1.0.0.GA - you'll need a different client implementation, and that implementation will need to be serializable over GWT-RPC to use in this way. See https://gitlab.com/ManfredTremmel/gwt-bean-validators and https://github.com/gwtproject/gwt/issues/9844.

On Monday, September 30, 2024 at 2:05:27 AM UTC-5 ma...@craig-mitchell.com wrote:

My comment probably doesn't help much.  I'm not sure how GWT extracts the Jakarta stuff for the library build.  I think it's all in here: https://github.com/gwtproject/gwt

In any case, adding GWT Servlet Jakarta should just work for Tomcat 10 (it did for me).

<dependency>
  <groupId>org.gwtproject</groupId>
  <artifactId>gwt-servlet-jakarta</artifactId>
</dependency>

On Monday 30 September 2024 at 12:27:09 pm UTC+10 Craig Mitchell wrote:

Yes.  Add this:  https://mvnrepository.com/artifact/org.gwtproject/gwt-servlet-jakarta

On Saturday 28 September 2024 at 4:12:52 am UTC+10 Moshe wrote:

Hello,

Are the Jakarta JARs what we need to use when moving to Tomcat 10? I was verifying but the servlet Jakarta sources jar has only some of the sources. So I decompiled some classes in gwt-servlet-jakarta.jar and I still see javax in imports. 

Thanks. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/dbaaa08b-f223-4323-937b-fde6c02ca966n%40googlegroups.com.

Re: Moving to jakarta from javax

The gwt-servlet-jakarta.jar is the one you want for using GWT-RPC in jakarta.servlet environments. Which classes that you need are not updated correctly?

The one (deliberate) omission I'm aware of is validation, but there is no server-side validation component for GWT. However, you may not be able to serialize validation types over gwt-rpc (though it is unlikely you were using this feature) though, since the built-in GWT implementation of validation is frozen at 1.0.0.GA - you'll need a different client implementation, and that implementation will need to be serializable over GWT-RPC to use in this way. See https://gitlab.com/ManfredTremmel/gwt-bean-validators and https://github.com/gwtproject/gwt/issues/9844.

On Monday, September 30, 2024 at 2:05:27 AM UTC-5 ma...@craig-mitchell.com wrote:

My comment probably doesn't help much.  I'm not sure how GWT extracts the Jakarta stuff for the library build.  I think it's all in here: https://github.com/gwtproject/gwt

In any case, adding GWT Servlet Jakarta should just work for Tomcat 10 (it did for me).

<dependency>
  <groupId>org.gwtproject</groupId>
  <artifactId>gwt-servlet-jakarta</artifactId>
</dependency>

On Monday 30 September 2024 at 12:27:09 pm UTC+10 Craig Mitchell wrote:

Yes.  Add this:  https://mvnrepository.com/artifact/org.gwtproject/gwt-servlet-jakarta

On Saturday 28 September 2024 at 4:12:52 am UTC+10 Moshe wrote:

Hello,

Are the Jakarta JARs what we need to use when moving to Tomcat 10? I was verifying but the servlet Jakarta sources jar has only some of the sources. So I decompiled some classes in gwt-servlet-jakarta.jar and I still see javax in imports. 

Thanks. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/034cc507-0d10-473a-a516-7f1b886501b1n%40googlegroups.com.

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

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 itself also have released many versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a huge application rapidly is not possible, so we want to be very sure.   

The newest GWT 2.11 version will be fine. It still supports running on Java 8 but future versions will likely not.

 

2. We are using "Apache Netbeans IDE" from a long time and now the team is also very much famlier with it. Upgraded GWT4NB plugin was missing from market place. Can we go for upgradation without changing IDE?

I don't know about Netbeans and GWT4NB. However GWT SDK itself hasn't changed in structure so I don't see why GWT4NB shouldn't work anymore with newer GWT versions. Of course you can use GWT without any IDE plugin and launch GWT SuperDevMode and GWT Compile via ANT for example. Of course you would loose all benefits the IDE plugin gave you.

 

3. We are using "JDK 1.8". Do we required to upgrade JDK too?

No, as of now. But future versions will require newer JDK. If you upgrade your libraries then you can probably pretty easily upgrade JDK as well. You might need to add some libraries as some classes have been removed from JDK 11, see: https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8190378

 

4. We are using "PAYARA-WEB-SERVER" in both development + Production environment. GWT upgraded versions are comming with inbuild JETTY servers. Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have to stick wit JETTY only?

GWT ships with Jetty for convenience to get a demo app up and running quickly. But these days we recommend using your own servlet container and it can be any servlet container you like. If you do not use any servlet specific features of GWT like GWT-RPC or RequestFactory then you can use whatever server you like. PAYARA should continue to work fine.

 

5. We are using "ANT build" not "Maven build" means we are not having any type of POM files.  

Then you likely have a project or a folder with all your dependencies. You can download GWT from gwtproject.org, unzip it and use these jars in your ANT file. Alternatively there are ANT tasks provided by Maven which allows ANT to download dependencies based on POM files. See: https://maven.apache.org/resolver-ant-tasks/

 

6. We are using sencha (gxt 3.1.1) mainly for GRID functionality. Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT is paid. What are its alternative?

That is probably the main issue to solve. There are some UI widget libraries for GWT like https://dominokit.com/solutions/domino-ui/v2 but if you switch the library you would need to rewrite your code of course. 

Maybe you can make GXT work by patching it yourself if allowed.

 

7. Our application is having GWT standard architecure eg: (client + shared + server) in the same application. We want to split our application as client & server seperate. Where we want to move server part in SPRING-BOOT without any major changes. Is it possible?    

Sure. First split your application without using spring boot and make it run again. Then apply spring boot to your server project. GWT 2.11 also has a JakartaEE variant now so Spring Boot 3+ should work as well (but requires Java 17). The benefit of splitting your project into three is that you can also use different JDK versions for client and server projects. Sometimes that is useful if your server has JDK requirements that are either newer or older than what you want to use for the client.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/d604e43a-e5fe-44dc-8df6-6e41863c9363n%40googlegroups.com.

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

Thank you  

JENS & FRANK for your valuable input. Your suggestions will surly help us in upgrading the version. 

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 itself also have released many versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a huge application rapidly is not possible, so we want to be very sure.   

The newest GWT 2.11 version will be fine. It still supports running on Java 8 but future versions will likely not.

 

2. We are using "Apache Netbeans IDE" from a long time and now the team is also very much famlier with it. Upgraded GWT4NB plugin was missing from market place. Can we go for upgradation without changing IDE?

I don't know about Netbeans and GWT4NB. However GWT SDK itself hasn't changed in structure so I don't see why GWT4NB shouldn't work anymore with newer GWT versions. Of course you can use GWT without any IDE plugin and launch GWT SuperDevMode and GWT Compile via ANT for example. Of course you would loose all benefits the IDE plugin gave you.

 

3. We are using "JDK 1.8". Do we required to upgrade JDK too?

No, as of now. But future versions will require newer JDK. If you upgrade your libraries then you can probably pretty easily upgrade JDK as well. You might need to add some libraries as some classes have been removed from JDK 11, see: https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8190378

 

4. We are using "PAYARA-WEB-SERVER" in both development + Production environment. GWT upgraded versions are comming with inbuild JETTY servers. Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have to stick wit JETTY only?

GWT ships with Jetty for convenience to get a demo app up and running quickly. But these days we recommend using your own servlet container and it can be any servlet container you like. If you do not use any servlet specific features of GWT like GWT-RPC or RequestFactory then you can use whatever server you like. PAYARA should continue to work fine.

 

5. We are using "ANT build" not "Maven build" means we are not having any type of POM files.  

Then you likely have a project or a folder with all your dependencies. You can download GWT from gwtproject.org, unzip it and use these jars in your ANT file. Alternatively there are ANT tasks provided by Maven which allows ANT to download dependencies based on POM files. See: https://maven.apache.org/resolver-ant-tasks/

 

6. We are using sencha (gxt 3.1.1) mainly for GRID functionality. Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT is paid. What are its alternative?

That is probably the main issue to solve. There are some UI widget libraries for GWT like https://dominokit.com/solutions/domino-ui/v2 but if you switch the library you would need to rewrite your code of course. 

Maybe you can make GXT work by patching it yourself if allowed.

 

7. Our application is having GWT standard architecure eg: (client + shared + server) in the same application. We want to split our application as client & server seperate. Where we want to move server part in SPRING-BOOT without any major changes. Is it possible?    

Sure. First split your application without using spring boot and make it run again. Then apply spring boot to your server project. GWT 2.11 also has a JakartaEE variant now so Spring Boot 3+ should work as well (but requires Java 17). The benefit of splitting your project into three is that you can also use different JDK versions for client and server projects. Sometimes that is useful if your server has JDK requirements that are either newer or older than what you want to use for the client.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/416daefe-d600-4e32-a3b0-f63f6fa48c5fn%40googlegroups.com.

Re: Moving to jakarta from javax

My comment probably doesn't help much.  I'm not sure how GWT extracts the Jakarta stuff for the library build.  I think it's all in here: https://github.com/gwtproject/gwt

In any case, adding GWT Servlet Jakarta should just work for Tomcat 10 (it did for me).

<dependency>
  <groupId>org.gwtproject</groupId>
  <artifactId>gwt-servlet-jakarta</artifactId>
</dependency>

On Monday 30 September 2024 at 12:27:09 pm UTC+10 Craig Mitchell wrote:

Yes.  Add this:  https://mvnrepository.com/artifact/org.gwtproject/gwt-servlet-jakarta

On Saturday 28 September 2024 at 4:12:52 am UTC+10 Moshe wrote:

Hello,

Are the Jakarta JARs what we need to use when moving to Tomcat 10? I was verifying but the servlet Jakarta sources jar has only some of the sources. So I decompiled some classes in gwt-servlet-jakarta.jar and I still see javax in imports. 

Thanks. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/ab932496-d27d-4d3e-b5bd-ec9ed9cb0b91n%40googlegroups.com.

Re: Moving to jakarta from javax

Yes.  Add this:  https://mvnrepository.com/artifact/org.gwtproject/gwt-servlet-jakarta

On Saturday 28 September 2024 at 4:12:52 am UTC+10 Moshe wrote:

Hello,

Are the Jakarta JARs what we need to use when moving to Tomcat 10? I was verifying but the servlet Jakarta sources jar has only some of the sources. So I decompiled some classes in gwt-servlet-jakarta.jar and I still see javax in imports. 

Thanks. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/009e2b97-6b50-4bc9-8292-34b938acf210n%40googlegroups.com.

Moving to jakarta from javax

Hello,

Are the Jakarta JARs what we need to use when moving to Tomcat 10? I was verifying but the servlet Jakarta sources jar has only some of the sources. So I decompiled some classes in gwt-servlet-jakarta.jar and I still see javax in imports. 

Thanks. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/59ed59c9-cea3-4b3a-b0d8-5a7c1c7f0dban%40googlegroups.com.

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

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 itself also have released many versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a huge application rapidly is not possible, so we want to be very sure.   

The newest GWT 2.11 version will be fine. It still supports running on Java 8 but future versions will likely not.

 

2. We are using "Apache Netbeans IDE" from a long time and now the team is also very much famlier with it. Upgraded GWT4NB plugin was missing from market place. Can we go for upgradation without changing IDE?

I don't know about Netbeans and GWT4NB. However GWT SDK itself hasn't changed in structure so I don't see why GWT4NB shouldn't work anymore with newer GWT versions. Of course you can use GWT without any IDE plugin and launch GWT SuperDevMode and GWT Compile via ANT for example. Of course you would loose all benefits the IDE plugin gave you.

 

3. We are using "JDK 1.8". Do we required to upgrade JDK too?

No, as of now. But future versions will require newer JDK. If you upgrade your libraries then you can probably pretty easily upgrade JDK as well. You might need to add some libraries as some classes have been removed from JDK 11, see: https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8190378

 

4. We are using "PAYARA-WEB-SERVER" in both development + Production environment. GWT upgraded versions are comming with inbuild JETTY servers. Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have to stick wit JETTY only?

GWT ships with Jetty for convenience to get a demo app up and running quickly. But these days we recommend using your own servlet container and it can be any servlet container you like. If you do not use any servlet specific features of GWT like GWT-RPC or RequestFactory then you can use whatever server you like. PAYARA should continue to work fine.

 

5. We are using "ANT build" not "Maven build" means we are not having any type of POM files.  

Then you likely have a project or a folder with all your dependencies. You can download GWT from gwtproject.org, unzip it and use these jars in your ANT file. Alternatively there are ANT tasks provided by Maven which allows ANT to download dependencies based on POM files. See: https://maven.apache.org/resolver-ant-tasks/

 

6. We are using sencha (gxt 3.1.1) mainly for GRID functionality. Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT is paid. What are its alternative?

That is probably the main issue to solve. There are some UI widget libraries for GWT like https://dominokit.com/solutions/domino-ui/v2 but if you switch the library you would need to rewrite your code of course. 

Maybe you can make GXT work by patching it yourself if allowed.

 

7. Our application is having GWT standard architecure eg: (client + shared + server) in the same application. We want to split our application as client & server seperate. Where we want to move server part in SPRING-BOOT without any major changes. Is it possible?    

Sure. First split your application without using spring boot and make it run again. Then apply spring boot to your server project. GWT 2.11 also has a JakartaEE variant now so Spring Boot 3+ should work as well (but requires Java 17). The benefit of splitting your project into three is that you can also use different JDK versions for client and server projects. Sometimes that is useful if your server has JDK requirements that are either newer or older than what you want to use for the client.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c5089e63-9519-4a1a-a1ad-7a67dd30978bn%40googlegroups.com.

Re: What is the version of JARs in GWT 2.11.0 download

Yes I took a second look and I see the differences you noted. Yes sorry, I mean transitive. 

Thanks again for the quick reply. 

On Thursday, September 26, 2024 at 11:48:08 AM UTC-7 Colin Alworth wrote:

If you downloaded the 2.11.0 zip, those are 2.11.0 jars in there. The current build process first produces the jars for the zip artifact, and then repackages those for release to maven central, so there will be differences (artifacts in the zip have most dependencies shaded into them, while the ones in Maven Central reference external dependencies were possible to keep the jar size down and allow downstream projects to manage versions as desired).

I think you are misreading the dependencies of org.gwtproject:gwt - you are looking at the _old groupId_ of com.google.gwt if you are seeing 2.10.0 in the org.gwtproject artifact for 2.11.0. The old groupId will continue to be listed so that any project that mixes (mistakenly or through necessity) org.gwtproject and com.google.gwt will end up with only org.gwtproject artifacts.

Take a closer look at that pom, and specifically check for the org.gwtproject dependencies - they are referenced as ${project.groupId}. From https://search.maven.org/artifact/org.gwtproject/gwt/2.11.0/pom,

compare

            <dependency>
                <groupId>com.google.gwt</groupId>
                <artifactId>gwt-user</artifactId>
                <version>2.10.0</version>
            </dependency>

with

            <dependency>
                <groupId>org.gwtproject</groupId>
                <artifactId>gwt-user</artifactId>
                <version>${project.version}</version>
            </dependency>

I'm not sure what transitional dependencies mean for gradle - do you mean transitive dependencies?

On Thursday, September 26, 2024 at 1:40:34 PM UTC-5 ude...@gmail.com wrote:

I downloaded the GWT 2.11.0 zip. I assumed the version of the JARs such as gwt-dev and gwt-user are 2.11.0, but there isn't a pom file in each JAR to confirm this assumption. 

I looked on mvnrepository and org.gwtproject:gwt shows the dependancoes to be 2.10.0. I also see the same thing in the POM view. It does indicate there are updates to 2.11.0. 

So what is the actual version of the JARs in the downloaded archive?

We don't use Maven, but Gradle. And we also don't use transitional  dependencies. I have to upload these JARs to our antifactory so I want to classify them accurately .

Thanks.  

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/61a6e117-aab2-4584-a911-5702ad3ade1dn%40googlegroups.com.

Re: What is the version of JARs in GWT 2.11.0 download

If you downloaded the 2.11.0 zip, those are 2.11.0 jars in there. The current build process first produces the jars for the zip artifact, and then repackages those for release to maven central, so there will be differences (artifacts in the zip have most dependencies shaded into them, while the ones in Maven Central reference external dependencies were possible to keep the jar size down and allow downstream projects to manage versions as desired).

I think you are misreading the dependencies of org.gwtproject:gwt - you are looking at the _old groupId_ of com.google.gwt if you are seeing 2.10.0 in the org.gwtproject artifact for 2.11.0. The old groupId will continue to be listed so that any project that mixes (mistakenly or through necessity) org.gwtproject and com.google.gwt will end up with only org.gwtproject artifacts.

Take a closer look at that pom, and specifically check for the org.gwtproject dependencies - they are referenced as ${project.groupId}. From https://search.maven.org/artifact/org.gwtproject/gwt/2.11.0/pom,

compare

            <dependency>
                <groupId>com.google.gwt</groupId>
                <artifactId>gwt-user</artifactId>
                <version>2.10.0</version>
            </dependency>

with

            <dependency>
                <groupId>org.gwtproject</groupId>
                <artifactId>gwt-user</artifactId>
                <version>${project.version}</version>
            </dependency>

I'm not sure what transitional dependencies mean for gradle - do you mean transitive dependencies?

On Thursday, September 26, 2024 at 1:40:34 PM UTC-5 ude...@gmail.com wrote:

I downloaded the GWT 2.11.0 zip. I assumed the version of the JARs such as gwt-dev and gwt-user are 2.11.0, but there isn't a pom file in each JAR to confirm this assumption. 

I looked on mvnrepository and org.gwtproject:gwt shows the dependancoes to be 2.10.0. I also see the same thing in the POM view. It does indicate there are updates to 2.11.0. 

So what is the actual version of the JARs in the downloaded archive?

We don't use Maven, but Gradle. And we also don't use transitional  dependencies. I have to upload these JARs to our antifactory so I want to classify them accurately .

Thanks.  

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/5a40a70a-daed-4c18-8a14-6f2952e1d87dn%40googlegroups.com.

What is the version of JARs in GWT 2.11.0 download

I downloaded the GWT 2.11.0 zip. I assumed the version of the JARs such as gwt-dev and gwt-user are 2.11.0, but there isn't a pom file in each JAR to confirm this assumption. 

I looked on mvnrepository and org.gwtproject:gwt shows the dependancoes to be 2.10.0. I also see the same thing in the POM view. It does indicate there are updates to 2.11.0. 

So what is the actual version of the JARs in the downloaded archive?

We don't use Maven, but Gradle. And we also don't use transitional  dependencies. I have to upload these JARs to our antifactory so I want to classify them accurately .

Thanks.  

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/4d89c386-b227-431b-b34d-8f490f095738n%40googlegroups.com.

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

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 itself also have released many versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a huge application rapidly is not possible, so we want to be very sure.   

The newest GWT 2.11 version will be fine. It still supports running on Java 8 but future versions will likely not.

 

2. We are using "Apache Netbeans IDE" from a long time and now the team is also very much famlier with it. Upgraded GWT4NB plugin was missing from market place. Can we go for upgradation without changing IDE?

I don't know about Netbeans and GWT4NB. However GWT SDK itself hasn't changed in structure so I don't see why GWT4NB shouldn't work anymore with newer GWT versions. Of course you can use GWT without any IDE plugin and launch GWT SuperDevMode and GWT Compile via ANT for example. Of course you would loose all benefits the IDE plugin gave you.

 

3. We are using "JDK 1.8". Do we required to upgrade JDK too?

No, as of now. But future versions will require newer JDK. If you upgrade your libraries then you can probably pretty easily upgrade JDK as well. You might need to add some libraries as some classes have been removed from JDK 11, see: https://www.oracle.com/java/technologies/javase/11-relnote-issues.html#JDK-8190378

 

4. We are using "PAYARA-WEB-SERVER" in both development + Production environment. GWT upgraded versions are comming with inbuild JETTY servers. Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have to stick wit JETTY only?

GWT ships with Jetty for convenience to get a demo app up and running quickly. But these days we recommend using your own servlet container and it can be any servlet container you like. If you do not use any servlet specific features of GWT like GWT-RPC or RequestFactory then you can use whatever server you like. PAYARA should continue to work fine.

 

5. We are using "ANT build" not "Maven build" means we are not having any type of POM files.  

Then you likely have a project or a folder with all your dependencies. You can download GWT from gwtproject.org, unzip it and use these jars in your ANT file. Alternatively there are ANT tasks provided by Maven which allows ANT to download dependencies based on POM files. See: https://maven.apache.org/resolver-ant-tasks/

 

6. We are using sencha (gxt 3.1.1) mainly for GRID functionality. Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT is paid. What are its alternative?

That is probably the main issue to solve. There are some UI widget libraries for GWT like https://dominokit.com/solutions/domino-ui/v2 but if you switch the library you would need to rewrite your code of course. 

Maybe you can make GXT work by patching it yourself if allowed.

 

7. Our application is having GWT standard architecure eg: (client + shared + server) in the same application. We want to split our application as client & server seperate. Where we want to move server part in SPRING-BOOT without any major changes. Is it possible?    

Sure. First split your application without using spring boot and make it run again. Then apply spring boot to your server project. GWT 2.11 also has a JakartaEE variant now so Spring Boot 3+ should work as well (but requires Java 17). The benefit of splitting your project into three is that you can also use different JDK versions for client and server projects. Sometimes that is useful if your server has JDK requirements that are either newer or older than what you want to use for the client.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1629c98e-989e-4405-904f-7df22e6ecf1en%40googlegroups.com.

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

Thank You 

JENS & COLIN for providing your inputs and valueable suggestions. We have applied the same in our application and here is the result:

currently our defferedJs are as follows:

                   

 

but after we removed all split points and only kept some major ones, here is the result:

                    

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. 

We again want to express our gratitude to JENS & COLIN for showing the right path towards the root cause along with the solution.  

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 itself also have released many versions after 2.6.1. Meanwhile J2CL had also been launched. Migrating a huge application rapidly is not possible, so we want to be very sure.   

2. We are using "Apache Netbeans IDE" from a long time and now the team is also very much famlier with it. Upgraded GWT4NB plugin was missing from market place. Can we go for upgradation without changing IDE?

3. We are using "JDK 1.8". Do we required to upgrade JDK too?

4. We are using "PAYARA-WEB-SERVER" in both development + Production environment. GWT upgraded versions are comming with inbuild JETTY servers. Can we use "PAYARA-WEB-SERVER" in development after upgradtion or we have to stick wit JETTY only?

5. We are using "ANT build" not "Maven build" means we are not having any type of POM files.  

6. We are using sencha (gxt 3.1.1) mainly for GRID functionality. Upgrading GWT will fall dependency is on SENCHA-GXT and upgraded SENCHA-GXT is paid. What are its alternative?

7. Our application is having GWT standard architecure eg: (client + shared + server) in the same application. We want to split our application as client & server seperate. Where we want to move server part in SPRING-BOOT without any major changes. Is it possible?    

For detail discussions we can connect on viny.jais@gmail.com. We welcome any type of suggestions or involvement on the same. 

On Wednesday, September 25, 2024 at 7:14:35 PM UTC+5:30 Colin Alworth wrote:

Agreed with Jens, definitely look at your split point usage. In the war that you have, you have a .cache.html file that you mentioned, 4.7MB. In that same dir, there should be a deferredjs/ directory - can you list its contents? It should have a directory per permutation (so, just one, named the same as your .cache.html file), and inside that, there should be some number of .cache.js files. How many are there, and what is their size range (like the .gwt.rpc table you made)?

Odds are very high that a significant number of them are quite small, and so shouldn't be created at all, so you can either remove them from your code (by finding their GWT.runAsync(...) calls), or use the compiler's built-in feature to try to minimize them, `-XfragmentCount=N`. That N is treated as a suggestion, and the compiler will create approximately that many split points in the final output - if that number is substantially less than the number of GWT.runAsync() calls, you probably will see a substantial compile time and memory usage improvement.

If most/all of the split points are small (say, under 100KB), you might consider disabling split points entirely to skip this processing step. There will be an increase in your initial page size, but possibly a manageable one.

But the most important thing when using split points is to measure impact on the user - when you load the page, watch the Network tab in browser tools, and see how much you are actually deferring, how many split points are being loaded, and how big they are. Odds are pretty high that the very last (going by file name) split point is loaded very soon after page load, and that this file is one of the biggest if not the biggest, which itself suggests that some work is necessary to improve your page loading experience. That split point is the "leftover" chunk, and represents any code shared by two or more chunks - using the -XfragmentCount feature is very likely to reduce its size, but modeling how your page loads and application builds is more complex than can be written in an email.

One more simple point: consider turning off the compiler report flag if you aren't actively using the results, it will take extra memory, compile time, and disk space. It would be helpful to turn it back on periodically, but shouldn't be necessary to keep it on all the time for all developers. This tool assists in some of the "why are my split points the way they are" debugging, but if the compile doesn't succeed anyway, odds are no one is looking at it.

Finally, GWT 2.6.1 is more than a decade old - if you're actively developing this application, strongly consider updating.

On Wednesday, September 25, 2024 at 4:40:36 AM UTC-5 Jens wrote:

Are you using a lot of code split points? 61GB memory seems pretty high. Someone else once posted a similar question and this person had ~100 split points which significantly impacted compilation. The more split points you have the more complex analysis will be in order to determine if some code is unique to a split point.

As comparision I have an app that produces 10MB JS in total per permutation and compiles fine using 4GB memory. It uses about 12 split points.

viny...@gmail.com schrieb am Dienstag, 24. September 2024 um 17:58:36 UTC+2:

Hi everyone,

We have stucked in a very strange / awkward situation. Our running GWT 2.6.1 application started crashing at the time of compilation since 2 days back.

We are using netbeans IDE (non-maven). we are sharing our app-information as follows:

1. "WAR" SIZE : 591MB

2. Total "*.gwt.rpc" files : 891 files (we have attached some of the *.gwt.rpc files for ref.)

                    

3. "*.cache.html" SIZE : 4.15 MB 

4. Earlier when WAR was compiling it was taking max 50 minutes for full comilation (single permutation) on hardware of (64 GB RAM, 4 Core, Xeon (R) CPU E3-1225 v5 @3.30 GHz,  window-server 2019 standard)  

5. using JVM option -Xmx61440M (gwt-conpilation config attached for ref.)

6. Currently we are getting following error: 

Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
   Compiling 1 permutation
      Compiling permutation 0...
      [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads
java.lang.OutOfMemoryError: Java heap space
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:133)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
at java.io.Writer.write(Writer.java:157)
at com.google.gwt.core.ext.soyc.impl.DependencyRecorder.flushOutput(DependencyRecorder.java:136)
at com.google.gwt.core.ext.soyc.impl.DependencyRecorder.endDependencyGraph(DependencyRecorder.java:70)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeComplementCfaForFragments(CodeSplitter.java:325)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeExclusivityMapWithFixups(CodeSplitter.java:362)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.execImpl(CodeSplitter.java:480)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.exec(CodeSplitter.java:115)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:423)
at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137)
at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:195)
at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)
at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
at java.lang.Thread.run(Thread.java:750)
         [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
      [ERROR] Unrecoverable exception, shutting down
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56)
at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
at java.lang.Thread.run(Thread.java:750)
      [ERROR] Not all permutation were compiled , completed (0/1)
F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:333: The following error occurred while executing this line:
F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:482: Java returned: 1

BUILD FAILED (total time: 39 minutes 36 seconds) 

We request you all to please provide any help / guidance on the same. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/73d1c410-0b45-4f72-a859-34c3f04638f1n%40googlegroups.com.

Re: Digest for google-web-toolkit@googlegroups.com - 2 updates in 1 topic

Just checked to be sure.

My previous project had 18M per permutation of cache.js, no split points and an -Xmx2000m for gwt compilation.

I just built the web project on my laptop and it was a 2 min build.

I don't know what one would have to do to require that many mem - or even need split points. I never ran into the need for more mem/split points.

But now I'm quite curious though ;-)

On Wed, Sep 25, 2024 at 10:56 PM <google-web-toolkit@googlegroups.com> wrote:

google-web-toolkit@googlegroups.com

Google Groups

Topic digest
View all topics

• [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads - 2 Updates

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

Jens <jens.nehlmeier@gmail.com>: Sep 25 02:40AM -0700 Are you using a lot of code split points? 61GB memory seems pretty high. Someone else once posted a similar question and this person had ~100 split points which significantly impacted compilation. The more split points you have the more complex analysis will be in order to determine if some code is unique to a split point.   As comparision I have an app that produces 10MB JS in total per permutation and compiles fine using 4GB memory. It uses about 12 split points.

Colin Alworth <colin@colinalworth.com>: Sep 25 06:44AM -0700 Agreed with Jens, definitely look at your split point usage. In the war that you have, you have a .cache.html file that you mentioned, 4.7MB. In that same dir, there should be a deferredjs/ directory - can you list its contents? It should have a directory per permutation (so, just one, named the same as your .cache.html file), and inside that, there should be some number of .cache.js files. How many are there, and what is their size range (like the .gwt.rpc table you made)?   Odds are very high that a significant number of them are quite small, and so shouldn't be created at all, so you can either remove them from your code (by finding their GWT.runAsync(...) calls), or use the compiler's built-in feature to try to minimize them, `-XfragmentCount=N`. That N is treated as a suggestion, and the compiler will create approximately that many split points in the final output - if that number is substantially less than the number of GWT.runAsync() calls, you probably will see a substantial compile time and memory usage improvement.   If most/all of the split points are small (say, under 100KB), you might consider disabling split points entirely to skip this processing step. There will be an increase in your initial page size, but possibly a manageable one.   But the most important thing when using split points is to measure impact on the user - when you load the page, watch the Network tab in browser tools, and see how much you are actually deferring, how many split points are being loaded, and how big they are. Odds are pretty high that the very last (going by file name) split point is loaded very soon after page load, and that this file is one of the biggest if not the biggest, which itself suggests that some work is necessary to improve your page loading experience. That split point is the "leftover" chunk, and represents any code shared by two or more chunks - using the -XfragmentCount feature is very likely to reduce its size, but modeling how your page loads and application builds is more complex than can be written in an email.   One more simple point: consider turning off the compiler report flag if you aren't actively using the results, it will take extra memory, compile time, and disk space. It would be helpful to turn it back on periodically, but shouldn't be necessary to keep it on all the time for all developers. This tool assists in some of the "why are my split points the way they are" debugging, but if the compile doesn't succeed anyway, odds are no one is looking at it.   Finally, GWT 2.6.1 is more than a decade old - if you're actively developing this application, strongly consider updating.       On Wednesday, September 25, 2024 at 4:40:36 AM UTC-5 Jens wrote:

Back to 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-toolkit+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/CABjQu7T32ZasY27zj3VhxFSR413cqPitH8TVMeT%2BX6M9PXqUhQ%40mail.gmail.com.

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

Agreed with Jens, definitely look at your split point usage. In the war that you have, you have a .cache.html file that you mentioned, 4.7MB. In that same dir, there should be a deferredjs/ directory - can you list its contents? It should have a directory per permutation (so, just one, named the same as your .cache.html file), and inside that, there should be some number of .cache.js files. How many are there, and what is their size range (like the .gwt.rpc table you made)?

Odds are very high that a significant number of them are quite small, and so shouldn't be created at all, so you can either remove them from your code (by finding their GWT.runAsync(...) calls), or use the compiler's built-in feature to try to minimize them, `-XfragmentCount=N`. That N is treated as a suggestion, and the compiler will create approximately that many split points in the final output - if that number is substantially less than the number of GWT.runAsync() calls, you probably will see a substantial compile time and memory usage improvement.

If most/all of the split points are small (say, under 100KB), you might consider disabling split points entirely to skip this processing step. There will be an increase in your initial page size, but possibly a manageable one.

But the most important thing when using split points is to measure impact on the user - when you load the page, watch the Network tab in browser tools, and see how much you are actually deferring, how many split points are being loaded, and how big they are. Odds are pretty high that the very last (going by file name) split point is loaded very soon after page load, and that this file is one of the biggest if not the biggest, which itself suggests that some work is necessary to improve your page loading experience. That split point is the "leftover" chunk, and represents any code shared by two or more chunks - using the -XfragmentCount feature is very likely to reduce its size, but modeling how your page loads and application builds is more complex than can be written in an email.

One more simple point: consider turning off the compiler report flag if you aren't actively using the results, it will take extra memory, compile time, and disk space. It would be helpful to turn it back on periodically, but shouldn't be necessary to keep it on all the time for all developers. This tool assists in some of the "why are my split points the way they are" debugging, but if the compile doesn't succeed anyway, odds are no one is looking at it.

Finally, GWT 2.6.1 is more than a decade old - if you're actively developing this application, strongly consider updating.

On Wednesday, September 25, 2024 at 4:40:36 AM UTC-5 Jens wrote:

Are you using a lot of code split points? 61GB memory seems pretty high. Someone else once posted a similar question and this person had ~100 split points which significantly impacted compilation. The more split points you have the more complex analysis will be in order to determine if some code is unique to a split point.

As comparision I have an app that produces 10MB JS in total per permutation and compiles fine using 4GB memory. It uses about 12 split points.

viny...@gmail.com schrieb am Dienstag, 24. September 2024 um 17:58:36 UTC+2:

Hi everyone,

We have stucked in a very strange / awkward situation. Our running GWT 2.6.1 application started crashing at the time of compilation since 2 days back.

We are using netbeans IDE (non-maven). we are sharing our app-information as follows:

1. "WAR" SIZE : 591MB

2. Total "*.gwt.rpc" files : 891 files (we have attached some of the *.gwt.rpc files for ref.)

                    

3. "*.cache.html" SIZE : 4.15 MB 

4. Earlier when WAR was compiling it was taking max 50 minutes for full comilation (single permutation) on hardware of (64 GB RAM, 4 Core, Xeon (R) CPU E3-1225 v5 @3.30 GHz,  window-server 2019 standard)  

5. using JVM option -Xmx61440M (gwt-conpilation config attached for ref.)

6. Currently we are getting following error: 

Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
   Compiling 1 permutation
      Compiling permutation 0...
      [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads
java.lang.OutOfMemoryError: Java heap space
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:133)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
at java.io.Writer.write(Writer.java:157)
at com.google.gwt.core.ext.soyc.impl.DependencyRecorder.flushOutput(DependencyRecorder.java:136)
at com.google.gwt.core.ext.soyc.impl.DependencyRecorder.endDependencyGraph(DependencyRecorder.java:70)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeComplementCfaForFragments(CodeSplitter.java:325)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeExclusivityMapWithFixups(CodeSplitter.java:362)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.execImpl(CodeSplitter.java:480)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.exec(CodeSplitter.java:115)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:423)
at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137)
at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:195)
at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)
at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
at java.lang.Thread.run(Thread.java:750)
         [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
      [ERROR] Unrecoverable exception, shutting down
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56)
at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
at java.lang.Thread.run(Thread.java:750)
      [ERROR] Not all permutation were compiled , completed (0/1)
F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:333: The following error occurred while executing this line:
F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:482: Java returned: 1

BUILD FAILED (total time: 39 minutes 36 seconds) 

We request you all to please provide any help / guidance on the same. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/0f64f783-0082-4046-9435-009e68a759cfn%40googlegroups.com.

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

Are you using a lot of code split points? 61GB memory seems pretty high. Someone else once posted a similar question and this person had ~100 split points which significantly impacted compilation. The more split points you have the more complex analysis will be in order to determine if some code is unique to a split point.

As comparision I have an app that produces 10MB JS in total per permutation and compiles fine using 4GB memory. It uses about 12 split points.

viny...@gmail.com schrieb am Dienstag, 24. September 2024 um 17:58:36 UTC+2:

Hi everyone,

We have stucked in a very strange / awkward situation. Our running GWT 2.6.1 application started crashing at the time of compilation since 2 days back.

We are using netbeans IDE (non-maven). we are sharing our app-information as follows:

1. "WAR" SIZE : 591MB

2. Total "*.gwt.rpc" files : 891 files (we have attached some of the *.gwt.rpc files for ref.)

                    

3. "*.cache.html" SIZE : 4.15 MB 

4. Earlier when WAR was compiling it was taking max 50 minutes for full comilation (single permutation) on hardware of (64 GB RAM, 4 Core, Xeon (R) CPU E3-1225 v5 @3.30 GHz,  window-server 2019 standard)  

5. using JVM option -Xmx61440M (gwt-conpilation config attached for ref.)

6. Currently we are getting following error: 

Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.
   Compiling 1 permutation
      Compiling permutation 0...
      [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads
java.lang.OutOfMemoryError: Java heap space
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:133)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
at java.io.Writer.write(Writer.java:157)
at com.google.gwt.core.ext.soyc.impl.DependencyRecorder.flushOutput(DependencyRecorder.java:136)
at com.google.gwt.core.ext.soyc.impl.DependencyRecorder.endDependencyGraph(DependencyRecorder.java:70)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeComplementCfaForFragments(CodeSplitter.java:325)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.computeExclusivityMapWithFixups(CodeSplitter.java:362)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.execImpl(CodeSplitter.java:480)
at com.google.gwt.dev.jjs.impl.codesplitter.CodeSplitter.exec(CodeSplitter.java:115)
at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:423)
at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137)
at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:195)
at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:50)
at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
at java.lang.Thread.run(Thread.java:750)
         [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
      [ERROR] Unrecoverable exception, shutting down
com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56)
at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
at java.lang.Thread.run(Thread.java:750)
      [ERROR] Not all permutation were compiled , completed (0/1)
F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:333: The following error occurred while executing this line:
F:\users\Avinash\forNewPlugin\aarogya\nbproject\build-gwt.xml:482: Java returned: 1

BUILD FAILED (total time: 39 minutes 36 seconds) 

We request you all to please provide any help / guidance on the same. 

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/a2a05066-1039-415b-a80e-09a5c58f3be1n%40googlegroups.com.