GWT 2.8.0 RC2 is here!

[Daniel Kurka]

Hi all,

I just build the GWT 2.8.0 RC2 and pushed it to maven central. The complete SDK is also available from here.

Please start testing and let us know if you run into any trouble and file bugs.

We are planing to release this as GWT 2.8.0 if we do not here about any serious issues within the next two weeks. The release notes for RC2 will be made available shortly after this notice, in the mean time you can take a look at the github repository.

Daniel,

on behalf of the GWT team

[Philippe Gonze]

Hi,

RC2 seems OK for our kind of developments... Great!

However I have a general question about the DOCTYPE header directive in the various *.gwt.xml files.

What is the good option among:

a) these lines are useless because quirk/standard discussion is obsolete. Ok to remove?

b) these lines have few effects, they are necessary, but the version reference 2.6 2.7 2.8... has absolutely no incidence. True?

c) these lines are critical and with 2.8.x, they have to be updated to ... ???

[ The online GWT doc is extremely poor on this (and others) point. Documentation and communication are obviously the weak parts of GWT. ]

Tnx for your answer.

Fil

[Jens]

However I have a general question about the DOCTYPE header directive in the various *.gwt.xml files.

What is the good option among:

a) these lines are useless because quirk/standard discussion is obsolete. Ok to remove?

b) these lines have few effects, they are necessary, but the version reference 2.6 2.7 2.8... has absolutely no incidence. True?

c) these lines are critical and with 2.8.x, they have to be updated to ... ???

The DOCTYPE is used by IDE's to provide XML autocompletion by looking at the referenced DTD file. So if GWT 2.8 would have introduced new XML elements and you want autocompletion for them you would need to update the DOCTYPE accordingly. Other than that its not really needed as seen in GWT's own *.gwt.xml files, e.g. https://gwt.googlesource.com/gwt/+/master/user/src/com/google/gwt/user/User.gwt.xml

-- J.

[Thomas Broyer]

