Re: [gwt-contrib] Update on J2CL

['Ray Cromwell' via GWT Contributors]

>. This comment from Goktug: ..."*we use some tools that does code pruning
during build which helps some with the performance, and those tools are not
available for open source. Something we will eventually look at but not
very soon*" worries me. Is J2CL a 100% Java or you use other stuff that can
not be released?

The main difference between bazel and other build systems is that it is
built for an immutable view of code trees.   Bazel rules are perfectly
predictable from inputs to outputs, and this allows highly parallelized
builds and caching. Everything at Google is build from HEAD, not SemVer,
and so perfect cachability and deterministic build stability is important
for us.

Internally, we have "dev mode" interactive versions of the Closure Compiler
that can do lightweight pruning for rapid development, but these are tied
to internal infrastructure and specialized Bazel stuff that accumulates a
pruned JS-level dependency graph in parallel with the build targets.  So
it's not that it isn't written in Java (actually some of this stuff isn't),
but more that it's tied to internal build infrastructure, which is probably
overkill for external developers, and something much simpler, akin to
concatenating all your dependencies and running Webpack/Rollup style
pruning on it would be sufficient for development.

The nice thing about J2CL is writing this edit/refresh environments is far
far simpler than it was to do with GWT DevMode, as your IDE or build tools
can already do file watching/rebuild, whereas DevMode had the burden of
being an incremental build system unto itself.

-Ray


On Thu, Jun 14, 2018 at 3:50 PM Hristo Stoyanov 
wrote:

> Guys,
> Thanks for the update to J2CL! Here is what I understood, the questions I
> have - correct me, if I am wrong:
>
> 1. Google is seeing good results from J2CL in a number of products, so
> your internal funding won't be cut, J2CL won't be abandoned! That is good
> news!
>
> 2. J2CL itself is build with Bazel (for the reasons you mentioned). This
> would not matter much, *as long as you could push the J2CL artifacts to
> Maven Central in an automated (Bazel) pipeline*. *Can Bazel do that*?
>
> 3. Some GWT folks are developing Gradle and Maven plug-ins. *What is the
> status of those*? I think this is the most important thing - once the
> J2CL jars are in Maven central and the plug-ins ready, people can start
> building apps with J2CL?
>
> 4. This comment from Goktug: ..."*we use some tools that does code
> pruning during build which helps some with the performance, and those tools
> are not available for open source. Something we will eventually look at but
> not very soon" worries me. Is J2CL a 100% Java or you use other stuff that
> can not be released?*
>
>
> *5. I still don't quite understand why not dump everything J2CL on Gihub
> "AS IS" and let us sort it out?*
>
>
> *Also, It would be helpful if some of the developers who already received
> the J2CL code drop comment and clarify what needs to be finished from their
> point of view.*
>
>
> *As far as GWT3, I don't understand what is the value of it at all, maybe
> valuable time/resources can be spent on J2CL instead, once it is placed on
> Github*
>
>
>
> *Thanks. *
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/807613cc-5945-49c1-8f5e-205dd53f5dea%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

['Ray Cromwell' via GWT Contributors]

On Fri, May 19, 2017 at 5:45 AM, Learner Evermore <
learner.everm...@gmail.com> wrote:

> So... If I read this correctly... Google has discovered that GWT is not
> good enough (is bad) to continue using it. It is creating a J2CL that
> produces readable code so that it can completely abandon its original Java
> source and continue without it. The already slow involvement will turn into
> no involvement at all. In fact, there may be no incentive at all to release
> that J2CL ever - as soon as it becomes good enough for Google to have a bit
> manual work left on the generated code it won't need it any more. If we
> exclude Google, who does not plan any future with GWT, steering committee
> is composed of representatives from Vaadin, RedCurrent, RedHat, Bizo and
> JetBrains. I truly may be mistaken but, other than perhaps Vaadin, I don't
> see any company (that I am familar with) that does anything of large scale
> with GWT. and may not have too much interest in particular GWT future
> either.
>
>
No, Google is not converting all Java to JS to abandon Java, it's the exact
opposite. Google needs to support 4 platforms with it's code: Web, Android,
iOS, and Server. We share code by using Java. 60-70% of our code base is
Java, which we transpile to Objective-C with J2ObjC, run natively on
Android and the Server, and compile to the Web with GWT, and now J2CL.

But the Gmail team is 12 years old, we have a vast codebase that includes a
lot of JS. We did not want to reimplement all of our existing Gmail code in
Java and port all the widgets, nor did we want to recreate some kind of
portable UI between Android, iOS, and Web like React-Native. In our
opinion, the "Swing" approach leads to an Uncanny Valley effect, and the
best approach is to use "native" UI for each platform.

So for our hybrid apps, the business logic is Java, and the UI layer is a
mix of JS and Java, Objective-C and Java (iOS), or just Java (Android).

For this to work, we need very low impedance JsInterop, hence we created
the JsInterop spec, and added -XclosureFormattedOutput to GWT, so that we
could feed the output of GWT into Closure compiler along with JS libraries
and get a single, statically linked and optimized, output. This saved well
over 500k out of a 2mb JS when first implemented. It also yields
type-checking between JS code and Java, so if you make a typo or pass in a
wrong argument from JS or vice versa.

But GWT had three pitfalls:

1) It optimizes twice in this scenario, once during GWT compilation, and
again with Closure Compiler.
2) It creates a monolithic target. We don't want monolithic targets, we
want compose.js to only have to depend on a few Java files like
Compose.java. GWT code splitting does not offer deterministic fine grained
control over what lands in a JS module.
3) GWT "closure formatted output" is still very unfriendly to Closure, it
doesn't output interfaces, doesn't output any JsDoc, has weird conventions
around class setup and the way cast checks work.

J2CL addresses all of these, it stands for Java-to-Closure, like J2ObjC
stands for "Java to Objective C"
1) It works like Javac, it translates a file at a time, very fast, can
recompile as soon as you hit save in your IDE
2) It produces standard ES6/Closure modules, and fully typed, fully
conformant Closure inputs
3) It relies on standard Java mechanisms for generators and permutations
(System.getProperty()/@define in Closure and APT)
4) It uses the build system to define split points. If you say target ABC
in your build has Foo.java and Bar.java, then that JS target has those
outputs (unless Closure moves them for being unused)
5) It can interop with the entire JS ecosystem with little effort, you
could make Node JS modules from Java and deploy them via NPM if you were
inclined (it would take a little bit of hacking to remove the Closure
library dependencies tho). You could put Java into ReactJS/Native projects
if you want.

GWT does too much, conceptially it is

1) a build system that tries to manage dependencies and run code generators
2) a linking system for assembling deployable JS to serve
3) a Java to JS translator
4) a Java optimizer
5) a JS optimizing compiler
6) a giant SDK runtime

We have decided to break this apart into lots of module pieces and replace
what we're duplicating from existing ecosystems

1) use existing build systems to do what GWT is doing internally with it's
module system and dependency checking
2) A standalone Java to JS translator as a separate build step (J2CL)
3) A standalone JS optimizing compiler as a separate build step (Closure
Compiler)
4) a small runtime (JRE, Elemental2)
5) A good interop layer for tying this to any SDK runtimes you want
(Polymer, Angular, React, Ember, GWT SDK, etc)

We've done what you're asking in effect, which is to break GWT up into
modular pieces, you just don't like the fact that this creates
incompatibility. But the foundational pieces, when they land, can be used
by the community to reconstruct a G

Re: [gwt-contrib] Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

['Ray Cromwell' via GWT Contributors]

On Thu, May 18, 2017 at 5:20 PM, Learner Evermore <
learner.everm...@gmail.com> wrote:

>
>>
>> Yes, I am absolutely aware of that. That point is restricted to just
> interoperability whilst using Java syntax. GWT seems to be reducing what it
> can do with Java, not increasing.
>

I'm not sure I understand. If you use JSweet, it is very likely to break on
using libraries from the Java ecosystem, which breaks a huge value
proposition of using Java in the first place. It doesn't even support
static field initialization and class initializers with proper semantics
last time I checked. Someone who has learned Java will be very surprised at
weird failures in the pipeline. GWT has parts of the JRE it doesn't
support, but from a language level, it passes most of the JLS spec with
some exceptions around numerics, overflow checks. My advice is, if you need
a language with types and good IDE support that maps to JS, use TypeScript
or Kotlin. Kotlin every has a great Java interop/JVM ecosystem story and
amazing IDE support.


>
>
>> IIRC WebAssembly doesn't do much for GC collected languages. You are not
>> allowed to dynamically allocate heap objects, unless you implement your own
>> memory management. I don't know if TeaVM does this, but it is typically
>> only used for stuff like C++->JS transpiling. The TeaVM benchmark vs GWT
>> does not disable GWT's internal preconditions checks, I'd be curious to see
>> these re-run. Last time I looked, code size was larger for TeaVM, and for
>> web, code size tends to dominate subjective performance except in rare
>> cases like games or codecs.
>>
>>
> That is correct. TeaVM implemented GC in WebAssemblt for this purpose - it
> does its own memory management. Disabling GWT precondition checks may make
> it comparable to TeaVM (assuming it doesn't do this), not (significantly)
> better. TeaVM size is approximately equal between TeaVM and GWT.
>

I just checked the demos on Github, TeaVM's box2d demo loads 306kb of JS
(when uncompressed).  WebAssembly version is ~500kb uncompressed. The GWT
version is 148kb uncompressed. The J2CL Box2D demo we use internally, while
not strictly an apples-to-apples comparison, is 35kb uncompressed.


> TeaVM is also a whole program optimizer. It eliminates unused methods and
> performs inlining and minification, includes only needed code. Readable
> output may indeed be helpful but only in edge cases. Why should I care
> about readability of that if I develop in Java and want to debug in Java?
>

Yes, it's a whole program optimizer, but it's about 50% worse than GWT at
pruning, and a lot worse than J2CL + Closure Compiler and it doesn't
support code splitting.  Why should one care about readability? Because
besides source maps, it makes it much more transparent what's going on AND
it integrates with the rest of the ES6 module system very easily. Every
Java file can become a ES6 module, and any JS file can simple
require/import it as if it was any other hand-written JS. This makes it
very easy for JS programmers to work with it (Inbox.google.com is 60% Java,
40% JS). It makes Java more of a natural, first class member of a JS
ecosystem. If you like JSweet, this does the same thing, only much better.


>
> There's a possibility this could be done, but I think the community will
>> need to do it. I prototype Async/Await for GWT it a while ago (
>> https://plus.google.com/+RayCromwell/posts/cDVuTGccK3p) using Babel, but
>> these days, I'd use Closure Compiler's transformations. Nothing comes even
>> close to Closure's optimization ability.
>>
>
> Community can only do it if the foundation allows it.
>

The foundation allows it, but it's hacky. I showed how it could be done.
You can use a Generator + Linker combo to get async/await annotations in
the output, and then invoke BabelJS from the linker to transpile the ES7
async/await calls back into ES5.


>
>
>> Driving up the # of split points in GWT has pitfalls. GWT only creates on
>> shared fragment (the leftovers fragment) which will grow larger and larger.
>> It needs to create a tree of shared modules, like Closure Compiler works
>> with, or Malte Ubl's splittable's project.
>>
>
> It the current, flawed (in my opinion) implementation. It does not need to
> do it this way. With simulation of synchronous execution even of
> asynchronous server requests for more code any call can become a split
> point. anywhere... and we can let the developer quite literally choose how
> to split code. A lot less analysis needed upfront, even though it may be
> useful as an informational tool to the developer.
>

Yes, any call can be come a split point, and we do that at Google on
projects like photos.google.com, where every controller, every event
handler, every widget, or every data request is a split point. But GWT
doesn't support this, someone needs to significantly improve the
CodeSplitter in GWT to make this worthwhile, otherwise, it will made total
code size loaded in the first split point triggered worse.

Re: [gwt-contrib] Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

['Ray Cromwell' via GWT Contributors]

On Thu, May 18, 2017 at 9:29 AM Learner Evermore 
wrote:

>
>1. For perfect interoperability with JavaScript one can use JavaScript
>or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
>
>
Keep in mind that, last time I looked, JSweet is not really Java and can
only compile a much smaller subset of Java, it does not fully obey JLS
semantics.  i.e. can it compile Guava out of the box?


>1.
>2. For runtime performance of the code written in Java (via
>optimizations and otherwise), TeaVM seems to yield better performance than
>GWT with JavaScript output and also has experimental support for
>WebAssembly, which yields about double the performance on some tests I've
>seen. One could offer both options, to support browsers that can't do
>WebAssembly.
>
>
> IIRC WebAssembly doesn't do much for GC collected languages. You are not
allowed to dynamically allocate heap objects, unless you implement your own
memory management. I don't know if TeaVM does this, but it is typically
only used for stuff like C++->JS transpiling. The TeaVM benchmark vs GWT
does not disable GWT's internal preconditions checks, I'd be curious to see
these re-run. Last time I looked, code size was larger for TeaVM, and for
web, code size tends to dominate subjective performance except in rare
cases like games or codecs.


>1.
>2. In terms of tooling - GWT seems to, now, be the worst. Super Dev
>Mode proved to be essentially a failure because one does not really see the
>data that matches the code. Runtime performance still suffers and debugger
>often freezes for long periods of time doing who-knows-what if/when
>breakpoints are set or we're stepping through code. Coding in JavaScript
>directly means what-you-see-is-what you get and no wait times. Other
>solutions offer their custom tooling which seem to be possibly better, at
>least on paper (did not check, so cannot verify yet). JSweet and TeaVM
>translation is much faster than GWT is, even without GWT RPC. TeaVM does
>not require source code, which is better for companies who need to deliver
>a module but keep the source closed. GWT needs *both* source and 
> binaries...
>
>
GWT is not a translator, it's a whole program optimizer, that's why it's
slow. Google's next-gen J2CL compiler does transpilation to human readable
ES6 Closure annotated code.  (
https://qconnewyork.com/ny2016/ny2016/presentation/j2cl-future-gwt.html)
This is being deployed on inbox.google.com right now. Much faster
transpilation, since it operates like JSweet during development, but it
produces fully JLS compliant code.

>
>1. Simulate synchronicity even for what would be, under the hood,
>asynchronous calls. See TeaVM for how multithreading is supported in it,
>Thread.yield() and related. We know why things must be asynchronous in
>JavaScript, but that does not mean that this has to be exposed as such in
>the Java world - a Java method could "block" at a call only to continue
>when a relevant event is triggered. This would go a long way to simplifying
>the code and increasing how much code can be shared between the client and
>the server without exposing the server to unnecessary asynchronicity or the
>client with synchronous methods that may/will not work.
>
>
>1.
>
> There's a possibility this could be done, but I think the community will
need to do it. I prototype Async/Await for GWT it a while ago (
https://plus.google.com/+RayCromwell/posts/cDVuTGccK3p) using Babel, but
these days, I'd use Closure Compiler's transformations. Nothing comes even
close to Closure's optimization ability.


>
>1.
>2. Doing the above will let you improve code splitting as you will be
>able to load code at any point, not just at GWT.runAsync() points. It will
>open up other possibilities of driving how the code is split - e.g. perhaps
>per module, project or package.
>
>
Driving up the # of split points in GWT has pitfalls. GWT only creates on
shared fragment (the leftovers fragment) which will grow larger and larger.
It needs to create a tree of shared modules, like Closure Compiler works
with, or Malte Ubl's splittable's project.


>
>1.
>2.
>3. If you are so hung up on removing GWT RPC, do so, but provide the
>means to replace all of its functionality externally, especially
>serialization. This is possible in TeaVM with its "Metaprogramming API".
>Arguments that "it is hard" are not helpful and "I don't need it" may apply
>to a class of users who really don't need GWT at all or are not creating
>very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but
>allowing matching OWN client and server code to communicate. Do include the
>means to store discovered relationships so that they don't have to be
>discovered again. Allow polymorphic serialization one way or another via
>specific annotations. Whether done internall

Re: [gwt-contrib] Re: JsInterop & collections

['Ray Cromwell' via GWT Contributors]

I think it would be better to use a JsArrayListAdapter in order to prevent
making copies all over the place, and also making mutations write-through
on both sides e.g.

public class JsArrayListAdapter extends AbstractList {
   public JsArrayListAdapter(ArrayLike blah) {
  this.array = blah;
  }

  // implement List methods to delegate to Array methods
}

To keep referential integrity, you need to use an expando or ES6 Symbol
property to hide a backreference.

That is, JsArrayListAdapter.wrap(nativeJsArray) ==
JsArrayListAdapter.wrap(nativeJsArray2) IFF nativeJsArray == nativeJsArray2.

This technique is less error prone IMHO if you are going to have mutable
objects. If you're using immutables, then making copies is superior.





On Tue, May 9, 2017 at 3:24 PM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Yes, theoretically you should be able to use the second parameter on
> Json.parse Json.stringify for conversion back and forth between java
> collections and js primitives. In this model, your javascript code needs to
> use Java collection APIs.
>
> > java.util.Arrays.asList() should be enough
>
> keep in mind that Arrays.asList won't let you go out of bounds.
>
>
>
> > I believe it was in plans with @JsConvert
>
>
> We are not working on @JsConvert right now. JsConvert is just convenience
> and you can mimic it:
>
>
>   @JsType(isNative=true)
>   interface MyType {
>  @JsConvert(ListConverter.class)
>  List getMyArray()
>  void setMyArray(@JsConvert(ListConverter.class) List array)
>   }
>
> is roughly equivalent to:
>
>   @JsType(isNative=true)
>   interface MyType {
>  @JsProperty(name="myArray")
>  Object[] getMyArrayInternal();
>
>  @JsOverlay
>  default List getMyArray() { return Arrays.asList(getMyArray()); }
>
>  @JsProperty(name="myArray")
>  void setMyArrayInternal(Object[] array);
>
>  @JsOverlay
>  default void setMyArray(List list) {
>setMyArrayInternal(array.toArray());
>  }
>   }
>
>
> On Tue, May 9, 2017 at 9:32 AM, Thomas Broyer  wrote:
>
>>
>>
>> On Tuesday, May 9, 2017 at 4:34:48 PM UTC+2, Marcin Okraszewski wrote:
>>>
>>> There is indeed something in it. Actually you could have some type of
>>> naming convention, like in TJSON (
>>> https://tonyarcieri.com/introducing-tjson-a-stricter-typed-form-of-json)
>>> or TypedJson (https://www.npmjs.com/package/typed-json) to figure out
>>> proper types. But then I would need to create eg. ArrayList with the
>>> Manuel's trick (the asList() from Polymer). I'll test it.
>>>
>>
>> java.util.Arrays.asList() should be enough actually:
>> https://github.com/gwtproject/gwt/blob/2.8.1/user/super/com/google/gwt/emul/java/util/Arrays.java#L136
>> (note that the ArrayList there is not java.util.ArrayList, it's an internal
>> java.util.Arrays.ArrayList class that directly wraps the array with no
>> copy).
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/95e1bd43-b4a6-4b2d-bd89-6cc6fb206631%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0Wr0pWKUcqyN2YMkuoZZK7b3e-ipm7jqv2DdDeqk8sMA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] Re: JsInterop & collections

['Ray Cromwell' via GWT Contributors]

The adapter class adds overhead though and you need to convert into and out
of it every time you pass it to JS. At that point you may as well use
Java.util.List and write an adapter around JS array.


On Mon, May 8, 2017 at 7:10 AM Jens  wrote:

> IMHO if you want a JavaScript array, set, map behave the same as a Java
> collection, so you can use it with other libraries, you should write an
> adapter class that implements the Java API and operates internally on the
> JavaScript data type.
>
> Basically do not rely on invisible magic. That could easily be implemented
> as a 3rd party project.
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/4d08f88c-ec88-4818-b778-3e0e247f2e7e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eX8PrDNzesa%2Ba-LrB6Y5FEW61Zu1O9Rzatapm72CWgOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Size of output is little large

['Ray Cromwell' via GWT Contributors]

FYI: https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS


On Tue, Dec 13, 2016 at 10:23 AM, Colin Alworth  wrote:
> Class literals for any object which can be created need to exist for
> getClass(), which is called by toString() at the very least - if the
> compiler sees any Object.toString, it must leave in all getClass methods -
> further reasoning about that might be tricky, and is a little out of my
> wheelhouse. If memory serves, class literals are harder to prune since they
> can be used in split points (though the class literals must exist in the
> original split point).
>
> The vars __gwt_stylesLoaded and __get_scriptsLoaded are part of the linker's
> communication with the main page, and how the linker defines what other
> resources it has grabbed up from the .gwt.xml file. $stats serves a similar
> purpose, it is one of several ways for the page to communicate with the
> module and vice versa. A custom linker can be written by forking one of the
> existing ones to remove these or simplify them if you never will have a use
> for them and really must save a dozen or so bytes each. Since there are a
> fixed set of these, it is a constant overhead, and won't grow as your
> application grows. These can't be optimized out without knowing how you will
> end up using the GWT app from the host page, which by definition isn't
> compiled as part of the app.
>
> I *believe* that the useless if statement you showed will be optimized out
> if you avoid PRETTY and do a normal compile, but I am not totally certain -
> clinits do seem to interfere with some optimizations of dead code. I'm
> looking into a way to deal with some of these cases, will post back within a
> few weeks if I am successful (and have time). As before though, simply
> depending on Core instead of User will avoid this entirely.
>
> If you are really after saving individual bytes, especially if you only have
> a single permutation, do look at building your own linker, and depending
> only on Core directly (and skipping the UserAgent module), and possibly
> rebinding some of these generated classes to do nothing.
>
> On Tuesday, December 13, 2016 at 10:17:41 AM UTC-6, Kirill Prazdnikov wrote:
>>
>> Hello,
>>
>> Thanks for the explanation,
>>
>> > value="false"/>
>>
>>
>> did the job, and removed
>> "$wnd.setTimeout($entry(assertCompileTimeUserAgent));" at the entry point.
>>
>>
>> But document.compatMode.severity=IGNORE did not change anything in code
>> generation, it still generates
>>
>>
>>> severity = ($clinit_DocumentModeAsserter$Severity() , IGNORE);
>>> if (severity == IGNORE) {
>>> return;
>>> }
>>
>>
>> It is unclear for what reason GWT generates (and never uses in the
>> generated code):
>>
>>
>>> if (!$wnd_0.__gwt_stylesLoaded) {
>>>   $wnd_0.__gwt_stylesLoaded = {};
>>> }
>>> if (!$wnd_0.__gwt_scriptsLoaded) {
>>>   $wnd_0.__gwt_scriptsLoaded = {};
>>> }
>>
>>
>>
>> It also would be very nice to remove that:
>>
>>
>>>
>>> function isHostedMode() {...} if (isHostedMode()) { alert(...); }
>>
>>
>>
>> And I see a lot of never used variables in the generated code, ex:
>>
>>
>>> var Lcom_google_gwt_core_client_impl_SchedulerImpl_2_classLit =
>>> createForClass(22);
>>> var onBodyDoneTimerId = setInterval(function () { 
>>> var $gwt_version = "2.8.0";
>>> var $stats = $wnd.__gwtStatsEvent ? function (a) { 
>>> var $strongName = '6D7BE6648CA01BEDC1B199CE04D6BBCD';
>>> var
>>> Lcom_google_gwt_core_client_impl_StackTraceCreator$Collector_2_classLit =
>>> createForClass(37);
>>> var
>>> Lcom_google_gwt_core_client_impl_StackTraceCreator$CollectorLegacy_2_classLit
>>> = createForClass(18);
>>> var
>>> Lcom_google_gwt_core_client_impl_StackTraceCreator$CollectorModern_2_classLit
>>> = createForClass(19);
>>
>>
>> Is it an issue that the GWT generates never-used variables ?
>>
>>
>> Thanks
>>
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/19737425-edc4-47c7-8eab-e78d070f7c51%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ecKXsH6CK%3DxU%3DrvN93m2O619jX_xQuEH9WD4q2c3dbzg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

['Ray Cromwell' via GWT Contributors]

Is the underlying object actually an ArrayBuffer? The return value is
supposed to be either an ArrayBuffer or a String depending on how you
invoke the reader API.

It seems to me that any methods which might throw CCE because of this
should actually return null, e.g.


class FileReader {

  public @JsOverlay ArrayBuffer getArrayBufferResult() {
 Object result = getResult();
 return result instanceof ArrayBuffer ? (ArrayBuffer) result : null;
  }

  public native Object getResult();
}


On Sat, Aug 6, 2016 at 7:08 PM, Luke Last  wrote:
> What's the best way to type cast objects? I get a ClassCastException in
> super dev mode with the following.
>
> ArrayBuffer ab = (ArrayBuffer) fileReader.result;
>
> The exception stems from com.google.gwt.lang.Cast#castToNative
>
> If I use JSNI to perform the cast it works fine.
>
> Thanks for working on Elemental2. I think it's super important for GWT.
> -Luke
>
>
> On Wednesday, June 29, 2016 at 8:23:51 PM UTC-4, Julien Dramaix wrote:
>>
>> A new experimental version of Elemental2 using the new JsInterop
>> specification has been pushed on Sonatype today.
>>
>>
>> You can try it by downloading the jar file or adding this following maven
>> dependency:
>>
>>
>> 
>>
>>  com.google.gwt
>>
>>  elemental2-experimental
>>
>>  16-06-30
>>
>> 
>>
>>
>> Then, inherits the elemental2 module:
>>
>>
>> 
>>
>>
>> This experimental version works only with the last 2.8-snapshot release of
>> GWT.
>>
>>
>> The goal of this release is to get feedback so don’t hesitate to report
>> any bugs, issues, concerns you have on this mailing list.
>>
>>
>> Important note: This is an experimental release and without doubt the
>> future updates until the final release are going to break code!
>>
>>
>> - Julien
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e0b5ae3d-e987-40e4-9d70-dfde08f1ffc2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ekncp%2Bkd1dqnzf5%3DedFyxm5XMTFw32wa7Qh7Fu2%2BaUKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Experimental release of Elemental2

['Ray Cromwell' via GWT Contributors]

should be able to make this a little tighter:

button.addEventListener("click", (evt) -> {
button.parentNode.removeChild(button); alert("Button has been
removed."); });

:)


On Thu, Jun 30, 2016 at 4:16 AM, Julien Dramaix
 wrote:
> I'll try to find some time next week for uploading examples on my github
> account.
>
> A simple example could be:
>
> package elemental.sample.simple;
>
> import static elemental2.Global.alert;
> import static elemental2.Global.document;
>
> import com.google.gwt.core.client.EntryPoint;
>
> import elemental2.Event;
> import elemental2.EventListener;
> import elemental2.HTMLButtonElement;
>
> public class SimpleApp implements EntryPoint{
>   public void onModuleLoad() {
> final HTMLButtonElement button = (HTMLButtonElement)
> document.createElement("button");
> button.textContent = "Click me";
> button.addEventListener(
> "click",
> new EventListener() {
>   @Override
>   public void handleEvent(Event evt) {
> button.parentNode.removeChild(button);
> alert("Button has been removed.");
>   }
> });
> document.body.appendChild(button);
>   }
> }
>
> Elemental2.Global can be considered as the entry point of the library. It
> gathers all methods/fields available from the global scope (but not the
> window API).
>
> On Thu, Jun 30, 2016 at 12:15 PM Matic Petek  wrote:
>>
>> Hi,
>>   I would be nice If you could publish simple example how to start using
>> it.
>> Regards,
>>Matic
>>
>> On Thursday, June 30, 2016 at 2:23:51 AM UTC+2, Julien Dramaix wrote:
>>>
>>> A new experimental version of Elemental2 using the new JsInterop
>>> specification has been pushed on Sonatype today.
>>>
>>>
>>> You can try it by downloading the jar file or adding this following maven
>>> dependency:
>>>
>>>
>>> 
>>>
>>>  com.google.gwt
>>>
>>>  elemental2-experimental
>>>
>>>  16-06-30
>>>
>>> 
>>>
>>>
>>> Then, inherits the elemental2 module:
>>>
>>>
>>> 
>>>
>>>
>>> This experimental version works only with the last 2.8-snapshot release
>>> of GWT.
>>>
>>>
>>> The goal of this release is to get feedback so don’t hesitate to report
>>> any bugs, issues, concerns you have on this mailing list.
>>>
>>>
>>> Important note: This is an experimental release and without doubt the
>>> future updates until the final release are going to break code!
>>>
>>>
>>> - Julien
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01963a7c-7972-4fd9-88ef-629d0a7bcbac%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5M5DQS--awYZ1bS8nHBu9po8Ne8JPY_ianrUjNZrSqyg%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7dPt6PdpYHVBfV%3Dru9br8qtCriAsTQgF%3DA2rH7OBsghrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental2 - What's the big secret?

['Ray Cromwell' via GWT Contributors]

Because Double, Boolean can now be used to get raw primitive numbers
and booleans as object references, the basic JS collections will work
out of the box.

The Elemental1 collections had one additional benefit in the sense
that there were pure-JRE implementations of interfaces. I don't think
Elemental2 will have interfaces for Array and Map, so it might be
worse exploring that, just so that someone can make JRE-only
implementations incase they want to write utility code upstream that
can run in either environment.



On Fri, Jun 17, 2016 at 12:39 PM, 'Goktug Gokdogan' via GWT
Contributors  wrote:
> Elemental2 is purely generated; doesn't have handrolled collection/json
> APIs. It uses closure extern files so you can investigate what will be
> available checking here:
>
> https://github.com/google/closure-compiler/tree/master/externs
>
> On Fri, Jun 17, 2016 at 8:18 AM, Thomas Broyer  wrote:
>>
>>
>>
>> On Friday, June 17, 2016 at 4:15:00 PM UTC+2, Paul Stockley wrote:
>>>
>>> The question I have is more general. What will the scope of Elemental 2
>>> be? Will it include collections and json support like elemental or will it
>>> be just an interface to browser API's?
>>
>>
>> With https://github.com/gwtproject/gwt/issues/9365 (not sure what it
>> actually means though, I might be wrong) and
>> https://github.com/gwtproject/gwt/issues/9364, I don't think you'd need
>> elemental.json anymore (given that String, Double and Boolean directly map
>> to JS String, Number and Boolean). The former might also remove the need for
>> elemental.util "collections".
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/43b64e81-7793-45f4-a532-a384ff6a6ece%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA08kebjZFpcya%3DUz_FvJO6tXx0rjTZfq8qX9CkFOycjww%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eJ0cdZYzHu8r2KtjtuRtNg3hWy8RwOdZFA0hMQ%3DOYTsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental2 - What's the big secret?

['Ray Cromwell' via GWT Contributors]

With these kinds of purely code generated APIs, I'd say trying to consume
it during development is not very useful. Every small change can lead to a
radical change in hundreds of interfaces output, so your app would likely
to be broken frequently, and with big migration costs each time. It makes
sense to wait until it stabilized a lot.


On Thu, Jun 16, 2016 at 5:20 AM Julien Dramaix 
wrote:

> Elemental is not secret, it is not ready yet...
>
> Stay tuned, in few days we should push an experimental version of
> elemental using JsInterop new specification.
>
> - Julien
>
> On Thu, Jun 16, 2016 at 1:13 PM Leif Åstrand  wrote:
>
>> Elemental 2 is a completely new project that is being developed
>> internally by Google, but their intention is to publish it as open source
>> once the maturity of the code matches their internal threshold.
>>
>> On Thursday, June 16, 2016 at 10:28:39 AM UTC+3, Alex White wrote:
>>>
>>> Just wondering where the source code is and why it has not been
>>> published before a major release for an allegedly open source project. Is
>>> the big secret that it won't be published?
>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/f5ec5e86-ffbc-41ca-b007-d337b4bf5caf%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D5MjFXjniTc%2BXzUfE2%2BF19ti5G9WKm0S2X7shtLpa6MHA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fYLRMFQCjBBLQneH3Vty8skfi0hZrGGbLryGOQDWeR%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Future direction for common JS api's

['Ray Cromwell' via GWT Contributors]

Elemental2 uses typescript as it's intermediate representation, so you can
do Closure Externs -> TypeScript -> JsInterop or WebIDL -> TypeScript ->
JsInterop or (insert favorite syntax here) -> TypeScript -> JsInterop.

BTW, Note that JSweet really punts on most JLS semantics, so it's
problematic for compiling shared or existing Java code bases.


On Wed, May 18, 2016 at 11:22 AM Stephen Haberman <
stephen.haber...@gmail.com> wrote:

> Interesting; I had not seen JSweet before.
>
> The javac -> TypeScript -> JS approach is surprisingly parallel (albeit
> with different selections) to J2CL's ecj -> closure -> JS.
>
> - Stephen
>
>
>
> On Wed, May 18, 2016 at 8:50 AM Jens  wrote:
>
>> Given that Elemental 2 is developed behind closed doors, I would guess it
>> can take TypeScript definition files and/or some IDL input to generate JS
>> APIs for GWT / J2CL. That should cover nearly all Web APIs.
>> IMHO TypeScript definition files would be preferred because there are tons
>> of them on https://github.com/DefinitelyTyped/DefinitelyTyped for all
>> kinds of JS libraries and Web APIs. It also has a definition for the Fetch
>> API:
>> https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/whatwg-fetch
>>
>>
>> It would be a shame if Elemental 2 would not understand them to generate
>> APIs. These files are basically what JSweet uses to generate their Candies (
>> http://www.jsweet.org/candies-releases/). But even if Elemental 2 only
>> takes IDL input or html5index.org as input it should cover all standard
>> web APIs.
>>
>> -- J.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/c72a2088-bc6a-4836-9312-518ec56507cd%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CANnRKuUsocdMoAJMzhfG2pG%3Du9b1MztdVeU3YwJnwSoRARtQOw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7dUCEmYad3dNrh_qhb6z%2B3x04wUnCX9-gF6WfeeXJWzKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental 2?

['Ray Cromwell' via GWT Contributors]

Elemental2 just generates code from whatever WebIDLs or Typescript
headers you feed it. If you want to knock out certain APIs, just
comment them out in the IDL file.


On Wed, May 18, 2016 at 2:10 PM, Ming-Yee Iu  wrote:
> It would also be nice if Elemental 2 also has an easy way to selectively
> knock out certain fields/methods in the code generator. I don't know how
> many times I'll be using code completion and accidentally end up writing
> something like
>
>div.setInnerText("click me")
>
> because innerText is available in WebKit when I should have been using
>
>div.setTextContent("click me")
>
> which is cross-platform. I would like to be able to easily go in and
> regenerate my own Elemental with innerText (among others) removed so that I
> can't accidentally do that.
>
> There's also the issue of dealing with variants like
> webkitRequestAnimationFrame(), mozRequestAnimationFrame(),
> msRequestAnimationFrame(), and requestAnimationFrame() without having four
> different methods. I guess I can just polyfill stuff like that though.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/01214f04-0b6a-48bc-bb57-530b29c539ea%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fFLw5vVPGhCJ03q4T8rHkpN9v%3Da3dUb2gVsCQuS_%3D4EA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental 2?

['Ray Cromwell' via GWT Contributors]

I agree with you on Java idiomatic API design, but the first version
won't be so specialized, we will have to hand curate overrides of the
auto-generated APIs, it's not really possible to automate this.


On Wed, May 18, 2016 at 10:22 AM, Ming-Yee Iu  wrote:
> Is it possible to get some hints about what's cooking for Elemental 2?
>
> Is the code generator still going to be Python or is it going to be
> rewritten in Java? I found modifying the Python code generator when I wanted
> to change Elemental 1 to be annoying.
>
> Is the output going to be a direct remapping of JS APIs to Java or are some
> of the more common APIs going to be massaged to be more Java-like? With
> Elemental 1, I found that the JS APIs were cumbersome to use in Java because
> they were designed for use in JavaScript.  A lot of type casting was
> required to use the APIs, a lot of potential opportunities for compile-time
> type safety were missed, lots of strings used as parameters etc.
>
> e.g.
> CanvasRenderingContext2D ctx =
> (CanvasRenderingContext2D)canvas.getContext("2d");
>
> (I often forget whether it's "2d" or "2D", and that type cast is gross)
>
> e.g.
> div.addEventListener(Events.CLICK, new EventListener() {
>void handleEvent(Event evt) {
>   MouseEvent e = (MouseEvent)evt;
>   ...
>}
> });
>
> (that would work so much better as something like
>
>  EventRemover addEventListener( EventType type,
> EventListener listener )
>
> so that it would be possible to do a
>
> div.addEventListener(Events.CLICK, (MouseEvent e) -> {...});
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e4eeefd6-cfdf-462d-8ae7-000fa8969d07%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eBh2aTjgeJZDTjDWYA9W2DSpWxAO%3DCch7ai7OqGAjTjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

['Ray Cromwell' via GWT Contributors]

Jens, the issue is not anything to do with ambiguity, it has to do
with the way we are able to treat an anonymous class as both a
function and an object, see Runtime.java makeLambdaFunction

  /**
   * Create a function that applies the specified samMethod on itself,
and whose __proto__ points to
   * instance.
   */
  public static native JavaScriptObject
makeLambdaFunction(JavaScriptObject samMethod,
  JavaScriptObject instance) /*-{
var lambda = function() { return samMethod.apply(lambda, arguments); }

if (lambda.__proto__) {
  lambda.__proto__ = instance;
} else {
  for (var prop in instance) {
lambda[prop] = instance[prop];
  }
}

return lambda;
  }-*/;


What this does is take a Java class, and a reference to it's prototype
method, creating a new function, and seeing its prototype to be the
Class.


This lets you invoke a lambda as both lambda() or lambda.method() in
JS and Java code, it also means stuff like lambda.getClass(),
lambda.hashCode() etc work.



On Tue, May 17, 2016 at 11:13 AM, Jens  wrote:
>
>> The issue is that @JsFunction implementors must "extend
>> java.lang.Object" as their parent. because standard library functions
>> are/canbe implemented on classes with complicated type hierarchies,
>> this would cause failures to compile.
>>
>> This restriction comes about from the efficiency trick we use to
>> reparent a lambda to have the native JS Function object as it's
>> parent. We can't reparent objects whose immediate supertype isn't
>> java.lang.Object, but not doing this trick would make output more
>> bloated/slow, and wouldn't allow Java8 lambas to act like JS functions
>> (e.g. can call Function.bind/apply/etc on them) without some kind of
>> wrapping/unwrapping process, plus an additional level of hacks to make
>> sure referential integrity was preserved.
>
>
> Can you elaborate on it? I think its really annoying that every project must
> redefine callbacks, functions, consumers, whatever just because JRE has some
> default methods in their version and GWT can not handle it. IMHO convenience
> is the most important thing here.
>
> For example wouldn't it be possible to redefine the way @JsFunction works so
> something like:
>
> 1.) @JsFunction marks a parameter to be a functional parameter
> 2.) The type of the parameter that is marked with @JsFunction must have
> exactly one @JsFunctionTarget in its class definition
> 3.) @JsFunctionTarget marks an abstract method in an interface or in an
> abstract class.
>
>
> Then we would do something like
>
> @JsType(native = true, ...)
> class SomeAsyncClass {
>   void onSuccess(@JsFunction Consumer onSuccess);
> }
>
>
> interface Consumer {
>   @JsFunctionTarget
>   void accept(T value);
>
>
>   // other default methods
> }
>
>
>
> JavaScript:
>
> var asyncClass = new SomeAsyncClass();
> var someConsumer = // ...anything that has implemented Consumer
> asyncClass.onSuccess(
>   function(value) {  // @JsFunction tells GWT to generate a "bridge" method
> using the parameters of @JsFunctionTarget and delegates to the
> Consumer implementation
> someConsumer.accept(value);
>   }
> );
>
>
> The above is probably not fully correct JS and maybe has some "this"
> problems but I think you get the idea. Marking parameters as @JsFunction
> would allow you to choose wether or not you want GWT to handle a Consumer as
> callback or as ordinary object, e.g. if you do not annotate a parameter of
> type Consumer with @JsFunction then it will be passed as normal object
> without any bridge methods that delegate to a @JsFunctionTarget method.
>
> Wouldn't this be possible?
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/db6a7e36-b288-4107-90f2-6b66b696779c%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Adding @JsFunction to java.util.function JRE Emulation?

['Ray Cromwell' via GWT Contributors]

The issue is that @JsFunction implementors must "extend
java.lang.Object" as their parent. because standard library functions
are/canbe implemented on classes with complicated type hierarchies,
this would cause failures to compile.

This restriction comes about from the efficiency trick we use to
reparent a lambda to have the native JS Function object as it's
parent. We can't reparent objects whose immediate supertype isn't
java.lang.Object, but not doing this trick would make output more
bloated/slow, and wouldn't allow Java8 lambas to act like JS functions
(e.g. can call Function.bind/apply/etc on them) without some kind of
wrapping/unwrapping process, plus an additional level of hacks to make
sure referential integrity was preserved.




On Wed, May 11, 2016 at 5:51 PM, Colin Alworth  wrote:
> No, its not a solution, so much as a "here is a workaround that might
> satisfy your specific case as you build your JsInterop-based lib so that it
> looks like it can use @FunctionalInterface types". I do not believe it to be
> a comprehensive way to provide the feature requested. At some point I'll try
> to write it out in more detail in case there is any actual merit to it (I'm
> all but sure that there isn't, or you would have thought of it already).
>
> On Wed, May 11, 2016 at 7:47 PM 'Goktug Gokdogan' via GWT Contributors
>  wrote:
>>
>> We cannot impose @JsFunction restrictions on standard library
>> @FunctionInterfaces. You can see some of the limitations in the Javadoc.
>>
>> @Colin: I didn't understand your solution. Feel free to propose something
>> more concrete and we can discuss over that.
>>
>> On Wed, May 11, 2016 at 4:22 PM, Colin Alworth  wrote:
>>>
>>> Unfortunately, you can't add the annotation to an interface with more
>>> than one method, even if those methods are default methods, at least as it
>>> is currently implemented.
>>>
>>> I can't remember the exact specifics around why this is the case, but
>>> believe it has to do with handling functions passed from js into java, and
>>> not being able to nicely handle instances that decide to override those
>>> other methods as well.
>>>
>>> You could nearly achieve this effect by just making a method reference to
>>> the "apply" or "test" method, and passing that as an actual JsFunction type.
>>> I don't right away see a problem with syntactic sugar doing this
>>> automatically, but am sure that someone will be able to enlighten us as to
>>> what confusing side effects this might have (or alternately confirm that
>>> this is a great idea, and point to where in the compiler the changes need to
>>> be made).
>>>
>>>
>>> On Wed, May 11, 2016, 6:15 PM David Becker 
>>> wrote:

 I think it would be good to add @JsFunction to all of the
 java.util.function interfaces in the JRE Emulation so that we can use
 standard function signatures with JsInterop.

 Would that work?  Any drawbacks?

 If you think that's a good idea, I can submit a patch.

 Thanks!

 --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/13df9bed-108f-4cdf-8c00-123f1186e461%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzaxRmFrvZUkQMG0VQETyJo5TWmjtFqPsn3msrBBvvLGg%40mail.gmail.com.
>>>
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0CktOO8rpggbAcfPyTPhP7bp3fOTZgxSZiWyGq09waBw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMwvRokmP5nq84jmE40Dmos3eMmPDH-V4RcCz-%2BjbubvxQ%40mail.gma

Re: [gwt-contrib] Potentially simple optimization when creating ObjectLiterals

['Ray Cromwell' via GWT Contributors]

A quick fix would be, in a linker, to substitute "new $wnd.Object"
with "{}". It's possible to write a peephole pass to fix this in the
Compiler, but I think given the number of people clamoring for GWT 2.8
and the other more pressing issues, this would be low on the totem
pole.


On Sun, May 1, 2016 at 6:30 AM, Paul Stockley  wrote:
> When you define an object literal as
>
> @JsType(isNative = true, namespace = JsPackage.GLOBAL, name="Object")
> public class SomeObjLiteral {
>
> }
>
>
> Calling new on this results in the following javascript code 'new
> $wnd.Object'. You could just emit {} instead.
>
> It is surprising the number times you see this code especially for React
> code bases and when dealing with JSON structures.
>
> Is it worth filing an issue?
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/e1388465-ce9f-4bd9-8846-d4de7dc635f8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7d1U4LvBySTrw2Lh_ao%3D2Bme9T%2BBAk1u%3DSy%2BxGtfKa6Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

I'm ok with restricting them to @JsFunction java8 lambdas. That's
likely to be the common path for web oriented code for event handling.


On Mon, Apr 18, 2016 at 10:47 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> That is why I am saying that it will be easy to do for JsFunctions but due
> to Java semantics (regular) lambdas are just not plain functions and thus I
> don't think there is much to gain there.
>
> I don't think there is much to gain on the regular lambdas. There are 2
> different ways we can handle them and reduce a bit of the generated code but
> I don't think there is a lot of potential ways.
> 1) do not generate anonymous inner classes, rather have the make lambda
> factory take all the required parameters, i.e. castmap.
> 2) create an anonymous innerclass based on the class/interface that is being
> extended/implemented when a lambda for that is seen. In that way if an
> interface is used with many lambdas there is only one supporting class
> instead of many.
>
>
> On Mon, Apr 18, 2016 at 10:22 AM, 'Ray Cromwell' via GWT Contributors
>  wrote:
>>
>> I understand, but the trampolines cause bloat, and if you're
>> suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
>> far as code-gen is concerned, then you would not be able to make the
>> following code work:
>>
>> foo(Callable x) { bar(x); }
>> foo(Runnable x) { bar(x); }
>>
>> bar(Object x) { if (x instanceof Callable) { print("it's a callable");
>> } else if (x instanceof Runnable) { print("It's a runnable"); } }
>>
>> You need a castMap for that.
>>
>>
>> On Mon, Apr 18, 2016 at 10:17 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>> > The point is that for JsFunctions you DON'T actually need to do the
>> > makeLambda(). JsFunction was designed to be able to pass JS functions to
>> > JAVA so there is a code path for that and we can exploit it for
>> > JsFunction
>> > lambdas.
>> >
>> > So x -> 42  + capture will be represented in the JAva AST as
>> > class X {
>> >   {
>> >  .  new X$0(capture);
>> >   }
>> >   // Synthetic lambda method
>> >   int lambda_f(capture, x) {
>> >  return 42 + capture;
>> >   }
>> >
>> > // Lambda function implmenetation. Nothing needs to be emitted for this
>> > in
>> > JS
>> > class X$0 implements JsFunctionInterface {
>> >   capture;
>> >   X$0(capture) {
>> >this.capture = capture;
>> >   }
>> >
>> >   int m(x) {
>> >  X.lambda_f(this.capture, x);
>> >   }
>> > }
>> >
>> >
>> > In the JS ast we do
>> >
>> >   new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }
>> >
>> > So we don't need makeLambda or anything else; we can just treat
>> > JsFunciton
>> > implementation as if they were functions passed in from JavaScript where
>> > object methods will go through the regular trampoline into the "JSO"
>> > implementation.
>> >
>> >
>> >
>> >
>> > On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors
>> >  wrote:
>> >>
>> >> That seems similar to my proposal, only you're doing it in GenJsAST.
>> >> You'll still need to the makeLambda() trick to allow it to work as a
>> >> regular obejct as well, with hashCode()/equals()/getClass()
>> >> properties, as well as castMap installed. But if you use static method
>> >> delegation, the size won't be as ideal if the static method doesn't
>> >> inline.
>> >>
>> >> You want something like x -> 42 + capture to compile to
>> >> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
>> >> not function(x) { return Class.foo(capture, x); } do you not?
>> >>
>> >>
>> >> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
>> >> Contributors  wrote:
>> >> > The scheme I had in mind does not modify much the Java AST
>> >> > representation
>> >> > but is more in the lowering to the JsAST, basically it boils down the
>> >> > the
>> >> > following:.
>> >> > 1. You create the lambda body as a static method of the class where
>> >> > it
>> >> > appears. This st

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

I understand, but the trampolines cause bloat, and if you're
suggesting treating all non-JsFunction Java8 lambdas as JsFunctions as
far as code-gen is concerned, then you would not be able to make the
following code work:

foo(Callable x) { bar(x); }
foo(Runnable x) { bar(x); }

bar(Object x) { if (x instanceof Callable) { print("it's a callable");
} else if (x instanceof Runnable) { print("It's a runnable"); } }

You need a castMap for that.


On Mon, Apr 18, 2016 at 10:17 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> The point is that for JsFunctions you DON'T actually need to do the
> makeLambda(). JsFunction was designed to be able to pass JS functions to
> JAVA so there is a code path for that and we can exploit it for JsFunction
> lambdas.
>
> So x -> 42  + capture will be represented in the JAva AST as
> class X {
>   {
>  .  new X$0(capture);
>   }
>   // Synthetic lambda method
>   int lambda_f(capture, x) {
>  return 42 + capture;
>   }
>
> // Lambda function implmenetation. Nothing needs to be emitted for this in
> JS
> class X$0 implements JsFunctionInterface {
>   capture;
>   X$0(capture) {
>this.capture = capture;
>   }
>
>   int m(x) {
>  X.lambda_f(this.capture, x);
>   }
> }
>
>
> In the JS ast we do
>
>   new X$0(capture)  -->  function(x) { X.lambda_f(capture, x) }
>
> So we don't need makeLambda or anything else; we can just treat JsFunciton
> implementation as if they were functions passed in from JavaScript where
> object methods will go through the regular trampoline into the "JSO"
> implementation.
>
>
>
>
> On Mon, Apr 18, 2016 at 9:55 AM, 'Ray Cromwell' via GWT Contributors
>  wrote:
>>
>> That seems similar to my proposal, only you're doing it in GenJsAST.
>> You'll still need to the makeLambda() trick to allow it to work as a
>> regular obejct as well, with hashCode()/equals()/getClass()
>> properties, as well as castMap installed. But if you use static method
>> delegation, the size won't be as ideal if the static method doesn't
>> inline.
>>
>> You want something like x -> 42 + capture to compile to
>> makeLambda(function(x) { return 42 + capture }, castMap, classLit),
>> not function(x) { return Class.foo(capture, x); } do you not?
>>
>>
>> On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>> > The scheme I had in mind does not modify much the Java AST
>> > representation
>> > but is more in the lowering to the JsAST, basically it boils down the
>> > the
>> > following:.
>> > 1. You create the lambda body as a static method of the class where it
>> > appears. This static method has all captures as parameters (thiis is
>> > very
>> > similar as we are doing today).
>> > 2. Synthesize an anonymous inner class that implement the JsFunciton
>> > (also
>> > same as we are doing now). The compiler in the java phase sees this as
>> > an
>> > innerclass.
>> > 3. Emit the following code for new JsFuncitonimplementation(capture1,
>> > capture2) as function(par1, par2, parn) ->
>> > {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2,
>> > parn) }.
>> > 4. Do not emit any code for the anonymous inner class.
>> >
>> > This function will behave as if it was a native function passed from JS,
>> > and
>> > object methods will work in the same way. Of course the devil is in the
>> > details.
>> >
>> >
>> > On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
>> >  wrote:
>> >>
>> >> Seems to me this'll be tricky to pull off. The GWT compiler has no
>> >> notion of captured scope. If you want to create a class type that
>> >> represents a lambda, but which doesn't actually get output as a class,
>> >> you'd have to change many many parts of the compiler.
>> >>
>> >> I think perhaps the best thing you could do would be a kind of
>> >> 'peephole' optimization pass. After all Java optimization passes have
>> >> run, and after JS has been generated, go through using pattern
>> >> matching to find "new generatedlambda(captured variables)" and replace
>> >> it with "makeLambda(classtype, castMap, classLiteral, function(...) {
>> >> body of single abstract method })". Then hope the JS dead code pruning
>> &g

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

That seems similar to my proposal, only you're doing it in GenJsAST.
You'll still need to the makeLambda() trick to allow it to work as a
regular obejct as well, with hashCode()/equals()/getClass()
properties, as well as castMap installed. But if you use static method
delegation, the size won't be as ideal if the static method doesn't
inline.

You want something like x -> 42 + capture to compile to
makeLambda(function(x) { return 42 + capture }, castMap, classLit),
not function(x) { return Class.foo(capture, x); } do you not?


On Mon, Apr 18, 2016 at 9:49 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> The scheme I had in mind does not modify much the Java AST representation
> but is more in the lowering to the JsAST, basically it boils down the the
> following:.
> 1. You create the lambda body as a static method of the class where it
> appears. This static method has all captures as parameters (thiis is very
> similar as we are doing today).
> 2. Synthesize an anonymous inner class that implement the JsFunciton (also
> same as we are doing now). The compiler in the java phase sees this as an
> innerclass.
> 3. Emit the following code for new JsFuncitonimplementation(capture1,
> capture2) as function(par1, par2, parn) ->
> {Class.lambdaFunctionImplementation(capture1, capture2, par1, par2, parn) }.
> 4. Do not emit any code for the anonymous inner class.
>
> This function will behave as if it was a native function passed from JS, and
> object methods will work in the same way. Of course the devil is in the
> details.
>
>
> On Mon, Apr 18, 2016 at 9:34 AM, 'Ray Cromwell' via GWT Contributors
>  wrote:
>>
>> Seems to me this'll be tricky to pull off. The GWT compiler has no
>> notion of captured scope. If you want to create a class type that
>> represents a lambda, but which doesn't actually get output as a class,
>> you'd have to change many many parts of the compiler.
>>
>> I think perhaps the best thing you could do would be a kind of
>> 'peephole' optimization pass. After all Java optimization passes have
>> run, and after JS has been generated, go through using pattern
>> matching to find "new generatedlambda(captured variables)" and replace
>> it with "makeLambda(classtype, castMap, classLiteral, function(...) {
>> body of single abstract method })". Then hope the JS dead code pruning
>> removes the unused inner class.
>>
>> I think if you try to model this in the Java AST it would impact too much
>> stuff.
>>
>>
>> On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>> > We accept patches :)
>> >
>> > On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley 
>> > wrote:
>> >>
>> >> Given that it will be realistically a couple of years before most large
>> >> projects could migrate to J2CL, it would be really nice to have a more
>> >> optimal code generation for lambda's, especially for JsFunction. When
>> >> 2.8
>> >> gets released, I think people will really start taking advantage of
>> >> existing
>> >> JS libraries that really heavily use functions.
>> >>
>> >>
>> >> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman
>> >> wrote:
>> >>>
>> >>> It should not be hard to make JsFunction lambdas more terse, but there
>> >>> are no plans for GWT 2.x.
>> >>>
>> >>>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "GWT Contributors" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d75d8079-463a-4334-8c3c-75f11cc9ab20%40googlegroups.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "GWT Contributors" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://gr

Re: [gwt-contrib] Lambda overhead

['Ray Cromwell' via GWT Contributors]

Seems to me this'll be tricky to pull off. The GWT compiler has no
notion of captured scope. If you want to create a class type that
represents a lambda, but which doesn't actually get output as a class,
you'd have to change many many parts of the compiler.

I think perhaps the best thing you could do would be a kind of
'peephole' optimization pass. After all Java optimization passes have
run, and after JS has been generated, go through using pattern
matching to find "new generatedlambda(captured variables)" and replace
it with "makeLambda(classtype, castMap, classLiteral, function(...) {
body of single abstract method })". Then hope the JS dead code pruning
removes the unused inner class.

I think if you try to model this in the Java AST it would impact too much stuff.


On Mon, Apr 18, 2016 at 9:04 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> We accept patches :)
>
> On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley  wrote:
>>
>> Given that it will be realistically a couple of years before most large
>> projects could migrate to J2CL, it would be really nice to have a more
>> optimal code generation for lambda's, especially for JsFunction. When 2.8
>> gets released, I think people will really start taking advantage of existing
>> JS libraries that really heavily use functions.
>>
>>
>> On Friday, April 15, 2016 at 12:03:12 PM UTC-4, Roberto Lublinerman wrote:
>>>
>>> It should not be hard to make JsFunction lambdas more terse, but there
>>> are no plans for GWT 2.x.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d75d8079-463a-4334-8c3c-75f11cc9ab20%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7g%3DkH9YQjA_P02ibv-Fg4u-gRW6s4Ojm6S2KgTK0KDOYmQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Re: JsInterop Object Literal

