Feature suggestions for the next GWT release

[Konstantin Solomatov]

Hello,

Today on the meeting Ray mentioned that it would be nice if every member of the committee proposes his list of features for the next release.

Here is my list:

• Support for Java 8 features. I think this is a no brained for almost everybody. However, AFAIU, eclipse compiler doesn't have support for it and it won't have it in the near future. I can propose the following solution for this problem. At JetBrains we extracted code parsing/resolving manipulation stuff so that it can be used separately from IntelliJ (It's used by Kotlin language). This code already supports Java8.
  

These are more controversial features:

• Support for Reflective features. Despite the fact that GWT code generation can be used as a way for meta programming, there's are several problems with it: it's a GWT only solution, i.e. it's hard to use it if my code is run, for example on GWT and Android. We shouldn't support full reflection API, for example, if we add support for Class.isInstanceOf and Class.newInstance, it will improve our life substantially and it seems to me that such an improvement is quite easy to implement. We also might add support for dynamic proxies.
• Better JRE emulation library. I.e. more methods and classes from JRE. The most painful part is working with dates. We created our own date manipulation library to make this easier.
• Support for Plugin systems. Now, if we want to create a plugin system for GWT application, we have to expose application API through Javascript, and to use it from another GWT application, we have to wrap it again. This is quite an inefficient, we have to clone GWT library every time we create a plugin, it involves a lot of extra work, etc. 
• Support for other languages. One of the greatest things that we have in GWT is Java compatible standard library. It can be used if we want to port JVM based language to GWT (for example, Scala or Kotlin). I know that there's a Scala+GWT project (http://scalagwt.github.com/). They modified Java parser a little so that, the source language is a better target for code generation than Java. May be we should expose some API for such cases?

What do you think about it?

Regards,

Konstantin

[Thomas Broyer]

On Friday, December 14, 2012 9:34:52 PM UTC+1, Konstantin Solomatov wrote:

Hello,

Today on the meeting Ray mentioned that it would be nice if every member of the committee proposes his list of features for the next release.

It's an appropriate time for a letter to santa [1] but I actually don't have high expectations/needs.

• Should I mention moving to a build system with managed dependencies (Maven) and modularizing GWT? Sounds like a given.
• I obviously want to see a better SuperDevMode (including more IncrementalGenerators) and compiler, and I know Google is working on it.
  
• Get rid of long-deprecated APIs (listeners anyone?) and possibly deprecate a few things (definitely replace c.g.g.event.shared with web.bindery.event, c.g.g.user.client.Element and at least parts of c.g.g.user.client.DOM)
• Make Editors and RequestFactory better: relax a few constraints and of course fix bugs. I'm eager to see what Google made with Cloud Endpoints and generating JsonRpc/RF client code from a "discovery" file.
• Java 7 (strings-in-switch and multi-catch would easily map to JS, and the other syntactic sugars –diamond, underscore in numeric literals– would be nice, I don't think try-with-resource or binary literals would be of much use in client-side code, but they don't cost that much to implement); on the longer term, of course Java 8 (including JSR310 emulation!), but we're not there yet.
• Did I mention JSR310?
• I'd love to see javax.json and JAX-RS 2.0 client API, "just because". I haven't looked at Errai in details yet but I suppose JBoss would work on JAX-RS 2.0 once it's finalized, and javax.json looks a lot like element.json, but javax.json also has a JsonGenerator to directly generate JSON as a String (strangely the API doesn't deal with Appendable or StringBuilder, only with Writer which we would have to emulate along with a StringWriter)

It won't surprise anyone if I say I'm volunteering on the RF/Editor front, and I'll happily help with deprecating things and removing the old-deprecated ones (hey, we already got rid of GWTShell and its dependency on Tomcat!), and emulating JSR310.

[1] OK, that pun probably doesn't translate well from French, see http://forum.wordreference.com/showthread.php?t=1302898 for more context

Here is my list:

• Support for Java 8 features. I think this is a no brained for almost everybody. However, AFAIU, eclipse compiler doesn't have support for it and it won't have it in the near future. I can propose the following solution for this problem. At JetBrains we extracted code parsing/resolving manipulation stuff so that it can be used separately from IntelliJ (It's used by Kotlin language). This code already supports Java8.
  

Are you proposing switching from ECJ to that JetBrains parser?

These are more controversial features:

• Support for Reflective features. Despite the fact that GWT code generation can be used as a way for meta programming, there's are several problems with it: it's a GWT only solution, i.e. it's hard to use it if my code is run, for example on GWT and Android. We shouldn't support full reflection API, for example, if we add support for Class.isInstanceOf and Class.newInstance, it will improve our life substantially and it seems to me that such an improvement is quite easy to implement. We also might add support for dynamic proxies.
• Better JRE emulation library. I.e. more methods and classes from JRE. The most painful part is working with dates. We created our own date manipulation library to make this easier.

JSR310! ;-)

