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 

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 

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
> 

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 <google-web-toolkit-contributors@googlegroups.com> 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
> <google-web-toolkit-contributors@googlegroups.com> 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 <google-web-toolkit-contributors@googlegroups.com> 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
>> > <google-web-toolkit-contributors@googlegroups.com> 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 <google-web-toolkit-contributors@googlegroups.com> 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:

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 <google-web-toolkit-contributors@googlegroups.com> 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
> <google-web-toolkit-contributors@googlegroups.com> 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 <google-web-toolkit-contributors@googlegroups.com> 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
>> > <google-web-toolkit-contributors@googlegroups.com> 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(..

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 <google-web-toolkit-contributors@googlegroups.com> 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
> <google-web-toolkit-contributors@googlegroups.com> 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 <google-web-toolkit-contributors@googlegroups.com> wrote:
>> > We accept patches :)
>> >
>> > On Sun, Apr 17, 2016 at 8:40 PM, Paul Stockley <pstockl...@gmail.com>
>> > 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-contri

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]

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 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

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 

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.
>

-- 

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
 

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] 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
 
 .

 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
>> 

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, 

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 

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
> 

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]

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 cromwell...@google.com
 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 d...@google.com 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
  * a href=
 https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
 
  * Polymer automatic node finding/a
  */
 T T getCustomStampedElement(String id, ClassT 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=emailutm_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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fZhv0AkiPYqfM2WWaW8zFvdgk-BYEucwRP8k4ewXEp6w%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https

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
google-web-toolkit-contributors@googlegroups.com 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 google-web-toolkit-contributors@googlegroups.com 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 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 cromwell...@google.com
  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 d...@google.com
 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

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
google-web-toolkit-contributors@googlegroups.com 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 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 cromwell...@google.com
 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 d...@google.com
 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

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 cromwell...@google.com 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 d...@google.com 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
  * a href=
 https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
 
  * Polymer automatic node finding/a
  */
 T T getCustomStampedElement(String id, ClassT 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=emailutm_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 d...@google.com 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
  * a href=
 https://www.polymer-project.org/1.0/docs/devguide/local-dom.html#node-finding
 
  * Polymer automatic node finding/a
  */
 T T getCustomStampedElement(String id, ClassT 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=emailutm_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/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 alexwhite3...@gmail.com 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
 https://groups.google.com/a/google.com/d/msg/gwt-users/i5KCHorBC6k/6wkPSuBBXBgJ
 needs to be supported).- Optimize away everything with regular optimization
 rules if the member is not exported.- Generate export statements for all
 pinned 

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
 * codeinstance/code.
 */
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 okr...@gmail.com
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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/97624985-35bf-48d6-b187-76181d9b8672%40googlegroups.com?utm_medium=emailutm_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/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 jens.nehlme...@gmail.com 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
 https://groups.google.com/d/msg/google-web-toolkit/PHtfLTSAJDM/oJjAo3qWa7sJ
 )


 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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/778b8f0b-8cc1-4a90-84d5-39c1b9c02afb%40googlegroups.com?utm_medium=emailutm_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/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 sciccare...@gmail.com
wrote:

 http://www.gwtproject.org/articles/elemental.html

 Is it the same?


 Il giorno mer 1 apr 2015 alle 23:32 nick936 niklas...@googlemail.com 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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/d32b27c4-a1eb-40cb-9720-3d1f6c535b03%40googlegroups.com?utm_medium=emailutm_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/CAK5-kh41Zt_3pz9JdBg5AW3seRCGBGZ8tyk2HK6oqMJj_qqCiw%40mail.gmail.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAK5-kh41Zt_3pz9JdBg5AW3seRCGBGZ8tyk2HK6oqMJj_qqCiw%40mail.gmail.com?utm_medium=emailutm_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/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]

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 michael.gorsk...@googlemail.com 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] 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
google-web-toolkit-contributors@googlegroups.com wrote:


 On Mon, Dec 8, 2014 at 1:00 PM, confile michael.gorsk...@googlemail.com
 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 jens.ne...@gmail.com 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] 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 google-web-toolkit-contributors@googlegroups.com 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 david.no...@gmail.com 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
