Re: [gwt-contrib] Update on J2CL

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

Re: [gwt-contrib] Lambda overhead

s/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 > <goog

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

Re: [gwt-contrib] Lambda overhead

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 {

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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 (

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

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

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

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

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

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

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

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

Re: [gwt-contrib] JsInterop Generator from webidl

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [gwt-contrib] JsInterop retrofit

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

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

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

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

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

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

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

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

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

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

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 {

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

@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

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

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

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

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.

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

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); } }

Re: [gwt-contrib] Compiler Faiure

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

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

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

Re: [gwt-contrib] Chrome LiveEdit and SDM

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

Re: [gwt-contrib] Chrome LiveEdit and SDM

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

Re: [gwt-contrib] JsInterop Advance

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,

Re: [gwt-contrib] JsInterop Advance

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

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

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

Re: [gwt-contrib] Discussion: Elemental Json

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

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

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

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

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

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

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

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

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