DOCTYPE is part of XML so it shouldn't need much documentation, and is generally useless and harmful (that's a debate for other forums though). But some IDEs (Eclipse at least) use it for autocompletion, so feel free to use it (GWT won't care).

[Philippe Gonze]

Okay and Tnx for the DOCTYPE  answers.

Now something else...

ECLIPSE RELOAD GWT WEB SERVER - MEMORY NOT CLEARED.

With RC1, it was impossible to reload the web server using the eclipse plugin.

With RC2, it is possible again.

However, there is a major problem encountered during the reload: the memory used by the previous web server has not been cleared, and the 2 web server occurences 

seem to share a unique adress space (coexisting threads?). In our case, the second web server is then unable to load its normal working content....

I am unable to assume about the problem origin: GWT plugin ? Eclipse (neon) config ? Jetty config ? Would this be a GWT bug to be filled?

Anyway, this problem was not present with 2.7.

Below is part of the eclipse console trace, containing a load part and a reload part... Observe the lines reporting memory percentage (the server was launched with -Xmx2000m).

Hope it helps.

Best regards to all.

Fil.

Running CodeServer with parameters: [-noprecompile, -port, 9876, -sourceLevel, 1.8, -bindAddress, 127.0.0.1, -launcherDir, /home/pge/javaNB4projects/gwtPBP/war, -logLevel, INFO, -style, OBFUSCATED, mscp.gwt.pbp.GwtPBP]

Super Dev Mode starting up

   workDir: /tmp/gwt-codeserver-4597875986963250914.tmp

2016-08-13 15:56:24.325:INFO::main: Logging initialized @3463ms

   Loading Java files in mscp.gwt.pbp.GwtPBP.

   Ignored 2 units with compilation errors in first pass.

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

   Module setup completed in 4879 ms

2016-08-13 15:56:27.534:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT

2016-08-13 15:56:28.156:INFO:oejsh.ContextHandler:main: Started o.e.j.s.ServletContextHandler@9c251b{/,null,AVAILABLE}

2016-08-13 15:56:28.172:INFO:oejs.ServerConnector:main: Started ServerConnector@1851946{HTTP/1.1}{127.0.0.1:9876}

2016-08-13 15:56:28.173:INFO:oejs.Server:main: Started @7311ms

The code server is ready at http://127.0.0.1:9876/

Code server started in 5.866 s ms

2016-08-13 15:56:28.352:INFO:oejs.Server:main: jetty-9.2.z-SNAPSHOT

INFO[3:56:30][S]PolyTED/

INFO[3:56:30][S]PolyTED/ContextInitialize... PolyTED V=11a

INFO[3:56:30][S]PolyTED/User init

INFO[3:56:30][S]PolyTED/User init done: 25 users 20 companies

INFO[3:56:30][S]PolyTED/initData start on server MMM DVP=true

INFO[3:56:30][S]PolyTED/initData 1003 nodes 244 attribs 2011 nuts 9454 cpv

INFO[3:56:30][S]PolyTED/Docu file loaded (dat) 508

INFO[3:56:30][S]PolyTED/Docu file loaded (typ) from ? to ?

INFO[3:56:31][S]PolyTED/Docu file loaded (lng) 975413

INFO[3:56:31][S]PolyTED/Docu file loaded (lnk) 255427/355692

INFO[3:56:32][S]PolyTED/Memory [11%M] after docuFile.reload()

INFO[4:05:06][S]PolyTED/Tracing started in /media/Shared/webApp/db/PBP/trace/trace.dvp.MMM.13.8

[...]

Reloading web app to reflect changes in /home/pge/javaNB4projects/gwtPBP/war

2016-08-13 19:23:40.167:INFO:oejs.ServerConnector:Thread-1: Stopped ServerConnector@1d0cfd6{HTTP/1.1}{127.0.0.1:8888}

INFO[7:23:40][S]PolyTED/ContextDestroy... 

INFO[7:23:40][S]PolyTED/ContextDestroyed

INFO[7:23:40][S]PolyTED/DataControl: thread exit

2016-08-13 19:23:40.180:INFO:oejsh.ContextHandler:Thread-1: Stopped c.g.g.d.s.j.WebAppContextWithReload@135ff34{/,file:/home/pge/javaNB4projects/gwtPBP/war/,UNAVAILABLE}{/home/pge/javaNB4projects/gwtPBP/war}

2016-08-13 19:23:40.185:INFO:oejs.Server:Thread-1: jetty-9.2.z-SNAPSHOT

INFO[7:23:42][S]PolyTED/

INFO[7:23:42][S]PolyTED/ContextInitialize... PolyTED V=11a

INFO[7:23:42][S]PolyTED/User init

INFO[7:23:42][S]PolyTED/User init done: 25 users 20 companies

INFO[7:23:42][S]PolyTED/initData start on server MMM DVP=true

INFO[7:23:42][S]PolyTED/initData 1003 nodes 244 attribs 2011 nuts 9454 cpv

INFO[7:23:42][S]PolyTED/Docu file loaded (dat) 508

INFO[7:23:52][S]PolyTED/Docu file loaded (typ) from ? to ?

INFO[7:23:52][S]PolyTED/Docu file loaded (lng) 975413

INFO[7:23:52][S]PolyTED/Docu file loaded (lnk) 255427/355692

INFO[7:24:00][S]PolyTED/Memory [74%M] after docuFile.reload()

Le vendredi 12 août 2016 03:25:18 UTC+2, Daniel Kurka a écrit :

[steve Zara]

This is great news.  Thanks for all the hard work.

[Alexander Polunochev]

Hi Daniel,

Link to download SDK on the official page still points to RC1.

http://www.gwtproject.org/download.html

[James Horsley]

I saw there were some commits to master after RC2 was cut. Are there plans to cut an RC3 or just roll those commits into the GA?

--
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 post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

I saw there were some commits to master after RC2 was cut. Are there plans to cut an RC3 or just roll those commits into the GA?

GA will likely be done from master branch. Maybe it becomes a branch then, because of upcoming GWT 3.0 changes and the fact that 2.8 will be maintained in parallel.

-- J.

[Philippe Gonze]

"the fact that 2.8 will be maintained in parallel. (Jens)  " !?!

We would certainly appreciate to know more about this fact (announced? published? where?).

As a matter of fact, if version 3.0 is in line with various statements read here and there on the web (disparition of widget library, disparition of RPC), we would certainly prefer version 2.8.x to any 3.dead versions !

We think the 2.8 branches will continue to attract more developers than the 3.x branches.

But in any case, the first need is a fair vision of the future of GWT. Something like an 'official' statement, or at least a target roadmap.

If both branches are maintained (hopefully), we suggest a better version naming. Version 3.0 should receive a radically different name, and version 3.0 should succeed to 2.8 on the 'classic' branch...

Best regards to the GWT developers.

PG

[Jens]

"the fact that 2.8 will be maintained in parallel. (Jens)  " !?!

We would certainly appreciate to know more about this fact (announced? published? where?).

Its just a logical consequence of GWT being open source and lots of large apps/companies depend on it. As long as people use GWT 2.8.x they will fix stuff in it if something is broken. However it also means you might need to step up yourself and provide a patch in order to have something fixed.

And because GWT is aware of it, 2.8 will either become a long living branch or the next version based around J2CL will be developed in a new repository. 

-- J.

[Thomas Broyer]

On Tuesday, August 23, 2016 at 3:39:26 PM UTC+2, Philippe Gonze wrote:

"the fact that 2.8 will be maintained in parallel. (Jens)  " !?!

We would certainly appreciate to know more about this fact (announced? published? where?).

One year ago: https://docs.google.com/document/d/1iOd8u4YFyKC82GA4M_0suMcUeOLFeDHcEfP1ymclTFs/edit

(and you can read echoes of it many times here since then)

 

As a matter of fact, if version 3.0 is in line with various statements read here and there on the web (disparition of widget library, disparition of RPC), we would certainly prefer version 2.8.x to any 3.dead versions !

We think the 2.8 branches will continue to attract more developers than the 3.x branches.

But in any case, the first need is a fair vision of the future of GWT. Something like an 'official' statement, or at least a target roadmap.

There's no such thing yet.

 

If both branches are maintained (hopefully), we suggest a better version naming. Version 3.0 should receive a radically different name, and version 3.0 should succeed to 2.8 on the 'classic' branch...

See also https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/s_kX17Xs1S4

Reality is that most of the work is done by Google, and Google wants to move on to a new compiler (J2Cl). If Google no longer works on the GWT 2.x compiler, GWT 2.x is going to die, as I can't see anyone putting enough energy to make it live.

Because “GWT 3.0” is going to be based on J2Cl, which removes GWT.create(), this is going to be a breaking change no matter what. This is why it'd been decided that the 2.x branch would be maintained in parallel to the 3.x branch, but it'll likely only remain a "maintenance branch" (understand: bug fixes, but I believe you can kiss goodbye to any JDT upgrade, so no Java 9 for you; and probably no new Java 8 emulated APIs –think java.time et al. unless they come before real work on 3.x has begun), mostly there so that people have time (2 years? maybe more) before switching to GWT 3.0.

That being said, "GWT 3.0" will likely be a "bundle" of various projects (similar to the Eclipse bundles released every year): J2Cl, the Java Runtime Emulation library (unless it comes with J2Cl), Elemental, etc. see also https://groups.google.com/forum/#!topic/google-web-toolkit-contributors/uhSgR5CWBK8 (as you can see, nothing's clear yet, so no "official statement" or "target roadmap"), and as such Google likely will never use "GWT 3.0" per se, that one really being a community-lead project.

For now, Google needs to make an MVP of their new compiler and make its sources public; then only we can start talking about what GWT 3.0 might look like, built around that new compiler, and start really testing things against it; in the meantime all we can do is handwave, throw FUD, or more constructively prepare for the inevitable demise of GWT.create(), particularly for those features that Google does not use themselves (they will "port" the ones they use), and all third-party projects. Work has begun already for a few of these things.

[pg]

Tnx Thomas for this detailed and valuable answer.

For software creators of my generation (born 1956), the immensely attractive argument of GWT was : "you can create WEB apps (complex and powerfull web apps) by just using the best langage you ever used : Java, and all the formal benefits behind Java (OO thinking was the key turn in software history, and Java is the most usable effect of that). 

THAT ("Only Java") made GWT a brillant approach. Developers like me are not interested in technologies, langages, etc... per se: we just want the most powerful tools to turn conceptualization process into running software, with minimal technology concerns. Learning new technogies is "wasted time" if it does not help on that.

Hearing that 3.0 will be a "bundle", our key concern is "How many technologies should we (learn?) mix and organize to work together?". Knowing from my experience that technology mixing => unpredicable inconsistencies incompatibilities, probable interferences, or unclear bug responsability, I am rather skeptical about this evolution.

I see GWT as a promising path facing now a dead end road. Disappointing. Just hoping that the 2.8.x branch will survive  10 years....

Anyway thanks again for your explanations Thomas.

PG

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/udNQeQ6cK8A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.

To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

---

---

Philippe Gonze Address: Rue de la bruyère 12 / 1428 Lillois / BE Phone : 00.32.473580758 Skype : matscape www.gonze.org

---

---

[Thomas Broyer]

On Wednesday, August 24, 2016 at 4:38:51 PM UTC+2, Philippe Gonze wrote:

Hearing that 3.0 will be a "bundle", our key concern is "How many technologies should we (learn?) mix and organize to work together?".

Currently, GWT gives you a compiler with various linkers, emulation library, dev server(s), testing tool (GWTTestCase), and various libraries (i18n, dom, widgets, editors, places, activities, resources, uibinder, xhr, http, rpc, requestfactory, storage, etc.), all developed in a monorepo and shipped as a whole every other year.

Tomorrow, each bit would be developed separately (this is still unclear though, maybe it won't be the case and everything will stay the same as nowadays), at its own pace, with intermediate releases so you don't have to wait one year for a feature to be completed to finally have your fixes for other features (this is exactly the situation with 2.8: the goal was to ship with JsInterop, and it took a year to polish, and in the mean time we got Java 8 with stream emulation as well, but many bugfixes –like the nocache.js timestamp bug from 2.7, which was fixed a couple weeks after the release– had to wait this long to finally ship in a release); and every now and then, the dev team would pick the latest versions of each part, verify that they indeed work well together, fixing them when needed, and ship them as a whole: a bill of material of each components' version that are guaranteed to work well together, so you can choose to pick new versions of some components when you need a specific bugfix or feature, and wait for the "bundled release" for everything else; instead of using snapshots of the whole thing.

The big difference would be that the compiler, which currently builds "permutations", calls generators, transpiles, and optimizes (dead-code pruning/tree-shaking, minification, bundling) will be split into 4 parts: annotation processors run by your standard Java compiler (APT exists since Java 5, integrated into the Java compiler in Java 6; it's a stable technology), transpilation to ES6 through J2Cl, then compilation/optimization through Closure Compiler (or actually the tool of your choice), and "manual" permutations (AFAICT, i.e. you manually run the transpiler+compiler once for each locale you want to build for; permutations would likely go away for user.agent as browsers converge to being able to all run the same code with only few tweaks/checks here and there as needed). That transpiler/compiler split means that the compilation/optimization can take place not only on code transpiled from Java but also all your external pure-JS libraries (you'd currently have to copy/paste the lib into a JSNI method to have it optimized by GWT).

GWT could then also possibly come with additional tools to run everything in one go (except possibly annotation processing), just like you do today, instead of configuring all those steps into your build tool of choice (or maybe that will be left to the next-gen gwt-maven-plugin, gwt-gradle-plugin, et al.)

The goal of that "bundling" would be mostly (if not only) to make it as easy as it is today to use GWT, such that migration should be as easy as replacing all your GWT.create() calls with calls to generated classes; modulo deprecated/unported libraries, and other changes/tweaks needed to make things work (e.g. change an "extends SomeMarkerInterface" to an annotation, to trigger the corresponding annotation processor replacing a GWT generator).

But I repeat: this is all handwaving and hypotheses for now (and my very own point of view), only very few things are certain at this point in time. It's still too early to start worrying: 2.8 is still not released, and real work will only start after that, and not necessarily immediately after the release (there could actually be a 2.8.1 and 2.8.2 before the code is branched out for GWT 3, who knows?)

[Kirill Prazdnikov]

All that sounds very good.
Is there any place where I can read about j2cl ?
It source is closed, right ?

[Tony]

Hey

First off - thank you very much for all the work you are doing on GWT. It's great to see all the amazing things coming in 2.8.0. Thank you!

Now to the issue that I'm reporting:

I'm using the Google Plugin For Eclipse and my project is using GWT (gwt-2.8.0-beta1) and AppEngine (1.9.42). 

Since I upgraded to gwt-2.8.0-rc1 (or rc2) I can no longer run the local dev server. The server starts but when I bring up the app in the browser I get an error saying that the code server is not available (full error message: "Couldn't load testserver1 from Super Dev Mode server at http://127.0.0.1:9876. Please make sure this server is ready. Do you want to try again?"). 

In the console, on the eclipse side, I get this error message: 

java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getHeader(Ljava/lang/String;)Ljava/lang/String;

(plus the stack trace)

as well as:

java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.isAsyncStarted()Z

(plus the stack trace).

I'm assuming that these errors are caused by the fact that the codeserver in RC1 and RC2 requires Servlet 3.0 and I'm running (as part of the Google Plugin for Eclipse) jetty-6.1.x which provides Servlet 2.5. 

What I don't understand is why is this setup working fine with gwt-2.8.0-beta1 but it is not working with gwt-2.8.0-rc1 or gwt-2.8.0-rc2. 

Thanks for the help

Tony

[Jens]

What I don't understand is why is this setup working fine with gwt-2.8.0-beta1 but it is not working with gwt-2.8.0-rc1 or gwt-2.8.0-rc2. 

Jetty has been upgraded from 8.x to 9.2.x between beta1 and rc1. Maybe your class path order is now different for some reasons and you need to rearrange it a bit so that servlet 2.5 isn't on class path first.

The correct solution is to separate your client / server code into distinct projects and launch them independently each with their own class path.

-- J.

[Tony]

Thank you J! I didn't know jetty was upgraded and yes I did mess up the order & export. once I moved the GWT SDK above the App Engine SDK... all worked well. 

Yes, I'm aware we need to decouple the client/server but we're a few releases away from that. We're still using GWT RPC and a few other things that we need to do away with. 

Thx again.

Tony

[Thomas Broyer]

First, you don't *have* to split your project, you have to *run* them separately (but then you'll probably have to tweak the classpath of each a bit).

Then, GWT RPC isn't a blocker for splitting your project (see my modular-webapp archetype at https://github.com/tbroyer/gwt-maven-archetypes)

[Василий Старцев]

Great! But there is a bug:

com.google.gwt.i18n.client.impl.cldr.DateTimeFormatInfoImpl_ru still have wrong weekdays order.

@Override
public String[] weekdaysFull() {
  return new String[] {
      "воскресенье",
      "понедельник",
      "вторник",
      "среда",
      "четверг",
      "пятница",
      "суббота"
  };
}

should be 

@Override
public String[] weekdaysFull() {
  return new String[] {
      "понедельник",
      "вторник",
      "среда",
      "четверг",
      "пятница",
      "суббота",
      "воскресенье"
  };
}


Please fix this.

[Thomas Broyer]

weekdaysFull starts on Sunday: https://github.com/gwtproject/gwt/blob/caf2f6fa9a35a2602ea7b16426473dd9fcc92cea/user/src/com/google/gwt/i18n/shared/DefaultDateTimeFormatInfo.java#L333-L343

and Google Translate tells me воскресенье (which you switched from the first to the last position) is Sunday, and thus should be first here.

So I see no bug there.

BTW, you employed the word "still", but this had never been reported; and the proper way to report a bug is to file an issue on the issue tracker on GitHub: http://www.gwtproject.org/makinggwtbetter.html#issuetracking

 

[Василий Старцев]

sorry for my english)