branflake2...@gmail.com 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 gok...@google.com 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 ltea...@gmail.com 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 gok...@google.com
 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 cromw...@google.com
 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 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 

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 ali.rac...@gmail.com 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 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 kujans...@gmail.com 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 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 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 michael.gorsk...@googlemail.com 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 csri...@gmail.com
 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 michael@googlemail.com
 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/kinetic/client/KShape.java'
[ERROR] org.test.kinetic.client.KNode cannot be
 resolved to a type
  Computing all possible rebind results for
 'test.mobile.client.app.photoEditor.PhotoEditor.Resources'
 Rebinding
 test.mobile.client.app.photoEditor.PhotoEditor.Resources
Checking rule generate-with
 class='com.googlecode.gwtphonegap.server.log.rebind.PhoneGapLogThresholdGenerator'/
   [ERROR] Hint: Check the inheritance chain from
 your module; it may not be inheriting a required module or a module 
 may not
 

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 gok...@google.com 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 perhaps that it's optional is a good thing,
 e.g. you could come back and add the @GenInterface-type method later
 if/when you wanted.

 Anyway, I think I do like the last proposal, the class/native method
 best.

 Thanks, Goktug!

 - Stephen

 --
 You received this message because you 

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
michael.gorsk...@googlemail.com 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 michael@googlemail.com
 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
 michael@googlemail.com 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/91c19564-b5ae-41d6-a23b-903f24296a7d%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/c7a4b31e-a355-4f13-9fe1-a4b3a6077a18%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 

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
michael.gorsk...@googlemail.com 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]

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
michael.gorsk...@googlemail.com 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
michael.gorsk...@googlemail.com 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]

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
michael.gorsk...@googlemail.com 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 JsArrayT {
default T 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 csri...@gmail.com
 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.
 
  :)
 
 

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 michael.gorsk...@googlemail.com
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

 michael@googlemail.com 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 JsArrayT {
 default T 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 csri...@gmail.com
  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 

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
rhmol...@gmail.com 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 ip: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 this group and stop receiving emails from it, send an email 
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To 

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 JsArrayT {
   default T 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 csrina...@gmail.com 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 michael@googlemail.com
 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.

 --

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 michael.gorsk...@googlemail.com 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
man...@apache.org wrote:
 Thank Roberto, that is the key, everything works if I exclude the asm
 transitive dependency in my pom

   dependency
 groupIdorg.eclipse.jetty/groupId
 artifactIdjetty-annotations/artifactId
 exclusions
 exclusion
 artifactIdorg.objectweb.asm/artifactId
 groupIdorg.eclipse.jetty.orbit/groupId
 /exclusion
 /exclusions

 On Wed, Oct 1, 2014 at 11:46 PM, 'Roberto Lublinerman' via GWT Contributors
 google-web-toolkit-contributors@googlegroups.com 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 man...@apache.org
 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 t.bro...@gmail.com 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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/65212555-efa9-493c-aead-031566baaf20%40googlegroups.com?utm_medium=emailutm_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/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 ivan.mar...@gmail.com 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 script inside the iframe with the newly
 recompiled permutation?
 (To have this instantaneous, only a script containing the changed types
 should be injected, however I'm not sure if/what needs to be fixed so that
 sourcemaps continue to work after that.)

  --
 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/eeeb5252-162b-4381-a3fa-14da59fa9873%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/eeeb5252-162b-4381-a3fa-14da59fa9873%40googlegroups.com?utm_medium=emailutm_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/CAPVRV7cF4WRTQyyPOB7PBhoYC-wCh7qxrVOymJdte-LF4920Gw%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]

Try using the xs linker instead.



On Sun, Aug 31, 2014 at 10:15 AM, Ivan Markov ivan.mar...@gmail.com 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 module.nocache.js works
 - However editing module-0.js does not work (big surprise)

 Problem 1: I think the sourceURL=module-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 script tag src
 attribute is directly modified to point to the CAGFG...AB.cache.js
 permutation this is probably just bringing confusion, no?

 Unfortunately, fixing Problem 1 alone did not enable LiveEdit.
 I think another issue (let's call it Problem 2) is that the xsiframe
 linker is creating the iframe  script tags dynamically using
 JavaScript DOM manipulations. There is some evidence on the internet that
 editing scripts injected that way is not supported.

 I was thinking of solving Problem 2 by just switching to the sso
 (SingleScriptLinker) linker, but then:
 (a) It is still not supported in SuperDevMode -
 https://code.google.com/p/google-web-toolkit/issues/detail?id=7722
 (b) By looking at the source, it seems it is wrapping all the generated
 GWT code in enclosing functions, which are then called at the end of the
 script block. I don't think LiveEdit will be re-evaluating these, so this
 wrapping has to go somehow...

 Any ideas?

  --
 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/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/033a0106-49a2-4d66-aed0-5ee07d515c4d%40googlegroups.com?utm_medium=emailutm_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/CAPVRV7cX2MMcxHLUEnQ4QpWajFhiL4B6goR93UZVxyZ9-DxpBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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 csrina...@gmail.com
 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 csri...@gmail.com
 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
 https://github.com/workingflows/gwt-jscore/blob/master/src/main/java/com/workingflows/js/jscore/client/factory/JS.java

 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/
 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+unsubscribe@
 googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/google-web-toolkit-contributors/3268ccc7-9953-
 

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 NodeListT extends Element extends IterableT {
T item(int x);
int length();

   default IteratorT 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 csrina...@gmail.com
 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
 https://github.com/workingflows/gwt-jscore/blob/master/src/main/java/com/workingflows/js/jscore/client/factory/JS.java

 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/
 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-574096f0d5d3%40googlegroups.com
 

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

['Ray Cromwell' via GWT Contributors]

On Mon, Aug 18, 2014 at 7:14 AM, Ivan Markov ivan.mar...@gmail.com 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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/5a2a4436-5c2d-4e60-9d5d-314db0045b7d%40googlegroups.com?utm_medium=emailutm_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/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
man...@apache.org 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
google-web-toolkit-contributors@googlegroups.com 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.CollaborativeOperation
 get(0);

 to:
 final CollaborativeOperation first = (CollaborativeOperation)
 operations.CollaborativeOperation get(0);

 -Daniel


 On Mon, Jun 30, 2014 at 8:09 AM, 田传武 i...@goodow.com 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, 田传武 i...@goodow.com 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.CollaborativeOperation 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fodJL3qBmJGSMXm_sEidYypd0B22GQt9n1O_DzVbaKAA%40mail.gmail.com.
For more options, 

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 niloc...@gmail.com 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 j...@jaet.org wrote:

 On Mon, Jun 9, 2014 at 6:33 PM, Colin Alworth niloc...@gmail.com 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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM5k6X8CHkCjQK1CvGRxwS9H279BKpnZ%3DjeYwuVgqZtj6JJD3w%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 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
 https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMzdu5cz3bjvWYW7%3DvUm%3D%3DfC0b83sg0%3Dbs7j%2BmTNDjFSeg%40mail.gmail.com?utm_medium=emailutm_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/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, 田传武 i...@goodow.com wrote:

 Hello,

 I tried converted two projects we are currently using GWT Exporter to
 @JsInterface for interoperate with JS. The *first project*
 https://github.com/goodow/realtime-channel/commit/e809e7cf9ee81fb4f470336212abfe113550ac8d
  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 
 man...@apache.orgwrote:

 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 jens.nehlme...@gmail.com 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.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/2f99fddc-668c-449a-8e98-2abf26d8a3bd%40googlegroups.com?utm_medium=emailutm_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/CAM28XAsxeDCVrEHLrMm4icr%2BY-OVh89RBqfDdnbBUi_qyudZaA%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsxeDCVrEHLrMm4icr%2BY-OVh89RBqfDdnbBUi_qyudZaA%40mail.gmail.com?utm_medium=emailutm_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/CA%2B%2BRBT8z5gtVUbMpkmtLdoykvYv%2BrGgYDT79agjLBG0VzC1X_Q%40mail.gmail.comhttps://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT8z5gtVUbMpkmtLdoykvYv%2BrGgYDT79agjLBG0VzC1X_Q%40mail.gmail.com?utm_medium=emailutm_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/CAPVRV7dU9o9uPZiHN14Y8p0E1ZHzjy5PLkw2xhQYqZOmht4Ztg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.