['Ray Cromwell' via GWT Contributors]

Use an annotation processor

@AutoLiteral
@JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "Object")
class MyFoo {
   public int field1, field2;

}

@Generated(...)
@JsType(IsNative = true, namespace = JsPackage.GLOBAL, name = "Object")
class MyFooLiteral extends MyFoo {
  public MyFooLiteral make() { return new MyFooLiteral(); }
  @JsOverlay
  final public MyFooLiteral field1(int x) { field1 = x; }
  @JsOverlay
  final public MyFooLiteral field2(int x) { field2 = x; }
}


callFunc(MyFooLiteral.make().field1(42).field2(99));


On Tue, Mar 22, 2016 at 9:53 AM, Jens  wrote:
>
>> If your concert is to be able to write one-line initializers, and you are
>> using java8 syntax you also do something like that:
>>
>> public static  T apply(T t, Consumer fn) {
>> fn.accept(t);
>> return t;
>> }
>>
>> @JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "Object")
>> class SomeObjectLiteral {
>> int field1;
>> String field2;
>> }
>>
>> {
>> SomeObjectLiteral sol = apply(new SomeObjectLiteral(), o -> { o.field1
>> = 1; o.field2 = "str"; });
>>
>> }
>>
>>
>> Copied from kotlin (although without method extensions and method inline
>> is not the same ;)), this is usable for client and server code when you need
>> to initialize small pojos without fluent api.
>
>
> Looks like a good example how to over-use lambdas. IMHO its just more
> complicated without any added value if its just for initialization.
>
> SomeObjectLiteral sol = apply(new SomeObjectLiteral(), o -> { o.field1 = 1;
> o.field2 = "str"; });
>
> SomeObjectLiteral sol = new SomeObjectLiteral(); sol.field1 = 1; sol.field2
> = "str";
>
>
> Old school is even shorter ;-)
>
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/c007f5d8-48cc-43d5-a813-fa2acaa37337%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Re: JsInterop Object Literal

['Ray Cromwell' via GWT Contributors]

Right now, the best you can do is

@JsType(isNative = true, namespace =JsPackage.GLOBAL, name = "Object")
class MyLiteral {
}

And put js properties on the object


On Sat, Mar 19, 2016 at 11:11 PM, Brandon Donnelson
 wrote:
> I found a doc talking about object literal creation
> https://docs.google.com/document/d/1DFrC-GtcK7cu6DGxaWCswvb2fai9cnrWPvGcdgsKlBw/edit.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/3c62911e-0304-4181-b6d3-03b4689debb9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fqdDTY8N_fyzta12aOOJ-WWcgFd0Qduyu03TWDUPQ%2B4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental 2?

['Ray Cromwell' via GWT Contributors]

JsInterop2 solves many of the problems of JsInterop1 and JSOs that plagued
Elemental1 and made it hard to pull off.


On Fri, Dec 11, 2015 at 8:10 AM, Benjamin Tillman <
benjamin.till...@gmail.com> wrote:

> For sure this will be the case. Elemental2 + JsInterop are so
> foundational, and much will be built on top of them. Even the simplest
> things like cleanly working with web-sockets. I'm also very much looking
> forward to something complete to work from, and a big thanks to those who
> are working on this.
>
> Regards,
> Ben.
>
> On Sunday, 22 November 2015 19:19:25 UTC+11, James Horsley wrote:
>>
>> When both Elemental2 and JsInterop are released I think that the
>> community will start to innovate on this front and new libraries will pop
>> up on github to address these needs; "if you build it, they will come" and
>> all that.
>>
>> I know I'm very much looking forward to Elemental2 + Jsinterop as a
>> platform to build on.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/cc9ae8e6-7f8c-4ad2-bbe9-fbb355f6ae1b%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fY6TtiwTN_QESpZnza%3Dy9Ju-k%3D%3DBRa51xNFzeZN9zqOg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Elemental 2?

['Ray Cromwell' via GWT Contributors]

There could be a separate Json library build with JsInterop. Some of the
decisions I made in the design of the original Elemental JSON were made
specifically because of DevMode support and GWT optimization internals.
Given the unboxing of Double and Boolean, and the elimination of DevMode,
the library can be much simpler now and still have a JVM implementation to
be portable.

On Sat, Nov 21, 2015 at 10:28 PM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Elemental2 will be just an auto-generated thin wrapper around the browser
> APIs. Unlike Elemental1, it will not provide a cross platform JSON
> implementation.
>
> I don't think you need to report compatibility bugs for Elemental1 unless
> a maintainer steps up and shows interest.
>
> On Sat, Nov 21, 2015 at 1:42 PM, Erik Kuefler  wrote:
>
>> What's the current thinking regarding JSON in Elemental 2? That part has
>> always been a bit different from the DOM libraries, and I know there was
>> talk a long time back about splitting it out. I've been using Elemental
>> JSON extensively in my projects just to have a JSON library that works in
>> GWT and in JVM, but I've found it to be extremely buggy (mostly in terms of
>> behavior differences between jvm, optimized gwt, and draft mode gwt). Are
>> these bugs worth reporting? Is it all being reworked for Elemental 2?
>>
>> On Friday, November 20, 2015 at 12:36:22 PM UTC-8, Ray Cromwell wrote:
>>>
>>> Another thing to consider is that J2CL was developed as a 'bake off', in
>>> which multiple prototypes and designs were discussed/looked at (compile
>>> from Java with JDT, compile from bytecode, compile using Javac APIs,
>>> writing parser by hand, etc) It would have been a bit premature to release
>>> any of them as they were all known ahead of time to be throwaways.
>>>
>>> I have a hacky Elemental2 prototype (which is not the official one that
>>> Julien is working on), if you want to take it and play around.
>>>
>>>
>>>
>>> On Fri, Nov 20, 2015 at 10:30 AM, 'Goktug Gokdogan' via GWT Contributors
>>>  wrote:
>>>
>>>> No worries :)
>>>>
>>>> On Fri, Nov 20, 2015 at 10:27 AM, Stephen Haberman <
>>>> stephen@gmail.com> wrote:
>>>>
>>>>> Hi Goktug,
>>>>>
>>>>> That's all true, thanks for providing a counter data point. You're
>>>>> right, the JsInterop design docs/etc. were all out in the open from day 1,
>>>>> which I thought was pretty exiting.
>>>>>
>>>>> I definitely can't take any credit for providing useful feedback, but
>>>>> I enjoyed seeing the thoughts and process from the community.
>>>>>
>>>>> So, apologies for the sweeping statement.
>>>>>
>>>>> - Stephen
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 20, 2015 at 11:58 AM, 'Goktug Gokdogan' via GWT
>>>>> Contributors  wrote:
>>>>>
>>>>>> Singular is not a Google project and not being developed internally.
>>>>>> It is Daniel's personal project and as fas as I know it is already in the
>>>>>> open source.
>>>>>>
>>>>>> We don't have anything to share for Elemental yet. We are talking
>>>>>> with other teams, thinking about alternatives etc. Also when we release, 
>>>>>> it
>>>>>> will not be part of GWT-SDK so there is going be extra work to move the
>>>>>> development outside; which doesn't make sense at this stage.
>>>>>>
>>>>>> The big things we recently developed for GWT, JsInterop and
>>>>>> SuperDevMode and they were all open source from day one.
>>>>>>
>>>>>> On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman <
>>>>>> stephen@gmail.com> wrote:
>>>>>>
>>>>>>> > Meanwhile I will revive my own generator project.
>>>>>>>
>>>>>>> I'll take the opportunity to hop on a soapbox, but the "closed
>>>>>>> source/eventually open source" model is a curious trend that I think 
>>>>>>> I've
>>>>>>> only seen in the GWT community (are their other examples?)...
>>>>>>>
>>>>>>> Musing, it probably s

Re: [gwt-contrib] Re: Elemental 2?

['Ray Cromwell' via GWT Contributors]

Another thing to consider is that J2CL was developed as a 'bake off', in
which multiple prototypes and designs were discussed/looked at (compile
from Java with JDT, compile from bytecode, compile using Javac APIs,
writing parser by hand, etc) It would have been a bit premature to release
any of them as they were all known ahead of time to be throwaways.

I have a hacky Elemental2 prototype (which is not the official one that
Julien is working on), if you want to take it and play around.



On Fri, Nov 20, 2015 at 10:30 AM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> No worries :)
>
> On Fri, Nov 20, 2015 at 10:27 AM, Stephen Haberman <
> stephen.haber...@gmail.com> wrote:
>
>> Hi Goktug,
>>
>> That's all true, thanks for providing a counter data point. You're right,
>> the JsInterop design docs/etc. were all out in the open from day 1, which I
>> thought was pretty exiting.
>>
>> I definitely can't take any credit for providing useful feedback, but I
>> enjoyed seeing the thoughts and process from the community.
>>
>> So, apologies for the sweeping statement.
>>
>> - Stephen
>>
>>
>>
>> On Fri, Nov 20, 2015 at 11:58 AM, 'Goktug Gokdogan' via GWT Contributors
>>  wrote:
>>
>>> Singular is not a Google project and not being developed internally. It
>>> is Daniel's personal project and as fas as I know it is already in the open
>>> source.
>>>
>>> We don't have anything to share for Elemental yet. We are talking with
>>> other teams, thinking about alternatives etc. Also when we release, it will
>>> not be part of GWT-SDK so there is going be extra work to move the
>>> development outside; which doesn't make sense at this stage.
>>>
>>> The big things we recently developed for GWT, JsInterop and SuperDevMode
>>> and they were all open source from day one.
>>>
>>> On Fri, Nov 20, 2015 at 5:34 AM, Stephen Haberman <
>>> stephen.haber...@gmail.com> wrote:
>>>
 > Meanwhile I will revive my own generator project.

 I'll take the opportunity to hop on a soapbox, but the "closed
 source/eventually open source" model is a curious trend that I think I've
 only seen in the GWT community (are their other examples?)...

 Musing, it probably stems from Google setting the example with GWT
 itself, where historically a lot happened internally before being mirrored
 externally, but it happens a bit for non-Google-GWT projects as well, like
 the repackaging of GPE, which was closed during initial development
 (although the result is great, and I really appreciate it), Singular, which
 is still closed during initial development, now Elemental2. I dunno, I
 find it curious.

 E.g. with Singular, it's like it's being developed like the next Apple
 phone; we have to be secret about it, not say anything, so we can have an
 awesome keynote where we surprise the world with how awesome it is.

 Granted, I'm sure those keynotes are very fun, but I guess I don't
 understand, wtf, why not just open source things from day 1? IMO the best
 case scenario, and most likely, is that you're going to attract early
 adopters who will a) give you feedback to validate approaches/etc and b)
 give you free work by tracking down bugs and committing patches.

 Keeping things closed source "until they're ready", IMO, stifles the
 potential contributor/committer pool that's needed for the long term health
 of an open source project.

 I suppose the risk is people writing a 100k LOC production app on a
 pre-1.0 project, and then they bitch about changes...but hopefully lots of
 disclaimers and 0.x release points would help mitigate that...

 Anyway, that is my soapbox. Or one of them, I guess. :-P Of course,
 we're all getting this work for free, so everyone is free to do what they
 please, and I will be very excited and thankful for both
 Elemental2/Singular when they are available to us.

 So please don't read this as "bah, that is dumb", but just as "gentle
 nudge towards open sourcing sooner, if that's okay, thanks!". :-)

 - Stephen



 On Fri, Nov 20, 2015 at 6:14 AM, Rene Hangstrup Møller <
 rhmol...@gmail.com> wrote:

