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?

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 Element

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

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

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 ( https://critique.corp.google.com/#review/92873682/depot/google3

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?

? 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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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

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.

Re: [gwt-contrib] Deprecating DeRPC classes

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? 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

Re: [gwt-contrib] Possible firefox leak fix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   3   4   5   >