In russia week starts with Monday (Понедельник)

Such a difference leads me to use workarround instead of LocaleInfo.getCurrentLocale().getDateTimeFormatInfo()

This case makes me in big disapointment: I run this code on JDK8

DateFormatSymbols symbols = new DateFormatSymbols(new Locale("ru"));

for (String day : symbols.getWeekdays()) {

    System.out.println(day);

}

and got

воскресенье

понедельник

вторник

среда

четверг

пятница

суббота

It's totally wrong!

To be more preciese here is my use case: in GWT UI ComboBox with names of week days and my users are Russians and they used to use weeks with Monday as a first day.

The ideal solution is to fill this ComboBox with values from LocaleInfo.getCurrentLocale().getDateTimeFormatInfo().weekdaysFullStandalone() bot no way.

The order of week days in Russian is such as in Ierald locale en_IE example

пятница, 9 сентября 2016 г., 17:42:20 UTC+3 пользователь Thomas Broyer написал:

[Thomas Broyer]

The arrays are normalized to start on Sundays (you'd find the same oddity with the French locale, as weeks start on Monday too in France), you need to use firstDayOfTheWeek and adjust your indexes accordingly:

for (int i = 0; i < 7; i++) {
….weekdaysFull()[(i + ….firstDayOfTheWeek()) % 7)];
}

http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/shared/DateTimeFormatInfo.html#firstDayOfTheWeek()

[Василий Старцев]

Hmm. This is help. Thank you.

[Patrick Tessier]

I'm upgrading from 2.7 to 2.8.1 now, but it seems I'm running into the same issue as Tony.  I'm using AppEngine on the server side, which is in the same IntelliJ/Maven module as the GWT code.  When launching devmode from IntelliJ, I get "Couldn't load project from Super Dev Mode server at...", with HTTP 500 "

java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getHeader(Ljava/lang/String;)Ljava/lang/String;"
on the codeserver.

I was convinced that I could rearrange the GWT/AppEngine dependencies in the IntelliJ module and
 get it working, but that appears to not be the case.  So I assume that to *run* them separately
 would have to mean splitting the client and server sides into separate pom.xml within the project
and splitting the dependencies. Correct?

Thanks

[Thomas Broyer]

Have a look at https://github.com/gwtproject/gwt/tree/master/samples/mobilewebapp, we haven't had issues with AppEngine and GWT in the same Maven module (even though I discourage such usage).