> Thanks for the update.
> Looking forward to seeing what you have been cooking up.
> Meanwhile I will revive my own generator project.
>
> /Rene
>
> Den fredag den 20. november 2015 kl. 11.05.44 UTC+1 skrev Julien
> Dramaix:
>>
>> It's a bit too early to answer to this question with absolute
>> certainty but I don't think I can guarantee the full backward 
>> compatibility
>> with the first version of elemental.
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> go

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

['Ray Cromwell' via GWT Contributors]

Keep in mind at Google, we write lots of large Web projects, and even the
ones that are pure JS (G+, Gmail, Docs, Maps, etc) use Closure Compiler and
lots of typing. We find it invaluable.

But the world is going mobile, and going forward, you need to support
Android, iOS, and Web, and you need to be flexible and not box yourself in.
You have a few choices to do this:

1) Try to deploy mobile Web everywhere.
2) Go with something like React-native
3) Rewrite all 3 clients 3 times in 3 languages
4) Try to share code as much as possible between platforms.

We have decided to go with option #4 for some projects. For example, the
next-generation Gmail (Inbox), Google Spreadsheets, and others. We share
80% of our code with all platforms.

J2Cl will join J2ObjC is providing an aligned solution for Hybrid apps.
This may not fit everyone's needs, in which case, there's still GWT.

IMHO, with J2Cl, Java8, Elemental2, and JsInterop, you'll have a solution
which lets you stay in Java 95% of the time, compile orders of magnitude
faster than GWT, interoperate with arbitrary libraries with much less
wrapper JSO boilerplate, and provide excellent integration with any Java
IDE as far as coding is concerned. The round-tripping should be nearly as
fast as Typescript.

But if you're conformable with ES6 or TS, I'd say go for it. Always use
whatever you're most productive in or what suits your needs.

-Ray


On Tue, Nov 17, 2015 at 12:25 AM, Robert Stone 
wrote:

>
>
> On Monday, 16 November 2015 18:52:50 UTC, Jens wrote:
>>
>>
>> I'm not talking about a re-write here, I'm talking about new projects.
>>> For new projects, I can't see a compelling reason for picking GWT, if the
>>> devs are going to have to understand JS to use GWT then it is better to
>>> invest up front time in getting them familiar enough with JS to use it for
>>> the whole project. This is the decision we have taken in my organization.
>>>
>>
>> If you just want to write that new app thingy that can do 3 things very
>> well and your client side code never reaches a critical size then fine, I
>> guess I would also skip GWT. But if you have a 500-5000 KLOC client side
>> application then its a totally different story and you quickly wish that
>> you would have used GWT/Java or a different language with better tooling
>> support than JS.
>>
>> So THE compelling reason for picking GWT is your expected app size. Even
>> for small apps for which I might want to skip GWT I would, at least, use
>> TypeScript to put as much type information as possible into my code to help
>> devs and IDEs to reason about code.
>>
>> -- J.
>>
>
> We have 2 big applications, one written in GWT and the other (slightly
> smaller) written in JS. The JS one is actually embedded inside the GWT app,
> we had the chance to write it in GWT but our experience with writing the
> big app led us to switch to JS. Don't get me wrong, GWT was the correct
> decision at the time we started the main app (5 years ago) because it
> solved the cross browser issues well and because of the relative immaturity
> of JS frameworks/unit testing/build tools at the time. But JS frameworks
> have improved so much over those years, the problems that used to plague
> pure JS solutions are much easier to avoid now.
>
> I can't remember the last time I suffered an issue due to dynamic typing,
> so I would disagree with you on the needing TypeScript point. My IDE of
> choice for my JS dev is Sublime Text with a few plugins, I feel more
> productive in that environment than in any of the 3 Java IDEs. With very
> good unit tests in place our JS application has far better code coverage
> than the GWT app and the ability to express/solve problems in JS seems to
> naturally lead to a much smaller (and more understandable) code base than
> the Java code.
>
> We will still be using GWT and I will be looking into what we can do with
> the code base to take it forward, thankfully we are using MVP so it should
> (in theory) be possible to move our views over to a more native solution
> (possibly using Elemento) which would allow us to at least think about
> moving to GWT 3.
>
> It may not sound like it, but I'm incredibly grateful for what GWT has
> been able to offer me over the years, indeed I wouldn't be in my current
> (very enjoyable) job without it :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d03c7beb-f1ff-46ac-873c-5ad1b13a4438%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this me

Re: [gwt-contrib] Re: GWTCon 2015 keynote question

['Ray Cromwell' via GWT Contributors]

My hope would be that some enterprising individuals will start porting
pieces of GWT generators to annotation processors in the future. Some of
them are definitely doable without much effort
(CssResource/ClientBundle/etc) Some of them will require more work, but are
still possible (UiBinder with caveats), and some of them just plain won't
work (RPC) because of the requirement of global information.

Other useful bits of com.google.gwt could be easy modified to use JsInterop
instead of JSNI as we have done in much of the JRE to share code with J2CL.




On Mon, Nov 16, 2015 at 3:51 PM, Alain Ekambi 
wrote:

> Errai UI ?
> On 17 Nov 2015 00:41, "Stephen Haberman" 
> wrote:
>
>>
>>
>>> I guess I will be trying UiBinder with GQuery and not rely on Widget for
>>> my project. The UiBinder might disappear, but we are using mostly plain
>>> HTML and Bootstrap styles. So we are only interested in binding events. The
>>> UiBinder templates will be easy to migrate later on.
>>>
>>
>> FWIW this is what we're doing, with a small variation:
>>
>> Use UiBinder, use regular CSS styling (bootstrap/etc.), but only very
>> minimal/core widgets, like TextBox (just an input tag), HTMLPanel, and
>> ListBox (select tag).
>>
>> My theory/hope is that porting away from UiBinder + TextBox/ListBox to
>> some other templating language + "basically a text box, basically a select
>> box" replacements should not be too painful.
>>
>> So, yes, it's still using widgets, but it's not the full slate of layout
>> panels, trees, cells, etc. that would be much harder to port.
>>
>> That said...if you could get away with widget-less UiBinder? That's
>> interesting. I've not really tried that. E.g. just use an > ui:field="..."> instead of "gwt:TextBox" at all. That sounds like a good
>> idea to me...
>>
>> - Stephen
>>
>>
>>
>>
>>>
>>> Any idea what is going on with Singular ? Is it also abandoned or will
>>> it finally appear after GWT 2.8 is final ?
>>>
>>>
>>> On Mon, Nov 16, 2015 at 12:10 PM, Alain Ekambi 
>>> wrote:
>>>
 Well the hope is that someone will step in and port existing js
 libraries to gwt 3 or create new one ? See vaadin sencha etc .. We will def
 port our ext js wrapper to gwt3
 On 16 Nov 2015 11:29, "Robert Stone"  wrote:

>
>
> On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote:
>>
>>
>> My worry about "just pick a mainstream JS framework and use it via
>> JSInterop" is that if you're a) coupled to a JS environment for unit
>> testing and b) interfacing with a framework that is inherently
>> dynamic/untyped, what's the benefit of using GWT in the first place?
>>
>
>
> And this for me sums up GWTs main issues going forward. The benefit
> before was that existing Java devs could use GWT to work on all the layers
> of an application. GWT 3 will force (not a bad thing) Java devs to use
> JavaScript for their views and will also force them to deal with
> integrating JS and Java code. At this point, you have to ask 'Why bother
> with Java/GWT at all' - switch the full application to pure JS.
>
> For existing large projects, switching to GWT 3 is almost a
> non-starter as there will be far too much existing view code to convert
> over so they will have to stick with the GWT 2 stream and hope that it
> remains well supported. This is the situation my company face with one of
> our products.
>
> So GWT 3 is not ideal for new projects and doesn't help with existing
> projects. Where is it's market?
>
> --
> You received this message because you are subscribed to the Google
> Groups "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/342561ff-64da-4e7a-aec4-6e9b84846f09%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
 --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGw%3D_ty7rjFQmUZhYv95aQBj8KgwSKcGk0nEyUkdTd4upBNtdA%40mail.gmail.com
 
 .

 For more options, visit https://groups.google.com/d/

Re: [gwt-contrib] Re: New JsInterop document

['Ray Cromwell' via GWT Contributors]

I think you might be able to get away with Async functions something like
this:

@JsFunction
interface AsyncFunction {
   T execute();
}

public class Foo {
   Promise fetchJson() {
   return Async.await(Xhr.fetch("/someJson")); // returns a
Promise
   }
}

public class Async {
   @MustBeInlined
   public static native  Promise await(Promise x) /*-{ yield x;
}-*/;
   public static native void makeFooAsync(Foo f) /*-{
 var old = f.@Foo::fetchJson;
 f.@Foo::fetchJson = function*() { return old.apply(f, arguments); }
   }-*/;
}

But I'm not sure. I prototyped a Linker approach to doing this by running
the output JS through the linker, finding all functions declared as @Async,
and adding 'async' keyword in front of them, then invoking BabelJS at the
end. I wrote about it in a G+ post and it works.

ES7 is quite a ways off so I'd probably suggest that for J2Cl this has to
be done with some kind of similar genrule to post process the JS.

It doesn't seem a stretch to imagine that Java annotations could be
harnessed to output decorators. @JsProperty is already a kind of decorator.

Personally, I think Symbols, Iterators, and Generators should be part of a
future JsInterop revision, regardless of whether Java has first class
support for them, there are always annotated or library based approaches
that can be used.


On Fri, Nov 13, 2015 at 1:51 PM, 'John Stalcup' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> Generally speaking J2CL seeks to support Java language features and in the
> process of doing so make use of modern ES6 features. When it comes to the
> separate topic of making advanced ES6 features (that don't exist in the
> Java language) available to J2CL users the path for that is via the
> JsInterop spec.
>
> To be specific:
>
> - J2CL currently outputs Closure goog.module()s instead of ES6 modules
> because no browser yet supports ES6 modules and we like having our output
> immediately runnable in the browser without a ES6to5 downsampling. When
> browsers support ES6 modules we are likely to switch.
> - When/if the Java language provides Decorators/Generators/Async
> functions we will transpile them
> - The JsInterop spec does not currently provide sugar for 
> Decorators/Generators/Async
> functions but it might in a future revision
> - You can already take advantage of Generators and Async functions (but
> probably not Decorators) by using JsInterop to expose a JS library to Java
> where that JS library exposes utility functions for Generators and Async
> functions
>
>
> On Fri, Nov 13, 2015 at 1:27 PM, Paul Stockley 
> wrote:
>
>> Do you plan on supporting these features in j2cl in the future?
>>
>> On Friday, November 13, 2015 at 4:23:21 PM UTC-5, Ray Cromwell wrote:
>>>
>>>
>>> You could probably support Modules via a GWT linker. Generators and
>>> Async functions could be done by a GWT Generator/Linker combo + BabelJS.
>>> There's no real plans to support ES6 in GWT, but you could arrange enough
>>> hacks with Generator/Linker/Library stuff to make GWT 2.x stuff consumable
>>> from ES6 code.
>>>
>>> On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley 
>>> wrote:
>>>
>>>> A number of the new frameworks (Angular 2, Aurelia)  are planning on
>>>> using ES6 and ES7 features such as Modules, Decorators, Generators and
>>>> Async functions etc. Are there plans to support these on the 2.x code base
>>>> or would these only be supported by j2cl in the future?
>>>>
>>>> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>>>>>
>>>>> As we are getting close to 2.8 release I wrote a new document that is
>>>>> concentrating on jsinterop features to be released in 2.8:
>>>>>
>>>>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>>>>
>>>>> Please share your feedback.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Goktug
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "GWT Contributors" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to
>>>> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%40googlegroups.com
>>>> <https://groups.google.com/d/

Re: [gwt-contrib] Re: New JsInterop document

['Ray Cromwell' via GWT Contributors]

You could probably support Modules via a GWT linker. Generators and Async
functions could be done by a GWT Generator/Linker combo + BabelJS.  There's
no real plans to support ES6 in GWT, but you could arrange enough hacks
with Generator/Linker/Library stuff to make GWT 2.x stuff consumable from
ES6 code.

On Fri, Nov 13, 2015 at 1:21 PM, Paul Stockley  wrote:

> A number of the new frameworks (Angular 2, Aurelia)  are planning on using
> ES6 and ES7 features such as Modules, Decorators, Generators and Async
> functions etc. Are there plans to support these on the 2.x code base or
> would these only be supported by j2cl in the future?
>
> On Friday, October 23, 2015 at 3:13:55 AM UTC-4, Goktug Gokdogan wrote:
>>
>> As we are getting close to 2.8 release I wrote a new document that is
>> concentrating on jsinterop features to be released in 2.8:
>>
>> https://docs.google.com/document/d/10fmlEYIHcyead_4R1S5wKGs1t2I7Fnp_PaNaa7XTEk0/edit#
>>
>> Please share your feedback.
>>
>> Thanks,
>>
>> Goktug
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8bed35c0-89a8-44df-8cb1-0ab4b7b73d53%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7frDE8%3DZ2iEhNnkbp9wwNNSNADKL1u%2BoLRrHHBFwZOYbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

['Ray Cromwell' via GWT Contributors]

It looks to me like it might be a type inferencing issue Roberto. Remember,
the lambda is matched to a SAM interface method. When it synthesizes the
implementation, it takes info from JDT about the 'expected type' which is
inferred by JDT. I wonder if the type inferred messes up type tightener
somehow. Here's something to try, put your lambda into a local var;

e.g.

Function foo = {data -> data.getAccount() etc}
service.get().getBootstrap().bootstrap().doOnNext(foo)

That way you force the param types to what you know they are.

I suppose another thing to try is to declare a type

service.get().getBootstrap().bootstrap().doOnNext(Data data -> .)

What I'm suspecting is that the compiler is seeing a different type for the
parameter somehow and inferring it is never instantiated.



On Mon, Oct 26, 2015 at 12:57 PM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> I said that optimize=0 fix errors, but I just compiled the project a get
> the same bootstrap+lamba error. But with draftCompile the result looks ok.
> // bootstrap case, lambda, pretty, draftCompile
> _.lambda$5 = function lambda$5(data_0){
>   $clinit_ApplicationBootstrapper();
>   var account, user;
>   {
> account = getAccount__Lshared_user_Account___devirtual$(data_0);
> if (isNull_2(account))
>   castTo(this.auth.get_1(), 242).resetSessionData(false);
> else
>   castTo(this.auth.get_1(), 242).setSessionData(account,
> getKeychain__LKeychain___devirtual$(data_0));
>
> castTo(this.theme.get_1(), 951).setCustomization(
> getCustomization__LCustomization___devirtual$(data_0));
> castTo(this.analytics.get_1(),7570).init_13(
> getAnalyticsUserAccount__Ljava_lang_String___devirtual$(data_0) +
> ':' +
> getAnalyticsDomainName__Ljava_lang_String___devirtual$(data_0));
> configureServer(getReverseGeocodingUrl__Ljava_lang_String___devirtual$
> (data_0));
> user = isNull_2(account)?'anonymous':
> getEmail__Ljava_lang_String___devirtual$(account);
> log_10.fine('Bootstrap data loaded successfully (user=' + user + ')');
>   }
> };
> defineClass(1672, 1, {1:1}, ApplicationBootstrapper$lambda$5$Type);
> _.call_0 = function call_3(arg0){
>   this.$$outer_0.lambda$5(arg0);
> };
> var Lclient_ApplicationBootstrapper$lambda$5$Type_2_classLit =
> createForClass('client', 'ApplicationBootstrapper/lambda$5$Type', 1672,
> Ljava_lang_Object_2_classLit);
>
>
>
> On Monday, October 26, 2015 at 8:27:41 PM UTC+1, Ignacio Baca
> Moreno-Torres wrote:
>
>> Bootstrap using lambda (fail)
>>
>> // java
>> return service.get().getBootstrap().bootstrap().doOnNext(data -> {
>> Account account = data.getAccount();
>> if (account == null) auth.get().resetSessionData(false);
>> else auth.get().setSessionData(account, data.getKeychain());
>> theme.get().setCustomization(data.getCustomization());
>> analytics.get().init(data.getAnalyticsUserAccount() + ":" + data.
>> getAnalyticsDomainName());
>> OsmQueryResolver.configureServer(data.getReverseGeocodingUrl());
>> final String user = account == null ? "anonymous" : account.getEmail
>> ();
>> log.fine("Bootstrap data loaded successfully (user=" + user + ")");
>> });
>> // javascript + pretty
>> function $lambda$5(this$static) {
>> var lastArg;
>> null .$_nullMethod();
>> $resetSessionData(castTo(this$static.auth.get_1(), 400), false);
>> $setCustomization((lastArg = castTo(this$static.theme.get_1(), 1067),
>> null .$_nullMethod(),
>> lastArg));
>> castTo(this$static.analytics.get_1(), 6137).init_2(null .$_nullMethod
>> () + ':' + null .$_nullMethod());
>> configureServer(null .$_nullMethod());
>> $fine_0(log_3, 'Bootstrap data loaded successfully (user=anonymous)'
>> );
>> }
>>
>>
>> ProcessResponse using anonymous class (success).
>>
>> // java
>> tracker.add(heads.subscribe(new Action1() {
>> @Override public void call(SubscriptionResponse response) {
>> ClientTelemetryStore.this.processResponse(response);
>> }
>> }));
>> // Javascript
>> defineClass(2064, 1, {}, ClientTelemetryStore$1);
>> _.call_0 = function call_145(response) {
>> $call_3(this, castToAllowJso(response, 6180));
>> };
>> function $call_3(this$static, response) {
>> $processResponse(this$static.this$01, response);
>> }
>> function $processResponse(this$static, response) {
>> var newUnits, xs, xs$iterator, xs$iterator0;
>> requireNonNull_0(response, 'response required');
>> requireNonNull_0(response.uuid, 'response.uuid required’);
>>
>>
>> ProcessResponse using lambda (fail).
>>
>> // Java
>> tracker.add(heads.subscribe(response -> { ClientTelemetryStore.this.
>> processResponse(response); }));
>> // Javascript
>> defineClass(2063, 1, {}, ClientTelemetryStore$lambda$3$Type);
>> _.call_0 = function call_153(arg0) {
>> $processResponse(this.$$outer_0, throwClassCastExceptionUnlessNull(
>> arg0));
>> };
>> function $processResponse(this$static, response) {
>> var newUnits, xs, xs$iterator, x

Re: [gwt-contrib] GWT compiler optimization breaks some lambdas

['Ray Cromwell' via GWT Contributors]

Are you using @JsFunction/JsInterop? Unless the implementation has changed
recently, Lambda's are supported in GWT by essentially synthesizing static
inner classes, and so if static inner classes work, but lambda's don't,
it's really weird. The optimization stages no nothing of lambdas and only
see Java classes. The exception is @JsFunction.


On Sat, Oct 24, 2015 at 2:37 PM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> This was from 94e45975a06ece1b8d65541aaabf833f9d8c7b07 (6 October 2015 at
> 04:29:19 GMT+2), I'll try tomorrow with HEAD, but looking the commits
> looks improbable that the problem has been solved.
>
> On Sat, Oct 24, 2015 at 10:30 PM 'Roberto Lublinerman' via GWT
> Contributors  wrote:
>
>> Are you using a recent snapshot?
>> On Oct 24, 2015 04:40, "Ignacio Baca Moreno-Torres" 
>> wrote:
>>
>>> There is a bug which optimizations nullify variables which might not be
>>> null. I'm trying to reproduce the error outside our app but I can't, I'll
>>> continue trying, but for now I going to describe the problem.
>>>
>>> return service.get().getBootstrap().bootstrap().doOnNext(data -> {
>>> Account account = data.getAccount();
>>> if (account == null) auth.get().resetSessionData(false);
>>> else auth.get().setSessionData(account, data.getKeychain());
>>> theme.get().setCustomization(data.getCustomization());
>>> analytics.get().init(data.getAnalyticsUserAccount() + ":" + 
>>> data.getAnalyticsDomainName());
>>> OsmQueryResolver.configureServer(data.getReverseGeocodingUrl());
>>> final String user = account == null ? "anonymous" : account.getEmail();
>>> log.fine("Bootstrap data loaded successfully (user=" + user + ")");
>>> });
>>>
>>> Produces the next js code.
>>> function fie(a) {
>>> var b;
>>> null .b1();
>>> bdf(Tub(a.b.Ee(), 388), false);
>>> Ujf((b = Tub(a.k.Ee(), 937),
>>> null .b1(),
>>> b));
>>> Tub(a.a.Ee(), 6122).VI(null .b1() + ':' + null .b1());
>>> Ivg(null .b1());
>>> U_l(cie, 'Bootstrap data loaded successfully (user=anonymous)')
>>> }
>>> BUT! if compile without optimizations (ex. using draft compile) or if
>>> anonymous class is used instead of a lambda, the output js is ok. Next
>>> block contains my current working code.
>>>
>>> //noinspection Convert2Lambda GWT optimize incompatible
>>> return service.get().getBootstrap().bootstrap().doOnNext(new 
>>> Action1() {
>>> @Override public void call(EntryPointData data) {
>>>
>>>
>>> The bootstrap method is a call of reactive restygwt service using this
>>> proyect https://github.com/ibaca/restygwt-rxadapter. I.e. bootstrap
>>> return an Observable which end up making a XMLHttpRequest (a lot of layer
>>> in between), and data is a EntryPoint interface, and the implementation
>>> received is an overlay.
>>>
>>> I know that with this info is almost impossible to discover the problem,
>>> but I put here to see if someone else have similar problem, and maybe some
>>> gwt compiler developer just seeing that may see where is the problem
>>> (improbable). If a get reproduced in a sample project I write back here.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/89de2084-b91d-415e-8f68-2bdb3159f702%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gn0j4oyMbkCkYGWHG2H4zgVwALGGZqQUTb%3DBjEZ4DbSiQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABVWDC7nOgq10%3D8ospVDQUgw22ACDXy%2B0L6g%2BY9meoA4wG9GVw%40mail.gmail.com
> 

Re: [gwt-contrib] Re: GWT compiler optimization breaks some lambdas

['Ray Cromwell' via GWT Contributors]

Does it still happen if you use an anonymous inner class instead of a
lambda?

On Sat, Oct 24, 2015 at 4:54 AM, Ignacio Baca Moreno-Torres <
igna...@bacamt.com> wrote:

> Other situation producing the same problem. If next code is replaced by
> lambda and method reference... the next block end up being optimized as if
> response is always null.
>
> //noinspection Convert2Lambda,Anonymous2MethodRef IGP-1732 gwt optimize 
> incompatible
> tracker.add(heads.subscribe(new Action1() {
> @Override public void call(SubscriptionResponse response) {
> ClientTelemetryStore.this.processResponse(response);
> }
> }));
>
> The processResponse java code.
>
> private void processResponse(SubscriptionResponse response) {
> Objects.requireNonNull(response, "response required");
> Objects.requireNonNull(response.getUuid(), "response.uuid required");
> if (uuid == null) uuid = response.getUuid(); // first response
> else assert uuid.equals(response.getUuid()) : "subscription uuid 
> mismatch";
> boolean newUnits = false;
> for (UnitDescriptor xs : response.getUnits()) {
> newUnits |= processUnitCreate(xs);
> }
> for (ProtoUnit xs : response.getData()) {
> processUnitUpdate(xs);
> }
> // accumulate change updates per response
> if (newUnits) tStoresChange.onNext(tStores);
> }
>
> And processResponse js code.
> function Hak(a, b) {
> var c, d, e, f;
> lWl(b, 'response required');
> lWl(null ._0(), 'response.uuid required');
> a.g = null ._0();
> c = false;
> for (f = null ._0()._0(); f.Nd(); ) {
> d = Vub(f.Od());
> c = c | Iak(a, d)
> }
> for (e = null ._0()._0(); e.Nd(); ) {
> d = Uub(e.Od(), 6163);
> Jak(a, d)
> }
> c && lrm(a.d, a.c)
> }
>
> On Saturday, October 24, 2015 at 1:40:24 PM UTC+2, Ignacio Baca
> Moreno-Torres wrote:
>>
>> There is a bug which optimizations nullify variables which might not be
>> null. I'm trying to reproduce the error outside our app but I can't, I'll
>> continue trying, but for now I going to describe the problem.
>>
>> return service.get().getBootstrap().bootstrap().doOnNext(data -> {
>> Account account = data.getAccount();
>> if (account == null) auth.get().resetSessionData(false);
>> else auth.get().setSessionData(account, data.getKeychain());
>> theme.get().setCustomization(data.getCustomization());
>> analytics.get().init(data.getAnalyticsUserAccount() + ":" + 
>> data.getAnalyticsDomainName());
>> OsmQueryResolver.configureServer(data.getReverseGeocodingUrl());
>> final String user = account == null ? "anonymous" : account.getEmail();
>> log.fine("Bootstrap data loaded successfully (user=" + user + ")");
>> });
>>
>> Produces the next js code.
>> function fie(a) {
>> var b;
>> null .b1();
>> bdf(Tub(a.b.Ee(), 388), false);
>> Ujf((b = Tub(a.k.Ee(), 937),
>> null .b1(),
>> b));
>> Tub(a.a.Ee(), 6122).VI(null .b1() + ':' + null .b1());
>> Ivg(null .b1());
>> U_l(cie, 'Bootstrap data loaded successfully (user=anonymous)')
>> }
>> BUT! if compile without optimizations (ex. using draft compile) or if
>> anonymous class is used instead of a lambda, the output js is ok. Next
>> block contains my current working code.
>>
>> //noinspection Convert2Lambda GWT optimize incompatible
>> return service.get().getBootstrap().bootstrap().doOnNext(new 
>> Action1() {
>> @Override public void call(EntryPointData data) {
>>
>>
>> The bootstrap method is a call of reactive restygwt service using this
>> proyect https://github.com/ibaca/restygwt-rxadapter. I.e. bootstrap
>> return an Observable which end up making a XMLHttpRequest (a lot of layer
>> in between), and data is a EntryPoint interface, and the implementation
>> received is an overlay.
>>
>> I know that with this info is almost impossible to discover the problem,
>> but I put here to see if someone else have similar problem, and maybe some
>> gwt compiler developer just seeing that may see where is the problem
>> (improbable). If a get reproduced in a sample project I write back here.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/9dd3316c-68f5-4ed9-8d8c-c7a34f123109%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] elemental.Json broken with 2.8-SNAPSHOT

['Ray Cromwell' via GWT Contributors]

Ok I'll take a look, it's probably my unboxing patch. Is this devmode or
web?

On Monday, September 7, 2015, Leif Åstrand  wrote:

> The latest 2.8-SNAPSHOT seems quite broken at least with elemental.Json.
>
> This fails in compiled mode, while hosted passes: assertEquals(JsonType.
> BOOLEAN, Json.create(true).getType());
>
> This worked on Friday, but is broken today after downloading a new
> snapshot.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
> 
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/629fb668-ea69-43aa-88b8-54b5801412a2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7erLnw6RORFhNMPoXmFW%3DMCKX9NZh3wHRORi0A-Lf%2BVwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Class literals for JsTypes in superdevmode

['Ray Cromwell' via GWT Contributors]

ok, taking a look


On Tue, Jun 9, 2015 at 11:38 AM, 'Roberto Lublinerman' via GWT Contributors
 wrote:

> I tweaked the code a bit and now it should never output duplicated class
> literals. @Ray, Could you review the patch?
>
> On Tue, Jun 9, 2015 at 10:31 AM, 'Ray Cromwell' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> I don't think it's an issue that blocks since people are most likely to
>> use SDM in uncompiled mode, and the 'error' can always be suppressed and
>> turned into a warning. At best, it might inhibit a const optimization in
>> Closure where it sees the same variable declared/assigned twice I think.
>>
>>
>> On Tue, Jun 9, 2015 at 10:27 AM, 'Roberto Lublinerman' via GWT
>> Contributors  wrote:
>>
>>> SDM expects that classes/interfaces get generated as a whole either all
>>> of it or none. As you know, class literals are not really part of the class
>>> but they are field in a separate synthetic class). Even SDM (with all
>>> optimizations off, no pruning at UnifyAST) if a reference to the class
>>> literal is not seen when generating the JS for the class then its class
>>> literal field wont be part of the JS for the class.
>>>
>>> For SDM it could only happen for interfaces (and maybe primitive types)
>>> because GwtAstBuilder will synthezise a getClass for each class containing
>>> reference to its class literals.
>>>
>>> The problem is further obscured because we (re)generate an epilogue each
>>> time and it contains all the class literals that are referenced from the
>>> code that is being recompiled whose classes where not part of the current
>>> compile. This serves a purpose in NON SDM where if only the class literal
>>> for a class is referenced, the class can be pruned.
>>>
>>> The only glitch remaining is that in SDM there might be duplicated class
>>> literals (but it should not affect the correctness). Is this an issue for
>>> Closure?
>>>
>>> On Tue, Jun 9, 2015 at 9:48 AM, 'Ray Cromwell' via GWT Contributors <
>>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>>
>>>> Chris,
>>>>   My change actually fixed a bug which may have obscured a problem.
>>>> There were duplicate class literals being generated. So you'd get
>>>> InterfaceFoo.class twice in the output, and it may be in SDM you'd be
>>>> covered, but in regular compiled mode you'd get the duplicates which were
>>>> causing closure compiler issues.
>>>>
>>>>  Roberto,  Maybe this is an issue with
>>>> ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
>>>>
>>>>
>>>> On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors <
>>>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>>>
>>>>> @Ray, rolling back your change indeed fixed the problem (
>>>>> https://gwt-review.googlesource.com/#/c/12311/). How do you recommend
>>>>> we proceed? Anything I can do to help?
>>>>>
>>>>> @Roberto, thanks for your suggestion, but I had already tried
>>>>> restarting the code server and clearing the cache. This did not fix 
>>>>> things.
>>>>>
>>>>> Chris
>>>>>
>>>>> On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT
>>>>> Contributors  wrote:
>>>>>
>>>>>> This might be due to the way we handle class literals. Class literals
>>>>>> for interfaces if not referenced during the initial compile might cause
>>>>>> that error. The error should go aways if you restart SDM.
>>>>>>
>>>>>> The offending sequence is
>>>>>>
>>>>>> 0) Suppose initially you have (interface A, class B and class C) and
>>>>>> start SDM.
>>>>>> 1) Now edit class B to add a reference to A.class and recompile with
>>>>>> SDM (do not touch A at this time nor anything that makes it recompile) .
>>>>>> This should work fine because the literals that are referenced but whose
>>>>>> classes where not part of this compile will be generated in the epilogue.
>>>>>> 2) Now edit class C in any way that does not make B or A recompile.
>>>>>> Here you will have an error like the one you des

Re: [gwt-contrib] Class literals for JsTypes in superdevmode

['Ray Cromwell' via GWT Contributors]

I don't think it's an issue that blocks since people are most likely to use
SDM in uncompiled mode, and the 'error' can always be suppressed and turned
into a warning. At best, it might inhibit a const optimization in Closure
where it sees the same variable declared/assigned twice I think.


On Tue, Jun 9, 2015 at 10:27 AM, 'Roberto Lublinerman' via GWT Contributors
 wrote:

> SDM expects that classes/interfaces get generated as a whole either all of
> it or none. As you know, class literals are not really part of the class
> but they are field in a separate synthetic class). Even SDM (with all
> optimizations off, no pruning at UnifyAST) if a reference to the class
> literal is not seen when generating the JS for the class then its class
> literal field wont be part of the JS for the class.
>
> For SDM it could only happen for interfaces (and maybe primitive types)
> because GwtAstBuilder will synthezise a getClass for each class containing
> reference to its class literals.
>
> The problem is further obscured because we (re)generate an epilogue each
> time and it contains all the class literals that are referenced from the
> code that is being recompiled whose classes where not part of the current
> compile. This serves a purpose in NON SDM where if only the class literal
> for a class is referenced, the class can be pruned.
>
> The only glitch remaining is that in SDM there might be duplicated class
> literals (but it should not affect the correctness). Is this an issue for
> Closure?
>
> On Tue, Jun 9, 2015 at 9:48 AM, 'Ray Cromwell' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> Chris,
>>   My change actually fixed a bug which may have obscured a problem. There
>> were duplicate class literals being generated. So you'd get
>> InterfaceFoo.class twice in the output, and it may be in SDM you'd be
>> covered, but in regular compiled mode you'd get the duplicates which were
>> causing closure compiler issues.
>>
>>  Roberto,  Maybe this is an issue with
>> ControlFlowRecorder/RapidTypeAnalyzer and interface literals?
>>
>>
>> On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> @Ray, rolling back your change indeed fixed the problem (
>>> https://gwt-review.googlesource.com/#/c/12311/). How do you recommend
>>> we proceed? Anything I can do to help?
>>>
>>> @Roberto, thanks for your suggestion, but I had already tried restarting
>>> the code server and clearing the cache. This did not fix things.
>>>
>>> Chris
>>>
>>> On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT
>>> Contributors  wrote:
>>>
>>>> This might be due to the way we handle class literals. Class literals
>>>> for interfaces if not referenced during the initial compile might cause
>>>> that error. The error should go aways if you restart SDM.
>>>>
>>>> The offending sequence is
>>>>
>>>> 0) Suppose initially you have (interface A, class B and class C) and
>>>> start SDM.
>>>> 1) Now edit class B to add a reference to A.class and recompile with
>>>> SDM (do not touch A at this time nor anything that makes it recompile) .
>>>> This should work fine because the literals that are referenced but whose
>>>> classes where not part of this compile will be generated in the epilogue.
>>>> 2) Now edit class C in any way that does not make B or A recompile.
>>>> Here you will have an error like the one you described.
>>>>
>>>> If you restart SDM at this point it should work.
>>>>
>>>> I'll get a fix for this tomorrow.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors <
>>>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>>>
>>>>> Ooops, wrong pointer (for external users) This one
>>>>> https://gwt-review.googlesource.com/#/c/12311/
>>>>>
>>>>>
>>>>> On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell 
>>>>> wrote:
>>>>>
>>>>>> Try rolling back this CL and see if it fixes it (
>>>>>> https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
>

Re: [gwt-contrib] Class literals for JsTypes in superdevmode

['Ray Cromwell' via GWT Contributors]

Chris,
  My change actually fixed a bug which may have obscured a problem. There
were duplicate class literals being generated. So you'd get
InterfaceFoo.class twice in the output, and it may be in SDM you'd be
covered, but in regular compiled mode you'd get the duplicates which were
causing closure compiler issues.

 Roberto,  Maybe this is an issue with
ControlFlowRecorder/RapidTypeAnalyzer and interface literals?


On Tue, Jun 9, 2015 at 9:43 AM, 'Chris DiGiano' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> @Ray, rolling back your change indeed fixed the problem (
> https://gwt-review.googlesource.com/#/c/12311/). How do you recommend we
> proceed? Anything I can do to help?
>
> @Roberto, thanks for your suggestion, but I had already tried restarting
> the code server and clearing the cache. This did not fix things.
>
> Chris
>
> On Mon, Jun 8, 2015 at 6:55 PM 'Roberto Lublinerman' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> This might be due to the way we handle class literals. Class literals for
>> interfaces if not referenced during the initial compile might cause that
>> error. The error should go aways if you restart SDM.
>>
>> The offending sequence is
>>
>> 0) Suppose initially you have (interface A, class B and class C) and
>> start SDM.
>> 1) Now edit class B to add a reference to A.class and recompile with SDM
>> (do not touch A at this time nor anything that makes it recompile) . This
>> should work fine because the literals that are referenced but whose classes
>> where not part of this compile will be generated in the epilogue.
>> 2) Now edit class C in any way that does not make B or A recompile. Here
>> you will have an error like the one you described.
>>
>> If you restart SDM at this point it should work.
>>
>> I'll get a fix for this tomorrow.
>>
>>
>>
>>
>> On Mon, Jun 8, 2015 at 3:23 PM, 'Ray Cromwell' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> wrote:
>>
>>> Ooops, wrong pointer (for external users) This one
>>> https://gwt-review.googlesource.com/#/c/12311/
>>>
>>>
>>> On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell 
>>> wrote:
>>>
>>>> Try rolling back this CL and see if it fixes it (
>>>> https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
>>>> )
>>>>
>>>>
>>>> On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano  wrote:
>>>>
>>>>> I'm having trouble referencing a JsType interface when running under
>>>>> superdevmode. I'm trying to pass the JsType as a class reference to a
>>>>> method that uses the class to coerce the results into the expected type:
>>>>>
>>>>> myelement.getCustomStampedElement("dialog",
>>>>> PolymerDialog.class).open();
>>>>>
>>>>> Unfortunately, in superdevmode (and only in SDM) I get this error:
>>>>>
>>>>> Uncaught ReferenceError:
>>>>> Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
>>>>> is not defined
>>>>>
>>>>> PolymerDialog is declared like this:
>>>>>
>>>>> @JsType
>>>>> public interface PolymerDialog {
>>>>>   void open();
>>>>> }
>>>>>
>>>>> and getCustomStampedElement is defined like this:
>>>>>
>>>>> /**
>>>>>  * Returns the element specified in this custom element's template
>>>>> that matches the given id
>>>>>  * with the result coerced to a non-vanilla element type.
>>>>> Equivalent to Polymer's $ function.
>>>>>  *
>>>>>  * @see
>>>>>  * https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
>>>>> ">
>>>>>  * Polymer automatic node finding
>>>>>  */
>>>>>  T getCustomStampedElement(String id, Class type);
>>>>>
>>>>> It appears that the PolymerDialog JsType is being left out of the list
>>>>> of class literals available in superdevmode. Is this a bug? Any ideas for
>>>>> workarounds?
>>>>>
>>>>> 

Re: [gwt-contrib] Class literals for JsTypes in superdevmode

['Ray Cromwell' via GWT Contributors]

Ooops, wrong pointer (for external users) This one
https://gwt-review.googlesource.com/#/c/12311/


On Mon, Jun 8, 2015 at 3:14 PM, Ray Cromwell  wrote:

> Try rolling back this CL and see if it fixes it (
> https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
> )
>
>
> On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano  wrote:
>
>> I'm having trouble referencing a JsType interface when running under
>> superdevmode. I'm trying to pass the JsType as a class reference to a
>> method that uses the class to coerce the results into the expected type:
>>
>> myelement.getCustomStampedElement("dialog",
>> PolymerDialog.class).open();
>>
>> Unfortunately, in superdevmode (and only in SDM) I get this error:
>>
>> Uncaught ReferenceError:
>> Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
>> is not defined
>>
>> PolymerDialog is declared like this:
>>
>> @JsType
>> public interface PolymerDialog {
>>   void open();
>> }
>>
>> and getCustomStampedElement is defined like this:
>>
>> /**
>>  * Returns the element specified in this custom element's template
>> that matches the given id
>>  * with the result coerced to a non-vanilla element type. Equivalent
>> to Polymer's $ function.
>>  *
>>  * @see
>>  * https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
>> ">
>>  * Polymer automatic node finding
>>  */
>>  T getCustomStampedElement(String id, Class type);
>>
>> It appears that the PolymerDialog JsType is being left out of the list of
>> class literals available in superdevmode. Is this a bug? Any ideas for
>> workarounds?
>>
>> Chris DiGiano
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Class literals for JsTypes in superdevmode

['Ray Cromwell' via GWT Contributors]

Try rolling back this CL and see if it fixes it (
https://critique.corp.google.com/#review/92873682/depot/google3/third_party/java_src/gwt/svn/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java
)


On Mon, Jun 8, 2015 at 3:04 PM, Chris DiGiano  wrote:

> I'm having trouble referencing a JsType interface when running under
> superdevmode. I'm trying to pass the JsType as a class reference to a
> method that uses the class to coerce the results into the expected type:
>
> myelement.getCustomStampedElement("dialog",
> PolymerDialog.class).open();
>
> Unfortunately, in superdevmode (and only in SDM) I get this error:
>
> Uncaught ReferenceError:
> Lcom_google_ccc_groups_rosters_frontend_polymer_jstype_PolymerDialog_2_classLit_0_g$
> is not defined
>
> PolymerDialog is declared like this:
>
> @JsType
> public interface PolymerDialog {
>   void open();
> }
>
> and getCustomStampedElement is defined like this:
>
> /**
>  * Returns the element specified in this custom element's template
> that matches the given id
>  * with the result coerced to a non-vanilla element type. Equivalent
> to Polymer's $ function.
>  *
>  * @see
>  * https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
> ">
>  * Polymer automatic node finding
>  */
>  T getCustomStampedElement(String id, Class type);
>
> It appears that the PolymerDialog JsType is being left out of the list of
> class literals available in superdevmode. Is this a bug? Any ideas for
> workarounds?
>
> Chris DiGiano
>
>  --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/9826758e-1b0f-4797-8902-738a1fade037%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7e%3DDigWWWfxi%3DeBt70zU-yMOYzQp2yFLxPo%2Bnq%2BnKfEJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Ray Cromwell' via GWT Contributors]

There are multiple things JsInterop needs to accomplish:

1) preventing method/field renames
2) pinning methods (preventing code pruning)
3) giving a global name/namespace alias to something
4) auto-converting parameters to allow idiomatic programming
5) allowing GWT objects to extend native objects

