[gwt-contrib] Re: 2.7.0 RC1 SDM not working when using java.util.List - Example attached
Ok thanks so far. Because the List.size() call is executed from GXT I don't have the possibility to change that call. I've rewritten my JsArrayListWrapper and it's not a JSO any more. So I'm good to go. Cheers, Jan Am Montag, 17. November 2014 20:22:29 UTC+1 schrieb John Stalcup: A fix for this is now committed. Which means this code snippet will now be rejected all the time. To accomplish the same thing you need to execute the .size() function dispatch (or really any function dispatch on a List instance since you've used the List interface on a JSO type) inside of a *Java* not inside of a JSNI function. This is relatively straight forward if you make a static Java function that takes a List instance and calls size() on it, and you can call this static Java function inside of your JSNI. On Wed Nov 12 2014 at 4:05:26 PM John Stalcup sta...@google.com javascript: wrote: It's more like, 50% of the time. Here's what's going on: It's currently illegal to call foo.blah() in JSNI if the variable foo is either a JSO type or interface that is implemented by some JSO type. The error you're seeing is JsniReferenceResolver enforcing this requirement, the weird part is that it should enforce it all the time but it's only enforcing it 50% of the time. The reason this is occurring is that depending on the order that JDT processes types we may or may not yet have collected the knowledge to know that the java.util.List interface is used on a JSO before JsniReferenceResolver performns its check. We need to move the correctness check to some later stage, late enough that is JSO checks will always be accurate. In the 50% of compiles that are succeeding for you right now you're actually vulnerable to runtime errors because it's outputting code that attempts to call the size() function on the prototype of the list parameter (and that will fail if the instance that is passed in happens to be a JsArrayListWrapper). On Wed Nov 12 2014 at 1:27:42 PM John Stalcup sta...@google.com javascript: wrote: I'm able to repro this both with -noincremental and -incremental, but only randomly (seems about 30% of the time). Still looking into it. On Wed Nov 12 2014 at 8:24:43 AM Thomas Broyer t.br...@gmail.com javascript: wrote: [+cc stalcup@] This might be because of incremental compilation: when JsArrayListWrapper is in another module, that module is precompiled, so the compiler knows about the type. When it's in the same module, because it's the module being compiled, it can be pruned (unused) and as consequence doesn't interfere with the JSNI checks. The workaround would be to call a static method passing the List as argument, and call the size() method in that static method, in Java-land, outside of JSNI. On Wednesday, November 12, 2014 1:39:55 PM UTC+1, Jan Thewes wrote: Hello guys, we're currently running in problems related to the SDM in GWT 2.7. We've attached two examples. JsListWrapperWorking is an example project where everything is working fine. It is CODE IDENTICAL to JsListWrapperNotWorking. In the latter one we've moved the source for the two classes JsArrayListWrapper and JsArrayWrapper to another module. No source code has been touched. When starting SDM for JsListWrapperWorking everything is working fine. When starting SDM for JsListWrapperNotWorking we get following exception: [ERROR] Errors in 'file:~/JsListWrapperNotWorking/src/ de/gad/list/client/JsListWrapperNotWorking.java' [ERROR] Line 19: Referencing interface method 'java.util.List.size()': implemented by 'de.gad.list.client.myListImpl.JsArrayListWrapper'; references to instance methods in overlay types are illegal; use a stronger type or a Java trampoline method If you need any further information I'll provide them as soon as possible! Cheers, Jan -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/21699301-33e5-4bed-a793-3ca461d681a9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Logging not working anymore in GWT 2.7.0 RC
Hey guys, we've a problem with logging since testing GWT 2.7. We're using java.util.Logger() and with 2.7 any message trying to be logged with WARN or lower doesn't end up in the browser console. What I found out is that my Logger.info(String message) call is thrown away by the GWT compiler? Why does this happen? What do I have to do to get the old behavior? Cheers, Jan -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/52ec051f-318a-4f56-bc33-13dc4321a257%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Logging not working anymore in GWT 2.7.0 RC
GWT 2.7 changed property value gwt.logging.enabled from TRUE to SEVERE (in Logging.gwt.xml) so by default app logs errors only. To get back to pre-2.7 logging behavior, set this property to TRUE or WARNING (if you want to log warnings and errors). On Thursday, November 20, 2014 12:15:16 PM UTC+3, Jan Thewes wrote: Hey guys, we've a problem with logging since testing GWT 2.7. We're using java.util.Logger() and with 2.7 any message trying to be logged with WARN or lower doesn't end up in the browser console. What I found out is that my Logger.info(String message) call is thrown away by the GWT compiler? Why does this happen? What do I have to do to get the old behavior? Cheers, Jan -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc407279-a9b3-4434-a970-bd0e71859338%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: Logging not working anymore in GWT 2.7.0 RC
see below, - GWT apps that inherit the com.google.gwt.logging.Logging module have different default behavior for messages logged using the java.util.logging package. The new default is to log messages at level SEVERE and above to the browser's console. PopupLogHandler and SystemHandler are no longer enabled by default. On Thursday, November 20, 2014 2:45:16 PM UTC+5:30, Jan Thewes wrote: Hey guys, we've a problem with logging since testing GWT 2.7. We're using java.util.Logger() and with 2.7 any message trying to be logged with WARN or lower doesn't end up in the browser console. What I found out is that my Logger.info(String message) call is thrown away by the GWT compiler? Why does this happen? What do I have to do to get the old behavior? Cheers, Jan -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ace00a95-1ee1-4d1e-a449-9333ad21a708%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: SDM + gin + generated GinModule not working well together
Though we do not make a promise to process GWT.create() of entry point
types before any other GWT.create() calls, it was easy to restore this
behavior in incremental, so I went ahead and did it (
https://gwt-review.googlesource.com/#/c/10410/).
You should probably find a way not to depend on this in the future, as it
is not promised and may change again.
On Mon Nov 17 2014 at 2:07:02 PM Christopher Viel
viel.christop...@gmail.com wrote:
Hi,
I'm gonna add some more background here.
The generator generates a bunch of file and binds the interfaces using
GIN. I would't say this is strictly necessary, but it brings the advantages
of DI to the generated code. So we have an Entry Point that is an interface
and a rebind rule. UserAgentAsserter uses a similar technique. What we also
do is generate a Ginjector interface and put a
*GWT.create(GeneratedGinjector.class)* call inside the generated entry
point. That way GIN's generator is called after and everything should be
resolvable. The generated ginjector is setup to look at a specific property
to load additional gin modules. Here it happens that one of them is also
generated. So all of that actually work with 2.7.
What no longer works is if the entry point and the ginjector are no longer
generated. If there is a GWT.create() call that resolves to a Ginjector
from an explicit entry point, it fails. I'm not sure I'm being very clear
here so here's an example:
*MyModule.gwt.xml:*
module
entry-point class=com.project.EntryPointToGenerate/
entry-point class=com.project.ExplicitEntryPoint/
extend-configuration-property name=gin.ginjector.modules
value=com.project.GeneratedGinModule/
generate-with class=com.project.EntryPointGenerator
when-type-is class=com.project.EntryPointToGenerate/
/generate-with
/module
*EntryPointToGenerate:*
public interface EntryPointToGenerate extends EntryPoint {}
*EntryPointGenerator*: Generates *com.project.GeneratedGinModule* and an
implementation of *EntryPointToGenerate*
*ExplicitEntryPoint*:
public class ExplicitEntryPoint implements EntryPoint {
private static final ExplicitGinjector GINJECTOR = GWT.create(
ExplicitGinjector.class);
@Override
public void onModuleLoad() {}
}
*ExplicitGinjector:*
@GinModules( value = ExplicitGinModule.class, properties =
gin.ginjector.modules )
public interface ExplicitGinjector extends Ginjector {
/* snip */
}
With this code in a regular compilation, EntryPointToGenerate is generated
before ExplicitEntryPoint is traversed. With incremental compilation,
ExplicitEntryPoint is traversed (and incidentally GINs generator is called)
before EntryPointGenerator is called. I would expect the first entry point
to be traversed at first, even if it means calling a generator.
On Sunday, November 16, 2014 3:56:20 PM UTC-5, Nicolas Morel wrote:
Hi,
I'm currently testing GWT 2.7.0-rc1 and one of my project using GWTP
Rest-Dispatch https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch is
not working under SDM.
The compilation fails with this error :
[ERROR] Unable to load gin module type
[com.gwtplatform.dispatch.rest.client.RestGinModule], maybe you haven't
compiled your client java sources?
java.lang.ClassNotFoundException: com$gwtplatform$dispatch$rest$
client$RestGinModule
at com.google.gwt.inject.rebind.GinBridgeClassLoader.findClass(
GinBridgeClassLoader.java:150)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at com.google.gwt.inject.rebind.GinBridgeClassLoader.loadClass(
GinBridgeClassLoader.java:108)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:340)
at com.google.gwt.inject.rebind.GinjectorGenerator.loadClass(
GinjectorGenerator.java:223)
at com.google.gwt.inject.rebind.GinjectorGenerator.
getPropertyModuleClasses(GinjectorGenerator.java:137)
at com.google.gwt.inject.rebind.GinjectorGenerator.getModuleClasses(
GinjectorGenerator.java:116)
at com.google.gwt.inject.rebind.GinjectorGenerator.generate(
GinjectorGenerator.java:72)
at com.google.gwt.core.ext.IncrementalGenerator.generateNonIncrementally(
IncrementalGenerator.java:40)
The full stack trace is available in attachment.
The problem has been reported to the GWTP team here
https://github.com/ArcBees/GWTP/issues/614. The normal compilation
works but not the incremental compile from SDM.
I made a simple example available here
https://github.com/nmorel/hello-gwt-rest-dispatch.
From what I saw, the RestGinModule that gin is trying to load is
generated by a GWT generator (VelocityGenerator
https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-dispatch-rest/src/main/java/com/gwtplatform/dispatch/rest/rebind/VelocityGenerator.java
.generateRestGinModule()) and passed to gin through the property
gin.ginjector.modules.
It seems unconventional but was working before.
Any ideas
[gwt-contrib] Re: Getting rid of autoboxing?
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 cromwell...@google.com wrote: I explored that a long time ago when Lightweight Collections were proposed, but it won't work that simply. (Sadly, most of the original discussions on this with the Atlanta team were in Google Wave and forever lost) The reason why it won't work is that there is no way to tell the difference between Integer and Double, Float, Byte, Short, et al. Only one boxed type can own Number.prototype, so instanceof and equals() checks will fail. Also, toString() and compareTo() might return values that break existing apps. It is impossible to write a runtime test on a primitive JS number that can distinguish between a Double and a Float, and it is impossible to store a castable type map on a given instance of number. The only way to make this work would be to ensure that *all such* JS numbers are boxed. This won't work: var x = 42.3; x.isFloat = true; This also won't work var x = Number(42.3); x.isFloat = true; because typeof(x) == number This will work var x = Object(42.3) x.isFloat = true; x + 2 = prints 44.3 x.isFloat = prints true But this is nothing more than making a JSO that holds the number with extra runtime fields. Leaving all this aside, I don't understand why you're trying to do this in the first place. Java is a language which insists on a difference between the 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? -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To