[Konstantin Solomatov]

Are you proposing switching from ECJ to that JetBrains parser?

I don't know the code well enough to propose such changes. I'm just making everybody aware that there's a reusable high level code parsing library which already support Java8.

[Stephen Haberman]

> - Support for Java 8 features. I think this is a no brained for

> almost everybody. However, AFAIU, eclipse compiler doesn't have
> support for it and it won't have it in the near future.

Pragmatically, given many GWT programmers use Eclipse to write code, it
would not be very useful for them if GWT could understand Java 8 stuff,
but their IDE couldn't actually compile/type-assist/etc. it.

Granted, there are other IDEs around, but I would think Eclipse should
be caught up by the time Java 8 becomes sufficiently interesting to GWT.

However, if not, it's good to know we have alternatives.

> Support for Reflective features.

Yes, that is controversial. :-)

> Support for other languages

Always a fan of this, but it requires a lot of coordination.

- Stephen

[Konstantin Solomatov]

On Sat, Dec 15, 2012 at 12:01 PM, Stephen Haberman <stephen....@gmail.com> wrote:

>    - Support for Java 8 features. I think this is a no brained for

> almost everybody. However, AFAIU, eclipse compiler doesn't have
> support for it and it won't have it in the near future.

Pragmatically, given many GWT programmers use Eclipse to write code, it
would not be very useful for them if GWT could understand Java 8 stuff,
but their IDE couldn't actually compile/type-assist/etc. it.

Granted, there are other IDEs around, but I would think Eclipse should
be caught up by the time Java 8 becomes sufficiently interesting to GWT.

However, if not, it's good to know we have alternatives.

Agree. Without the most of people being actually able to use the new features, adding them to GWT has little value.

BTW, I've taken a look at Google's compiler from Java -> ObjC (we've been doing a similar thing at JetBrains with JetBrains MPS which I led for several years), and seen that as opposed to GWT, it uses JDT tree which is higher level than Eclipse compiler's tree used by GWT. Did anyone think about migrating to this tree instead of compiler tree?

[Thomas Broyer]

It might have to do with performance, both at compile-time (batch) and
in DevMode (incremental; or maybe not IIUC what Stephen said in
GWT-contrib). GWT has been "patching" every version of ECJ/JDT to
reduce its memory footprint and make it faster.

--
Thomas Broyer
/tɔ.ma.bʁwa.je/

[Christian Goudreau]

I don't have a lot to add to what was already said, but there's still some HandlerRegistration reference that doesn't use the new bindery structure. ValueChangeHandler<T> being one. I know there's an issue open for that and since it seems fairly straightforward, I could do that alongside deprecating the old ones.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit Steering" group.
To unsubscribe from this group, send email to gwt-steering...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Christian Goudreau | CEO - Président

M: 1.877.635.1585 | S: christian.goudreau

ArcBees | Blog | Facebook | LinkedIn

[Stephen Haberman]

> GWT has been "patching" every version of ECJ/JDT to
> reduce its memory footprint and make it faster.

This is perhaps naive/obvious, but did the ECJ patch ever get submitted
upstream?

- Stephen

[Stephen Haberman]

Any thoughts on:

1. Serializing final fields in GWT-RPC (there is a patch ready that puts it
behind a flag).

Or, even better, removing the flag all together and just always
serializing final fields? (This is a semantic change, but makes the
code simpler, and to me is what release notes are for.)

2. Adding IsXxx widget interfaces.

Personally I find these very useful for MVP, since you can expose an
entire, say, IsTextBox, to a presenter instead of piecemeal
characteristic interfaces. I have both IsXxx interfaces and StubXxx
implementations for most widgets already in Tessell:

https://github.com/stephenh/tessell/blob/master/user/src/main/java/org/tessell/gwt/user/client/ui/IsTextBox.java

https://github.com/stephenh/tessell/blob/master/user/src/main/java/org/tessell/gwt/user/client/ui/StubTextBox.java

But would prefer moving them into GWT proper.

- Stephen

[Thomas Broyer]

That patch is about using com.google.gwt.dev.util.collect.HashMap instead of java.util.HashMap [1], so there's no way it's been upstreamed.

I have absolutely no idea how HashMap evolved in the JDK(s) and whether that class is still needed, and how ECJ/JDT has evolved and whether that patch would still be needed or new ones would be required.

I have a patch almost ready to move to JDT 3.8 so I guess Google could possibly try it and report on how it impacts compilation time and memory consumption.

Let's move that technical discussion to GWT-Contrib though.

[1] https://code.google.com/p/google-web-toolkit/source/detail?r=10869