@JsType actually combines #1/#2/#5 (although it only pins methods if the
object is instantiated)
@JsExport combines #2 and #3 (it not only pins a method, but treats the
type as instantiable, plus it gives it a global alias)

#4 is handled by @JsConvert/JsAware/JsFunction

#5 is handled by @JsType(prototype="...")

Goktug is trying separate out the behavior into the 5 types of interop
semanics:

1) a way of indicating a method/field should not be renamed
2) a way of indicating not to prune something
3) a way of indicating giving a global alias to something
4) a way of indicating something extends a native object

There are cases where you want to prevent renaming, but allow dead code
elimination.

You could make these separate annotations, that's matter of aesthetics, e.g.

@JsPin
@JsExport
@JsName
@JsPrototype

etc



On Sat, May 9, 2015 at 2:34 PM, Alex White  wrote:

> +1 to keeping the original system. For an interface a finite number of
> types > infinite number of String parameters.
> Once it gets properly documented on gwtproject.org I doubt people will
> consider it confusing. The problem imo is that most of the existing stuff
> out there is pseudocode.
>
> We just started using JsInterop and the only stumbling block we
> encountered was that at first we weren't using @JsNamespace.
> The other thing we have found is really weird bugs in some of the
> nightlies a few days ago, like types deleted from our codebase still
> existing and other new types not existing.
> It was from about 4-7 days ago and seems to have stopped now. It may be
> related to the sourcemaps. The emergent behavior was that after a hard
> cache reset Chrome would be trying to fetch a sourcemap for a deleted type.
> If we grepped for that symbol in our codebase, we would find references to
> it despite it being long gone in a cleanly built proj. Does the gwt
> compiler keep some state information hidden somewhere on the hd? Because
> that was weird.
>
>
>
> On Wednesday, April 22, 2015 at 4:42:10 AM UTC+10, Goktug Gokdogan wrote:
>
>> There is some upcoming changes to JsInteorp in preparation toward v1.0
>> release.
>>
>> The most major change is to the annotations and their meanings. Here is
>> the doc explaining the changes and the reasoning. We are looking for your
>> feedback, especially on alternatives.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Issues with existing design and annotations 1. @JsExport/@JsType slicing
>> is not intuitive for a lot of people esp. with gwt-exporter background.
>> People are confused about when to use what.2. There is no reason to why
>> @JsType doesn’t have any effect on the static methods. That is only because
>> of the original use cases that the design was tackling only cared about
>> well formed prototypal structures. Diving deeper into Elemental and
>> different javascript output styles, ability to define the full class
>> structure without exporting proves to be useful.3. @JsExport uses @JsType
>> to define the prototype structure. However this imposes unnecessary
>> restriction if/when there will be no javascript implementers of the @JsType
>> contract. @JsType that extends non-JsType is normally ok if it is not
>> implemented in js.4. You always need to fully qualify the name of the
>> export even if you just want to change the simple name.The New Annotation
>> SystemThere will be single annotation called @Js. Applying @Js to a member
>> is making that member available in javascript without any obfuscation.
>> However it is not safe from pruning if there are no references in java
>> code, so one needs to put enable exporting for the type if no pruning
>> wanted. Applying @Js at class level should considered as a shortcut to
>> apply @Js to all members. See following chart for the attributes and their
>> corresponding behavior:@JsType@Js(exports =
>> INSTANCE_MEMBERS)@JsFunction@Js(mode = FUNCTION)@JsLiteral@Js(mode =
>> LITERAL)@JsMethod@Js(name = "myName")@JsProperty@Js(property =
>> true)@Js(name = "myName", property = true)@JsNamespace@Js(namespace =
>> "mynamespace")@JsExport@Js(exports = STATIC_MEMBERS)@Js(name = “A”, exports
>> = ALL)@Js(name = “A”, namespace=”a.b.c.”, exports = ALL)// When applied to
>> a member@Js(export = true)@Js(name = “myName”, export =
>> true)@JsNoExport@Js(ignore=true)@JsOpaque@Js(opaque=true)See Appendix below
>> for a complete comparison to existing annotations.Semantics /
>> Implementation in GWTImplementation: - Apply all Js names as bridge methods
>> (or the reverse if Js extends Java object case
>> 
>> needs to be supported)

Re: [gwt-contrib] Re: Experience with JsInterop status

['Ray Cromwell' via GWT Contributors]

Lambda's are inner classes, so there is always a 'this' bound to the
generated instance, otherwise, the handling method wouldn't be invokable.
Imagine if you were implementing this with JSNI:

class HandlerWithThisImpl implements HandlerWithThis {
   public void onEvent(Element target, Event e) { ... }
}

You'd have to write a wrapper that did this:

static native JavaScriptObject makeFunction(HandlerWithThis impl) /*-{
return function(e) { impl.@onEvent(*)(this, e); }
}-*/;

But to make referential integrity work so that a HandlerWithThis passing
into JS and back into Java always converts to the same function and object
reference, you'd have to generate a lot more boilerplate.


Instead, to make @JsThis work efficiently, you'd have to do something like
this with the magic makeLambdaFunction

/**
 * Create a function that applies the specified samMethod on itself,
and whose __proto__ points to
 * instance.
 */
public static native JavaScriptObject
makeLambdaFunction(JavaScriptObject samMethod,
JavaScriptObject instance, int jsThisArgPosition) /*-{
  var lambda = function() {
var args = arguments;
if (jsThisArgPosition >= 0) {
  args.splice(jsThisArgPosition, 0, this);
}
return samMethod.apply(lambda, args);
  }
  lambda.__proto__ = instance;
  return lambda;
}-*/;

It's feasible, but I think the community needs to chime in.  IIRC, the DOM
APIs have changed over the years to include the context as a field of the
event argument.

But perhaps when you look at libraries like Ember, Angular, React,
Backbone, et al, all common is it for the 'this' to be bound, passing this
explicitly as a parameter?

Typical Google coding style internally is if you want to use this, you use
Function.bind() to set it to what you want when you pass in a handler
function to something.

Rebinding this from the calling context seems iffy and dangerous when you
think about Java code.




On Wed, Apr 29, 2015 at 12:32 AM, Marcin Okraszewski 
wrote:

>
>>>1. @JsFunction exported to JS doesn't have apply() and call()
>>> operations. Apply() is used by JQuery (2.1.3) to call callbacks, so
>>>basically it wasn't possible to add handlers using JQuery. See other 
>>> thread
>>>on this:
>>>https://groups.google.com/forum/#!topic/google-web-toolkit/PHtfLTSAJDM
>>>
>>>
>>> Pretty interesting how to model that JQuery callback with JsInterop.
>> Basically when you do $("p").click(handler) then JQuery sets "this" for the
>> handler to the element the event occurred on so you can do
>>
>> $("p").click(function() {
>>$(this).slideUp(); // slides the clicked p element up
>> });
>>
>> I think you can't really do that with just JsInterop. I think your Java
>> callback must be JQueryCallback.exec(Element elem, Event e) and you have to
>> use JSNI to create a pure JS function that passes "this" as "elem" to the
>> JQueryCallback.
>>
>
>
> This is definitely problematic. I didn't give it too much though, but I
> think it would be great if we could opt-in to get the *this* from
> JavaScript. Something like this:
>
> @JsFunction
> public interface HandlerWithThis {
>public void onEvent(*@JsThis* Element target, Event e);
> }
>
> If you need the JavaScript *this,* then you just add it as parameter to
> method with @JsThis annotation. As currently @JsFunction is not a
> JavaScript function, but an object that pretend the function, it should be
> possible to implement apply() and call() in such a way, that it passes this
> if there is a @JsThis parameter in the method signature. In case you don't
> need *this*, you just don't specify such parameter; in such case the
> method signature would be void onEvent(Event e). This would be much nicer
> then telling, you need to go to JSNI to do that.
>
> Do you think it could be done like this?
>
> Thanks,
> Marcin
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/97624985-35bf-48d6-b187-76181d9b8672%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7e-HtaWNMSHWUQM8zkeGS1Ncz1hKaJiFr4_Occ4kArNFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Upcoming overhaul to JsInterop annotations in preparation towards v1.0 release

['Ray Cromwell' via GWT Contributors]

Goktug, I though we were keeping @JsType and others as syntactic sugar?


On Tue, Apr 21, 2015 at 5:40 PM, Jens  wrote:

> Damn it, Safari crashed. So now a shorter version of my answer:
>
> First I agree that the current design has become quite confusing.
> Personally I really dislike the single @Js annotation approach because:
> - can be applied everywhere so you throw away some compile time checks
> provided by Java's @Target annotation
> - exports vs. export is a bit misleading. One must be used with
> interfaces/classes the other with methods. That issue only exists because
> @Js alone has no real meaning.
> - You have to type more because it is always annotation name + property +
> value if you can't stick with the default "@Js".
> - Can't see a good use case for splitting exports in ALL, INSTANCE_MEMBERS
> and STATIC_MEMBERS. When I want to export a class I want to export its
> public API.
>
>
> Personally what describes JsInterop best is the alternative using the
> import/export concepts. So I would stick with:
>
> Import/Export types:
>
> @JsImport: can only be applied on interfaces.
> @JsExport: always exports all public API in a given scope (package, class,
> method). So no ALL, INSTANCE_MEMBER, STATIC_MEMBER distinction. @JsIgnore
> can be used to opt-out selectively.
>
> Configure import/export:
>
> @JsNamespace: import/export from/to namespace
> @JsName: workaround reserved keywords
> @JsProperty: mark method as JS property
> @JsIgnore: opt-out of export. Might even be useful for import, e.g. do not
> generate trampoline for annotated default method.
>
> Special constructs:
>
> @JsLiteral
> @JsFunction (currently it seems not to be a real function which breaks
> interop
> 
> )
>
>
> I guess that is the cleanest you can get. Not sure what @JsOpaque is good
> for?!
>
> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7ec1A4w4sb4ZN9wpruLg7K%2BrdnQq3nC0LXtSCK2N5%3DBeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JsInterop Generator from webidl

['Ray Cromwell' via GWT Contributors]

Yes, there is a version under development based on html5index.org (
https://github.com/tidej/html5index)

On Wed, Apr 1, 2015 at 8:39 PM, Stefano Ciccarelli 
wrote:

> http://www.gwtproject.org/articles/elemental.html
>
> Is it the same?
>
>
> Il giorno mer 1 apr 2015 alle 23:32 nick936  ha
> scritto:
>
>> Hi,
>> while playing with the new JsInterop feature i decided to write a code
>> generator which generate the interfaces out of webidls fetched from
>> https://html.spec.whatwg.org/ or the mozilla repository. Yesterday i
>> started this littel project. It's a prototype and far away from being
>> stable, but enough to use the generated interfaces for test purposes. I did
>> a rather quick and dirty just to use the interfaces my internal test
>> project and the code needs some refactoring. I used ANTLR4, javasoup and
>> javapoet. You can find the sources in this github repo
>> https://github.com/Nickel671/JsInteropGenerator. You can find the
>> generated Interfaces here
>> https://github.com/Nickel671/JsInteropGenerator/tree/master/target/generated-sources/gwt/org/niklas/elemental/Elemental/client/elements.
>> If you are interested in this i will improve it.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d32b27c4-a1eb-40cb-9720-3d1f6c535b03%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAK5-kh41Zt_3pz9JdBg5AW3seRCGBGZ8tyk2HK6oqMJj_qqCiw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7f8pKKAQMHjC7Nsm0sS%2Bpbt9NdaiPavcTcHw%2BT3ievn-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: How to get the full StackTrace when using SuperDevMode in GWT 2.7?

['Ray Cromwell' via GWT Contributors]

He said he's not using Chrome, he's using Safari, which I don't think
respects the displayName feature. We can't rely on cross-browser
debugging supporting a client-side Chrome proprietary feature. IDEs
and SDM need to support source-map/symbolmap based log deobfuscation.

On Mon, Dec 8, 2014 at 1:40 PM, 'Goktug Gokdogan' via GWT Contributors
 wrote:
>
>
> On Mon, Dec 8, 2014 at 1:00 PM, confile 
> wrote:
>>
>> I use GWT-PhoneGap on an iPhone5 and Super Dev Mode. SDM works file. I use
>> the Safari console for logging.
>>
>
> The problem is you shouldn't be seeing obfuscated method names in GWT 2.7
> SDM as incremental compiler uses pretty names. You should see "at
> Unknown.somethingMeaningfulHere$(Unknown Source)" instead of "at
> Unknown.gPc_g$(Unknown Source)" without stacktrace deobfuscation.
>
>> It would be great if you could provide an example of how
>> StackTraceDeobfuscation worked. I see there is a lack in the documentation.
>>
>> Michael
>>
>>
>> Am Montag, 8. Dezember 2014 21:28:56 UTC+1 schrieb Goktug Gokdogan:
>>>
>>> The stack traces that are logged as escaped exceptions (with missing
>>> causes) and the ones that are logged by Logger (without inheriting
>>> c.g.gwt.logging) will be deobfuscated by Chrome dev tools (if haven't
>>> already fixed in Dev channel).
>>> Being said that, I don't understand why you are not seeing pretty names
>>> for your methods. Are you not using incremental?
>>>
>>> On Mon, Dec 8, 2014 at 10:25 AM, Jens  wrote:
>
> I use it like this:
>
> GWT.setUncaughtExceptionHandler(new
> SuperDevModeUncaughtExceptionHandler());

 Then just throw an exception somewhere in your app that you do not catch
 yourself. The handler does not fix your java.util.logging.Logger or
 GWT.log() calls.

 But as you are using Safari you might not get any benefit of it anyways.
 In that case, as already said, your only chance is to use remote logging 
 and
 use StackTraceDeobfuscator on a server to make the exception readable.

 -- J.

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

 For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/6a0c1571-da4a-4ba5-8ff2-77a68c06e517%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA10f-igQmV3zcSgH71S25AKhCX0GFs0LTVBd%3DOb%2BYjGNw%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Re: How to get the full StackTrace when using SuperDevMode in GWT 2.7?

['Ray Cromwell' via GWT Contributors]

You need to get the underlying Javascript exception trace, not the GWT
Exception.getStackTrace().  I guess no one has been testing or
updating StackTraceDeobfuscator on the server. We added code IIRC to
preserve the original underlying JS Error object in GWT, but probably
no one paid attention to hooking up StackTraceDeobfuscator for
browsers that don't support showing nice stack traces (or
deobfuscating logs correctly in SDM)

So the short answer is, you need to turn on GWT logging, and use the
Remote stack trace deobfuscator stuff. That means the -aux output in
the SDM directory needs to be seen by your deobfuscation servlet.


On Mon, Dec 8, 2014 at 8:52 AM, confile  wrote:
> I am using GWT-PhoneGap with my iPhone 5. This means that I have to use
> Safari as dev console.
>
>
> Am Montag, 8. Dezember 2014 15:45:35 UTC+1 schrieb Jens:
>>>
>>> Well this still does not solve the problem!
>>
>>
>> As a workaround you can try using:
>> https://gist.github.com/jnehlmeier/cddbc476fd330b1d4999
>>
>> I use the master branch of GWT but I think it should also work with GWT
>> 2.7. In Chrome I get clickable stack traces that point to the source mapped
>> Java file and it also special cases UmbrellaException which might have more
>> than one cause chain (e.g. you have two listeners on a button and both throw
>> an exception you will see both causes and not just the first one).
>>
>> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/7d575edb-4ce0-4cf1-831a-82048bab6161%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7c6jSbcyRN73u1GtvO%2BAYm4jQhYMv_AmomF%2BR7zTD2OQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] SuperDevMode sometimes puts member fields in __proto__ why is that ?

['Ray Cromwell' via GWT Contributors]

Static final fields on the prototype? I'm pretty sure these are
promoted to global in optimized mode. Perhaps you meant final
non-static fields? (which we should have an optimization for promoting
to static :) )


On Fri, Dec 5, 2014 at 7:29 AM, 'Roberto Lublinerman' via GWT
Contributors  wrote:
> In draft compile Java compile time constants are emitted in the prototype.
> This should be exactly static final fields of primitive or string type
> assigned at declaration.
>
> This is the approach to compile time constants taken to implement Java
> semantics.
>
> FWIW in optimized compiles other fields might be "upgraded" to compile time
> constants.
>
> On Dec 5, 2014 2:18 AM, "stuckagain"  wrote:
>>
>> I've been trying out GWT 2.7 and SuperDevMode in combination with the SDBG
>> eclipse plugin.
>>
>> In the Chrome debugger I noticed that some fields are sometimes available
>> under 'this' but sometimes they are available only in 'this.__proto__'.
>> It seems that if I have a boolean field that is set to false that it does
>> not appear in 'this' but under 'this.__proto__' and that I can not see it at
>> all in the SDBG plugin. I filed a bug report on SDBG, but I am trying to
>> figure out how this works in GWT SuperDevMode.
>>
>> Another thing that takes getting used: list/map structures are not that
>> easy to navigate anymore. I hope they found some way to make it easier to
>> have some support to convert them to something readable in the debugger.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d948f131-0da7-4e9a-998a-925e68a62ced%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gnmswu4mF_7SRPnZjQYjvykkTvgnnthPDfuFy5gpGamcQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Invesigating OOPHM chrome dev tools js extension creation

['Ray Cromwell' via GWT Contributors]

If you mean replacing the DevMode plugin with pure JS in Chrome Dev
Tools, I don't think it's practical. You need synchronously re-entrant
code execution. Javascript's only synchronous blocking call is XHR
sync. But you also need re-entrancy, and when you are
debugging/pausing execution, you run into additional hurdles. Many
people have tried hacks to do this, with Applets, with XHR, it's
possible in theory if you rewrite all code sent to the browser to use
continuations. I would advocate just continuing to make IDE
integration with SDM better.




On Mon, Nov 24, 2014 at 9:38 AM, Brandon Donnelson
 wrote:
> I'm investigating the possibility of creating a js chrome dev tools
> extension to talk OOPHM with GPE OOPHM. So far it looks potential feasible
> to use what's in place on in GPE to do the communicating with some new
> browser extension. Although I do see having to write some new bidirectional
> options to sync up the log entries and maybe adding some new parsing ability
> for sdm output.
>
> For those who might know some about the OOPHM process, would you see any
> hang ups in writing a chrome dev tools javascript extension?
>
> Thanks,
> Brandon
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/a1363906-faef-427d-b8f6-c9209dce891a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7cKBFJeg8S-1B_Mzw%2BGMb21k-3qkRO-jzb%2B0-hQkR%3D4VQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Getting rid of autoboxing?

['Ray Cromwell' via GWT Contributors]

It could be conditioned on jsinterop being switched on or not, in
general though, more and more compiler switch modes I think encourage
lazy/bad code practices in the ecosystem.

Better would be a "lint"/"checked mode" that throws hard errors in
your app when you do something that violates the assumptions, like
thinking there's a way to tell if something is a float vs a double.


On Fri, Nov 21, 2014 at 11:53 AM, Goktug Gokdogan  wrote:
> The one of the problems is the boxing makes the support of method
> overloading, var args, etc. more complicated and much slower in JsInterop.
> Making it optional is not going to help with those.
> I think with the experiment we will have a very good data on the impact of
> this change, after that we can make a much better educated decision. If the
> impact is significant then like you said we can look for other options like
> making it optional.
>
> On Fri, Nov 21, 2014 at 2:57 AM, Arnaud TOURNIER  wrote:
>>
>> Can that be an option ? So that the user knows what happens consciously,
>> in order to optimize the runtime. I admit, that this would not simplify the
>> jscompiler base code, but would provide the user with another powerful
>> optimization...
>> Just an idea...
>>
>> Thanks
>> Arnaud
>>
>> Le vendredi 21 novembre 2014 02:41:42 UTC+1, Goktug Gokdogan a écrit :
>>>
>>> Resurrecting this.
>>>
>>> I talked with Roberto and then Ray yesterday and we think that this is a
>>> good idea and this will both improve performance and simplify
>>> jsinterop/compiler.
>>>
>>> The general idea is to make the boxed types work similar to String so all
>>> instance methods will be staticified and instanceof operations will work
>>> like typeof x === 'number'. There are other issues we need to solve as well
>>> but it looks feasible.
>>>
>>> The main drawback is; when somebody does something like list.get(x), if
>>> the returned value is number, it will return true to both instanceof Double
>>> and instanceof Integer etc.
>>> In practice we don't believe this is going to be an issue and our
>>> numerical emulation of java is already has other gotchas.
>>>
>>> Ray volunteered to provide us a patch to analyze the impact in google3
>>> and we will go from there.
>>>
>>> Let me know what you think.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Aug 3, 2013 at 7:05 PM, Goktug Gokdogan 
>>> wrote:
>>>>
>>>> I know this is something beyond interop stuff.
>>>> However, in general I don't like the idea of autoboxing being a concern
>>>> in shaping of any APIs so it started to keep bugging me since our
>>>> discussion.
>>>>
>>>> I know this will sound controversial but I really wonder if most
>>>> applications would care if boxed type of Integer and Double were actually
>>>> act like the same class.
>>>> (i.e. instanceOf Integer and instanceOf Double both will return true to
>>>> same object. So equals will return true when the values are equal even
>>>> boxing types are different)
>>>> Also current implementations of compareTo, toString, hashcode are all
>>>> compatible so those shouldn't be ok.
>>>> I think this can be a good candidate for an opt-in kind of optimization
>>>> in compiler.
>>>> We can quickly experiment with it in Google3 by changing the behavior of
>>>> equals and instanceof and then see which projects survive :)
>>>>
>>>> Another option is making this change just for Double (i.e. let the
>>>> Double own Number.prototype). Then anybody who wants numeric performance
>>>> then can stick with double and safely put into lists, maps, use it in loops
>>>> without any concerns.
>>>>
>>>> I also wonder if we would have better performance if we were to use js
>>>> boxing type (ie. new Number(100)) as the boxing type? Perhaps JS VMs 
>>>> perform
>>>> better if they do the unboxing themselves?
>>>>
>>>>
>>>>
>>>> On Fri, Aug 2, 2013 at 1:33 AM, Ray Cromwell 
>>>> wrote:
>>>>>
>>>>> I explored that a long time ago when Lightweight Collections were
>>>>> proposed, but it won't work that simply. (Sadly, most of the original
>>>>> discussions on this with the Atlanta team were in Google Wave and forever
>>>>> lost) The rea

Re: [gwt-contrib] asm.js compilations in GWT

['Ray Cromwell' via GWT Contributors]

GWT compiles Java, a garbage collected language. asmjs doesn't support
garbage collection, so the translation would be difficult. String's
have no simple mapping. I don't think the performance win would be all
that big. We shipped Angry Birds for the Web written in GWT in 2012,
back when JS was a lot slower and it ran at 60fps.

On Wed, Nov 12, 2014 at 10:39 PM, Ali Akhtar  wrote:
> Hi there,
>
> Just wondering whether GWT supports any asm.js like optimizations, or if
> there are any plans for adding them in the future? It can make GWT very
> attractive for writing games, for example.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/64b3037f-53b5-4ed5-820b-4b2296fa5431%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eJmkA1hFb%2Brh-mqE5Q6DPuajbLSHtJpWwxHa72STApQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JSInterop handle JavaScript get/set function with the same name

['Ray Cromwell' via GWT Contributors]

Overloads are currently not allowed except for @JsProperty setters and
getters in C-style initializer pattern, e.g

interface Foo {
  @JsProperty
  void x(int a); // this is a setter
  @JsProperty
  int x(); // this is a getter
}

We plan to relax this restriction in the future. @JsMethod will be the
short term workaround coming soon.


On Wed, Nov 5, 2014 at 1:24 AM, confile  wrote:
> I also tried method overlaying based on Parameter types.
>
> @JsType(prototype = "$wnd.Kinetic.Node")
> public interface KNode {
> void fire(String eventType, JavaScriptObject evt, KNodeEventCallbackJSO
> option);
> void fire(String eventType);
> }
>
> This does not work. I get the following error:
>
> [ERROR] Line 100: JsType methods cannot overload another method.
>
>[ERROR] Aborting compile due to errors in some input files
>
>
>
> Am Dienstag, 4. November 2014 21:04:29 UTC+1 schrieb Goktug Gokdogan:
>>
>> Sorry guys. When I said next release, I meant next major release (2.8 or
>> 3.0).
>>
>> On Tue, Nov 4, 2014 at 8:04 AM, Cristian Rinaldi 
>> wrote:
>>>
>>> @confile
>>>
>>>   @goktug said "However we don't have an ETA for this and 2.7 is already
>>> at RC1 so you need to wait for the next release."
>>>   This may mean:
>>>
>>>   1) wait until the 2.7.0-rc2 or
>>>   2) wait until the next release of GWT (3.0.0)
>>>
>>>In my opinion it is more likely to be version 3.0.0, because some
>>> things are missing, and many come with Java 8 support.
>>>
>>>Perhaps @goktug can clarify the picture.
>>>
>>> Greetings.
>>>
>>>
>>> El martes, 4 de noviembre de 2014 11:04:03 UTC-3, confile escribió:

 @Cristian I did not get what you say. Will this be part of GWT 2.7
 release?



 Am Dienstag, 4. November 2014 13:56:46 UTC+1 schrieb Cristian Rinaldi:
