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 <ekuef...@gmail.com> 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
>>> <google-web-toolkit-contributors@googlegroups.com> 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 <google-web-toolkit-contributors@googlegroups.com> 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?)...
>>>>>>>
>>

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

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

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.

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

['Ray Cromwell' via Google Web Toolkit]

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 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
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.

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

[Ray Cromwell]

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

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

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

class GangnamButton extends HTMLButtonElement_prototype {
...
}

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


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


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

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



On Fri, Feb 28, 2014 at 4:59 PM, James Nelson ja...@wetheinter.net wrote:


 SourceWriter is not incompatible with APT, just like JavaWriter is not
 incompatible with generators. Both take a PrintWriter where they write;
 SourceWriter is string-based with only a few helpers for javadoc and
 indent/outdent, whereas JavaWriter is more Java oriented with methods to
 begin/end types, methods, control flow blocks, fields, etc.


  Not to shamelessly plug my own work or anything, but I do maintain a
 SourceBuilder library that contains piles of helper functions, the ability
 to add method or field buffers that effectively tear-off a position in the
 source writer, so you can build multiple methods at the same time; it uses
 all fluent interfaces, automatically imports classes (returning the
 shortest name possible that can be used in code [fully qualified if import
 name is already taken]), has fluent interfaces for all methods, and has
 simple support for jsni.


 https://github.com/WeTheInternet/xapi/blob/master/dev/source/src/main/java/xapi/dev/source/
 groupIdnet.wetheinter/groupId
 artifactIdxapi-dev-source/artifactId
 version0.4/version

 It looks something like:

 MethodBuffer valueProvider = beanCls
 .createMethod(protected Object valueOf(String name, Object o))
 // definition is lexed; it can be modified later if you desire
 .setUseJsni(true)
 .addAnnotation(UnsafeNativeLong.class)
 .println(switch(name) {)
 .indent()
 .println(case 'this': return o;)
 .println(case 'this.name()':)
 .indentln(return o...@java.lang.Object
 ::getClass()().@java.lang.Class::getName()(););

 Or, here's a test with more features:

 SourceBuilderObject b = new SourceBuilderObject(
   public static abstract class Test);
 b.setPackage(xapi.test);
 b.getClassBuffer()
   .createMethod(public T extends java.util.Date void
 Test(java.lang.String t) {)
   .indentln(System.out.println(\Hellow World\ + new
 java.sql.Date());)
   .createLocalClass(class InnerClass )
   .createMethod(void innerMethod())
   ;
 // We discard java.lang imports
 Assert.assertFalse(b.toString().contains(import java.lang.String;));
 // We used java.util.Date as a fully qualified name first, so it
 should be imported
 Assert.assertTrue(b.toString().contains(import java.util.Date;));
 Assert.assertTrue(b.toString().contains(T extends Date));
 // We used java.sql.Date as a fqcn after java.util.Date, so it must
 NOT be imported
 Assert.assertFalse(b.toString().contains(import java.sql.Date;));

 At the core, it's based on StringBuilder, and it takes the best of
 SourceWriter and JavaWriter, then adds a bunch of shiny on top.
 It's mutable, supports the notion of ClassBuffer, MethodBuffer and
 FieldBuffer, with child writers scoped correctly, to make inner classes or
 even local classes that retain their place in the SourceBuilder stack.

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


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

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

[Ray Cromwell]

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




On Thu Feb 27 2014 at 4:17:15 PM, James Nelson ja...@wetheinter.net wrote:

 Is there anywhere to get a sneak preview on the discussions about the
 future of codegen?

 Andres and I have both invested time in some extensions of ast-based
 codegen, and could really use some time and forewarning to adapt our
 strategy to stay future-friendly with out apis.

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


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

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

[Ray Cromwell]

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



On Tue, Jan 28, 2014 at 12:05 PM, Kurt Dmello kdme...@gmail.com wrote:

 Thanks Thomas,
 That was helpful.  I tried the img tag and it did work.


 What you're seeing here is browser sanitization from innerHTML (not
 sanitization actually, just that the script are not run). Try with img
 onerror=alert(1) src=// or similar (onclick, etc.)


 What should someone performing code review on a GWT app. be looking for ?


 Everywhere SafeHtml / SafeStyles / SafeUri could be used but is not
 (HasHTML#setHTML is one such things)

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


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

Re: [gwt-contrib] Deprecating DeRPC classes

[Ray Cromwell]

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

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



On Tue, Nov 5, 2013 at 10:07 AM, Matthew Dempsky mdemp...@google.comwrote:

 Just curious, is there a particular impetus to removing DeRPC at this
 time?  E.g., is it causing code bloat or slowness, or making new
 development more difficult?

 I'm fine with marking the class as @Deprecated, but unfortunately we
 [Google] still have an internal customer using DeRPC and so far I haven't
 been successful in convincing them to prioritize moving off of it.  (I did
 manage to remove our other internal uses of DeRPC.)

 Alternatively, if there's an easy way for us to split DeRPC out of GWT
 core and maintain it separately, I'm happy to do that (e.g., we're already
 doing that for GWTShell).  But it sounds like DeRPC is heavily entangled
 into GWT-RPC?


 On Tue, Nov 5, 2013 at 9:45 AM, Thomas Broyer t.bro...@gmail.com wrote:

 The first step would be to delete com.google.gwt.rpc and the
 HybridServiceServlet, and then remove all the hooks in RPC that were added
 to make deRPC possible (there's at least one in RemoteServiceServlet), and
 probably others in the RPC generator.


 On Tuesday, November 5, 2013 5:26:21 PM UTC+1, Stephen Haberman wrote:

 Hi Naresh,

  Could you please let me know is there any patch available to check
  the impact of removing de rpc calls.

 I'm glad you're interested in looking in to this.

 Unfortunately, I don't really know much about DeRPC. There are probably
 others on the gwt-contrib list who do though...we'll see if anyone can
 point you in the right direction.

 - Stephen

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


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


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

Re: Thoughts on GWT 3.0 re: Java 8 and IE 8/9

[Ray Cromwell]

I think what we're really thinking about doing is preserving IE8 for the 
existing gwt widget stuff, but any features (APIs) we add going forward are 
going to leverage modern browser stuff, and we are not going to design 
(poorly performing, hacky) fallback/polyfill workarounds. 

For GWT 3.0, we are looking at making a new, parallel way of writing Web 
UIs that is based on the emerging Web Components standard, and we will lean 
heavily on modern browser layout engines, e.g. flexible box model.  We're 
not going to break your existing apps, but we're not going to make these 
new models work on old browsers. For example, to make data-binding working 
efficiently in Web Components, you need mutation observers, Node.bind, 
Object.observe(), etc. 

We are not going to require Java7 or Java8 to run servlet code or even 
invoke the compiler, but we will support compiling Java8 code to JS, and 
we'll have super-sourced versions of java.util.function/java.util.stream.

Basically, the future is easier interop with the browser APIs, external 
libraries, and web components, and less reliance on heavy weight widgets 
that run lots of JS and shield the browser. This is a vision more in tune 
with the fact that mobile is increasingly becoming a bigger and bigger 
chunk of the web, and the original GWT metaphor of a Desktop-like 
AWT/Swing-like UI library with layout done by executing code is less 
efficient on mobile and is suboptimal for fast browser jank-free execution. 
 We don't want to break existing applications, and we don't want to hamper 
designs for the future by requiring them to work on ancient browsers.



On Friday, October 25, 2013 8:59:28 AM UTC-7, Andy wrote:

 Thanks for your input. It sounds like we're in the identical situation.

 Regarding onFailure, do you use an abstract implementation of 
 AsyncCallback, like I mention in this post?

 http://stackoverflow.com/a/4725052/497700

 -Andy

 On Friday, October 25, 2013 11:47:43 AM UTC-4, stuckagain wrote:

 IE8/IE9 I agree, we are in the same situation. Our customers only just 
 migrated to IE8, so that will take at least 2 years before they will move 
 on.
 We could wait longer to move on to GWT 3.0, but the problem is that other 
 customers are already asking for IE11 support. 

 About Java8 support on the client, I am looking forward to lambdas 
 instead of asynccallbacks, it would make my code a lot more compact! I only 
 have one onFailure implementation so it would be great if the APIs would 
 decouple these and allow for a default implementation.

 But the gwt-servlet.jar will still need to be compiled for Java 7 
 compatibility or we will be really in big problems. A lot of customers are 
 still running Java 6 on the server side.
 Java 7 is about to become mandatory for us, but Java 8 that will take 
 ages.

 David



 On Fri, Oct 25, 2013 at 4:50 PM, Andy pul...@gmail.com wrote:

 I just read through the notes from the GWT steering 
 committeehttps://groups.google.com/d/msg/gwt-steering/ldyo7OXUnHQ/ogtT-kPFoaoJand
  would like to share our perspective. I know you have a lot of survey 
 results and we're just 1 company, but here's some more info based on our 
 needs.

 *Java 8 only*

 I would encourage and support this move. I've been writing a ton of 
 Javascript for the past few weeks and really miss the functional style when 
 I come back to Java. Lambdas in Java 8 are going to be powerful and fun and 
 they should be used liberally throughout the GWT 3.0 APIs. We won't be able 
 to move our backend to Java 8 for a while, but since we only ship the JS 
 output of the GWT compiler, I'm happy to use Java 8 for front-end 
 development.

 *Dropping IE 8/9*
 *
 *
 We just decided on Tuesday to drop IE7 with our next release. We got 
 tired of working around hasLayout bugs, etc. We have several major 
 customers that still have users with XP/IE7, but after consulting with 
 them, we decided we could go ahead with dropping support. Unfortunately, 
 many of our customers are using IE8 and we won't be able to drop IE 8/9 
 anytime soon. As a developer this is extremely frustrating, but it's the 
 sad reality of the enterprise.

 So Java 8 would be awesome, but dropping support for IE 8/9 would 
 prevent us from being about to use GWT 3.0 until our enterprise customers 
 upgrade their browsers.

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




-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: Thoughts on GWT 3.0 re: Java 8 and IE 8/9

[Ray Cromwell]

We're thinking about introducing a way of developing UI that is more like 
traditional HTML design, you create HTML, CSS, and then attach behavior via 
Java. UiBinder is sort of like this, but it is not HTML and still requires 
building. What we want to do is follow the Web Components spec, which is a 
standards-based, browser supported, way of doing templating, which means 
GWT could interop with widgets developed in JS or Dart or any other 
language easily. There's not even an internal proposal for this yet, we 
expect to hash it out before the gwt.create conference.

But I could see it working something like this:

!-- Foo.html --
html
headlink rel=import href=shippingaddress.html/head
body
acme-shipping id=ship/acme-shipping
Your final cost is {{cost}}
/body
/html

/* Foo.java */
class Foo {
  AcmeShipping ship; // auto-injected
  double cost; // auto-injected, both two-way databinding

  onChange() {
 cost = ship.calculateCost();
  }
}


Another option is angular-style, see my AngularGwt TodoMVC example:
https://github.com/cromwellian/angulargwt/blob/master/src/main/java/com/google/gwt/angular/client/todomvc/TodoController.java
https://github.com/cromwellian/angulargwt/blob/master/src/main/webapp/angulargwt.html

We don't expect you to 'port' your existing apps to this. Those can keep 
using the old way, but if you are designing a new mobile phone or mobile 
tablet app, than it will be recommended to use this lighter weight 
approach. The way mobile browsers work, the less JS is involved in layout 
and DOM manipulation, the better in terms of performance. Daniel Kurka will 
have a talk on this.

-Ray


On Friday, October 25, 2013 10:32:27 AM UTC-7, Timothy Spear wrote:

 Ray,

 There is already two existing versions of most container components. Are 
 you stating GWT will introduce a third? Or just migrate the Layout ones?
 In addition, do you know if there will be significant changes to UiBinder?

 Tim

 On Oct 25, 2013, at 1:21 PM, Ray Cromwell cromw...@google.comjavascript: 
 wrote:


 I think what we're really thinking about doing is preserving IE8 for the 
 existing gwt widget stuff, but any features (APIs) we add going forward are 
 going to leverage modern browser stuff, and we are not going to design 
 (poorly performing, hacky) fallback/polyfill workarounds. 

 For GWT 3.0, we are looking at making a new, parallel way of writing Web 
 UIs that is based on the emerging Web Components standard, and we will lean 
 heavily on modern browser layout engines, e.g. flexible box model.  We're 
 not going to break your existing apps, but we're not going to make these 
 new models work on old browsers. For example, to make data-binding working 
 efficiently in Web Components, you need mutation observers, Node.bind, 
 Object.observe(), etc. 

 We are not going to require Java7 or Java8 to run servlet code or even 
 invoke the compiler, but we will support compiling Java8 code to JS, and 
 we'll have super-sourced versions of java.util.function/java.util.stream.

 Basically, the future is easier interop with the browser APIs, external 
 libraries, and web components, and less reliance on heavy weight widgets 
 that run lots of JS and shield the browser. This is a vision more in tune 
 with the fact that mobile is increasingly becoming a bigger and bigger 
 chunk of the web, and the original GWT metaphor of a Desktop-like 
 AWT/Swing-like UI library with layout done by executing code is less 
 efficient on mobile and is suboptimal for fast browser jank-free execution. 
  We don't want to break existing applications, and we don't want to hamper 
 designs for the future by requiring them to work on ancient browsers.



 On Friday, October 25, 2013 8:59:28 AM UTC-7, Andy wrote:

 Thanks for your input. It sounds like we're in the identical situation.

 Regarding onFailure, do you use an abstract implementation of 
 AsyncCallback, like I mention in this post?

 http://stackoverflow.com/a/4725052/497700

 -Andy

 On Friday, October 25, 2013 11:47:43 AM UTC-4, stuckagain wrote:

 IE8/IE9 I agree, we are in the same situation. Our customers only just 
 migrated to IE8, so that will take at least 2 years before they will move 
 on.
 We could wait longer to move on to GWT 3.0, but the problem is that 
 other customers are already asking for IE11 support. 

 About Java8 support on the client, I am looking forward to lambdas 
 instead of asynccallbacks, it would make my code a lot more compact! I only 
 have one onFailure implementation so it would be great if the APIs would 
 decouple these and allow for a default implementation.

 But the gwt-servlet.jar will still need to be compiled for Java 7 
 compatibility or we will be really in big problems. A lot of customers are 
 still running Java 6 on the server side.
 Java 7 is about to become mandatory for us, but Java 8 that will take 
 ages.

 David



 On Fri, Oct 25, 2013 at 4:50 PM, Andy pul...@gmail.com wrote:

 I just read through the notes from the GWT

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

[Ray Cromwell]

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

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






On Tue, Oct 8, 2013 at 1:44 AM, Thomas Broyer t.bro...@gmail.com wrote:

 [cc: gwt-contrib, please follow-up there]


 On Tue, Oct 8, 2013 at 10:06 AM, Artur Signell ar...@vaadin.com wrote:

 On Oct 8, 2013, at 4:59 AM, Matthew Dempsky mdemp...@google.com wrote:

 On Mon, Oct 7, 2013 at 1:17 AM, Joonas Lehtinen joo...@vaadin.comwrote:

 Furthermore we should decide if GWT 3.0 supports Java 6+ or Java 7+ or
 Java 8+.


 Joonas, can you clarify whether you're referring here to support for user
 code (i.e., whether the GWT compiler will support compiling Java 6/7/8
 code) or about host JVM support (i.e., whether the GWT compiler and
 libraries will run on a Java 6/7/8 VM)?


 Both the questions are interesting to me:

 1. What's the oldest Java version you can use to compile the GWT project?
 (This also defines the oldest version you can use in your GWT app and where
 you can deploy your app)
 2. What's the newest Java version you can use in your own GWT app project?

 Today (GWT 2.6) we have:
 1. The project can be compiled using Java 6 provided you manually disable
 the Java 7 tests. The server classes are usable on a server which supports
 Java 6 (most modern servers).
 2. You can use Java 7 to develop your GWT app.

 Where are we going with GWT 3.0?
 1. Java 6? I don't see much reason to change this to Java 7 as there are
 not many major improvements in 7 compared to 6. The most visible effect
 would be that you can no longer deploy your application on servers
 supporting only Java = 6. Java 8 again has advantages but the server
 support is not there.


 Note that we could have different targets for client vs. server code, or
 maybe just for main vs. test classes: compile GWT with -source 1.6
 -target 1.6 and compile tests with -source 1.7 -target 1.7 (or even
 1.8); i.e. require Java 7 (or 8?) for building GWT, but not for running it.

 I see no reason to *not* mandate Java 7 (or newer) for hacking on GWT.


 2. For this I see Java 8 as a must-have


 We would need tests for the Java 8 features, which would mandate using
 Java 8 for building (testing) GWT; unless we start using profiles to
 disable sets of tests that we know cannot be compiled/run with the current
 JDK.

 Note: I'm assuming that by GWT 3.0 we'll have switched our build system.

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

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


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

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

[Ray Cromwell]

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



On Tue, Oct 8, 2013 at 2:45 PM, Brian Slesinsky skybr...@google.com wrote:

 In practice on open source projects, things happen because some person or
 company volunteers to implement them and sees the project through to the
 end. So I don't really see steering committee schedule-making as a process
 that's going to work. The Google GWT team is going to set its own quarterly
 goals and everyone else is going to make their own decisions about what to
 work on too.

 And even if it could work, it's not a good idea. As a more recent example,
 I don't think we should still do Mavenization just because that's what we
 originally decided and there were slides at Google I/O to that effect.
 That's not a winning argument. We should fix the build process in the way
 that makes the most sense now.

 We're not doing GWT users any favors by making flat-out promises we won't
 necessarily keep. It's fair to say that there some things we have to do and
 supporting major browsers is certainly one of them. But if it's at all
 doubtful we should leave things open and it's a good idea to hedge. A good
 phrase to use is we don't have a crystal ball, but [...].

 - Brian

 On Tue, Oct 8, 2013 at 2:02 PM, Thomas Broyer t.bro...@gmail.com wrote:

 But we now have a steering committee, and decisions are made in public so
 anyone can bug you when you forget. That's a different situation than
 before.
 Le 8 oct. 2013 22:43, Brian Slesinsky skybr...@google.com a écrit :


 On Tue, Oct 8, 2013 at 12:15 PM, Jens jens.nehlme...@gmail.com wrote:

 [...] since in practice we won't consider ourselves bound to them.


 Why not?


 Because we'll either we'll forget about that page due to turnover or
 something new will happen and priorities will change. Put it this way: how
 much do you feel bound by decisions made a few years ago by people who no
 longer work on GWT?

 - Brian

  --
 http://groups.google.com/group/Google-Web-Toolkit-Contributors
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups GWT Contributors group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/google-web-toolkit-contributors/GO4iP9RkxQY/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 google-web-toolkit-contributors+unsubscr...@googlegroups.com.

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

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


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


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

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

[Ray Cromwell]

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


On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer t.bro...@gmail.com wrote:



 On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote:


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


 And now I regret not having (seriously) looked at Gradle before ;-)

 IIUC, thanks to the Ivy backend, we could even remove the need to checkout
 the tools from SVN, and simplifying dependency management at the same
 time; with a combination of client module 
 dependencieshttp://www.gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies
  and
 an Ivy repository with custom 
 patternshttp://www.gradle.org/docs/current/userguide/dependency_management.html#N14ECC;
 maybe not worth the effort if we want to stop bundling our dependencies in
 the JARs (they'll have to be deployed to some Maven repo –Central– to
 support Maven).

 I'm gonna work on adding support for building and running unit tests and
 adding SuperDevMode launch rules, then I'll put it up for review.


 Would you mind publishing what you have already? (publish as a draft
 –refs/drafts/master instead of refs/for/master– and add me as a reviewer if
 you don't want to publicize it yet)
 I'm curious how well Gradle will handle the fact that gwt-dev tests
 require gwt-user.jar (and includes the sources of the HelloWorld sample,
 but that's easy)


 Eclipse users will have to figure out their own gradle magic. ;-p


 I'll have a look at it then (yep, still mostly an Eclipse user)

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


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

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

[Ray Cromwell]

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



On Mon, Sep 30, 2013 at 12:43 PM, Jonathan Strootman stroot...@gmail.comwrote:

 The only part I got stuck on was the tools installation. It is mentioned
 in the README.txt, but I mixed it up with the tools directory that is in
 the source already.

 As Thomas pointed out, it is a separate repo. I'm guessing that I'm not
 the only one who ran into that problem.

 Also, if you are contributing, don't forget the CLA (
 http://www.gwtproject.org/makinggwtbetter.html#clas).


 On Wednesday, September 25, 2013 4:07:12 AM UTC-7, Samuel Schmid wrote:

 No i did't saw that. Thanks for the hint. I'll check this and come back
 if I stuck.

 Sam

 On Wednesday, September 25, 2013 12:15:27 PM UTC+2, Thomas Broyer wrote:

 Have you tried following the eclipse/README.txt?

 BTW, you also need to svn checkout http://google-web-toolkit.**
 googlecode.com/svn/toolshttp://google-web-toolkit.googlecode.com/svn/tools
 

 On Wednesday, September 25, 2013 11:13:06 AM UTC+2, Samuel Schmid wrote:

 Hi to all contributors

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

 I checked out the GWT Source Code with

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

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

 Does somebody have some hints for me?

 Sam

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


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

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

[Ray Cromwell]

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



On Sat, Sep 28, 2013 at 3:59 PM, Thomas Broyer t.bro...@gmail.com wrote:



 On Sunday, September 29, 2013 12:11:29 AM UTC+2, Ray Cromwell wrote:


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


 And now I regret not having (seriously) looked at Gradle before ;-)

 IIUC, thanks to the Ivy backend, we could even remove the need to checkout
 the tools from SVN, and simplifying dependency management at the same
 time; with a combination of client module 
 dependencieshttp://www.gradle.org/docs/current/userguide/dependency_management.html#sub:client_module_dependencies
  and
 an Ivy repository with custom 
 patternshttp://www.gradle.org/docs/current/userguide/dependency_management.html#N14ECC;
 maybe not worth the effort if we want to stop bundling our dependencies in
 the JARs (they'll have to be deployed to some Maven repo –Central– to
 support Maven).

 I'm gonna work on adding support for building and running unit tests and
 adding SuperDevMode launch rules, then I'll put it up for review.


 Would you mind publishing what you have already? (publish as a draft
 –refs/drafts/master instead of refs/for/master– and add me as a reviewer if
 you don't want to publicize it yet)
 I'm curious how well Gradle will handle the fact that gwt-dev tests
 require gwt-user.jar (and includes the sources of the HelloWorld sample,
 but that's easy)


 Eclipse users will have to figure out their own gradle magic. ;-p


 I'll have a look at it then (yep, still mostly an Eclipse user)

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


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

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

[Ray Cromwell]

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



On Thu, Sep 26, 2013 at 10:26 AM, Jens jens.nehlme...@gmail.com wrote:


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

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


 Shouldn't it be the other way around? A Gradle plugin that generates
 Google build files sounds more logical to me as you have more freedom to
 adjust the generated files to your internal system. Outside Google no one
 will really use these buck/internal build scripts anyways (lack of IDE
 support).

 -- J.

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


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

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

[Ray Cromwell]

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

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

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



On Thu, Sep 26, 2013 at 3:35 PM, Brian Slesinsky skybr...@google.comwrote:


 On Thu, Sep 26, 2013 at 10:26 AM, Jens jens.nehlme...@gmail.com wrote:


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

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


 Shouldn't it be the other way around? A Gradle plugin that generates
 Google build files sounds more logical to me as you have more freedom to
 adjust the generated files to your internal system. Outside Google no one
 will really use these buck/internal build scripts anyways (lack of IDE
 support).


 I don't think direct IDE support for the build system is necessary so long
 as we can generate correct IDEA and Eclipse projects via commands that
 everyone can run, sort of like the webAppCreator command. The real question
 is what language we want the project definitions to be in; it should be
 something easy to understand, edit, and generate other representations from.

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


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

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

[Ray Cromwell]

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

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

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



On Thu, Sep 26, 2013 at 4:09 PM, Thomas Broyer t.bro...@gmail.com wrote:



 On Thursday, September 26, 2013 3:35:15 AM UTC+2, Ray Cromwell wrote:

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


 It would of course be possible, but would *a priori* require duplicating
 a bunch of code from Buck (search for all BUCK files, exec them with custom
 implementations of the build rules, find the source root using the
 .buckconfig's java.src_roots config)
 buck targets --json --type java_library wouldn't work as it resolves
 the glob() calls, so you'd have to call the tool every time you create a
 file so it updates the Gradle files to include the new file)

 That said, based on Shawn Pearce's experience on Gerrit, I'm not sure
 having the IDE configured the same way as the build is a requirement (for
 Gerrit, there's a single Eclipse project with all the sources)

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


 That's what Gerrit is doing ;-)
 (they also “hack the IDE stuff” that way, generating Eclipse .project and
 .classpath; Buck has built-in support for IntelliJ but it only work if you
 have BUCK files spread within your project's source tree, rather than a
 single BUCK file like I did)
 Ivy would also work, used as a standalone tool. And a small tool could
 produce a BUCK file with prebuilt_jar rules for the downloaded
 dependencies, without the need to handle transitive dependencies manually.
 Ivy would also help deploy the generated JARs to Central.
 The more I think about it, the more I like the Buck+Ivy combo idea, but it
 requires building a few additional tools… (IDE configuration, release
 script, etc.)
 I'm just starting to try Gradle for a project at work, if it goes well,
 maybe I'll experiment with it on GWT (first step: replace Ant with Gradle,
 then possibly modularize in the same way I did it with Buck, without moving
 files, then we could decide the best file/folder layout for both Gradle and
 Google)

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


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

Re: [gwt-contrib] Possible firefox leak fix

[Ray Cromwell]

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




On Tue, Sep 24, 2013 at 6:48 PM, Colin Alworth niloc...@gmail.com wrote:

 Done, change is at https://gwt-review.googlesource.com/4680.

 Concern about breaking WindowImpl#initWindowCloseHandler was my guess as
 well - after connect() is called and the app starts up, the app has already
 wired up its own close handler, so it is too late when connect is
 successful to replace unload.

 Both the standard WindowImpl and the IE specific one replace onunload and
 call the old version, so provided those stay consistent with
 hosted.html/devmode.js, this approach should be okay...

 I'd love to get any independent verification on this as even being a
 viable fix - I've only tried it in FF24/mac so far.

 -Colin


 On Tuesday, September 24, 2013 8:02:54 PM UTC-5, Brian Slesinsky wrote:

 +cromwellian since he did unload support.

 Oops, I see now that you attached it. Could you upload it to Gerrit?

 I looked pretty hard for a reason why it's window.onUnload and not
 window.onload and I can't find any. It dates back to 2010 at least and was
 copied from hosted.html, whether deliberately I don't know.

 One issue is that it's possible the app itself might want an onunload
 handler. See
 user/src/com/google/gwt/user/**client/impl/WindowImpl.java line 32 where
 it can install an onunload handler. It does preserve the old one but it
 still seems kind of fragile to install one in the devmode.js. I wonder if
 there's some way to detect the unload event in C++?

 - Brian



 On Tue, Sep 24, 2013 at 5:25 PM, Colin Alworth nilo...@gmail.com wrote:

 The patch I provided only tweaks the normal source, and leaves the
 generated sources and binaries alone - I think that is already what you are
 after.

 Note that this does *not* stop the leak by itself - we need to decide
 what to do about hosted.html/devmode.js. One (ugly) option is to try to
 have the ff plugin add an event handler to the window's close to call back
 to its own disconnect? I think there are other ways we could think about
 doing this as well, but changing hosted.html keeps it consistent across the
 board.


 On Tuesday, September 24, 2013 6:50:07 PM UTC-5, Brian Slesinsky wrote:

 Hi,

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

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



 On Tue, Sep 24, 2013 at 4:31 PM, Colin Alworth nilo...@gmail.comwrote:

 I spent a little time this weekend learning how to build firefox
 plugins, and a little time spilled out into this week, but I think I'm at 
 a
 point where I can share what I've done, what I'm seeing, and start asking
 for help to finalize this (if it is as meaningful as I hope it is).

 First, the issue itself: It looks like we're actually leaking on both
 ends - that is, not just in the JVM, but in the browser itself. When Dev
 Mode transfers control back to the browser itself, it runs
 BrowserChannelServer.**reactToMe**ssages(). This listens at the open
 socket between the browser's plugin and itself, and waits for the next 
 byte
 to float over the wire, meaning that the browser wants something. This
 waiting specifically happens in Message.readMessageType, where we block on
 stream.readByte(). Once a tab/window has been closed, the thread that is
 actively watching that connection stays stuck in readByte(), waiting for
 that next message to float over the wire.

 My first thought was why can't we just ask if that socket is closed?
 - well, the socket *isn't* closed, which means that the browser is leaking
 the socket itself, along with whatever supporting objects were set up to
 manage that socket. Note that this suggests a workaround to the leak - 
 quit
 and relaunch firefox, and since the socket will be forcibly closed then,
 readByte() will throw a EOF exception, and reactToMessages will trip off a
 RemoteDeathError (not ideal, but at least it just logs it and moves on,
 finishing the leak off).

 Next I dug into how to make the plugin actually disconnect when the
 page was closed. I started this by finding exactly where the socket was
 opened (common/HostChannel.{h|cpp}), then what creates HostChannel objects
 in the firefox plugin. This turns out to be achieved in this line in
 xpcom/ExternalWrapper.cpp (plus instructive comments):
   // TODO(jat): leaks HostChannel -- need to save it in a session
 object and
   // return that so the host page can call a disconnect method on it
 at unload
   // time or when it gets GC'd.
   HostChannel* channel = new HostChannel();

 Okay, so at the time it was written, it was known that this leaks the
 channel. This is where I started losing confidence, as it doesnt look like
 it could be this easy... 

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

[Ray Cromwell]

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

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

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

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

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

IMHO, here should be how someone contributes to GWT:

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

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




On Wed, Sep 25, 2013 at 1:32 AM, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, September 25, 2013 9:52:25 AM UTC+2, Cristiano wrote:

 Hi Thomas,
 I'm (part-time) having a look at your gwt-sandbox with maven build;

 I like the way it is modularized:
 gwt-dev-parent
  gwt-jsni-parser
 gwt-util-parent
 gwt-shared
 gwt-tools-api
  gwt-dev-json
 gwt-dev-ext
 gwt-user-parent
 gwt-core-shared
  gwt-core-client
 gwt-compiler
 gwt-maven-plugin
  gwt-regexp-server
 gwt-http
 gwt-safehtml-server
 gwt-codegen
  gwt-jetty-launcher
 gwt-devmode
 gwt-codeserver
  gwt-i18n-shared
 gwt-i18n-server
 gwt-core-server
 gwt-regexp-client
  gwt-bindery-parent
 event
 event-gwt
 gwt-event-shared
  gwt-event-client
 gwt-event-logical-shared
 gwt-event-logical-client
  gwt-safehtml-client
 gwt-dom
 gwt-i18n-client
 gwt-rpc-shared
  gwt-rpc-api
 gwt-rpc-client
 gwt-rpc-server
 gwt-browsermanager
  gwt-resources-core
 gwt-window
 gwt-timer
 gwt-junit
  gwt-jsonp
 gwt-resources
 gwt-mockutilities
 gwt-safecss-server
  gwt-safecss-client
 autobean-shared
 autobean-vm
  autobean-gwt
 gwt-user
 requestfactory-shared
 requestfactory-client
  requestfactory-server
 requestfactory-gwt
 requestfactory-apt
  gwt-dev
 gwt-user
 gwt-codeserver
 gwt-legacy-parent

 I think it is a very precious piece of work!


 The build process fails however in resolution of a pugin,
 com.google.gwt.maven:gwt-**maven-plugin:jar:2.6.0-**SNAPSHOT
 but it is not the
 org.codehaus.mojohttp://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.codehaus.mojo%22
 :gwt-maven-**plugin:jar:2.6.0-SNAPSHOT

 is that the one at 
 https://github.com/tbroyer/**gwt-maven-pluginhttps://github.com/tbroyer/gwt-maven-plugin
  ?


 No, it's the modulemaven/module. It's a snapshot/copy of the one
 linked above.


 I don't like that it is still required to have the gwt-tools in the
 environment path;


 This is a temporary step in the migration process. The goal is to migrate
 to non-patched/non-repackaged dependencies whenever possible, and deploy
 the third-party deps on Central otherwise.


 referring to the your post ;-) for me the ultimate build tool is the one
 that allow you to build a project in two steps:

 [me@host]# ultimate-scm checkout 
 http://my.project.org/source_**codehttp://my.project.org/source_codetrunk
 [me@host]# ultimate-build-tool build trunk

 having to configure gwt-tools it is out of my ideal way of building a
 project: I don't know if it possible, but gwt-tools should be mavenized too
 in my opinion. Many libs found inside the gwt tools are available as maven
 artifacts in Maven Central Repo (for stability, I always try to avoid
 referring dependency not found on http://search.maven.org/) but this may
 require

 Later I also want to try out your buck build files at https://gwt-review.
 **googlesource.com/3741 https://gwt-review.googlesource.com/3741,
 (if I find out how the command line options to apply the patch :-D) so to
 compare the buck output.


 There's a download section next to each patch set giving you the Git
 commands to checkout, pull or cherry-pick the changes.

 Just let me know if you want me 

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

[Ray Cromwell]

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

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



On Wed, Sep 25, 2013 at 10:26 AM, Thomas Broyer t.bro...@gmail.com wrote:



 On Wednesday, September 25, 2013 6:20:19 PM UTC+2, Ray Cromwell wrote:


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

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


 +1


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

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


 Looking at Gradle currently for work, support in Eclipse is rather good
 too. IDE support is much more easily done with Gradle than with Maven,
 because of their design. I'm writing a blog post about my issues with Maven
 that'll talk about that, will publish it soon.

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


 +1 to what Brian said re. checking the .iml et al. in the Git repo; and
 add Konstantin as a reviewer ;-)

 IMHO, here should be how someone contributes to GWT:

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

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


 +1

 (OK, I wouldn't mind an intermediate download dependencies once and for
 all after the git clone if needed; oh, and you should probalby do a
 command-line build –or at least using the build tool– before pushing, but
 that's a detail, and the current state of the Ant build is the main reason
 I don't do it today)

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


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

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

[Ray Cromwell]

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



On Sat, Sep 21, 2013 at 5:31 AM, Łukasz Jąder ljader...@gmail.com wrote:

 +1 all the way.
 Checking out SNAPSHOT version would be fun an could help find more issues.

 W dniu czwartek, 19 września 2013 16:29:18 UTC+2 użytkownik Johannes Barop
 napisał:

 Hi,

 what do you think of publishing nightly builds of GWT to a Maven
 repository? This would save users which want to try/work with
 latest/unreleased features of building it on their own.

 A repository exists already. But I don't know who has write access to it
 https://oss.sonatype.org/**content/repositories/google-**
 snapshots/com/google/gwt/https://oss.sonatype.org/content/repositories/google-snapshots/com/google/gwt/

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


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

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

[Ray Cromwell]

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



On Sun, Aug 11, 2013 at 12:46 PM, Rafiq Ahamed ra...@eitworks.com wrote:

 I agree. My thoughts are more towards integrating the good things from
 spiffyUI (spiffyui.org) into GWT. Wondering why no a great concept like
 SpiffyUI is not going mainstream but the same old JSF like Vaadin is
 getting into mainstream. The great thing about thick clients is that, they
 can be easily wrapped with android wrappers or IOS wrappers or even JavaFX
 wrappers.

 On Monday, August 12, 2013 12:02:43 AM UTC+5:30, John A. Tamplin wrote:

 On Sun, Aug 11, 2013 at 2:21 PM, Rafiq Ahamed ra...@eitworks.com wrote:

 Dear Folks,
Any thoughts on DropWizard framework (http://dropwizard.codahale.**
 com/ http://dropwizard.codahale.com/) as a backend for GWT. RESTFUL
 webservices is the way to go and I feel GWT RPC is an Anti-Pattern.


 GWT RPC was never intended to be the solution to all problems.  It is
 easy to use and allows you to send entire object graphs without much
 effort.  Of course, you get versioning issues and you can send entire
 object graphs without much effort.

 You can already use JSON easily now if you prefer, and protos with a bit
 more effort.  REST vs other options is really more about the server anyway.


And also, what about integrating ApacheCouchDB or ApacheSolr (Json
 style Schema less 4.4 version) as a backend for GWT so that the application
 can be developed rapidly. This is the approach I have taken for one of my
 new project.


 GWT has generally been server-agnostic, so I would expect any server-side
 integration with a specific framework would be a separate project.

 --
 John A. Tamplin

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




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

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

[Ray Cromwell]

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

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

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




On Sun, Aug 11, 2013 at 11:42 PM, John A. Tamplin j...@jaet.org wrote:

 On Mon, Aug 12, 2013 at 2:29 AM, Goktug Gokdogan gok...@google.comwrote:

 An example use-case would be implementing String.format when the format
 string is a compile-time constant.  I had a proof of concept mostly working
 for this, but it was going to require more surgery to the compiler than I
 was willing to do at the time.



 I didn't fully understand the example but it sounds like it requires way
 more than today's deferred binding so I'm not sure it is a good use case
 with replace-with/generate-with and static selectors. Perhaps it should be
 better done with something like evaluate-with instead. Actually,
 evaluate-with sounds interesting - I'll think about it :)


 I thought we were talking about potential improvements to GWT.create, so
 it doesn't have to be something that can be done with today's
 implementation.  Similar motivations were behind some proposals RayC made
 years ago as well.

 --
 John A. Tamplin

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




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

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

[Ray Cromwell]

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



On Fri, Aug 16, 2013 at 2:22 AM, Andrés Testi andres.a.te...@gmail.comwrote:

 I've been working on a prototype inspired by Ray Cromwell's proposal for
 @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
 apologize for not to post this in the Possible GWT.create() Improvements
 thread, but this message is too long to be only a comment.
 You can check my patch at https://gwt-review.googlesource.com/4110. This
 prototype has passed many JUnit tests cases and works fine (only fails
 JEnumTypeTest after my last pull, I don't know why). Devmode also works.
 This proposal differs from Ray's original idea in that @GwtCreate is a
 parameter annotation instead of a method annotation. Later I will justify
 this decision.
 This new proposal consists on rewriting methods adding a trailing implicit
 parameter of type GwtCreateFactory for each parameter annotated with
 @GwtCreate. GwtCreateFactory is a hidden interface used by the compiler:

   interface GwtCreateFactory {
 T T create();
   }

 When the compiler finds a code-gen method like

   Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
 return GWT.create(fooType);
   }

 it is rewritten as

   Foo createFoo(final Class? extends Foo type, GwtCreateFactory
 fooType$factory) {
 return fooType$factory.create();
   }

 IMPORTANT:
  The @GwtCreate parameter requires to be final.
  This proposal doesn't require constant evaluation expression. The
 final modifier is required to disable non reproductible side effects.

 At method call site, an invocation like

   Foo foo = createFoo(SubFoo.class);

 is rewritten as

   class SubFoo$GwtCreateFactory implements GwtCreateFactory {
 @Override public T T create() {
   return GWT.create(SubFoo.class);
 }
   }

   Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());

 Just like Scala implicit parameters, @GwtCreate can fight against type
 erasure and subtyping

   interface FooCreator {

 T extends Foo T create(@GwtCreate ClassT fooType);
   }

   class FooCreatorImpl extends FooCreator {

 T extends Foo T create(@GwtCreate final ClassT fooType) {
   return GWT.create(fooType);
 }
   }

 code-gen constructors are supported too

   class CreateByConstructorT extends Foo {

 final T instance;

 public  CreateByConstructor(@GwtCreate final ClassT fooType) {
   instance = GWT.create(fooType);
 }
   }

 Again, as in Scala implicit parameters, nesting is allowed

   class Foo {}
   class SubFoo extends Foo {}

   F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
 return GWT.create(fooType);
   }

   S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType) {
 return createFoo(subFooType);
   }

 The decision to locate @GwtCreate on parameters was taken to support mixed
 code-gen methods

   F extends Foo, B extends Bar
   void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
 ClassB barType) {
 foo = GWT.create(fooType);
 bar = GWT.create(barType);
   }

 Note that the @GwtCreate class parameters aren't replaced by
 GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
 access to actual parameters.

   ClassT storedType;
   T instance;

   void createFoo(@GwtCreate final ClassT type) {
 storedType = type;
 instance = GWT.create(type);
   }

 * Further improvements:

   1) Support for explicit generators

 @GwtCreate(generator = FooGenerator.class)

 We should forbid assignation between parameters that differs in
 @GwtCreate signature

   Foo createFoo(@GwtCreate(generator = FooGen.class) final Class?
 extends Foo) {...}

   // This will fail
   Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
 Class? extends Foo fooType) {
 return createFoo(fooType);
   }

   2) Multiple parameters for GWT.create() by means of @GwtCreate.Param

   U, O UiBinderU, O createBinder(
 @GwtCreate(generator = UiBinGen.class) final ClassU uiType,
 @GwtCreate.Param final ClassO ownerType) {

  return GWT.create(uiType, ownerType);
   }

 @GwtCreate.Params must respect the same kind of signature rules than
 @GwtCreate, and a strict order of invocation

   // Good ordering
   Foo createFoo(
 @GwtCreate final Class? extends Foo fooType,
 @GwtCreate.Param final Class? arg1,
 @GwtCreate.Param final Class? arg2) {
 return GWT.create(fooType, arg1, arg2);
   }

   // Bad ordering, this will fail
   Foo createFoo(
   @GwtCreate final Class? extends Foo fooType,
   @GwtCreate.Param final Class? arg1,
   @GwtCreate.Param final Class? arg2) {

 return GWT.create(fooType, arg2, arg1);
   }

 To allow mixed multiple code-gen parameters, we would bind main
 parameters

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

[Ray Cromwell]

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


On Fri, Aug 9, 2013 at 4:16 PM, Goktug Gokdogan gok...@google.com wrote:

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

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

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

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

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


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

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


On Fri, Aug 9, 2013 at 1:24 PM, Brian Slesinsky skybr...@google.com wrote:

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

- Brian

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

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


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

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

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

[Ray Cromwell]

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

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

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

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

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




On Thu, Aug 8, 2013 at 2:25 PM, Xavier Mehaut xavier.meh...@gmail.comwrote:

 I desagree with this assertion ; the goal is not to interop with ts, haxe,
 coffee, ..., but only with js. Moreover the future of js is ecmascript 6,
 so ts is a good candidate to express properly an interface; this is not the
 case IMO of a jsdoc like solution which is verbose and not so precise and
 concise as a true language.

 To finish, i recall in mind
 https://github.com/borisyankov/DefinitelyTyped
 as a reminder of the power of the d.ts technics

 Best regards
 Xavier

 Envoyé de mon iPhone

 Le 8 août 2013 à 22:39, Ray Cromwell cromwell...@google.com a écrit :

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



 On Thu, Aug 8, 2013 at 9:08 AM, Brian Slesinsky skybr...@google.comwrote:

 It might be nice to be able to say that anything defined in a .d.ts can
 be imported into GWT. This will make it easier to work with JavaScript
 programmers since they don't have to write any Java code. So perhaps it's
 worth making sure that generating the Java interfaces from .d.ts files will
 work? I know that generating Elemental code from WebKit IDL files wasn't
 easy.

 However, our main use case is to import web components which are new. So
 my question is how likely people are to write .d.ts files for web
 components; I don't know if there is much overlap between those two
 communities yet.


 On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan gok...@google.comwrote:

 Jon (Stalcup) just warned me that it may not necessarily orthogonal so I
 will make a clarification to what I said.

 There are number of reasons why it makes we sense to define the contract
 with java syntax and interface files for GWT (easy IDE support and JDT
 integration and developer familiarity etc.), but someone might have chosen
 to start with a custom syntax like the d.ts files.
 Assuming these interfaces exist and understood by the compiler, any
 other support can be built on top of that by generating them and provide a
 seamless integration.


 On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan gok...@google.comwrote:

 We were planning to look into making integration seamless if closure
 type annotations exists but that's kind of orthogonal to this proposal.
 When we have that integration, it might not be hard to utilize
 typescript via typescript to closure conversion.
 Thanks for suggestion.


 On Tue, Aug 6, 2013 at 1:29 AM, Xavier Mehaut 
 xavier.meh...@gmail.comwrote:

 Hi goktuk
 A nice way to interop with js is the way typescript does through the
 .d.ts files where js api is declared in a typed way, ensuring then the
 ability to interop with any preexisted js. Moreover, already existing

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

[Ray Cromwell]

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



On Fri, Aug 9, 2013 at 12:19 PM, Andrés Testi andres.a.te...@gmail.comwrote:

 Ray:

 I'm writing a design doc like Nextgen GWT/JS Interop, but for
  Relaxation of GWT.create(). I don't know if there are previous official
 efforts to bring something like this to life, but if so, I would like know
 about similar experiences.
 Is there a guideline for these kind of design doc? When I finish a first
 document draft, I will share it.
 Thanks!

 - Andrés

 El miércoles, 7 de agosto de 2013 14:31:01 UTC-3, Ray Cromwell escribió:

 The annotations were also there to allow the compiler to do error
 checking so that class-literal propagation was always possible. So if you
 write a function foo(Class? klazz), that then calls GWT.create(klazz),
 there will be a compile time error thrown if foo() is not called with a
 literal, just like GWT.create(). This means that it will always be possible
 to propagate the class literal from parameter to use.




 On Wed, Aug 7, 2013 at 5:31 AM, Andrés Testi andres@gmail.comwrote:

 Hi Ray. I would like to add your proposal to my patch and generalize
 GWT.create() relaxation. I think your annotation @GwtCreate(generator=...)
  would solve my problem with the GWT frameworks tendency to instantiate
 everything with GWT.create() instead of new.
 As Matt Mastracci proposed here https://groups.google.com/d/**
 msg/google-web-toolkit-**contributors/_jf8vBC8QDI/**X9LDLTbqB64Jhttps://groups.google.com/d/msg/google-web-toolkit-contributors/_jf8vBC8QDI/X9LDLTbqB64J
  a
 better approach is to generate a GwtCreateFactory to replace @GwtCreate
 Class fields and params.
 I will elaborate a more advanced proposal with all of these in account.
 Thanks!

 - Andrés

 El lunes, 5 de agosto de 2013 20:37:45 UTC-3, Ray Cromwell escribió:

 Hey Andres, I haven't fully looked at this, but I'm overjoyed you're
 working on it, and it seems promising. One thing you might want to do is
 review one of my old proposals on allowing any method to delegate
 parameters to GWT.create(), see here: http://timepedia.**blogspo**
 t.com/2009/03/relaxing-**constra**ints-on-gwtcreate.htmlhttp://timepedia.blogspot.com/2009/03/relaxing-constraints-on-gwtcreate.html

 I'm wondering if your work could be adapted to support this.

 -Ray



 On Mon, Aug 5, 2013 at 8:36 AM, Andrés Testi andres@gmail.comwrote:

 Are there interest adding support for allowing
 GWT.create(this.getClass()) invocations?
 I wrote an experimental patch to support it, adding a few changes to
 UnifyAst. I've added the patch as an attached file, because I don't have
 yet a CLA (I know this is not the right way to proceed).
 There are many usecases for this feature, based in the super type
 token pattern (http://gafter.blogspot.com.**ar**
 /2006/12/super-type-tokens.**htm**lhttp://gafter.blogspot.com.ar/2006/12/super-type-tokens.html).
 I've named this feature as Self Generated Objects (selfgen).

 * Some use cases are:
 -- Hide invocations to GWT.create()
 -- Reduce boilerplate, minimizing the need of extend interfaces like
 UiBinder, EditorDriver, etc..
   Example, a custom composite :

 abstract class UiBinderComposite extends Composite {
   protected UiBinderComposite() {
 UiBinderWidget, UiBinderComposite binder =
 GWT.create(this.getClass());
 initWidget(binder.**createAndBin**dUi(this));
   }
 }

 // Usage:
 @UiTemplate(mywidget.ui.xml)
 class MyUiBinderWidget extends UiBinderComposite {

   @UiField
   Button clickMe;
 }

 -- Allow runtime type information on demand (Stroustrup’s
 zero-overhead rule: “what you don’t use, you don’t pay for”) by means of
 emulation of guava's TypeToken
 Example:
 abstract class TypeTokenT {

   private final TypeInfoT typeInfo;

   protected TypeToken() {
 typeInfo = GWT.create(this.getClass());
   }

   ...
 }

 // Usage
 new TypeTokenListString(){}

 * Implementation
 To support this feature, my patch searchs for
 GWT.create(this.getClass()) invocations, and replaces they with an
 invocation to a syntetic method named this$create. This method is added to
 the current class, and is implemented for each non abstract subclass,
 returning an invocation to GWT.create(currentClass).

 * Problems found with this implementation:
 -- Anonymous classes are hidden to generators, and it is unable to do
 something like new TypeTokenListString(){}. Workaround: Expose these
 classes.
 -- GWT frameworks have a tendence to instantiate user objects calling
 GWT.create() instead of new operator. With GWT.create(this.getClass()) we
 want to instantiate a diferent class, like UiBinder in UiBinderComposite.
 Workaroud: Provide a flag to generators reporting if the invocation was
 from a class literal or a this.getClass() invocation.

 I've added a sample application to my patch, called HelloSelfgen

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

[Ray Cromwell]

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



On Thu, Aug 8, 2013 at 9:08 AM, Brian Slesinsky skybr...@google.com wrote:

 It might be nice to be able to say that anything defined in a .d.ts can be
 imported into GWT. This will make it easier to work with JavaScript
 programmers since they don't have to write any Java code. So perhaps it's
 worth making sure that generating the Java interfaces from .d.ts files will
 work? I know that generating Elemental code from WebKit IDL files wasn't
 easy.

 However, our main use case is to import web components which are new. So
 my question is how likely people are to write .d.ts files for web
 components; I don't know if there is much overlap between those two
 communities yet.


 On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan gok...@google.com wrote:

 Jon (Stalcup) just warned me that it may not necessarily orthogonal so I
 will make a clarification to what I said.

 There are number of reasons why it makes we sense to define the contract
 with java syntax and interface files for GWT (easy IDE support and JDT
 integration and developer familiarity etc.), but someone might have chosen
 to start with a custom syntax like the d.ts files.
 Assuming these interfaces exist and understood by the compiler, any other
 support can be built on top of that by generating them and provide a
 seamless integration.


 On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan gok...@google.comwrote:

 We were planning to look into making integration seamless if closure
 type annotations exists but that's kind of orthogonal to this proposal.
 When we have that integration, it might not be hard to utilize
 typescript via typescript to closure conversion.
 Thanks for suggestion.


 On Tue, Aug 6, 2013 at 1:29 AM, Xavier Mehaut 
 xavier.meh...@gmail.comwrote:

 Hi goktuk
 A nice way to interop with js is the way typescript does through the
 .d.ts files where js api is declared in a typed way, ensuring then the
 ability to interop with any preexisted js. Moreover, already existing .d.ts
 files for many js libraries exist on
 https://github.com/borisyankov/DefinitelyTyped
 No extra wirk to do then :)

 Best regards
 Xavier


 Envoyé de mon iPhone

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

 I've shared an item with you.



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

 Please take a look and provide us some feedback.

 Cheers,

  - Goktug

 [image: Document] Nextgen GWT/JS Interop 
 (Public)https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing
 Google Drive: create, share, and keep all your stuff in one place. [image:
 Logo for Google Drive] https://drive.google.com

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



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





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




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




-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
Contributors 

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

[Ray Cromwell]

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

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

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

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

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

This also won't work

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

because typeof(x) == number

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

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

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

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

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

-Ray



On Thu, Aug 1, 2013 at 6:01 PM, Goktug Gokdogan gok...@google.com wrote:

 I was thinking about autoboxing of numbers when assigned to Object and I
 started to question if we really need them in Java to JS translation - at
 least for a subset (i.e. Integer and Double).

 Object has only a few methods that we can put into Number.prototype (like
 we do for String) and all methods to Integer/Double can be converted to
 static calls then theoretically we can drop most of the java autoboxing
 code. We can also find similar solutions to calls over java.lang.Number.

 Perhaps, I'm missing some corner cases but I really feel like we can find
 a way to get rid of them at least for the most scenarios. Am I being too
 naive on this?


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

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

[Ray Cromwell]

To me clear, if I put catch(Exception), catch(Throwable), or
catch(RuntimeException), I would expect to catch JavaScriptExceptions. I
would only expect a JS exception to escape if and only if, there are no
catch blocks for it, or any of it's supertypes, and no uncaught exception
handler is installed.



On Fri, Jun 14, 2013 at 5:51 PM, Goktug Gokdogan gok...@google.com wrote:

 I just wanted to give you a heads up that Roberto and I are working on a
 compiler patch so that catch statement will not break js originated
 exceptions.

 To give you some background, if you put any try/catch statement in Java,
 js originated exceptions will be converted into JavaScriptException even if
 you are not catching a JavaScriptException or any of its parents.
 Because of this problem there are workarounds in SDK to avoid catch
 statements if there are no UncaughtExceptionHandlers registered. By
 avoiding catch statements and repeating code, we are making sure a js
 exception can correctly escape and reported by the browser.

 Also with this patch, we can make some exceptions escape to the
 browser asynchronously without breaking the code flow. This is useful to
 fix problems like issue #6833 and similar others in the SDK.

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




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