>
> @Goktug:
>This news is great !!!
>The issue of the overload was something he had already asked in
> another thread, it's good to read that will be supported.
>
> Thank you ...
>
> El martes, 4 de noviembre de 2014 08:40:15 UTC-3, Joost Gustavson
> escribió:
>>
>> +1 same here. Hope this get solved in GWT 2.7 RC2.
>>
>> Joost
>>
>>
>>
>> On Tuesday, November 4, 2014 12:15:10 AM UTC+1, Goktug Gokdogan wrote:
>>>
>>> Method overloading is supposed to be ok if there is no prototype is
>>> given, however in your case prototype is provided hence even if we fix 
>>> it,
>>> it will not work for your case.
>>>
>>> There two ways to cover your use case here. One is making var-args
>>> work (if it is not already working) so that you can do something like
>>> following to cover both in single method:
>>>
>>>   boolean draggable(Object... args)
>>>
>>> You can give it a try and see if works (but I doubt it will work
>>> right now).
>>>
>>> The second way is to support overloading. We already decided to
>>> support overloading at least based on number of arguments and this 
>>> scenario
>>> is covered under that.
>>>
>>> However we don't have an ETA for this and 2.7 is already at RC1 so
>>> you need to wait for the next release.
>>>
>>> On Mon, Nov 3, 2014 at 1:27 PM, confile 
>>> wrote:

 Will the custom names method be part of the GWT 2.7 release? That
 would be great. I think with this method you can handle nearly 
 everything
 with JsInterop.

 When I tried the above JsType as Interface I get the following
 error:

 GET /recompile/mobilePhoneGapIOS
Job test.mobile.MobilePhoneGapIOS_1_6
   starting job: test.mobile.MobilePhoneGapIOS_1_6
   binding: mgwt.density=xhigh
   Compiling module test.mobile.MobilePhoneGapIOS
  Ignored 1 unit with compilation errors in first pass.
 Compile with -strict or with -logLevel set to TRACE or DEBUG to see
 all errors.
  Tracing compile failure path for type
 'org.test.kinetic.client.KNode'
 [ERROR] Errors in
 'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/KNode.java'
[ERROR] Line 22: JsType methods cannot overload
 another method.
 [ERROR] Errors in
 'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/events/KNodeEventCallbackJSO.java'
[ERROR] org.test.kinetic.client.events.KNodeEvent
 cannot be resolved to a type
 [ERROR] Errors in
 'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test/kinetic/client/events/KNodeEvent.java'
[ERROR] org.test.kinetic.client.KShape cannot be
 resolved to a type
 [ERROR] Errors in
 'file:/Users/mg/Documents/Grails/GGTS3.5.1Test/test/src/gwt/org/test

Re: [gwt-contrib] JSInterop assign a function/callback to a property

['Ray Cromwell' via GWT Contributors]

That document represents intent to implement, but SAM handling isn't
implemented yet in GWT 2.7, since it is most useful after Java8 lands.
Shortly Java8 will land, and then SAM handling in JsInterop and you'll
be able to use GWT 2.8 nightly snapshots. For now, you'll need a
utility function that wraps a SAM as a function, e.g.

public static native JavaScriptObject samToFunction(MyCallback cb) /*-{
  return function(arg) { return cb.@MyCallback::someMethod(*)(arg); };
}-*/;

On Tue, Nov 4, 2014 at 11:28 PM, Kay-Uwe Janssen  wrote:
> As i had no luck on Google+ yet, i'll try it here.
>
> First the G+ Post:
> https://plus.google.com/116136390679208063122/posts/52kcbwwngWo
>
>
> Well I just started to work on a ChromeCast Receiver built with GWT. As the
> Receiver API is in JS i wanted to try JSInterop over JSNI but had some
> struggle.
>
> The ChromeCast Api has some properties that can be set with a function to
> act as a callback. eg for onReady.
>
> castReceiverManager.onReady = function(event) {
>   // do stuff
> };
>
> Now my question is: How can i do this with JsInterop or is it not yet
> possible?
>
> as mentioned in
> https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4
> below "Single Abstract Method Handling" i tried something like this
>
> @JsType
> public interface Receiver {
>   @JsProperty
>   void onReady(Runnable onReady);
> }
>
> when trying to execute the method with this snipped i get "Exception caught:
> (TypeError) : object is not a function"
>
> private native void test(Receiver receiver)/*-{
>   receiver.onReady();
> }-*/;
>
>
> to see whats the value of onReady i did console.log(receiver) and got this:
> (where onReady is set the way above and onSenderConnected has been set the
> JS way inside an JSNI method.
>
> onReady: JsTest$1_1_g$
> onSenderConnected: function (event_0_g$)
>
>
> is there a way to achieve this yet or do i have to wait for 2.8/3.0?
>
> i tried to dig into the gwt code to see if there is a way to add something
> to support this but unfortunately the gwt code for js processing is a bit
> out of my scope.
>
>
> some possible solutions would be either
> interface JsFunction {
>  T call(Object... args);
> }
> or
> interface MyOnReadyCallback {
>   @JsFunction
>   MyReturnType anyName(String arg1, boolean arg2, SomeOtherType arg3);
> }
>
> and let the "Single Abstract Method Handling" find the method and add it.
>
>
> Thanks! :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4c8fb2c-6060-4680-9b24-e118a452dc0d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fygaH78adStNz3zgyBbWG%3D9RKQcfOLsEfyM28yG9WzAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] JsInterop retrofit

['Ray Cromwell' via GWT Contributors]

Moving from interfaces to classes has other downsides. For example, you
can't avoid not generating a Java class/object, you can't have your own
super-class hierarchy and mark your class as supporting the same interface
as an external JS implemented one, the notion of JS objects "implementing"
a Java interface would seem strange if they implement the interface without
subclassing the prototype of the Java object with the annotation.

Take something like Elemental 2.0, which is likely to have several hundred,
maybe 1000 types for every conceivable WebUI, we do not want defineClass(),
class literals, castmaps, or java.lang.Object stuff set up for any of them.
With interfaces, it's clear there's no backing interface to compile. With
classes, we'd have to add some hackery to the compiler like "if it's a
jstype, and it has zero implemented methods, and it's all native, and it
doesn't extend another class that has non-native methods, *then* we can
just drop it's class setup from the output".

Otherwise, for every single one of these you'll get massive bloat, and a
SDM compile of Elemental 2.0 would have a thousand stubbed out classes in
it.


On Sat Nov 01 2014 at 10:07:21 AM 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> (I will read & respond to comments after the weekend)
>
> On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan  wrote:
>
>> There is also a third option.
>>
>> User writes:
>>
>> @JsType(prototype = "Object")interface JsObject {
>>
>>   class prototype extends Prototype_JsObject {}
>>
>>   interface Static {
>> String[] keys(JsObject obj);
>> JsObject defineProperties(JsObject obj, JsObject props);
>>   }
>>
>>   static Static getStatic() {
>> return new Static_JsObject();
>>   }
>>
>>   static JsObject of(Object obj) {
>> return obj instanceof JsObject ? (JsObject) obj : null;
>>   }
>>
>>   @JsConstructor
>>   void constructor(String param);
>>
>>   boolean hasOwnProperty(String prop);
>>   boolean isPrototypeOf(JsObject prop);
>> }
>>
>> 
>> which generates:
>>
>> @PrototypeOfJsType(JsObject.class)public class Prototype_JsObject {
>>JsObject constructor(String param) { return null;}
>>boolean hasOwnProperty(String prop) { return false; }
>>boolean isPrototypeOf(JsObject prop) { return false; }
>> }
>> public class Static_JsObject implements Static {
>>   JsObject newInstance(String param) {
>> return js("new Object($0)", param);
>>   }
>>
>>   public String[] keys(JsObject obj) {
>> return js("Object.keys($0)", obj);
>>   };
>>
>>   public JsObject defineProperties(JsObject obj, JsObject props) {
>> ...
>>   }
>> }
>>
>> 
>> And usage looks like:
>>
>>   MyObject extends JsObject.prototype {}
>>
>>   JsObject.getStatic().keys( ... );
>>
>>   JsObject.getStatic().newInstance( ... );
>>
>>   JsObject.of(new Object());
>>
>> 
>> And it is perfectly testable.
>>
>> On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman <
>> stephen.haber...@gmail.com> wrote:
>>
>>>
>>> > I will try to summarize my thought process and different options that
>>> > I have played with so that you could get a better understanding where
>>> > I'm coming from and I hope it will provide good documentation for
>>> > future.
>>>
>>> Thanks for the email; I think the format was really useful.
>>>
>>> > One may argue that if we are committing to use some kind of DSL why
>>> > not use something else like IDL or xml etc. There are 3 main reasons
>>> > to use java + APT instead of others:
>>>
>>> I really want to advocate APT, as I've used it and do generally like it,
>>> but frankly it can be a huge PITA for Eclipse. See long-standing issues
>>> e.g.:
>>>
>>> https://github.com/square/dagger/issues/126
>>>
>>> Granted, maybe someone can just fix Eclipse, but, in my experience, it
>>> can really ruin the first impressions for a project (1000s of compile
>>> errors due to missing generated code, and no hints that, btw, it's
>>> because the APT was not on the classpath/didn't run).
>>>
>>> > All the cons are around the testability aspect. For JRE testing,
>>> > native methods are a headache. Also we no longer generate an interface
>>> > for static methods.
>>>
>>> I know I just bitched about APT, but, just musing, what if the class
>>> (with the native methods/etc.) was the DSL the user wrote, and then APT
>>> just generated an interface from that?
>>>
>>> This is basically what I'm doing by hand in tessell with writing
>>> IsTextBox for TextBox, etc.
>>>
>>> I admittedly am not an expert on JS prototype semantics, so am not sure
>>> how this would handle statics/etc. But in testing I usually only care
>>> about instance methods anyway...
>>>
>>> A few years ago I spiked an APT processor to do this automatically:
>>>
>>> https://github.com/stephenh/interfacegen
>>>
>>> The oddity then becomes that the user is writing "class JsObject", but
>>> then if they want testable code, they need to code against the generated
>>> "IsJsObject" interface. But pe

Re: [gwt-contrib] Re: GWT 2.7.0-RC1 is available

['Ray Cromwell' via GWT Contributors]

Thomas is talking about memory on the mobile device. Safari on iOS
only has about 512mb of heap to work with IIRC. You could be loading
in 50-100Mb of generated JS, slowing down the mobile browser a lot.

I would develop using SDM and Chrome emulation in the desktop browser,
or use XCode's iOS emulator, and then when you need to test a real
device, do an optimized compile. Or, if you have an Android phone, use
Chrome for development, as Android devices have 2x-3x the RAM of iOS
devices.


On Fri, Oct 31, 2014 at 8:17 AM, confile
 wrote:
> Which kind of memory do you mean? Compile works fine it has -Xmx1024m.
>
>
> Am Freitag, 31. Oktober 2014 15:49:16 UTC+1 schrieb Thomas Broyer:
>>
>>
>>
>> On Friday, October 31, 2014 10:22:41 AM UTC+1, confile wrote:
>>>
>>> Hi Daniel,
>>>
>>> this (https://github.com/mgwt/mgwt/wiki/SuperDevMode-with-PhoneGap) is
>>> what I did. Super dev mode is working. I get a recompile after reload that
>>> is working.
>>>
>>> In my app I have a long list with images. When I scroll down the app
>>> freezes when the scrolling reaches a point where new images have to be
>>> loaded from the server. The loading feels very slow it took more than 10
>>> seconds. During this time the app is completely blocked. I compared the same
>>> app running in the same environment except that i switched to GWT 2.6.1. In
>>> GWT 2.6.1 it runs so mouth no blocking while scrolling. I am not sure what
>>> changed in GWT 2.7 that causes this effect, but I suppose that other people
>>> might have similar problems too. By the way I use the latest version of MGWT
>>> and GWT-PhoneGap.
>>
>>
>> Could it be that you're running out of memory? (given that SDM compiles
>> with 2.7 are bigger than with 2.6)
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/bee1925d-f3b9-4f7e-9701-c5a8e8e2df0f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eZhZU6GNgxc8Cd8AYDaaWipdXpHdgyQNBEncbZC2-PAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: GWT 2.7.0-RC1 is available

['Ray Cromwell' via GWT Contributors]

SDM 2.6 was not incremental, it actually pruned code. If you want the
same behavior in 2.7, you'll have to disable incremental compilation
in SDM. This will increase compile times, but probably make the JS
smaller.

However, prod compiles in 2.6 vs 2.7 should have no performance
regression, if anything, performance should be much better, we made
lots of things faster.


On Fri, Oct 31, 2014 at 2:22 AM, confile
 wrote:
> Hi Daniel,
>
> this (https://github.com/mgwt/mgwt/wiki/SuperDevMode-with-PhoneGap) is what
> I did. Super dev mode is working. I get a recompile after reload that is
> working.
>
> In my app I have a long list with images. When I scroll down the app freezes
> when the scrolling reaches a point where new images have to be loaded from
> the server. The loading feels very slow it took more than 10 seconds. During
> this time the app is completely blocked. I compared the same app running in
> the same environment except that i switched to GWT 2.6.1. In GWT 2.6.1 it
> runs so mouth no blocking while scrolling. I am not sure what changed in GWT
> 2.7 that causes this effect, but I suppose that other people might have
> similar problems too. By the way I use the latest version of MGWT and
> GWT-PhoneGap.
>
> Michael
>
>
> Am Freitag, 31. Oktober 2014 09:06:11 UTC+1 schrieb Daniel Kurka:
>>
>> You are comparing apples and oranges here. SDM compiles are not optimized,
>> thus much bigger. If you want to compare performance you will need to do an
>> optimized compile.
>>
>> The SDM setup in my blog post is now outdated, here is how you use SDM
>> with Phonegap in 2.7:
>> https://github.com/mgwt/mgwt/wiki/SuperDevMode-with-PhoneGap
>>
>> -Daniel
>>
>>
>> On Fri, Oct 31, 2014 at 8:01 AM, confile 
>> wrote:
>>>
>>> I use iOS7 and Super dev mode as described by Daniel here. I use -strict
>>> -XjsInteropMode JS and output style detailed to compile the code for the
>>> PhoneGap container.
>>>
>>>
>>>
>>> Am Freitag, 31. Oktober 2014 01:02:58 UTC+1 schrieb Ray Cromwell:
>>>>
>>>> I am not aware of any changes in 2.7 that should effect performance
>>>> loading images. Are you running on iOS7 or iOS8? Daniel would probably
>>>> be best able to help you. Are you talking about SuperDevMode loading
>>>> performance, or fully optimized compile loading performance?
>>>>
>>>>
>>>>
>>>> On Thu, Oct 30, 2014 at 2:27 PM, confile
>>>>  wrote:
>>>> > I compared my GWT-PhoneGap written in GWT 2.6.1 which switching to GWT
>>>> > 2.7beta. Here are my experience. I feel that loading of data
>>>> > especially
>>>> > images are much slower in GWT 2.7 than in GWT 2.6.1. I tested it on an
>>>> > iPhone 5. Due to the delay in loading the app feels slow and scrolling
>>>> > does
>>>> > not work smouth.
>>>> >
>>>> > Michael
>>>> >
>>>> >
>>>> >
>>>> > Am Donnerstag, 30. Oktober 2014 16:37:38 UTC+1 schrieb Jens:
>>>> >>>
>>>> >>> Turning off precompile in incremental mode.
>>>> >>> Super Dev Mode starting up
>>>> >>>workDir:
>>>> >>>
>>>> >>> /var/folders/xh/1xkfq26532j97q23qw5pdhs4gn/T/gwt-codeserver-7573159147938212004.tmp
>>>> >>>
>>>> >>>
>>>> >>> Does this mean anything? Is it a problem if precompile is turned off
>>>> >>> or
>>>> >>> does it mean that incremental compile is not working?
>>>> >>
>>>> >>
>>>> >> That's fine. Precompilation is turned off intentionally as it can
>>>> >> sometimes cause SDM to not detect just a single permutation.
>>>> >>
>>>> >> -- J.
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> > Groups
>>>> > "GWT Contributors" group.
>>>> > To unsubscribe from this group and stop receiving emails from it, send
>>>> > an
>>>> > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>>> > To view this discussion on the web visit
>>>> >
>>>> > https://groups.google.com/d/msgid/google-web-toolkit-contributors/9574bc95-abd7-4c08-bf6d-58f20c2fa6f3%40googlegroups.com.
>>>> >
>>>>

Re: [gwt-contrib] Re: GWT 2.7.0-RC1 is available

['Ray Cromwell' via GWT Contributors]

I am not aware of any changes in 2.7 that should effect performance
loading images. Are you running on iOS7 or iOS8? Daniel would probably
be best able to help you. Are you talking about SuperDevMode loading
performance, or fully optimized compile loading performance?



On Thu, Oct 30, 2014 at 2:27 PM, confile
 wrote:
> I compared my GWT-PhoneGap written in GWT 2.6.1 which switching to GWT
> 2.7beta. Here are my experience. I feel that loading of data especially
> images are much slower in GWT 2.7 than in GWT 2.6.1. I tested it on an
> iPhone 5. Due to the delay in loading the app feels slow and scrolling does
> not work smouth.
>
> Michael
>
>
>
> Am Donnerstag, 30. Oktober 2014 16:37:38 UTC+1 schrieb Jens:
>>>
>>> Turning off precompile in incremental mode.
>>> Super Dev Mode starting up
>>>workDir:
>>> /var/folders/xh/1xkfq26532j97q23qw5pdhs4gn/T/gwt-codeserver-7573159147938212004.tmp
>>>
>>>
>>> Does this mean anything? Is it a problem if precompile is turned off or
>>> does it mean that incremental compile is not working?
>>
>>
>> That's fine. Precompilation is turned off intentionally as it can
>> sometimes cause SDM to not detect just a single permutation.
>>
>> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/9574bc95-abd7-4c08-bf6d-58f20c2fa6f3%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7dXFx1SYtYRLCJCe0V%3DBu%3Du3B6_VXe1jN5thhFOAE8OnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

['Ray Cromwell' via GWT Contributors]

Whether you use $wnd.SomeJsObject or SomeJsObject depends on the following:
1) whether you want 'instanceof' to only work on objects that come
from the host page
2) whether or not you're going to extend/subtype JS objects

In most cases, you want "$wnd.SomeJsObject", however there are cases
where you don't

1) if you loaded some hand written JS into 'window' instead of $wnd
2) if you are referring to inbuilt native JS objects like Window or
HTMLDivElement

If you do the following

@JsType(prototype="$wnd.Window")
interface Window {
 ...
}

Window w = someIframe.window();

Then w instanceof Window => false. Why? Because the GWT compiler will
emit "w instanceof $wnd.Window", but your checking for Window objects
from ANY location.


So you see, a prefix of $wnd leads to an ABSOLUTE instanceof operator.
If you don't specify $wnd, then the instanceof check is relative. So
for example, it will just check if your constructor is 'Window', no
matter which context where it came from.

In general, native DOM elements == no $wnd prefix, JS libraries loaded
in host page == $wnd prefix


On Wed, Oct 29, 2014 at 7:04 AM, confile
 wrote:
> thank oyu Jens. What about my first question:
>
> Is it @JsType(prototype="SomeJsObject") or
> @JsType(prototype="$wnd.SomeJsObject") ?
>
> Best
> Michael
>
> Am Mittwoch, 29. Oktober 2014 14:45:33 UTC+1 schrieb Jens:
>>>
>>> Consider an interface
>>>
>>> @JsType
>>> interface Test {
>>>   void do();
>>> }
>>>
>>> How do I instantiate such an interface?
>>
>>
>> For now you need to use a JSNI factory method. May it be in a static inner
>> class or a dedicated factory class for all your JsTypes.
>>
>> With GWT 3.0 (and Java8 support) you can use a static factory method on
>> the interface which uses GWT.jsni() or GWT.js() or whatever name that
>> special GWT method will have. So in GWT 3.0 it will probably look like:
>>
>> @JsType
>> interface Test {
>>static Test create() { return GWT.js("new Test()"); }
>>void do();
>> }
>>
>>
>> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/a8612613-de28-4413-926f-ed97086436fa%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fuBJCLq7kpyxjDxTqvPQ_ST-h%3DULprM%3D9K0UVO56FsEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

['Ray Cromwell' via GWT Contributors]

@JsType(prototype="Window") means that "x instanceof Window" will return
false if the underlying object isn't a Window. That is, the GWT compiler
generates a JS instanceof operator with the specified prototype.

Otherwise, @JsType interfaces are treated like JavaScriptObject overlay
types as far as castability/instanceof is concerned.

isNative is just documentation for now, but says that the underlying
prototype is a browser built-in as opposed to a hand written user supplied
JS prototype. Native prototypes have restrictions that pure-JS ones don't.

@JsType(prototype="...") will also trigger an annotation processor in the
future that generates a stub _Prototype for extending, e.g.

@JsType(prototype="HTMLDivElement")
interface HTMLDivElement extends HTMLElement { ... }

will generate a

@PrototypeOfJsType(HTMLDivElement.class)
class HtmlDivElement_Prototype extends HTMLElement_Prototype { ... }

This makes it possible to subclass JS objects, e.g.

class MyDivElement extends HTMLDivElement_Prototype { ... }


On Tue Oct 28 2014 at 9:17:55 AM confile 
wrote:

> Okay great. But what is the difference between the following?
>
> *@JsType(prototype="Window"**)* and *@JsType *
>
> Also could you please explain when to use isNative = true?
>
>
>
>
> Am Dienstag, 28. Oktober 2014 17:06:47 UTC+1 schrieb Ray Cromwell:
>>
>> GWT.create() doesn't work to create Js interfaces. It's part of the
>> GWT deferred binding system and can only be bound to concrete Java
>> subtypes. (GWT.create uses the 'new' operator)
>>
>> JsInterop is going to move towards Java8 syntax for the use case you
>> describe, e.g
>>
>> @JsType
>> interface Window {
>>static Window get() { return js("window"); }
>> }
>>
>>
>>
>> On Tue, Oct 28, 2014 at 8:33 AM, confile
>>
>  wrote:
>> > What is the difference in using the following?
>> >
>> > @JsType(prototype="Window") and @JsType
>> >
>> > It does not become very clear from the documentation.
>> >
>> > Here is the interface I implemented:
>> >
>> > @JsType(prototype="Window")
>> >
>> > public interface MyWindow {
>> >
>> >
>> > public static abstract class Statics {
>> >
>> > public static native MyWindow create() /*-{
>> >
>> > var w = $wnd;
>> >
>> > return w;
>> >
>> > }-*/;
>> >
>> > }
>> >
>> > void alert(String msg);
>> >
>> > }
>> >
>> >
>> > When I want to use the interface I have to do: MyWindow w =
>> > MyWindow.Statics.create();
>> >
>> > I also would expect that the following should work too: MyWindow w =
>> > GWT.create(MyWindow.class);
>> >
>> > The compiler throws an error in the later case:
>> >
>> >  [ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
>> >
>> >  Unification traversed 735 fields and methods and 538 types. 7
>> are
>> > considered part of the current module and 7 had all of their fields and
>> > methods traversed.
>> >
>> >   [ERROR] Compiler returned false
>> >
>> >
>> > Two questions:
>> >
>> > 1. When do I use or do I not use the prototype and isNative attribute
>> of
>> > @JsType?
>> >
>> > 2. Do I use the correct way to instantiate a JSInterop Interface?
>> >
>> >
>> >
>> >
>> >
>> > Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
>> >>
>> >> Using default methods in Java8 is exactly how we plan to allow
>> >> specifying method bodies without using JSOs. We are also going to
>> >> introduce a new annotation, @JsFinal to declare these methods final
>> >> (which you can't do on interfaces) to make it a compile time error for
>> >> subclasses to override them.
>> >>
>> >> Why? One of the reasons why JSOs are efficient is that they are not
>> >> polymorphic, and essentially turn into static method calls, e.g.
>> >>
>> >> getState() is rewritten as getState(SwitchElement this$static) /*-{
>> >> return this$static.bootstrapSwitch("state"); }-*/;  which is
>> >> inlineable by the compiler.
>> >>
>> >> Polymorphic methods are not inlineable and if there is a concrete
>> >> implementor, it forces the compiler to insert a trampolin

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

['Ray Cromwell' via GWT Contributors]

GWT.create() doesn't work to create Js interfaces. It's part of the
GWT deferred binding system and can only be bound to concrete Java
subtypes. (GWT.create uses the 'new' operator)

JsInterop is going to move towards Java8 syntax for the use case you
describe, e.g

@JsType
interface Window {
   static Window get() { return js("window"); }
}



On Tue, Oct 28, 2014 at 8:33 AM, confile
 wrote:
> What is the difference in using the following?
>
> @JsType(prototype="Window") and @JsType
>
> It does not become very clear from the documentation.
>
> Here is the interface I implemented:
>
> @JsType(prototype="Window")
>
> public interface MyWindow {
>
>
> public static abstract class Statics {
>
> public static native MyWindow create() /*-{
>
> var w = $wnd;
>
> return w;
>
> }-*/;
>
> }
>
> void alert(String msg);
>
> }
>
>
> When I want to use the interface I have to do: MyWindow w =
> MyWindow.Statics.create();
>
> I also would expect that the following should work too: MyWindow w =
> GWT.create(MyWindow.class);
>
> The compiler throws an error in the later case:
>
>  [ERROR] Line 46: Rebind result 'test.client.MyWindow' must be a class
>
>  Unification traversed 735 fields and methods and 538 types. 7 are
> considered part of the current module and 7 had all of their fields and
> methods traversed.
>
>   [ERROR] Compiler returned false
>
>
> Two questions:
>
> 1. When do I use or do I not use the prototype and isNative attribute of
> @JsType?
>
> 2. Do I use the correct way to instantiate a JSInterop Interface?
>
>
>
>
>
> Am Sonntag, 5. Oktober 2014 08:32:26 UTC+2 schrieb Ray Cromwell:
>>
>> Using default methods in Java8 is exactly how we plan to allow
>> specifying method bodies without using JSOs. We are also going to
>> introduce a new annotation, @JsFinal to declare these methods final
>> (which you can't do on interfaces) to make it a compile time error for
>> subclasses to override them.
>>
>> Why? One of the reasons why JSOs are efficient is that they are not
>> polymorphic, and essentially turn into static method calls, e.g.
>>
>> getState() is rewritten as getState(SwitchElement this$static) /*-{
>> return this$static.bootstrapSwitch("state"); }-*/;  which is
>> inlineable by the compiler.
>>
>> Polymorphic methods are not inlineable and if there is a concrete
>> implementor, it forces the compiler to insert a trampoline, e.g
>> .
>>
>> @JsType
>> interface JsArray {
>>default  get(int x) { return js("this[$0]", x); }
>> }
>>
>> If we didn't have @JsFinal, and someone did class Blah implements
>> JsArray { ... }, it would slow down every single JsArray call in the
>> entire program, because the compiler has to emit code like this:
>>
>> jsArray.get ? jsArray.get(i) : this[i];
>>
>> That is, it has to check to see if the method is implemented and call
>> it, otherwise fall back to the default.
>>
>>
>> This is why the full JsInterop will require Java8, because it makes
>> syntax so much better, and without it, things get verbose and
>> boilerplatey.
>>
>> Java8 support is very close to landing. After that, a bunch of
>> JsInterop changes will go in. Then Elemental 2.0 will follow on top of
>> that which implements all of the code browser APIs you see at
>> html5index.org
>>
>>
>> On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi 
>> wrote:
>> > +Ray Cromwell:
>> >   Suppose the following definition:
>> >
>> > @JsType(prototype = "jQuery")
>> > public interface JQueryElement {
>> > JQueryElement append(JQueryElement element);
>> >
>> > @JsProperty
>> > JQueryElement html();
>> >
>> > void data(String key, String value);
>> >
>> > Object val();
>> >
>> > void on(String event,
>> > com.workingflows.js.jscore.client.api.Function fn);
>> >
>> > void attr(String attr, Object value);
>> > }
>> >
>> > Now suppose that there is an element called SwitchElement, the item is a
>> > JQueryElement but has a particual implementation of a method, for
>> > example:
>> >
>> >  public class SwitchElement extends JavaScriptObject {
>> >
>> > protected SwitchElement() {
>> > }
>> >
>> > public final native boolean getState()/*-{
>> > 

Re: [gwt-contrib] Re: GWT 2.7 SDM incremental output too large

['Ray Cromwell' via GWT Contributors]

Post 2.7, we're going to look into pruning down the incremental
output. However, this won't solve poor sourcemap implementations in
other browsers. One option is to get source-map support improved
directly in Eclipse/IntelliJ, so that the Javascript-based developer
tools are not used, rather, the IDEs connect to the Browsers via
remote debugging protocols, but the SourceMap/indexing/navigation is
done by Eclipse/IntelliJ.


On Wed, Oct 22, 2014 at 3:42 AM, Rene Hangstrup Møller
 wrote:
> Our application is roughly the same size (3.5mb) and I have never been able
> to debug using source maps in firefox. It freezes when it has to load them.
> I have also tried remote javascript debugging with super devmode from
> IntelliJ. I can typically step over a couple of breakpoints and then it
> drops the connection. So I still use DevMode with Firefox 24 ESR when I have
> to debug.
>
> Works fine in chrome.
>
> Best regards
> Rene
>
> Den onsdag den 22. oktober 2014 11.52.40 UTC+2 skrev Jens:
>>
>> Hi,
>>
>> Our app produces permutations about 3.5mb in size when doing optimized
>> production builds. It is roughly 150.000 fields across 12.000 types
>> (according to the first SDM incremental compile output). I tried that app
>> with several browsers (all Mac OS) to see how things work with SDM
>> incremental compile:
>>
>> - Opening the native dev tools of Firefox 33 and switching to the debugger
>> tab freezes Firefox for several (5+) minutes until it finally displays all
>> source mapped java files. And thats for each page reload. Breakpoints work
>> but since you can not see which source line is mapped you might need to
>> guess a bit until you find a spot where the breakpoint actually works (or
>> look it up on the code server). But because of the reload times debugging is
>> literally unusable. Maybe it is possible to use FireFox remote debugging in
>> IntelliJ. Haven't tried that yet.
>>
>> - Safari 7 also has quite some lag. The reason is that Safari Dev Tools
>> store each XHR request done to fetch a source mapped file from code server.
>> If you now want to search for a Java file in the browser the search lags
>> quite a bit because it also filters all these 1000+ XHR requests. But thats
>> a Safari issue one must accept for now. I also noticed that sometimes the
>> CodeServer responds with 404 for all source mapped files that are generated
>> by GWT generators, e.g.
>>
>> GET /sourcemaps/app/3427F4D36ECEACFA71B338AB1AE1396C_sourcemap.json
>>sent source map for module 'app' in 269 ms
>> GET
>> /sourcemaps/app/gen/com/google/gwt/cell/client/TextInputCell_TemplateImpl.java
>>Sent error page: unknown source file:
>> gen/com/google/gwt/cell/client/TextInputCell_TemplateImpl.java
>>
>> When I open up the CodeServer web site at :9876/sourcemaps/app/ I can
>> see an entry for gen/com/google/gwt/cell/client/ . Once I enter it I can see
>> the TextInputCell_TemplateImpl.java however if I want to open it in the
>> browser the CodeServer can not find it and reports an error. Thats something
>> I haven't noticed in Chrome so far.
>> Finally setting break points in the source mapped Java file does not seem
>> to work at all in Safari 7. Breakpoints are accepted but never hit by the
>> debugger. I tried several different code lines (all are marked as black
>> lines on the code server sourcemap html output so they should have valid
>> mappings).
>>
>> - In IE 11 it also takes quite some time until source mapped java files
>> appear in the dev tools (similar to FireFox). Once they appear, file
>> filtering is pretty slow but I can live with that. However if I want to set
>> a breakpoint in any of my files then the breakpoint is actually placed in a
>> GWT file called ModuleUtils.java. No idea why but that also makes debugging
>> impossible. Trying to open the pure JS file does not work either.
>>
>>
>> So in short, although incremental compilation is pretty cool all non
>> Google Chrome browsers have issues with our app because 1.) the pure JS size
>> produced by incremental compile is too large (Safari actually showed the
>> total size of resources downloaded and it shows 75MB) and 2.) handling the
>> source map does not work well and break points might be dead.
>> For IE we can still use classic DevMode but for FireFox, Safari and mobile
>> browsers debugging doesn't work well for large apps.
>>
>>
>> -- J.
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/69d8d8a2-367e-4339-92fe-708841d23e30%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from th

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

['Ray Cromwell' via GWT Contributors]

Using default methods in Java8 is exactly how we plan to allow
specifying method bodies without using JSOs. We are also going to
introduce a new annotation, @JsFinal to declare these methods final
(which you can't do on interfaces) to make it a compile time error for
subclasses to override them.

Why? One of the reasons why JSOs are efficient is that they are not
polymorphic, and essentially turn into static method calls, e.g.

getState() is rewritten as getState(SwitchElement this$static) /*-{
return this$static.bootstrapSwitch("state"); }-*/;  which is
inlineable by the compiler.

Polymorphic methods are not inlineable and if there is a concrete
implementor, it forces the compiler to insert a trampoline, e.g
.

@JsType
interface JsArray {
   default  get(int x) { return js("this[$0]", x); }
}

If we didn't have @JsFinal, and someone did class Blah implements
JsArray { ... }, it would slow down every single JsArray call in the
entire program, because the compiler has to emit code like this:

jsArray.get ? jsArray.get(i) : this[i];

That is, it has to check to see if the method is implemented and call
it, otherwise fall back to the default.


This is why the full JsInterop will require Java8, because it makes
syntax so much better, and without it, things get verbose and
boilerplatey.

Java8 support is very close to landing. After that, a bunch of
JsInterop changes will go in. Then Elemental 2.0 will follow on top of
that which implements all of the code browser APIs you see at
html5index.org


On Sat, Oct 4, 2014 at 3:29 PM, Cristian Rinaldi  wrote:
> +Ray Cromwell:
>   Suppose the following definition:
>
> @JsType(prototype = "jQuery")
> public interface JQueryElement {
> JQueryElement append(JQueryElement element);
>
> @JsProperty
> JQueryElement html();
>
> void data(String key, String value);
>
> Object val();
>
> void on(String event,
> com.workingflows.js.jscore.client.api.Function fn);
>
> void attr(String attr, Object value);
> }
>
> Now suppose that there is an element called SwitchElement, the item is a
> JQueryElement but has a particual implementation of a method, for example:
>
>  public class SwitchElement extends JavaScriptObject {
>
> protected SwitchElement() {
> }
>
> public final native boolean getState()/*-{
>  return this.bootstrapSwitch("state");
>  }-*/;
>
> public final native void setState(boolean state)/*-{
>  this.bootstrapSwitch("state", state);
>  }-*/;
> }
>
> The problem is, if the JQueryElement interface is implemented, all methods
> must be implemented. In fact, the implementation of JQueryElement is
> performed by the compiler, and I have no access to that implentación.
>
> 1) The solution can be: define an Java8 interface with methods implemented
> by default?
>
> 2) It is possible to access a Prototype implementation of JQueryElement, by
> example:
>
> public class SwitchElement extends JQueryElement.Prototype{
>  protected SwitchElement() {
>  }
>
>  public final native boolean getState()/*-{
>  return this.bootstrapSwitch("state");
>  }-*/;
>
>  public final native void setState(boolean state)/*-{
>  this.bootstrapSwitch("state", state);
>  }-*/;
>
> }
>
> But for this, it is necessary to use APT or the JsType generation process,
> is performed by APT.
> I'm right, or very far from reality.
>
> :)
>
>
> El sábado, 4 de octubre de 2014 15:24:19 UTC-3, Ray Cromwell escribió:
>>
>> Yes, but it will require Java8, which allows interfaces to contain
>> static methods. Here's how you'll do it soon when the Java8 stuff
>> lands:
>>
>> @JsType
>> public interface ImageUtils {
>>  public static Texture loadTexture(String url)  { return
>> js("$wnd.THREE.ImageUtils.loadTexture($0)", url); }
>> }
>>
>> ImageUtils.loadTexture(url);
>>
>>
>>
>> On Sat, Oct 4, 2014 at 8:18 AM, confile 
>> wrote:
>> > Consider the following static JavaScript function:
>> >
>> > THREE.ImageUtils = {
>> >loadTexture: function (url) { ... }
>> >
>> > }
>> >
>> > The way I use to create the static function with JsInterop is to create
>> > an
>> > interface for ImageUtils and then create an inner abstract class
>> > MyStatic
>> > which contains the static methods implemented with JSNI.
>> >
>> > Here is an example of the above class:
>> >
>> > @JsType
>> > public interface ImageUtils {
>> >
>> > public static abstract class MyStatic {
>> >
>> 

Re: [gwt-contrib] GWT 2.7 JsInterop Handle static JavaScript Functions

['Ray Cromwell' via GWT Contributors]

Yes, but it will require Java8, which allows interfaces to contain
static methods. Here's how you'll do it soon when the Java8 stuff
lands:

@JsType
public interface ImageUtils {
 public static Texture loadTexture(String url)  { return
js("$wnd.THREE.ImageUtils.loadTexture($0)", url); }
}

ImageUtils.loadTexture(url);



On Sat, Oct 4, 2014 at 8:18 AM, confile  wrote:
> Consider the following static JavaScript function:
>
> THREE.ImageUtils = {
>loadTexture: function (url) { ... }
>
> }
>
> The way I use to create the static function with JsInterop is to create an
> interface for ImageUtils and then create an inner abstract class MyStatic
> which contains the static methods implemented with JSNI.
>
> Here is an example of the above class:
>
> @JsType
> public interface ImageUtils {
>
> public static abstract class MyStatic {
>
> public static native Texture create(String url) /*-{
> return new $wnd.THREE.ImageUtils.loadTexture(url);
> }-*/;
> }
>
> }
>
>
> I don't think this is the best solution. Is there a better way to handle
> static functions with JsInterop?
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/8f6cf42a-2910-4536-a2f7-1ae2d55422ac%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Compiler Faiure

['Ray Cromwell' via GWT Contributors]

We kind of knew this sort of incompatibility would happen, but I still
think GWT should continue get out of the business of rebasing
everything. We should even have a version of the JAR that can use
dynamic dependencies.



On Wed, Oct 1, 2014 at 3:16 PM, Manuel Carrasco Moñino
 wrote:
> Thank Roberto, that is the key, everything works if I exclude the asm
> transitive dependency in my pom
>
>   
> org.eclipse.jetty
> jetty-annotations
> 
> 
> org.objectweb.asm
> org.eclipse.jetty.orbit
> 
> 
>
> On Wed, Oct 1, 2014 at 11:46 PM, 'Roberto Lublinerman' via GWT Contributors
>  wrote:
>>
>> This seems to be the error:
>>
>> java.lang.IncompatibleClassChangeError: class
>> com.google.gwt.dev.javac.asm.CollectMethodData has interface
>> org.objectweb.asm.MethodVisitor as super class
>>
>> and the problem seems to be that you have ASM < 5 in your class path. (It
>> seems that MethodVisitor was an interface in ASM < 4 and is now an abstract
>> class.
>>
>> 2.7 no longer rebases ASM
>>
>> On Wed, Oct 1, 2014 at 2:33 PM, Manuel Carrasco Moñino 
>> wrote:
>>>
>>> Hi all,
>>>
>>> Do anyone knows what could change lately which makes the compiler fail if
>>> jetty annotations is in your classpath.
>>>
>>> The way to reproduce is compiling any project which jetty-annotations.jar
>>> before  before gwt-dev.jar.
>>>
>>> Attached trace.
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtxtLYTr43FBqwm7-CLFMkGVcS2Oi9-vPP6MdpkqqPw_w%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAC7T7gmTDSDYfCPzVg5o1AEXzHNcrXhLL91iWv_n%2BJsVJ-oNxA%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAvmpneRqr1LLry_C612U7PsdY-raj9fPo_5ysAJ3qoGaw%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fUFGt8ksPPoPTwhxUN2xBjVLLoJ%2B%3DbooMpDoy6cN5wWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: DevMode with -superDevMode hardcoded -noprecompile

['Ray Cromwell' via GWT Contributors]

This was fixed recently I think, where all public resources are copied even
if no precompile happens.


On Sun, Sep 28, 2014 at 3:02 AM, Thomas Broyer  wrote:

> I'd rather say DevMode's -superDevMode should share the same behavior as
> https://gwt-review.googlesource.com/#/c/9137/4/dev/codeserver/java/com/google/gwt/dev/codeserver/Recompiler.java
>
>
> On Sunday, September 28, 2014 10:56:17 AM UTC+2, Brandon Donnelson wrote:
>>
>> I've been thinking it might be good to be able to turn off noprecompile
>> when using super dev mode.
>>
>> I found with dev mode, the resources in the public folder could be added
>> to html page, although with -superDevMode on the resources are not
>> available till the first compile happens and this happens after the web
>> page is requested and if any public resources are included in the web page
>> there will be a 404 until the first compile. DevMode blocks until the
>> compile is done so the pattern of resource inclusion has to change for
>> those using public resources in the html page.
>>
>> Anyway do you think -noprecompile should be an option to turn off when
>> running DevMode with SuperDevMode?
>>
>> Thoughts?
>>
>> Thanks,
>> Brandon
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/65212555-efa9-493c-aead-031566baaf20%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fb0_-h0iLHhYJxuEP7qBXo8tQ0UW6w%3Dth3Dpygs5W_2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Chrome LiveEdit and SDM

['Ray Cromwell' via GWT Contributors]

HotPatching via recompilation will require significant work in SDM. If you
just did the naive thing and patched in the JS that changed, stuff would
break:

1) clinit()s which have already been called would be restored, so classes
would get initialized twice
2) some instance fields of the class would get reinitialized
3) callbacks held by JSNI closures might still point to old code in some
circumstances I think

SDM mode would have to do minimally the following:
1) collect only the JS that actually changed
2) don't emit clinits for already live classes,  and if the user added a
new clinit to an existing class or a new statically initialized field,
force a full refresh
3) don't re-emit  field initializers for existing fields on classes, only
for new added fields
4) if method signatures change, may have to force a full refresh
5) the code must be patched in via linker-dependent scope injection as if
it were an AsyncFragment



On Sat, Sep 6, 2014 at 9:05 AM, Ivan Markov  wrote:

> Another option would be to abandon Chrome LiveEdit completely in favor of
> a do-it-yourself approach.
> JavaScript does allow functions and variables redefinition, so maybe we
> can just inject another 

Re: [gwt-contrib] Chrome LiveEdit and SDM

['Ray Cromwell' via GWT Contributors]

Try using the xs linker instead.



On Sun, Aug 31, 2014 at 10:15 AM, Ivan Markov  wrote:

> (Background: I'm trying to further shorten the edit-compile-debug cycle by
> playing with hot-code swapping of recompiled JavaScript in Chrome (via
> Eclipse / SDBG))
>
> GWT 2.7.0-SNAPSHOT, SDM mode, xsiframe linker (obviously), playing with
> LiveEdit from within Chromedevtools initially:
> - Editing ".nocache.js" works
> - However editing "-0.js" does not work (big surprise)
>
> Problem 1: I think the "sourceURL=-0.js" line at the end of the
> script should be present only if CrossSiteIframeLinker is running in
> "non-pretty /  production" mode. In pretty mode, where the 

Re: [gwt-contrib] JsInterop Advance

['Ray Cromwell' via GWT Contributors]

I think the IDL->DOM generation stuff will be the easy part since the API
is driven by the IDL. The more tricky (likely to bikeshed) stuff I think is
modeling all of the ES5 APIs that back everything.  e.g. JsObject, JsArray,
etc.

I somewhat like the old Elemental interfaces (ArrayOf, MapFromStringTo...)
at a high level for allowing shared code to continue to work, but at a
lower level, we need basic interfaces that let you write anything you could
write in JS, like

JsObject.hasOwnProperty(), JsObject.keys(), JsObject.defineProperty(), etc

My goal would be to minimize the need to drop to JS snippets to as small as
possible. But we won't be able to do it perfectly (e.g. dealing with
statics and overloads), and so the workarounds will be where the debate is.
:)




On Thu, Aug 21, 2014 at 9:33 AM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

>
>
>
> On Thu, Aug 21, 2014 at 5:29 AM, Cristian Rinaldi 
> wrote:
>
>> Thanks +Goktug Gokdogan for response.
>>
>> APT is very good option and java 8 support for GWT 3.0 would be a amazing
>> thing.
>> You have a planning for Elemental 2.0 or initial documentation to share,
>> to how you plan address the desing?
>>
>>
> Nothing planned yet other than the plan to work on it :) My anticipation
> is. initially we will auto generate JsTyped DOM, deal with problems and
> incrementally improve it.
>
>
>> El miércoles, 20 de agosto de 2014 16:38:31 UTC-3, Goktug Gokdogan
>> escribió:
>>
>>>
>>>
>>>
>>> On Wed, Aug 20, 2014 at 6:17 AM, Cristian Rinaldi 
>>> wrote:
>>>
 Community:
  I'm playing with JsInterop , and I have two questions:

  1) Are you planning to try the static methods of JS objects, such
 as Object, Promise, etc.?

>>>
>>>
>>> There will be some static helpers provided from the SDK. I originally
>>> started the JSNI 2.0 document but it is basically waiting for me to start
>>> on Elemental 2.0 and accumulate more experience to turn it into something
>>> more concrete.
>>>
>>>
>>>
  2) How do when an instance is mapped to an existing Object, eg
 Promise, has a constructor with parameters?


>>>
>>> Actually I have new ideas on this derived from how some other APTs work.
>>>
>>> I need to update the JsInterop doc but these are the options that I'm
>>> thinking right now:
>>>
>>> *Option 1 (works better for extending):*
>>>
>>> @JsType(prototype = "Promise")public interface Promise {
>>>   /* Protoype_Promise is an autogenerated package visible class */
>>>   public static class Prototype extends Protoype_Promise {
>>> public Prototype(Function... functions) {
>>>super(functions);
>>> }
>>>   }
>>>
>>>   void then(Function f);
>>>
>>>   void cath(Function f);
>>> }
>>>
>>> 
>>>
>>> *Option 2 (works better for general use):*
>>>
>>> @JsType(prototype = "Promise")public interface Promise {
>>>   /* Protoype_Promise is an autogenerated package visible class */
>>>   public static Promise create(Function... functions) {
>>>  return new Protoype_Promise(functions);
>>>   }
>>>
>>>   void then(Function f);
>>>
>>>   void cath(Function f);
>>> }
>>>
>>> 
>>>
>>> *Of course one can do both:*
>>>
>>> @JsType(prototype = "Promise")public interface Promise {
>>>
>>>   public static class Prototype extends Protoype_Promise {
>>> public Prototype(Function... functions) {
>>>super(functions);
>>> }
>>>   }
>>>
>>>   public static Promise create(Function... functions) {
>>>  return new Prototype(functions);
>>>   }
>>>
>>>   void then(Function f);
>>>
>>>   void cath(Function f);
>>> }
>>>
>>> 
>>>
>>>
 Currently to resolve this 1) I created the following class Factory:
 JS
 

 But the interfaces define a contract at the level instance of a
 class or object, this way of doing things, I do not know if it is
 semantically correct.

To solve 2) there are not many options:

  Create a Factory that returns an instance of the object, because
 it has no meaning, only to make the new, implement the interface, because
 the compiler already does.
  There is some progress in this?

  I saw in one of the post a proposal to do something like this:

  Promise Promise.Prototype p = new (new Function ., new
 Function );

 Where Promise, is the interface defined with prototype = "Promise".

 @JsType(isNative = true, prototype = "Promise")
 public interface Promise {

   void then(Function f);

   void cath(Function f);
   }

 Here 'access to jsCore project:

 https://github.com/workingflows/gwt-jscore/
 


>>> Great work. This kind of stuff is also very valuable as a feedback.
>>>
>>>

Re: [gwt-contrib] JsInterop Advance

['Ray Cromwell' via GWT Contributors]

Static methods on interfaces is a Java8 only feature, but I prefer it.
Since you can use Java8 with GWT even if you are running Java7 or below as
a JVM, and since these features are not for shared code, but for Web code,
I'm kinda leaning towards the idea of JSNI 2.0 requiring Java8. We should
have a debate about this in the community. We get several benefits:

1. Static methods on interfaces
2. Defender methods to implement JSNI fragments on JsTypes
3. APIs designed for Lambdas everywhere.


Here's a motivating usecase right now:

@JsType
interface SomeJsType {
  void someMethod();
  default void anotherMethod(int arg) {
js("this.doIt($0, "must be present", arg);
  }
}

That is, there are some cases in Js interfaces where default prototype
dispatch is not what you want, and you need wrapper code.


Another use case

@JsType
@IterateAsArray(getter = "item", length="length")
interface NodeList extends Iterable {
T item(int x);
int length();

   default Iterator iterator() {
  return NodeListIterator(this);
   }
}


for (T x : nodeList) { ... }

Are we ballsy enough to say GWT 3.0 = Java8 source level enforced for
client side code?




On Wed, Aug 20, 2014 at 12:38 PM, 'Goktug Gokdogan' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

>
>
>
> On Wed, Aug 20, 2014 at 6:17 AM, Cristian Rinaldi 
> wrote:
>
>> Community:
>>  I'm playing with JsInterop , and I have two questions:
>>
>>  1) Are you planning to try the static methods of JS objects, such as
>> Object, Promise, etc.?
>>
>
>
> There will be some static helpers provided from the SDK. I originally
> started the JSNI 2.0 document but it is basically waiting for me to start
> on Elemental 2.0 and accumulate more experience to turn it into something
> more concrete.
>
>
>
>>  2) How do when an instance is mapped to an existing Object, eg
>> Promise, has a constructor with parameters?
>>
>>
>
> Actually I have new ideas on this derived from how some other APTs work.
>
> I need to update the JsInterop doc but these are the options that I'm
> thinking right now:
>
> *Option 1 (works better for extending):*
>
> @JsType(prototype = "Promise")public interface Promise {
>   /* Protoype_Promise is an autogenerated package visible class */
>   public static class Prototype extends Protoype_Promise {
> public Prototype(Function... functions) {
>super(functions);
> }
>   }
>
>
> void then(Function f);
>
>   void cath(Function f);
> }
>
> 
>
> *Option 2 (works better for general use):*
>
> @JsType(prototype = "Promise")public interface Promise {
>   /* Protoype_Promise is an autogenerated package visible class */
>   public static Promise create(Function... functions) {
>  return new Protoype_Promise(functions);
>   }
>
>
> void then(Function f);
>
>   void cath(Function f);
> }
>
> 
>
> *Of course one can do both:*
>
> @JsType(prototype = "Promise")public interface Promise {
>
>   public static class Prototype extends Protoype_Promise {
> public Prototype(Function... functions) {
>super(functions);
> }
>   }
>
>   public static Promise create(Function... functions) {
>  return new Prototype(functions);
>   }
>
>
> void then(Function f);
>
>   void cath(Function f);
> }
>
> 
>
>
>> Currently to resolve this 1) I created the following class Factory:
>> JS
>> 
>>
>> But the interfaces define a contract at the level instance of a class
>> or object, this way of doing things, I do not know if it is semantically
>> correct.
>>
>>To solve 2) there are not many options:
>>
>>  Create a Factory that returns an instance of the object, because it
>> has no meaning, only to make the new, implement the interface, because the
>> compiler already does.
>>  There is some progress in this?
>>
>>  I saw in one of the post a proposal to do something like this:
>>
>>  Promise Promise.Prototype p = new (new Function ., new Function
>> );
>>
>> Where Promise, is the interface defined with prototype = "Promise".
>>
>> @JsType(isNative = true, prototype = "Promise")
>> public interface Promise {
>>
>>   void then(Function f);
>>
>>   void cath(Function f);
>>   }
>>
>> Here 'access to jsCore project:
>>
>> https://github.com/workingflows/gwt-jscore/
>> 
>>
>>
> Great work. This kind of stuff is also very valuable as a feedback.
>
>
>> I hope the answers ...
>>
>> greetings
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/3268ccc7-9953-49c9-9079

Re: [gwt-contrib] SDM "-XcompilePerFile": initial feedback

['Ray Cromwell' via GWT Contributors]

On Mon, Aug 18, 2014 at 7:14 AM, Ivan Markov  wrote:

> Dear GWT team (and John in particular),
>
>
> In other words, with the new incremental compiler, the biggest slowdown
> during recompilation seems to be the linker now, right?
> If the linking time can go down to, say, a couple of seconds, then SDM is
> there (IMO).
>
>
Yes, we are working on speeding up the linkers right now. Most of the
linkers just write a file to disk, which should happen in less than a
second.


> For example, I noticed that a huge amount of time (> 50% of the whole
> linking time) is spend in "Saving source with extras", i.e. SourceSaver.
> Given that these sources are only needed by the browser during a
> sourcemap-based debugging session, can't they be served on the fly by the
> code server rather than being pregenerated on disk during the
> recompilation? There are debugging scenarios (in-IDE debugging with SDBG),
> where these source files are not even needed and never requested from the
> codeserver.
>
>
Actually, saving sources isn't strictly needed to make source maps work,
especially for non-Googlers, so we can probably default this to false.


> Finally one side question:
> Does the incremental compiler preserve the names of the generated
> JavaScript types/functions across recompiles? Including the names of the
> types/functions which ARE recompiled (as long as the programmer did not
> change the name of the corresponding Java method/class, that is)?
>
>
Yes, within a session. If you restart SDM, then no. Hot-patching and
expression evaluation are definitely things we've discussed (I want to
build an Apple XCode/Swift Playground-like REPL for fun myself), but first
we've got to make the normal SDM experience out of the box great, including
IDE integration and super-fast recompile.  Once we get there, hopefully we
can do the other things and reach a state that was better than DevMode was.


 --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/5a2a4436-5c2d-4e60-9d5d-314db0045b7d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fS17GY57Qsx_%3DyCqpi9vtz8SJud92j2kKFrh7v2kOFRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Discussion: Elemental Json

['Ray Cromwell' via GWT Contributors]

It is likely that all of the non-collections stuff is going to be
totally redone with JsInterop.
The actual collections interfaces (ArrayOf, etc) as well as Json, we
may keep because it is useful to to have JRE implementations to work
in a shared context.

However, the implementations backing those are likely to be completely
rewritten to use JsInterop. I don't mind splitting things up in
elemental if they want.  My gut feeling is that Elemental 2.0 may have
a completely different package structure.



On Fri, Aug 1, 2014 at 8:07 AM, Manuel Carrasco Moñino
 wrote:
>
> Hi all
>
> There is a patch [1] from Thomas in gerrit for spliting elemental apparently
> in 3 libraries:
> - elemental-collections
> - elemental-json
> - elemental
>
> 1.- What are the plans with elemental-json and elemental-collections?
> 2.- Are they though to replace some similar stuff in gwt-user like
> JsonUtils?
> 3.- Could it replace Json code in server side depending org.json?
> 4.- Is someone working on spliting the code?
>
>
> Thanks
> - Manolo
>
> [1] https://gwt-review.googlesource.com/#/c/4210/
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAtc9z3nbmrfz0Ev%3D3SSFk%3DPZJY%2BBtk_03xOgiVwReHTrQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7dvDF1SLoeJzGSidOmuQizEY5TvNfMvf_gPxenA_YYE%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Translated to null.nullField when using JsInterop & @JsType

['Ray Cromwell' via GWT Contributors]

Can you post the full source for CollaborativeOperation? My guess is
the UserID and SessionID fields are being proven by the compiler to be
uninstantiated types. Are userId/sessionId simple Strings, or some
other type?

.

On Mon, Jun 30, 2014 at 8:18 AM, 'Daniel Kurka' via GWT Contributors
 wrote:
> I have seen this happening before when the pruner removes a type that he
> does not consider live but actually is live.
>
> Fast try, can you change:
> final CollaborativeOperation first = operations.
> get(0);
>
> to:
> final CollaborativeOperation first = (CollaborativeOperation)
> operations. get(0);
>
> -Daniel
>
>
> On Mon, Jun 30, 2014 at 8:09 AM, 田传武  wrote:
>>
>> I'm sure this is an optimizer bug.
>>
>> null.nullField causes the following error at runtime:
>> SEVERE: (TypeError) : Cannot read property 'nullField' of
>> nullcom.google.gwt.core.client.JavaScriptException: (TypeError) : Cannot
>> read property 'nullField' of null
>> at
>> Unknown.$compose(http://localhost:63342/realtime/app/bower_components/realtime-store/realtime-store.js@41)
>>
>> However, the draft compilation javascript works very well.
>>
>> On Monday, June 30, 2014 10:58:08 PM UTC+8, John A. Tamplin wrote:
>>>
>>> Generally, null.nullField means the compiler can prove the value is null
>>> at that point, and draft compile skills the optimization that defects a lot
>>> of that.  So either it really is always null, or there is an optimizer bug.
>>>
>>> On Jun 30, 2014 10:31 AM, "田传武"  wrote:

 Hello,
 The newest @JsType feature is really very fascinating, and works in most
 cases. The only issue i found was the wrong null.nullField javascript
 output.

 the compile command:

 java -cp xxx com.google.gwt.dev.Compiler -war xxx -XnoclassMetadata
 -XnocheckCasts -XjsInteropMode JS -XclosureCompiler -style PRETTY
 com.goodow.realtime.store.StoreProd


 Java code:

 public CollaborativeOperation compose(JsonArray operations) {
 final CollaborativeOperation first =
 operations. get(0);
 if (operations.length() == 1) {
   return first;
 }
 final JsonArray components = Json.createArray();
 operations.forEach(...);
 return new CollaborativeOperation(first.userId, first.sessionId,
 components);
   }


 translated to the following javascript:

  function $compose(operations) {
   var components;
   components = operations[0];
   if (1 == operations.length) {
 return components;
   }
   components = [];
   $forEach(operations, new CollaborativeTransformer$1(components));
   return new CollaborativeOperation(null.nullField, null.nullField,
 components);
 }



 There's an easy workaround to fix this: using the -draftCompile options
 when compilation. Here is the full compilation log:
 https://travis-ci.org/goodow/realtime-store/builds/28777579 (search for
 ./gwt-compile.sh)


 --
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/35eb8ed2-588b-484a-b2f4-b58b5bb01f46%40googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/362b0daf-c174-4021-9bc8-acee19af0cfc%40googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Google Germany GmbH
> Dienerstr. 12
> 80331 München
>
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Katherine Stephens
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujirJ7CD%2B_fRDFyE9kUX%2BCLeeaMbd8JQraWMMp6CWQKtNMQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [gwt-contrib] Re: user tests fail to compile

['Ray Cromwell' via GWT Contributors]

I'm not sure why or when that happened. I checked in a big patch (#7600)
recently that may or may not have caused it. I wonder if someone can seek
back before my commit and see if the failure is still present.



On Sat, Jun 14, 2014 at 11:55 AM, Michael Prentice 
wrote:

> I've uploaded a patch for this:
> https://gwt-review.googlesource.com/#/c/7890/3
>
>
> On Saturday, June 14, 2014 10:22:47 AM UTC-4, Michael Prentice wrote:
>>
>> Thanks Jens, that worked great.
>>
>> This .classpath file is in source control, so this should probably go
>> into a patch. Is anyone working on one already?
>>
>> 
>>
>> On Friday, June 13, 2014 4:28:29 AM UTC-4, Jens wrote:
>>>
>>> In Eclipse any folder that contains super source should be excluded from
>>> the classpath so that its not treated as Java package but instead a simple
>>> folder with java files. So go to gwt-user project settings -> build path ->
>>> source. Select gwt-user/core/test -> Excluded and click edit. Add exclusion
>>> pattern **/super/** . Then the errors are gone in Eclipse.
>>>
>>> -- J.
>>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/6d1e9862-1217-49cd-994c-7faf9dfc36be%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7dYrdat%3DpPuYbxu5g8Sp28SYaiOghfnL583hqCjcvZw5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] SafeHtml on the server/vm

['Ray Cromwell' via GWT Contributors]

Most shared stuff should perhaps be copied into gwt-servlet.jar.  But
that's a temporary solution, really, we need smaller build targets for each
of those dependencies. You should be able to just depend on
gwt-safehtml-shared.jar

-Ray



On Mon, Jun 9, 2014 at 4:58 PM, Colin Alworth  wrote:

> Like I said, its not a concern for me (no servlet, no hibernate, no
> flute), but for those who want to stick gwt-user.jar in a WEB-INF/lib/, it
> would be nice to not have to renamed it "zwt-user.jar".
>
> My knee-jerk reaction is to put it in gwt-servlet (since other relatively
> new classes like AutoBeanFactorySource also made it in there) - does that
> seem like a reasonable step?
>
>
> On Mon, Jun 9, 2014 at 6:22 PM, John A. Tamplin  wrote:
>
>> On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth  wrote:
>>
>>> Currently SafeHtml &co live in gwt-user, though they are for the most
>>> part listed in a shared package, implying that a server can use them.
>>> However, gwt-user.jar also includes javax packages as well as hibernate,
>>> w3c, etc, so can't reasonably be imported to a server which already uses
>>> any of those packages (i.e. any servlet container). Is this an oversight in
>>> the publicly packaged GWT and is SafeHtml used by teams that package
>>> differently, or instead is this package not actually intended for server
>>> use, but instead just compile-time tasks where gwt-user is on the classpath
>>> like compiling or linking?
>>>
>>> I'm doing some work on a non-servlet server which hasn't so far seen
>>> concrete issues with gwt-user.jar, and having SafeHtml seemed to be an easy
>>> way to get server generated HTML from code that is shared with the client.
>>> This use case *appears* to be implied from the package name, but presently
>>> isn't possible for the majority of GWT backends.
>>>
>>> Ideas on why it is the way it is? Thoughts on how to make it available
>>> to the server (without giving it yet another jar a la
>>> requestfactory-server)? Interest in a contributed SafeHtmlTemplates
>>> implementation for JVM?
>>>
>>
>> Yes, SafeHtml is intended to be usable on the server.  There have been
>> various discussions about splitting up gwt-user into parts for client-only,
>> shared (and perhaps server-only), but that wasn't ever done.
>>
>> Mostly, putting gwt-user last on the classpath on your server won't cause
>> any issues, though at least one JVM used to be unhappy with native methods
>> without corresponding binaries.
>>
>> --
>> John A. Tamplin
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>  To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> 218.248.6165
> niloc...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzdu5cz3bjvWYW7%3DvUm%3D%3DfC0b83sg0%3Dbs7j%2BmTNDjFSeg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7cfPkbaNNZNFEpJ2R1%3DxzETb%2BR%3D67ikz2%3D51XLnwrUb%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[gwt-contrib] Re: When Migrating JsInterop from GWT-Exporter to @JsInterface, JSORestrictionsChecker throws NullPointerException

['Ray Cromwell' via GWT Contributors]

JsInterop is only half implemented and not for use right now. There are
several big patches that are going to land soon which change a lot about
it. I would hold off using it until then.



On Fri, Jun 6, 2014 at 1:24 AM, 田传武  wrote:

> Hello,
>
> I tried converted two projects we are currently using GWT Exporter to
> @JsInterface for interoperate with JS. The *first project*
> 
>  only
> exports three interfaces, and translated successfully.
>
> The second project's first migration step translated successfully, here
> are the commit and compile log:
>
> https://github.com/goodow/realtime-store/commit/643e5efc2a92ac9cbcbadc8b7dd1d97e456bfe92
> https://travis-ci.org/goodow/realtime-store/builds/26914674
>
> However, i encounter a strange NullPointerException when annotates more
> @JsInterface, here are the second commit and compile log:
>
> https://github.com/goodow/realtime-store/commit/f9b2978c6a91d6afe9cd0d6d0ebd20adbf34480a
> https://travis-ci.org/goodow/realtime-store/builds/26915260
>
> Thanks for help :)
>

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

Re: [gwt-contrib] Re: GWTproject site menu

['Ray Cromwell' via GWT Contributors]

While not part of this CL, the bottom footer being in the center of the
page on some short pages looks ugly. The footer should always be at least
at the bottom, or offscreen.



On Thu, May 8, 2014 at 2:27 PM, 'Brian Slesinsky' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> If you click "Tutorial" and then "Documentation" the animation is a bit
> unfortunate. Because the previous menu closes at the same time that the new
> one opens, the new menu expands both up and down so that your cursor ends
> up pointing to the middle of the new menu, and then you have to wait until
> it stops moving to figure out where to move the mouse next. In the old UI,
> the menu item you just clicked on never moves.
>
> But I'm not sure what to do about it. Maybe skip animating closing a menu
> when it's not the one you clicked on?
>
> Also, it's not in the demo, but we should make sure sourcemap debugging
> works with the new version. I sometimes include a link to gwtproject.orgin 
> browser bug reports since I don't know any other public websites that
> have GWT with sourcemaps on. Unfortunately this is going to break any
> specific directions I put into the bug reports, but hopefully something
> equivalent should work.
>
> - Brian
>
> On Thu, May 8, 2014 at 1:59 PM, Manuel Carrasco Moñino 
> wrote:
>
>> That's intentional, it is the same behavior than tree menus in google
>> wikis and GWT trees.
>> Now the parent item link is only clickable when it has a page associated
>> (it was not possible in the last version), so the click is handled to load
>> that page.
>>
>>
>> On Thu, May 8, 2014 at 6:19 PM, Jens  wrote:
>>
>>> I noticed that it is not possible anymore to close a menu category by
>>> clicking on the menu item text again. You can now only close a category by
>>> using the triangle icon.
>>>
>>> -- J.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>>  To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/2f99fddc-668c-449a-8e98-2abf26d8a3bd%40googlegroups.com
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>  To view this discussion on the web visit
>> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsxeDCVrEHLrMm4icr%2BY-OVh89RBqfDdnbBUi_qyudZaA%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT8z5gtVUbMpkmtLdoykvYv%2BrGgYDT79agjLBG0VzC1X_Q%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Ray Cromwell]

BTW, it is unlikely we will adopt lombok. We only considered it because the
JS Interop stuff depends on a 'magic' .Prototype class, and you cannot use
APT to inject subclasses into another existing class, but Lombok can
because it can rewrite classes. However we got deeply burned by DevMode
depending on undocumented browser native APIs and we'd like to avoid
depending on non-official APIs to make a core feature work.

Since APT is supported by all Java tools, and already works with
@AutoValue, we are likely to use it for the magic Prototype stuff, it just
will be less pretty, e.g.

@JsInterface(prototype = 'HTMLButtonElement')
interface HTMLButtonElement {
}

class GangnamButton extends HTMLButtonElement_prototype {
...
}

// auto-generated by APT
class HTMLButtonElement_prototype implements HTMLButtonElement {
}


My argument for using "_" is that using _ in Java class names is
unconventional and clearly denotes a special class, generated, that you
shouldnt touch. Also, @AutoValue also uses "_" in the name for the same
reason.


Hopefully, the way this works in your IDE is that the moment you create the
JsInterface and hit Save, APT will run and create the magic _prototype
class, and then you can start writing your Web Component or JS-subtype in
Java by extending it without red squigglies.

Lombok by contrast required seperate Java IDE plugins for IntelliJ and
Eclipse to make this happen.



On Fri, Feb 28, 2014 at 4:59 PM, James Nelson  wrote:

>
>> SourceWriter is not incompatible with APT, just like JavaWriter is not
>> incompatible with generators. Both take a PrintWriter where they write;
>> SourceWriter is string-based with only a few helpers for javadoc and
>> indent/outdent, whereas JavaWriter is more "Java oriented" with methods to
>> begin/end types, methods, control flow blocks, fields, etc.
>>
>
>  Not to shamelessly plug my own work or anything, but I do maintain a
> SourceBuilder library that contains piles of helper functions, the ability
> to add method or field buffers that effectively tear-off a position in the
> source writer, so you can build multiple methods at the same time; it uses
> all fluent interfaces, automatically imports classes (returning the
> shortest name possible that can be used in code [fully qualified if import
> name is already taken]), has fluent interfaces for all methods, and has
> simple support for jsni.
>
>
> https://github.com/WeTheInternet/xapi/blob/master/dev/source/src/main/java/xapi/dev/source/
> net.wetheinter
> xapi-dev-source
> 0.4
>
> It looks something like:
>
> MethodBuffer valueProvider = beanCls
> .createMethod("protected Object valueOf(String name, Object o)")
> // definition is lexed; it can be modified later if you desire
> .setUseJsni(true)
> .addAnnotation(UnsafeNativeLong.class)
> .println("switch(name) {")
> .indent()
> .println("case 'this': return o;")
> .println("case 'this.name()':")
> .indentln("return o...@java.lang.Object
> ::getClass()().@java.lang.Class::getName()();");
>
> Or, here's a test with more features:
>
> SourceBuilder b = new SourceBuilder(
>   "public static abstract class Test");
> b.setPackage("xapi.test");
> b.getClassBuffer()
>   .createMethod("public  void
> Test(java.lang.String t) {")
>   .indentln("System.out.println(\"Hellow World\" + new
> java.sql.Date());")
>   .createLocalClass("class InnerClass ")
>   .createMethod("void innerMethod()")
>   ;
> // We discard java.lang imports
> Assert.assertFalse(b.toString().contains("import java.lang.String;"));
> // We used java.util.Date as a fully qualified name first, so it
> should be imported
> Assert.assertTrue(b.toString().contains("import java.util.Date;"));
> Assert.assertTrue(b.toString().contains(""));
> // We used java.sql.Date as a fqcn after java.util.Date, so it must
> NOT be imported
> Assert.assertFalse(b.toString().contains("import java.sql.Date;"));
>
> At the core, it's based on StringBuilder, and it takes the best of
> SourceWriter and JavaWriter, then adds a bunch of shiny on top.
> It's mutable, supports the notion of ClassBuffer, MethodBuffer and
> FieldBuffer, with child writers scoped correctly, to make inner classes or
> even local classes that retain their place in the SourceBuilder stack.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it,

Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family

[Ray Cromwell]

I think if we move to APT, you can do AST based code-gen via something like
a JavaWriter to a stream, or if we adopt lombok, then you construct code by
directly manipulating the trees of JavaC and JDT.




On Thu Feb 27 2014 at 4:17:15 PM, James Nelson  wrote:

> Is there anywhere to get a sneak preview on the discussions about the
> future of codegen?
>
> Andres and I have both invested time in some extensions of ast-based
> codegen, and could really use some time and forewarning to adapt our
> strategy to stay future-friendly with out apis.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: XSS in GWT

[Ray Cromwell]

Maybe Matthew Dempsky can comment, but I believe there's an error-prone
plugin that handles checking for XSS in GWT and bad use of SafeHtml/setHTML.



On Tue, Jan 28, 2014 at 12:05 PM, Kurt Dmello  wrote:

> Thanks Thomas,
> That was helpful.  I tried the img tag and it did work.
>
>
> What you're seeing here is browser "sanitization" from innerHTML (not
>> sanitization actually, just that the 

Re: [gwt-contrib] Deprecating DeRPC classes

[Ray Cromwell]

DeRPC was essentially an experiment that didn't work out, it was supposed
to improve the speed of IE6. It added a lot of hacks to the compiler to
make it work, @ArtificialRescue, ability to invoke client-side methods from
server emitted functions, which actually requires clever hacks in some
classes to prevent inlining (see java/lang/Class emulation code)

It would be good to remove it. If you want really fast RPC, go with
something like JAXRS + JSOs. Parsing is blistering fast with JSON.parse()
on today's browsers, and there's no need to deserialize/copy.  RestyGWT is
one possibility.



On Tue, Nov 5, 2013 at 10:07 AM, Matthew Dempsky wrote:

> Just curious, is there a particular impetus to removing DeRPC at this
> time?  E.g., is it causing code bloat or slowness, or making new
> development more difficult?
>
> I'm fine with marking the class as @Deprecated, but unfortunately we
> [Google] still have an internal customer using DeRPC and so far I haven't
> been successful in convincing them to prioritize moving off of it.  (I did
> manage to remove our other internal uses of DeRPC.)
>
> Alternatively, if there's an easy way for us to split DeRPC out of GWT
> core and maintain it separately, I'm happy to do that (e.g., we're already
> doing that for GWTShell).  But it sounds like DeRPC is heavily entangled
> into GWT-RPC?
>
>
> On Tue, Nov 5, 2013 at 9:45 AM, Thomas Broyer  wrote:
>
>> The first step would be to delete com.google.gwt.rpc and the
>> HybridServiceServlet, and then remove all the hooks in RPC that were added
>> to make deRPC possible (there's at least one in RemoteServiceServlet), and
>> probably others in the RPC generator.
>>
>>
>> On Tuesday, November 5, 2013 5:26:21 PM UTC+1, Stephen Haberman wrote:
>>>
>>> Hi Naresh,
>>>
>>> > Could you please let me know is there any patch available to check
>>> > the impact of removing de rpc calls.
>>>
>>> I'm glad you're interested in looking in to this.
>>>
>>> Unfortunately, I don't really know much about DeRPC. There are probably
>>> others on the gwt-contrib list who do though...we'll see if anyone can
>>> point you in the right direction.
>>>
>>> - Stephen
>>>
>>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Steering committee meeting on GWT 3.0 IE & Java compatibility

[Ray Cromwell]

I don't think we should make hard guarantees, but we should have roadmaps
and milestones. If you look at how Firefox and Chromium work, they put all
kinds of new HTML5 features on the wishlist, prototype implementations are
done behind experimental flags, but most don't make the cut. Finally, they
announce an "intent to implement", which is a more serious declaration that
a particular feature is going to graduate from behind a flag.



On Tue, Oct 8, 2013 at 2:45 PM, Brian Slesinsky  wrote:

> In practice on open source projects, things happen because some person or
> company volunteers to implement them and sees the project through to the
> end. So I don't really see steering committee schedule-making as a process
> that's going to work. The Google GWT team is going to set its own quarterly
> goals and everyone else is going to make their own decisions about what to
> work on too.
>
> And even if it could work, it's not a good idea. As a more recent example,
> I don't think we should still do Mavenization just because that's what we
> originally decided and there were slides at Google I/O to that effect.
> That's not a winning argument. We should fix the build process in the way
> that makes the most sense now.
>
> We're not doing GWT users any favors by making flat-out promises we won't
> necessarily keep. It's fair to say that there some things we have to do and
> supporting major browsers is certainly one of them. But if it's at all
> doubtful we should leave things open and it's a good idea to hedge. A good
> phrase to use is "we don't have a crystal ball, but [...]".
>
> - Brian
>
> On Tue, Oct 8, 2013 at 2:02 PM, Thomas Broyer  wrote:
>
>> But we now have a steering committee, and decisions are made in public so
>> anyone can bug you when you forget. That's a different situation than
>> before.
>> Le 8 oct. 2013 22:43, "Brian Slesinsky"  a écrit :
>>
>>>
>>> On Tue, Oct 8, 2013 at 12:15 PM, Jens  wrote:
>>>
 [...] since in practice we won't consider ourselves bound to them.
>

 Why not?

>>>
>>> Because we'll either we'll forget about that page due to turnover or
>>> something new will happen and priorities will change. Put it this way: how
>>> much do you feel bound by decisions made a few years ago by people who no
>>> longer work on GWT?
>>>
>>> - Brian
>>>
>>>  --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "GWT Contributors" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/google-web-toolkit-contributors/GO4iP9RkxQY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Steering committee meeting on GWT 3.0 IE & Java compatibility

[Ray Cromwell]

As long as we don't use Java8 specific features in non-supersourced code,
we can get away with running on other JREs. So for example, the public
interfaces and internal implementations of gwt-user APIs could probably not
rely on java.util.function, java.util.streams, or java.time. If that were
the case, you could run in jre6 and even compile Java8 source. However,
this might lead to a lot of headaches.

My personal gut feeling is that at some point, we're going to have to break
people if we want to retire technical debt and radically improve things. If
we do that, we might be able to continue to evolve the 2.x line by
cherypicking 3.0 features back into it, but I think it'll be hard to really
leverage Java8, and make it work on JRE6, because the best integration is
to retrofit the existing gwt-user.jar APIs as needed, and to make that work
on JRE < 8, we'd need to ship two versions of the APIs :-(






On Tue, Oct 8, 2013 at 1:44 AM, Thomas Broyer  wrote:

> [cc: gwt-contrib, please follow-up there]
>
>
> On Tue, Oct 8, 2013 at 10:06 AM, Artur Signell  wrote:
>
>> On Oct 8, 2013, at 4:59 AM, Matthew Dempsky  wrote:
>>
>> On Mon, Oct 7, 2013 at 1:17 AM, Joonas Lehtinen wrote:
>>
>>> Furthermore we should decide if GWT 3.0 supports Java 6+ or Java 7+ or
>>> Java 8+.
>>>
>>
>> Joonas, can you clarify whether you're referring here to support for user
>> code (i.e., whether the GWT compiler will support compiling Java 6/7/8
>> code) or about host JVM support (i.e., whether the GWT compiler and
>> libraries will run on a Java 6/7/8 VM)?
>>
>>
>> Both the questions are interesting to me:
>>
>> 1. What's the oldest Java version you can use to compile the GWT project?
>> (This also defines the oldest version you can use in your GWT app and where
>> you can deploy your app)
>> 2. What's the newest Java version you can use in your own GWT app project?
>>
>> Today (GWT 2.6) we have:
>> 1. The project can be compiled using Java 6 provided you manually disable
>> the Java 7 tests. The server classes are usable on a server which supports
>> Java 6 (most modern servers).
>> 2. You can use Java 7 to develop your GWT app.
>>
>> Where are we going with GWT 3.0?
>> 1. Java 6? I don't see much reason to change this to Java 7 as there are
>> not many major improvements in 7 compared to 6. The most visible effect
>> would be that you can no longer deploy your application on servers
>> supporting only Java <= 6. Java 8 again has advantages but the server
>> support is not there.
>>
>
> Note that we could have different targets for client vs. server code, or
> maybe just for "main" vs. "test" classes: compile GWT with "-source 1.6
> -target 1.6" and compile tests with "-source 1.7 -target 1.7" (or even
> 1.8); i.e. require Java 7 (or 8?) for building GWT, but not for running it.
>
> I see no reason to *not* mandate Java 7 (or newer) for hacking on GWT.
>
>
>> 2. For this I see Java 8 as a must-have
>>
>
> We would need tests for the Java 8 features, which would mandate using
> Java 8 for building (testing) GWT; unless we start using "profiles" to
> disable sets of tests that we know cannot be compiled/run with the current
> JDK.
>
> Note: I'm assuming that by GWT 3.0 we'll have switched our build system.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Setting up Eclipse for Contributing to GWT

[Ray Cromwell]

Apropos to my thread on this the other day, it's way too hard for casual
contributors to get started. ;-(



On Mon, Sep 30, 2013 at 12:43 PM, Jonathan Strootman wrote:

> The only part I got stuck on was the "tools" installation. It is mentioned
> in the README.txt, but I mixed it up with the tools directory that is in
> the source already.
>
> As Thomas pointed out, it is a separate repo. I'm guessing that I'm not
> the only one who ran into that problem.
>
> Also, if you are contributing, don't forget the CLA (
> http://www.gwtproject.org/makinggwtbetter.html#clas).
>
>
> On Wednesday, September 25, 2013 4:07:12 AM UTC-7, Samuel Schmid wrote:
>>
>> No i did't saw that. Thanks for the hint. I'll check this and come back
>> if I stuck.
>>
>> Sam
>>
>> On Wednesday, September 25, 2013 12:15:27 PM UTC+2, Thomas Broyer wrote:
>>>
>>> Have you tried following the eclipse/README.txt?
>>>
>>> BTW, you also need to "svn checkout http://google-web-toolkit.**
>>> googlecode.com/svn/tools
>>> "
>>>
>>> On Wednesday, September 25, 2013 11:13:06 AM UTC+2, Samuel Schmid wrote:

 Hi to all contributors

 I'm developing with GWT since two years and now i want to contribute to
 GWT.

 I checked out the GWT Source Code with

 git clone https://gwt.googlesource.com/**gwt 
  trunk

 But I don't understand how to setup my eclipse project.

 Does somebody have some hints for me?

 Sam

>>>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

The @jar stuff isn't needed, I was just experimenting around in my patch.


On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer  wrote:

>
>
> On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote:
>>
>>
>> I bit the bullet and came up with a set of gradle files that can generate
>> IDEA projects which successfully import and then allow you to build
>> dev/user in the IDE and launch compilation of the samples. It's non-ideal
>> because the builtin IDEA support for importing gradle projects doesn't give
>> enough control (need to add Java source to class path but exclude it from
>> javac compile) However, running "gradle idea" generates the proper files
>> from the command line and you just open them.
>>
>
> And now I regret not having (seriously) looked at Gradle before ;-)
>
> IIUC, thanks to the Ivy backend, we could even remove the need to checkout
> the "tools" from SVN, and simplifying dependency management at the same
> time; with a combination of "client module 
> dependencies"<http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies>
>  and
> an Ivy repository with custom 
> patterns<http://www.gradle.org/docs/current/userguide/dependency_management.html#N14ECC>;
> maybe not worth the effort if we want to stop bundling our dependencies in
> the JARs (they'll have to be deployed to some Maven repo –Central– to
> support Maven).
>
> I'm gonna work on adding support for building and running unit tests and
>> adding SuperDevMode launch rules, then I'll put it up for review.
>>
>
> Would you mind publishing what you have already? (publish as a draft
> –refs/drafts/master instead of refs/for/master– and add me as a reviewer if
> you don't want to publicize it yet)
> I'm curious how well Gradle will handle the fact that gwt-dev tests
> require gwt-user.jar (and includes the sources of the HelloWorld sample,
> but that's easy)
>
>
>> Eclipse users will have to figure out their own gradle magic. ;-p
>>
>
> I'll have a look at it then (yep, still mostly an Eclipse user)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

Here's a commit on my private fork containing the gradle stuff
https://github.com/cromwellian/gwt-sandbox/commit/8f26f05d78109d0d9a91871df9102c0b461bef90



On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer  wrote:

>
>
> On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote:
>>
>>
>> I bit the bullet and came up with a set of gradle files that can generate
>> IDEA projects which successfully import and then allow you to build
>> dev/user in the IDE and launch compilation of the samples. It's non-ideal
>> because the builtin IDEA support for importing gradle projects doesn't give
>> enough control (need to add Java source to class path but exclude it from
>> javac compile) However, running "gradle idea" generates the proper files
>> from the command line and you just open them.
>>
>
> And now I regret not having (seriously) looked at Gradle before ;-)
>
> IIUC, thanks to the Ivy backend, we could even remove the need to checkout
> the "tools" from SVN, and simplifying dependency management at the same
> time; with a combination of "client module 
> dependencies"<http://www.gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies>
>  and
> an Ivy repository with custom 
> patterns<http://www.gradle.org/docs/current/userguide/dependency_management.html#N14ECC>;
> maybe not worth the effort if we want to stop bundling our dependencies in
> the JARs (they'll have to be deployed to some Maven repo –Central– to
> support Maven).
>
> I'm gonna work on adding support for building and running unit tests and
>> adding SuperDevMode launch rules, then I'll put it up for review.
>>
>
> Would you mind publishing what you have already? (publish as a draft
> –refs/drafts/master instead of refs/for/master– and add me as a reviewer if
> you don't want to publicize it yet)
> I'm curious how well Gradle will handle the fact that gwt-dev tests
> require gwt-user.jar (and includes the sources of the HelloWorld sample,
> but that's easy)
>
>
>> Eclipse users will have to figure out their own gradle magic. ;-p
>>
>
> I'll have a look at it then (yep, still mostly an Eclipse user)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

I bit the bullet and came up with a set of gradle files that can generate
IDEA projects which successfully import and then allow you to build
dev/user in the IDE and launch compilation of the samples. It's non-ideal
because the builtin IDEA support for importing gradle projects doesn't give
enough control (need to add Java source to class path but exclude it from
javac compile) However, running "gradle idea" generates the proper files
from the command line and you just open them.

I'm gonna work on adding support for building and running unit tests and
adding SuperDevMode launch rules, then I'll put it up for review. Eclipse
users will have to figure out their own gradle magic. ;-p



On Thu, Sep 26, 2013 at 10:29 PM, Brian Slesinsky wrote:

> I skimmed the Gradle manual and it looks pretty decent. While the syntax
> and terminology is different, it looks like the concepts map back to stuff
> I'm already comfortable with.
>
> It has "tasks" which are basically build rules which are configured via
> Groovy (instead of Python macros). The tool builds and executes a
> dependency graph, and you can look at the dependency graph before running
> it. There is a dependency cache and it sounds like they care about both
> avoiding duplicate work and reproducible builds. It has Maven and Ant
> compatibility without actually being Maven or Ant. Also, Android is
> standardizing on it which is a plus.
>
> Here's a good place to start reading:
> http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html
>
> - Brian
>
>
>
> On Thu, Sep 26, 2013 at 5:12 PM, Cristiano Costantini <
> cristiano.costant...@gmail.com> wrote:
>
>>
>>
>> Il giorno venerdì 27 settembre 2013, Goktug Gokdogan ha scritto:
>>
>> I have been in favor of Buck because that is what most contributors are
>>> already familiar with and can bring their expertise.
>>>
>>
>> This is a good point which need to be taken into account.
>>
>> But I've found frustrating buck cannot be built on windows, and no
>> binaries are provided. Also, it required me to upgrade to JDK 7 on the mac
>> before I can start to "try" building GWT...
>>
>> If this is the way to start with contributing to GWT it could be a
>> limitation...
>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Possible firefox leak fix

[Ray Cromwell]

Wow, colin you're on fire recently with your contributions. ;-)




On Tue, Sep 24, 2013 at 6:48 PM, Colin Alworth  wrote:

> Done, change is at https://gwt-review.googlesource.com/4680.
>
> Concern about breaking WindowImpl#initWindowCloseHandler was my guess as
> well - after connect() is called and the app starts up, the app has already
> wired up its own close handler, so it is too late when connect is
> successful to replace unload.
>
> Both the standard WindowImpl and the IE specific one replace onunload and
> call the old version, so provided those stay consistent with
> hosted.html/devmode.js, this approach should be okay...
>
> I'd love to get any independent verification on this as even being a
> viable fix - I've only tried it in FF24/mac so far.
>
> -Colin
>
>
> On Tuesday, September 24, 2013 8:02:54 PM UTC-5, Brian Slesinsky wrote:
>
>> +cromwellian since he did unload support.
>>
>> Oops, I see now that you attached it. Could you upload it to Gerrit?
>>
>> I looked pretty hard for a reason why it's window.onUnload and not
>> window.onload and I can't find any. It dates back to 2010 at least and was
>> copied from hosted.html, whether deliberately I don't know.
>>
>> One issue is that it's possible the app itself might want an onunload
>> handler. See
>> user/src/com/google/gwt/user/**client/impl/WindowImpl.java line 32 where
>> it can install an onunload handler. It does preserve the old one but it
>> still seems kind of fragile to install one in the devmode.js. I wonder if
>> there's some way to detect the unload event in C++?
>>
>> - Brian
>>
>>
>>
>> On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth  wrote:
>>
>>> The patch I provided only tweaks the normal source, and leaves the
>>> generated sources and binaries alone - I think that is already what you are
>>> after.
>>>
>>> Note that this does *not* stop the leak by itself - we need to decide
>>> what to do about hosted.html/devmode.js. One (ugly) option is to try to
>>> have the ff plugin add an event handler to the window's close to call back
>>> to its own disconnect? I think there are other ways we could think about
>>> doing this as well, but changing hosted.html keeps it consistent across the
>>> board.
>>>
>>>
>>> On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:
>>>
 Hi,

 Wow, thanks for tracking this down! Could you send a patch that just
 modifies the source (not worrying about the autogenerated files)? I will
 rebuild them when I do the next release.

 Usually I just leave the existing dll's alone and move forward; it's
 not worth fixing older plugins. However, I believe Firefox 24 will be an
 ESR release so I think it's worth rebuilding that version.



 On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth wrote:

> I spent a little time this weekend learning how to build firefox
> plugins, and a little time spilled out into this week, but I think I'm at 
> a
> point where I can share what I've done, what I'm seeing, and start asking
> for help to finalize this (if it is as meaningful as I hope it is).
>
> First, the issue itself: It looks like we're actually leaking on both
> ends - that is, not just in the JVM, but in the browser itself. When Dev
> Mode transfers control back to the browser itself, it runs
> BrowserChannelServer.**reactToMe**ssages(). This listens at the open
> socket between the browser's plugin and itself, and waits for the next 
> byte
> to float over the wire, meaning that the browser wants something. This
> waiting specifically happens in Message.readMessageType, where we block on
> stream.readByte(). Once a tab/window has been closed, the thread that is
> actively watching that connection stays stuck in readByte(), waiting for
> that next message to float over the wire.
>
> My first thought was "why can't we just ask if that socket is closed?"
> - well, the socket *isn't* closed, which means that the browser is leaking
> the socket itself, along with whatever supporting objects were set up to
> manage that socket. Note that this suggests a workaround to the leak - 
> quit
> and relaunch firefox, and since the socket will be forcibly closed then,
> readByte() will throw a EOF exception, and reactToMessages will trip off a
> RemoteDeathError (not ideal, but at least it just logs it and moves on,
> finishing the leak off).
>
> Next I dug into how to make the plugin actually disconnect when the
> page was closed. I started this by finding exactly where the socket was
> opened (common/HostChannel.{h|cpp}), then what creates HostChannel objects
> in the firefox plugin. This turns out to be achieved in this line in
> xpcom/ExternalWrapper.cpp (plus instructive comments):
>   // TODO(jat): leaks HostChannel -- need to save it in a session
> object and
>   // return that so the host page can call a 

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

At Google our BUILD files are distributed throughout the source directories
as we try to make them as simple as possible with as strict dependencies as
possible.  I'd love to have a Buck file that could compile
gwt-dev/user/servlet, but it would be even better if there was one for each
and every module and important subsystem.

The former is important because, we'd likely want to write a
"gwt_module"/"gwt_application" plugin for Buck (What Google has internally,
they are the equivalent of java_library/java_binary, but run GWT) and to
make incremental compilation work, we'd want things modularized in smaller
pieces. The latter because, there are parts of gwt-dev people would like to
use that are not neccessarily needed in the jar.

Is the Buck experiments you're doing working with the trunk as is, or on
your de-tangling dependency work you've done as part of the mavenization
attempt?



On Thu, Sep 26, 2013 at 4:09 PM, Thomas Broyer  wrote:

>
>
> On Thursday, September 26, 2013 3:35:15 AM UTC+2, Ray Cromwell wrote:
>>
>> Thomas,
>>   In terms of Gradle vs Buck models, is there any possibility of writing
>> a tool that takes a Buck build file and produces Gradle files? That would
>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>> clone of Google's BUILD system, and so that would actually help us to have
>> just one set of build files for internal vs external. However, it would be
>> nice not to have to hack the IDE stuff manually.
>>
>
> It would of course be possible, but would *a priori* require duplicating
> a bunch of code from Buck (search for all BUCK files, exec them with custom
> implementations of the build rules, find the "source root" using the
> .buckconfig's java.src_roots config)
> "buck targets --json --type java_library" wouldn't work as it "resolves"
> the glob() calls, so you'd have to call the tool every time you create a
> file so it updates the Gradle files to include the new file)
>
> That said, based on Shawn Pearce's experience on Gerrit, I'm not sure
> having the IDE configured the same way as the build is a requirement (for
> Gerrit, there's a single Eclipse project with all the sources)
>
> If Buck is like Google's BUILD, then a genrule could be used to download
>> dependencies from Maven repos. ;-)
>>
>
> That's what Gerrit is doing ;-)
> (they also “hack the IDE stuff” that way, generating Eclipse .project and
> .classpath; Buck has built-in support for IntelliJ but it only work if you
> have BUCK files spread within your project's source tree, rather than a
> single BUCK file like I did)
> Ivy would also work, used as a standalone tool. And a small tool could
> produce a BUCK file with prebuilt_jar rules for the downloaded
> dependencies, without the need to handle transitive dependencies manually.
> Ivy would also help deploy the generated JARs to Central.
> The more I think about it, the more I like the Buck+Ivy combo idea, but it
> requires building a few additional tools… (IDE configuration, release
> script, etc.)
> I'm just starting to try Gradle for a project at work, if it goes well,
> maybe I'll experiment with it on GWT (first step: replace Ant with Gradle,
> then possibly modularize in the same way I did it with Buck, without moving
> files, then we could decide the best file/folder layout for both Gradle and
> Google)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

Direct IDE still has benefits. Anytime a change is made to the build file
that requires regenerating the project, you run the risk of not preserving
project settings by overwriting stuff that is stored in those files that is
not part of the build, unless your generator has surgical capabiltiy (like
the IDE does).

IntelliJ has surgical Maven capability. If you import some dependency, it
can automatically offer to add it to a pom file, and if you edit the pom
file, it can automatically update the build dependencies in the IDE file.
It's just faster roundtripping.

That said, I am not opposed to writing a plugin or genrule for Buck to do
this. I would only say that if we are going to move to Buck, a prerequisite
is that we restructure the code the way Thomas has been moving to work more
like it does in Google3. Instead of one 'dev' dir and one 'user' dir, each
subdirectory that houses a major component should have a build file in it.
I should be able to rebuild say, the javac/jdt stuff without rebuilding all
of gwt-dev while developing. Things need to be more modular.



On Thu, Sep 26, 2013 at 3:35 PM, Brian Slesinsky wrote:

>
> On Thu, Sep 26, 2013 at 10:26 AM, Jens  wrote:
>
>>
>>>   In terms of Gradle vs Buck models, is there any possibility of writing
>>> a tool that takes a Buck build file and produces Gradle files? That would
>>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>>> clone of Google's BUILD system, and so that would actually help us to have
>>> just one set of build files for internal vs external. However, it would be
>>> nice not to have to hack the IDE stuff manually.
>>>
>>> If Buck is like Google's BUILD, then a genrule could be used to download
>>> dependencies from Maven repos. ;-)
>>>
>>
>> Shouldn't it be the other way around? A Gradle plugin that generates
>> Google build files sounds more logical to me as you have more freedom to
>> adjust the generated files to your internal system. Outside Google no one
>> will really use these buck/internal build scripts anyways (lack of IDE
>> support).
>>
>
> I don't think direct IDE support for the build system is necessary so long
> as we can generate correct IDEA and Eclipse projects via commands that
> everyone can run, sort of like the webAppCreator command. The real question
> is what language we want the project definitions to be in; it should be
> something easy to understand, edit, and generate other representations from.
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

It really depends on what Thomas or contributors are going to do, I don't
think we have any bandwidth on the GWT team to work on this right now ;-)



On Thu, Sep 26, 2013 at 10:26 AM, Jens  wrote:

>
>>   In terms of Gradle vs Buck models, is there any possibility of writing
>> a tool that takes a Buck build file and produces Gradle files? That would
>> seem like a good option in lieu of waiting for Buck support in IntelliJ and
>> Eclipse. This isn't to say I have anything against Buck, it is literally a
>> clone of Google's BUILD system, and so that would actually help us to have
>> just one set of build files for internal vs external. However, it would be
>> nice not to have to hack the IDE stuff manually.
>>
>> If Buck is like Google's BUILD, then a genrule could be used to download
>> dependencies from Maven repos. ;-)
>>
>
> Shouldn't it be the other way around? A Gradle plugin that generates
> Google build files sounds more logical to me as you have more freedom to
> adjust the generated files to your internal system. Outside Google no one
> will really use these buck/internal build scripts anyways (lack of IDE
> support).
>
> -- J.
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

Thomas,
  In terms of Gradle vs Buck models, is there any possibility of writing a
tool that takes a Buck build file and produces Gradle files? That would
seem like a good option in lieu of waiting for Buck support in IntelliJ and
Eclipse. This isn't to say I have anything against Buck, it is literally a
clone of Google's BUILD system, and so that would actually help us to have
just one set of build files for internal vs external. However, it would be
nice not to have to hack the IDE stuff manually.

If Buck is like Google's BUILD, then a genrule could be used to download
dependencies from Maven repos. ;-)



On Wed, Sep 25, 2013 at 10:26 AM, Thomas Broyer  wrote:

>
>
> On Wednesday, September 25, 2013 6:20:19 PM UTC+2, Ray Cromwell wrote:
>>
>>
>> The biggest problem with being a GWT contributor today is that it is
>> hard, very hard, to set up an environment to develop. If you look at the
>> original GWT instructions for Eclipse, and that was *with* already provided
>> .project/.classpath files, it was ridiculous. Starting from scratch is even
>> harder.
>>
>> My dream for mavenization was
>> a) fixing the spaghetti soup of cyclic dependencies so that IDEs would
>> have less trouble modeling the project layout
>> b) having a cross IDE platform representation of the project
>>
>
> +1
>
>
>> The way GWT exists today, after years of working with it, requires me to
>> spend over an hour configuring a new IntelliJ project from scratch if I
>> want to do it right, be able to develop both user and dev, be able to run
>> unit tests in the IDE, be able to debug the compiler in the IDE, etc.
>>
>> Ant is fine for command line builds, but it sucks for a) and b), and its
>> flexibility has allowed the GWT source tree to have a structure that would
>> not be tolerated by other build tools -- sometimes too much power is bad. I
>> don't have any particular love for Maven, I'd be fine with Buck or Gradle
>> (IntelliJ seems to have some support for Gradle), but the biggest issue for
>> me is, I don't want to spend an hour fiddling with IDE sub-projects,
>> hand-adding library dependencies (oh wait, which project needs
>> tomcat-jk2.jar?), etc.
>>
>
> Looking at Gradle currently for work, support in Eclipse is rather good
> too. IDE support is much more easily done with Gradle than with Maven,
> because of their design. I'm writing a blog post about my issues with Maven
> that'll talk about that, will publish it soon.
>
> Even on the GWT team at Google, members have taken to rather absurd
>> techniques like creating one working set of IPR/IML files, and copy/pasting
>> them everytime you start a new repository or branch because they have often
>> forget the precise order of magic tricks they used to set up the build the
>> first time.
>>
>
> +1 to what Brian said re. checking the .iml et al. in the Git repo; and
> add Konstantin as a reviewer ;-)
>
> IMHO, here should be how someone contributes to GWT:
>>
>> git clone http://some-repo
>> IDE open-project some-repo
>> git branch
>> hack hack hack
>> run tests/debug in IDE
>> git commit
>> git push
>>
>> Any more steps than that and I think you've lost.
>>
>
> +1
>
> (OK, I wouldn't mind an intermediate "download dependencies once and for
> all" after the "git clone" if needed; oh, and you should probalby do a
> command-line build –or at least using "the build tool"– before pushing, but
> that's a detail, and the current state of the Ant build is the main reason
> I don't do it today)
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Re: Maven-ization Status

[Ray Cromwell]

The biggest problem with being a GWT contributor today is that it is hard,
very hard, to set up an environment to develop. If you look at the original
GWT instructions for Eclipse, and that was *with* already provided
.project/.classpath files, it was ridiculous. Starting from scratch is even
harder.

My dream for mavenization was
a) fixing the spaghetti soup of cyclic dependencies so that IDEs would have
less trouble modeling the project layout
b) having a cross IDE platform representation of the project

The way GWT exists today, after years of working with it, requires me to
spend over an hour configuring a new IntelliJ project from scratch if I
want to do it right, be able to develop both user and dev, be able to run
unit tests in the IDE, be able to debug the compiler in the IDE, etc.

Ant is fine for command line builds, but it sucks for a) and b), and its
flexibility has allowed the GWT source tree to have a structure that would
not be tolerated by other build tools -- sometimes too much power is bad. I
don't have any particular love for Maven, I'd be fine with Buck or Gradle
(IntelliJ seems to have some support for Gradle), but the biggest issue for
me is, I don't want to spend an hour fiddling with IDE sub-projects,
hand-adding library dependencies (oh wait, which project needs
tomcat-jk2.jar?), etc.

Even on the GWT team at Google, members have taken to rather absurd
techniques like creating one working set of IPR/IML files, and copy/pasting
them everytime you start a new repository or branch because they have often
forget the precise order of magic tricks they used to set up the build the
first time.

IMHO, here should be how someone contributes to GWT:

git clone http://some-repo
IDE open-project some-repo
git branch
hack hack hack
run tests/debug in IDE
git commit
git push

Any more steps than that and I think you've lost.




On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer  wrote:

>
>
> On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote:
>>
>> Hi Thomas,
>> I'm (part-time) having a look at your gwt-sandbox with maven build;
>>
>> I like the way it is modularized:
>> gwt-dev-parent
>>  gwt-jsni-parser
>> gwt-util-parent
>> gwt-shared
>> gwt-tools-api
>>  gwt-dev-json
>> gwt-dev-ext
>> gwt-user-parent
>> gwt-core-shared
>>  gwt-core-client
>> gwt-compiler
>> gwt-maven-plugin
>>  gwt-regexp-server
>> gwt-http
>> gwt-safehtml-server
>> gwt-codegen
>>  gwt-jetty-launcher
>> gwt-devmode
>> gwt-codeserver
>>  gwt-i18n-shared
>> gwt-i18n-server
>> gwt-core-server
>> gwt-regexp-client
>>  gwt-bindery-parent
>> event
>> event-gwt
>> gwt-event-shared
>>  gwt-event-client
>> gwt-event-logical-shared
>> gwt-event-logical-client
>>  gwt-safehtml-client
>> gwt-dom
>> gwt-i18n-client
>> gwt-rpc-shared
>>  gwt-rpc-api
>> gwt-rpc-client
>> gwt-rpc-server
>> gwt-browsermanager
>>  gwt-resources-core
>> gwt-window
>> gwt-timer
>> gwt-junit
>>  gwt-jsonp
>> gwt-resources
>> gwt-mockutilities
>> gwt-safecss-server
>>  gwt-safecss-client
>> autobean-shared
>> autobean-vm
>>  autobean-gwt
>> gwt-user
>> requestfactory-shared
>> requestfactory-client
>>  requestfactory-server
>> requestfactory-gwt
>> requestfactory-apt
>>  gwt-dev
>> gwt-user
>> gwt-codeserver
>> gwt-legacy-parent
>>
>> I think it is a very precious piece of work!
>>
>>
>> The build process fails however in resolution of a pugin,
>> com.google.gwt.maven:gwt-**maven-plugin:jar:2.6.0-**SNAPSHOT
>> but it is not the
>> org.codehaus.mojo
>> :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT
>>
>> is that the one at 
>> https://github.com/tbroyer/**gwt-maven-plugin
>>  ?
>>
>
> No, it's the maven. It's a snapshot/copy of the one
> linked above.
>
>
>> I don't like that it is still required to have the gwt-tools in the
>> environment path;
>>
>
> This is a temporary step in the migration process. The goal is to migrate
> to non-patched/non-repackaged dependencies whenever possible, and deploy
> the third-party deps on Central otherwise.
>
>
>> referring to the your post ;-) for me the ultimate build tool is the one
>> that allow you to build a project in two steps:
>>
>> [me@host]# ultimate-scm checkout 
>> http://my.project.org/source_**codetrunk
>> [me@host]# ultimate-build-tool build trunk
>>
>> having to configure gwt-tools it is out of my ideal way of building a
>> project: I don't know if it possible, but gwt-tools should be mavenized too
>> in my opinion. Many libs found inside the gwt tools are available as maven
>> artifacts in Maven Central Repo (for stability, I always try to avoid
>> referring dependency not found on http://search.maven.org/) but this may
>> require
>>
>> Later I also want to try out your buck build files at https://gwt-review.
>> **googlesource.com/3741 ,
>> (if I find out how the command line options to apply the patch :-D) so to
>

Re: [gwt-contrib] Re: Publish nighly snapshots of GWT builds to Maven

[Ray Cromwell]

Matthew,
  Is there an easy way to make Jenkins push out a snapshot after a
successful build?



On Sat, Sep 21, 2013 at 5:31 AM, Łukasz Jąder  wrote:

> +1 all the way.
> Checking out SNAPSHOT version would be fun an could help find more issues.
>
> W dniu czwartek, 19 września 2013 16:29:18 UTC+2 użytkownik Johannes Barop
> napisał:
>
>> Hi,
>>
>> what do you think of publishing nightly builds of GWT to a Maven
>> repository? This would save users which want to try/work with
>> latest/unreleased features of building it on their own.
>>
>> A repository exists already. But I don't know who has write access to it
>> https://oss.sonatype.org/**content/repositories/google-**
>> snapshots/com/google/gwt/
>>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Thoughts on dropwizard framework as a backend for GWT

[Ray Cromwell]

There was talk at the last GWT meetup of adding official JAX-RS support to
GWT. There are several implementations floating around (RestyGWT,
Errai-JAXRS, etc) Is this another JAXRS implementation? I'd be interested
in seeing a comparison between the major implementations.



On Sun, Aug 11, 2013 at 12:46 PM, Rafiq Ahamed  wrote:

> I agree. My thoughts are more towards integrating the good things from
> spiffyUI (spiffyui.org) into GWT. Wondering why no a great concept like
> SpiffyUI is not going mainstream but the same old JSF like Vaadin is
> getting into mainstream. The great thing about thick clients is that, they
> can be easily wrapped with android wrappers or IOS wrappers or even JavaFX
> wrappers.
>
> On Monday, August 12, 2013 12:02:43 AM UTC+5:30, John A. Tamplin wrote:
>
>> On Sun, Aug 11, 2013 at 2:21 PM, Rafiq Ahamed  wrote:
>>
>>> Dear Folks,
>>>Any thoughts on DropWizard framework (http://dropwizard.codahale.**
>>> com/ ) as a backend for GWT. RESTFUL
>>> webservices is the way to go and I feel GWT RPC is an Anti-Pattern.
>>>
>>
>> GWT RPC was never intended to be the solution to all problems.  It is
>> easy to use and allows you to send entire object graphs without much
>> effort.  Of course, you get versioning issues and you can send entire
>> object graphs without much effort.
>>
>> You can already use JSON easily now if you prefer, and protos with a bit
>> more effort.  REST vs other options is really more about the server anyway.
>>
>>
>>>And also, what about integrating ApacheCouchDB or ApacheSolr (Json
>>> style Schema less 4.4 version) as a backend for GWT so that the application
>>> can be developed rapidly. This is the approach I have taken for one of my
>>> new project.
>>>
>>
>> GWT has generally been server-agnostic, so I would expect any server-side
>> integration with a specific framework would be a separate project.
>>
>> --
>> John A. Tamplin
>>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Initial support for @GwtCreate (code-gen methods)

[Ray Cromwell]

Andres, this looks amazing! I've been out this week on vacation but
returning tomorrow, I'll take a look when I return.



On Fri, Aug 16, 2013 at 2:22 AM, Andrés Testi wrote:

> I've been working on a prototype inspired by Ray Cromwell's proposal for
> @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
> apologize for not to post this in the "Possible GWT.create() Improvements"
> thread, but this message is too long to be only a comment.
> You can check my patch at https://gwt-review.googlesource.com/4110. This
> prototype has passed many JUnit tests cases and works fine (only fails
> JEnumTypeTest after my last pull, I don't know why). Devmode also works.
> This proposal differs from Ray's original idea in that @GwtCreate is a
> parameter annotation instead of a method annotation. Later I will justify
> this decision.
> This new proposal consists on rewriting methods adding a trailing implicit
> parameter of type GwtCreateFactory for each parameter annotated with
> @GwtCreate. GwtCreateFactory is a hidden interface used by the compiler:
>
>   interface GwtCreateFactory {
>  T create();
>   }
>
> When the compiler finds a code-gen method like
>
>   Foo createFoo(@GwtCreate final Class fooType) {
> return GWT.create(fooType);
>   }
>
> it is rewritten as
>
>   Foo createFoo(final Class type, GwtCreateFactory
> fooType$factory) {
> return fooType$factory.create();
>   }
>
> IMPORTANT:
>  The @GwtCreate parameter requires to be final.
>  This proposal doesn't require constant evaluation expression. The
> final modifier is required to disable non reproductible side effects.
>
> At method call site, an invocation like
>
>   Foo foo = createFoo(SubFoo.class);
>
> is rewritten as
>
>   class SubFoo$GwtCreateFactory implements GwtCreateFactory {
> @Override public  T create() {
>   return GWT.create(SubFoo.class);
> }
>   }
>
>   Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
>
> Just like Scala implicit parameters, @GwtCreate can fight against type
> erasure and subtyping
>
>   interface FooCreator {
>
>  T create(@GwtCreate Class fooType);
>   }
>
>   class FooCreatorImpl extends FooCreator {
>
>  T create(@GwtCreate final Class fooType) {
>   return GWT.create(fooType);
> }
>   }
>
> code-gen constructors are supported too
>
>   class CreateByConstructor {
>
> final T instance;
>
> public  CreateByConstructor(@GwtCreate final Class fooType) {
>   instance = GWT.create(fooType);
> }
>   }
>
> Again, as in Scala implicit parameters, nesting is allowed
>
>   class Foo {}
>   class SubFoo extends Foo {}
>
>F createFoo(@GwtCreate final Class fooType) {
> return GWT.create(fooType);
>   }
>
>S createSubFoo(@GwtCreate final Class subFooType) {
> return createFoo(subFooType);
>   }
>
> The decision to locate @GwtCreate on parameters was taken to support mixed
> code-gen methods
>
>   
>   void fooBarCreator(@GwtCreate final Class fooType, @GwtCreate final
> Class barType) {
> foo = GWT.create(fooType);
> bar = GWT.create(barType);
>   }
>
> Note that the @GwtCreate class parameters aren't replaced by
> GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
> access to actual parameters.
>
>   Class storedType;
>   T instance;
>
>   void createFoo(@GwtCreate final Class type) {
> storedType = type;
> instance = GWT.create(type);
>   }
>
> * Further improvements:
>
>   1) Support for explicit generators
>
> @GwtCreate(generator = FooGenerator.class)
>
> We should forbid assignation between parameters that differs in
> @GwtCreate signature
>
>   Foo createFoo(@GwtCreate(generator = FooGen.class) final Class extends Foo>) {...}
>
>   // This will fail
>   Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
> Class fooType) {
> return createFoo(fooType);
>   }
>
>   2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
>
>UiBinder createBinder(
> @GwtCreate(generator = UiBinGen.class) final Class uiType,
> @GwtCreate.Param final Class ownerType) {
>
>  return GWT.create(uiType, ownerType);
>   }
>
> @GwtCreate.Params must respect the same kind of signature rules than
> @GwtCreate, and a strict order of invocation
>
>   // Good ordering
>   Foo createFoo(
> @GwtCreate final Class fooType,
> @GwtCreate.Param final Class arg1,
> @GwtCr

Re: [gwt-contrib] Possible GWT.create() Improvements (link)

[Ray Cromwell]

My original motivation was like the String.format() case, but with
GwtQuery's $() function, since GwtQuery supported compile-time CSS selector
parsing, is was really tedious to add them to an interface when all you
wanted was $(".foo > h1.title") or some such. Later, when doing GWT
Exporter I noticed again code getting peppered with GWT.create() calls that
were not type safe. Finally, after seeing repeating patterns in this,
ranging from GWT RPC, to UiBinder, Editors, AutoBeans, Validators, etc I
came to the conclusion that GWT.create()'s inability to be wrapped in a
typed Java API and reliance on call-site inlining actually produced code
smell -- it prevents the design of APIs and instead causes people to
indulge in interface voodoo.

The reality is, I think people want to write code like $("css query") or
String.format(fmt, args...) or Mockito.mock(SomeClass.class).

The only real wave I've seen this made manageable with minimal boilerplate
is via the CDI stuff of Errai, but that kind of dependency injection I
think is pretty heavyweight for what GWT users want to do. It's like
imposing Guice/GIN on all GWT users.




On Sun, Aug 11, 2013 at 11:42 PM, John A. Tamplin  wrote:

> On Mon, Aug 12, 2013 at 2:29 AM, Goktug Gokdogan wrote:
>
>> An example use-case would be implementing String.format when the format
>> string is a compile-time constant.  I had a proof of concept mostly working
>> for this, but it was going to require more surgery to the compiler than I
>> was willing to do at the time.
>>
>>>
>>>
>> I didn't fully understand the example but it sounds like it requires way
>> more than today's deferred binding so I'm not sure it is a good use case
>> with replace-with/generate-with and static selectors. Perhaps it should be
>> better done with something like "evaluate-with" instead. Actually,
>> evaluate-with sounds interesting - I'll think about it :)
>>
>
> I thought we were talking about potential improvements to GWT.create, so
> it doesn't have to be something that can be done with today's
> implementation.  Similar motivations were behind some proposals RayC made
> years ago as well.
>
> --
> John A. Tamplin
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Possible GWT.create() Improvements (link)

[Ray Cromwell]

I don't think APT is good enough. Java8 has a compiler plugin API for
code-gen that might work. APT has limitations that make it problematic to
replace generators. Stephen Haberman brought this up at the GWT meetup.


On Fri, Aug 9, 2013 at 4:16 PM, Goktug Gokdogan  wrote:

I think in the long-run we should separate the two concepts that is being
tackled by GWT.create today.

First purpose is the class replacement, especially used by permutations. I
think this one should not have anything to do with GWT.create. We can do
any class replacement in compiler without requiring a call to GWT.create.
This is similar to super-sourcing and can be solved similar and perhaps
together.

Second purpose is for triggering generators and what most of the proposal
are about.

As Roberto and perhaps others have been bringing up, it is best to follow
regular java code generation practices in GWT.

That means for the long-term we can mostly rely on AnnotationProcessors.
There are many advantages of that:
  1. Not GWT only - continue sharing code with server (JRE), client(GWT)
and mobile(Android).
  2. IDE support: IDE can trigger codegen (esp. for debugging)
  3. Parallelizing the compilation and ease moving from JDT into java 8
compiler plugin.
  4. Reusing knowledge from java world and lower the barrier for entry to
generators.


With that move, deferred binding definition for code generator can be just
about providing the naming conventions such as "
-> $Generated".
Based on the rule, when the compiler sees GWT.create(A.class), it can be
turned into "new A$Generated()" and expect the generated code to be there.

The reason I'm bringing this up is; for any proposal I think it is best to
keep it feasible w.r.t this aspect and not push us into a corner for the
long run.


On Fri, Aug 9, 2013 at 1:24 PM, Brian Slesinsky  wrote:

Hi, I've published a document [1] with my thoughts on some of the
GWT.create() proposals. This doesn't cover everything we've discussed but I
think it's a start. If you're on this mailing list you should be able to
comment.

- Brian

[1]
https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXMcRI#

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
"GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


 --
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
"GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Patch to support GWT.create(this.getClass())

[Ray Cromwell]

Andres,
  You might want to wait a day or two. I think Brian started one by copy
and pasting your proposals and mine into a doc, it might be better for him
to make it public and we all hack on that.



On Fri, Aug 9, 2013 at 12:19 PM, Andrés Testi wrote:

> Ray:
>
> I'm writing a design doc like "Nextgen GWT/JS Interop", but for
>  "Relaxation of GWT.create()". I don't know if there are previous official
> efforts to bring something like this to life, but if so, I would like know
> about similar experiences.
> Is there a guideline for these kind of design doc? When I finish a first
> document draft, I will share it.
> Thanks!
>
> - Andrés
>
> El miércoles, 7 de agosto de 2013 14:31:01 UTC-3, Ray Cromwell escribió:
>>
>> The annotations were also there to allow the compiler to do error
>> checking so that class-literal propagation was always possible. So if you
>> write a function foo(Class klazz), that then calls GWT.create(klazz),
>> there will be a compile time error thrown if foo() is not called with a
>> literal, just like GWT.create(). This means that it will always be possible
>> to propagate the class literal from parameter to use.
>>
>>
>>
>>
>> On Wed, Aug 7, 2013 at 5:31 AM, Andrés Testi wrote:
>>
>>> Hi Ray. I would like to add your proposal to my patch and generalize
>>> GWT.create() relaxation. I think your annotation @GwtCreate(generator=...)
>>>  would solve my problem with the GWT frameworks tendency to instantiate
>>> everything with GWT.create() instead of new.
>>> As Matt Mastracci proposed here https://groups.google.com/d/**
>>> msg/google-web-toolkit-**contributors/_jf8vBC8QDI/**X9LDLTbqB64J<https://groups.google.com/d/msg/google-web-toolkit-contributors/_jf8vBC8QDI/X9LDLTbqB64J>
>>>  a
>>> better approach is to generate a GwtCreateFactory to replace @GwtCreate
>>> Class fields and params.
>>> I will elaborate a more advanced proposal with all of these in account.
>>> Thanks!
>>>
>>> - Andrés
>>>
>>> El lunes, 5 de agosto de 2013 20:37:45 UTC-3, Ray Cromwell escribió:
>>>>
>>>> Hey Andres, I haven't fully looked at this, but I'm overjoyed you're
>>>> working on it, and it seems promising. One thing you might want to do is
>>>> review one of my old proposals on allowing any method to delegate
>>>> parameters to GWT.create(), see here: http://timepedia.**blogspo**
>>>> t.com/2009/03/relaxing-**constra**ints-on-gwtcreate.html<http://timepedia.blogspot.com/2009/03/relaxing-constraints-on-gwtcreate.html>
>>>>
>>>> I'm wondering if your work could be adapted to support this.
>>>>
>>>> -Ray
>>>>
>>>>
>>>>
>>>> On Mon, Aug 5, 2013 at 8:36 AM, Andrés Testi wrote:
>>>>
>>>>> Are there interest adding support for allowing
>>>>> GWT.create(this.getClass()) invocations?
>>>>> I wrote an experimental patch to support it, adding a few changes to
>>>>> UnifyAst. I've added the patch as an attached file, because I don't have
>>>>> yet a CLA (I know this is not the right way to proceed).
>>>>> There are many usecases for this feature, based in the super type
>>>>> token pattern (http://gafter.blogspot.com.**ar**
>>>>> /2006/12/super-type-tokens.**htm**l<http://gafter.blogspot.com.ar/2006/12/super-type-tokens.html>).
>>>>> I've named this feature as Self Generated Objects (selfgen).
>>>>>
>>>>> * Some use cases are:
>>>>> -- Hide invocations to GWT.create()
>>>>> -- Reduce boilerplate, minimizing the need of extend interfaces like
>>>>> UiBinder, EditorDriver, etc..
>>>>>   Example, a custom composite :
>>>>>
>>>>> abstract class UiBinderComposite extends Composite {
>>>>>   protected UiBinderComposite() {
>>>>> UiBinder binder =
>>>>> GWT.create(this.getClass());
>>>>> initWidget(binder.**createAndBin**dUi(this));
>>>>>   }
>>>>> }
>>>>>
>>>>> // Usage:
>>>>> @UiTemplate("mywidget.ui.xml")
>>>>> class MyUiBinderWidget extends UiBinderComposite {
>>>>>
>>>>>   @UiField
>>>>>   Button clickMe;
>>>>> }
>>>>>
>>>>> -- Allow runtime type information on demand (Stroustrup’s
>>>>> z

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

[Ray Cromwell]

AFAIK, JsDoc actually is more expressive than TypeScript, for example, TS
doesn't currently support union types IIRC, which is critical for
expressing real world Javascript libraries. It is also a form of repeating
yourself to specify a TS file, because a Javascript programmer writing his
library code is not going to document it in two places by creating separate
files for everything. That repo is great for TS programmers, but honestly,
I don't imagine a high velocity JS project constantly keeping these
bindings in sync. Who is going to be responsible for updating the TS
interface definitions everytime a release of the underlying JS library is
pushed?

We've had the same problem with GWT JSNI wrappers in the past, they get out
of sync with the JS library that are mapping to, because the person
maintaining the JS library doesn't care.

I don't have anything against TS, I'm all for first class typing, but I
think a solution in which the person who maintains the JS library
themselves is encouraged to add the types is superior, and I don't have a
high degree of confidence that JS developers enmasse are going to adopt
writing TS definitions. Also, I haven't been following ES6 recently, but as
far as I'm aware, there are no plans to add either optional types of
documentary types.

The way I'd propose building this is just to have a pluggable parser for
collecting the type definitions, and so when the compiler sees a given .js
input file, it asks the plugins to hand back all of the first class type
definitions for that file. The format could be anything, parsing JsDoc,
loading TS, WebIDL, or XML files like IntelliJ uses. The JS world is too
fragmented probably to have one solution.

However I will say this: We are looking at replacing the backend JsAst of
the GWT compiler with Closure Compiler in the future, so that we don't need
to maintain the JS optimization pipeline (only the Java optimization
stages), and so using Closure types as intermediate representation makes a
lot of sense.




On Thu, Aug 8, 2013 at 2:25 PM, Xavier Mehaut wrote:

> I desagree with this assertion ; the goal is not to interop with ts, haxe,
> coffee, ..., but only with js. Moreover the future of js is ecmascript 6,
> so ts is a good candidate to express properly an interface; this is not the
> case IMO of a jsdoc like solution which is verbose and not so precise and
> concise as a true language.
>
> To finish, i recall in mind
> https://github.com/borisyankov/DefinitelyTyped
> as a reminder of the power of the d.ts technics
>
> Best regards
> Xavier
>
> Envoyé de mon iPhone
>
> Le 8 août 2013 à 22:39, Ray Cromwell  a écrit :
>
> As cool as I think TS is, there are far more lines of code out there in
> Js, some even with JsDoc type assertions, so I think the latter would be
> more useful as a first pass. JsDoc is comments so it works with existing
> JS. We could explore importing libraries defined in TS, Dart, haXe, et al
> via some kind of standard plugin extension.
>
>
>
> On Thu, Aug 8, 2013 at 9:08 AM, Brian Slesinsky wrote:
>
>> It might be nice to be able to say that anything defined in a .d.ts can
>> be imported into GWT. This will make it easier to work with JavaScript
>> programmers since they don't have to write any Java code. So perhaps it's
>> worth making sure that generating the Java interfaces from .d.ts files will
>> work? I know that generating Elemental code from WebKit IDL files wasn't
>> easy.
>>
>> However, our main use case is to import web components which are new. So
>> my question is how likely people are to write .d.ts files for web
>> components; I don't know if there is much overlap between those two
>> communities yet.
>>
>>
>> On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan wrote:
>>
>>> Jon (Stalcup) just warned me that it may not necessarily orthogonal so I
>>> will make a clarification to what I said.
>>>
>>> There are number of reasons why it makes we sense to define the contract
>>> with java syntax and interface files for GWT (easy IDE support and JDT
>>> integration and developer familiarity etc.), but someone might have chosen
>>> to start with a custom syntax like the d.ts files.
>>> Assuming these interfaces exist and understood by the compiler, any
>>> other support can be built on top of that by generating them and provide a
>>> seamless integration.
>>>
>>>
>>> On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan wrote:
>>>
>>>> We were planning to look into making integration seamless if closure
>>>> type annotations exists but that's kind of orthogonal to this proposal.
>>>> When we have

Re: [gwt-contrib] Nextgen GWT/JS Interop (Public) (google-web-toolkit-contributors@googlegroups.com)

[Ray Cromwell]

As cool as I think TS is, there are far more lines of code out there in Js,
some even with JsDoc type assertions, so I think the latter would be more
useful as a first pass. JsDoc is comments so it works with existing JS. We
could explore importing libraries defined in TS, Dart, haXe, et al via some
kind of standard plugin extension.



On Thu, Aug 8, 2013 at 9:08 AM, Brian Slesinsky  wrote:

> It might be nice to be able to say that anything defined in a .d.ts can be
> imported into GWT. This will make it easier to work with JavaScript
> programmers since they don't have to write any Java code. So perhaps it's
> worth making sure that generating the Java interfaces from .d.ts files will
> work? I know that generating Elemental code from WebKit IDL files wasn't
> easy.
>
> However, our main use case is to import web components which are new. So
> my question is how likely people are to write .d.ts files for web
> components; I don't know if there is much overlap between those two
> communities yet.
>
>
> On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan  wrote:
>
>> Jon (Stalcup) just warned me that it may not necessarily orthogonal so I
>> will make a clarification to what I said.
>>
>> There are number of reasons why it makes we sense to define the contract
>> with java syntax and interface files for GWT (easy IDE support and JDT
>> integration and developer familiarity etc.), but someone might have chosen
>> to start with a custom syntax like the d.ts files.
>> Assuming these interfaces exist and understood by the compiler, any other
>> support can be built on top of that by generating them and provide a
>> seamless integration.
>>
>>
>> On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan wrote:
>>
>>> We were planning to look into making integration seamless if closure
>>> type annotations exists but that's kind of orthogonal to this proposal.
>>> When we have that integration, it might not be hard to utilize
>>> typescript via typescript to closure conversion.
>>> Thanks for suggestion.
>>>
>>>
>>> On Tue, Aug 6, 2013 at 1:29 AM, Xavier Mehaut 
>>> wrote:
>>>
 Hi goktuk
 A nice way to interop with js is the way typescript does through the
 .d.ts files where js api is declared in a typed way, ensuring then the
 ability to interop with any preexisted js. Moreover, already existing .d.ts
 files for many js libraries exist on
 https://github.com/borisyankov/DefinitelyTyped
 No extra wirk to do then :)

 Best regards
 Xavier


 Envoyé de mon iPhone

 Le 6 août 2013 à 09:24, "Goktug Gokdogan (Google Drive)" <
 gok...@google.com> a écrit :

 I've shared an item with you.



 This is a design doc that describes a proposal for improving 
 interoperability with GWT and javascript. The proposal provides some 
 essential pieces to provide better and easier interoperability with JS 
 while putting more complex scenarios (e.g. Web Components) and testability 
 into account.

 Please take a look and provide us some feedback.

 Cheers,

  - Goktug

 [image: Document] Nextgen GWT/JS Interop 
 (Public)
 Google Drive: create, share, and keep all your stuff in one place. [image:
 Logo for Google Drive] 

 --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.



  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to the Google
 Groups "GWT Contributors" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.



>>>
>>>
>>  --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "GWT Contributors" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>  --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
> ---
> You received this message because you are subscribed to the Google Groups
> "GWT Contributors" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google

[gwt-contrib] Re: Getting rid of autoboxing?

[Ray Cromwell]

I explored that a long time ago when Lightweight Collections were proposed,
but it won't work that simply. (Sadly, most of the original discussions on
this with the Atlanta team were in Google Wave and forever lost) The reason
why it won't work is that there is no way to tell the difference between
Integer and Double, Float, Byte, Short, et al.

Only one boxed type can "own" Number.prototype, so instanceof and equals()
checks will fail. Also, toString() and compareTo() might return values that
break existing apps.

It is impossible to write a runtime test on a primitive JS number that can
distinguish between a Double and a Float, and it is impossible to store a
castable type map on a given instance of number.

The only way to make this work would be to ensure that *all such* JS
numbers are boxed.

This won't work:
var x  = 42.3;
x.isFloat = true;

This also won't work

var x = Number(42.3);
x.isFloat = true;

because typeof(x) == "number"

This will work
var x = Object(42.3)
x.isFloat = true;

x + 2 => prints 44.3
x.isFloat => prints true

But this is nothing more than making a JSO that holds the number with extra
runtime fields.

Leaving all this aside, I don't understand why you're trying to do this in
the first place. Java is a language which insists on a difference between
the semantics of primitive value types and class based reference types.
This will most definitely break DevMode. For interop purposes, just
declaring the right return type is better IMHO. If you were to write a game
using WebGL that had all the interfaces using boxed types, it would be
horrendous performance wise.

Eliminating autoboxing via a hack like this might be plausible, but I think
it should be separate from the interop stuff. It's an optimization that has
impacts far and wide.

-Ray



On Thu, Aug 1, 2013 at 6:01 PM, Goktug Gokdogan  wrote:

> I was thinking about autoboxing of numbers when assigned to Object and I
> started to question if we really need them in Java to JS translation - at
> least for a subset (i.e. Integer and Double).
>
> Object has only a few methods that we can put into Number.prototype (like
> we do for String) and all methods to Integer/Double can be converted to
> static calls then theoretically we can drop most of the java autoboxing
> code. We can also find similar solutions to calls over java.lang.Number.
>
> Perhaps, I'm missing some corner cases but I really feel like we can find
> a way to get rid of them at least for the most scenarios. Am I being too
> naive on this?
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups "GWT 
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [gwt-contrib] Working on a patch to fix Exception wrapping/unwrapping in compiler

[Ray Cromwell]

What I mean is, uncaught native JS exceptions should still be caught by a
catch(Throwable) being somewhere on the stack frame. Techncially, the stack
trace wasn't lost, as it was available on
JavaScriptException.getException().stack, but I get the point, I
implemented a similar unwrap for gwt-exporter projects internally.
Actually, non-JS exceptions lose the underlying stack trace which is a
problem. If you have a stack trace  that looks like this:
js func
js func
gwt func
gwt func
js func
js func
gwt func
gwt func

And the bottom gwt func does "throw new SomeJavaException()", but you let
this exception bubble up to JS, you lose the original Error.stack created
in StackTraceCreator (it is used and thrown away). StackTraceElement's
don't really model external JS functions very well. I modified Throwable
with an expando as a hack so that my subclass of CollectorChrome saves the
resulting native JS Error and unwraps it on bubbling to JS, so that the
Chrome Devtools can show something sensible, and source map tools could
deobfuscate a combined JS/Java stack trace.




On Tue, Jul 9, 2013 at 4:25 PM, Goktug Gokdogan  wrote:

>
>
>
> On Tue, Jul 9, 2013 at 2:30 PM, Ray Cromwell wrote:
>
>> To me clear, if I put catch(Exception), catch(Throwable), or
>> catch(RuntimeException), I would expect to catch JavaScriptExceptions.
>>
>
> Yes, that's correct. We are not changing that.
>
>
>>  I would only expect a JS exception to escape if and only if, there are
>> no catch blocks for it, or any of it's supertypes, and no uncaught
>> exception handler is installed.
>>
>>
> I'm not sure what you exactly mean. Do you mean the behavior should change
> if there are any catch blocks in the stack even the same exception
> re-thrown? I would disagree with that.
>
> It is possible to add a code to intercept and rethrow an exception. As a
> java developer, you would not expect that to change anything. However
> currently it changes the behavior.
>
> E.g.
>
> void a() {
>   try {
> b();
>   } catch(Exception e) {
> // some logic here, e.g. log or report the error in UI
> throw e; // throw the same e that was caught
>   }
> }
> void b() {
>   X x = null;
>   x.toString(); // or anything else such as JSNI that causes js throw
> }
> native void someNativeCode() /*-{
>   try {
> @x.y.Example::a();)
>   }
>   catch(e) {
>  // before the fix e would have been a java object (i.e. 
> JavaScriptException)
>  // while calling @x.y.Example::b is a native JS TypeError.
>   }
> }-*/;
>
>
> The fix I submitted basically unwraps 'e' on rethrow so putting the catch
> block doesn't change propagated exception as most developers would expect.
> In addition to that, if the exception in the example ends up escaping to
> browser, we used to lose the stack trace as it was no longer a native
> javascript exception, which is also fixed with the submitted patch.
>
> (Actually, in reality the previous behavior was even worse: If the code
> was catching any exception (e.g. IOException), it would still cause the
> same problems - having just a 'catch' was enough to break native
> exceptions.)
>
>
>>
>> On Fri, Jun 14, 2013 at 5:51 PM, Goktug Gokdogan wrote:
>>
>>> I just wanted to give you a heads up that Roberto and I are working on a
>>> compiler patch so that catch statement will not break js originated
>>> exceptions.
>>>
>>> To give you some background, if you put any try/catch statement in Java,
>>> js originated exceptions will be converted into JavaScriptException even if
>>> you are not catching a JavaScriptException or any of its parents.
>>> Because of this problem there are workarounds in SDK to avoid catch
>>> statements if there are no UncaughtExceptionHandlers registered. By
>>> avoiding "catch" statements and repeating code, we are making sure a js
>>> exception can correctly escape and reported by the browser.
>>>
>>> Also with this patch, we can make some exceptions escape to the
>>> browser asynchronously without breaking the code flow. This is useful to
>>> fix problems like issue #6833 and similar others in the SDK.
>>>
>>> --
>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "GWT Contributors" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com
>>> .
>>> For more optio