Re: How to use javascript's regular expression by jsni?
Sorry,there is typing mistake in my question:the returning type of
reEmail() isn't boolean but String,and my code is:
private native String reEmail()/-*{
return
^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\...@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$;
}-*/;
and it doesn't work.
On Thursday, November 20, 2014 3:18:32 PM UTC+8, Alex Luya wrote:
Hello:
Similar question has been asked here: How to pass a regular
expression as a function parameter
http://stackoverflow.com/questions/11143702/how-to-pass-a-regular-expression-as-a-function-parameter,
but I can't get it work by JSNI.
This is the string of the regular expression that will be used to test
email:
^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$
))@((%5C[[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C])%7C(([a-zA-Z%5C-0-9]+%5C.)+[a-zA-Z]%7B2,%7D))$
and if putting it to firebug execute like this:
/^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$
))@((%5C[[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C])%7C(([a-zA-Z%5C-0-9]+%5C.)+[a-zA-Z]%7B2,%7D))$/.test(t...@domain.com
t...@domain.com)
it will give what I want,but If wrapping it to a JSNI method:
private native boolean reEmail()/-*{
return
^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$
))@((%5C[[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C])%7C(([a-zA-Z%5C-0-9]+%5C.)+[a-zA-Z]%7B2,%7D))$;
}-*/;
then passing it to the function:
private native boolean validate(String value, String regexp)/-*{
//escape special characters
var re=regexp.replace(/([-()\[\]{}+?*.$\^|,:#!\\])/g,
'\\$1').replace(/\x08/g, '\\x08');
return new RegExp(re,'g').test(value)
}-*/;
like this:
validate(t...@domain.com t...@domain.com,reEmail());
It will give me false.Please tell what mistakes I have made,thanks.
--
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 2.7.0 is here
Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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.
Re: GWT 2.7.0 is here
Awesome!! On 20 November 2014 07:59, Daniel Kurka danku...@google.com wrote: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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. -- 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.
Re: GWT 2.7.0 is here
Well done Daniel (and all the GWT developer community)!! Proud to have met you in Firenze! On Thu, Nov 20, 2014 at 12:11 PM, Juan Pablo Gardella gardellajuanpa...@gmail.com wrote: Awesome!! On 20 November 2014 07:59, Daniel Kurka danku...@google.com wrote: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes. The release is available for download here or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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. -- 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. -- Luca Morettoni luca(AT)morettoni.net | http://www.morettoni.net http://it.linkedin.com/in/morettoni/ | http://twitter.com/morettoni Google+ profile: https://www.google.com/+LucaMorettoni Member of GDG Perugia: http://perugia.gtugs.org -- 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.
Re: GWT 2.7.0 is here
Waiting for Maven Central.. Il giorno giovedì 20 novembre 2014 11:59:06 UTC+1, Daniel Kurka ha scritto: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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.
Re: GWT 2.7.0 is here
Waiting for Maven Central.. https://repo1.maven.org/maven2/com/google/gwt/gwt-user/2.7.0/ Maven search website just doesn't reveal it yet. -- J. -- 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.
Re: GWT 2.7.0 is here
Great!!! Excited to get to try JSInterop , albeit experimential Am Donnerstag, 20. November 2014 11:59:06 UTC+1 schrieb Daniel Kurka: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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.
Re: GWT 2.7.0 is here
Now it's there, when I tried Maven build failed. Thank you, now I want to test all my projects :) Il giorno giovedì 20 novembre 2014 13:40:39 UTC+1, Jens ha scritto: Waiting for Maven Central.. https://repo1.maven.org/maven2/com/google/gwt/gwt-user/2.7.0/ Maven search website just doesn't reveal it yet. -- J. -- 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.
Re: GWT 2.7.0 is here
Thank you! Wov it really compiles fast after the first compilation. This really makes a difference in development. In small change Sketchboard.io used to take 5 - 6 seconds to compile and now it takes little bit over a 1 second, I am impressed. Saiki -- http://sketchboard.io - Make a complex problem simple together. Sketch. On Thursday, November 20, 2014 3:36:49 PM UTC+2, Luca wrote: Now it's there, when I tried Maven build failed. Thank you, now I want to test all my projects :) Il giorno giovedì 20 novembre 2014 13:40:39 UTC+1, Jens ha scritto: Waiting for Maven Central.. https://repo1.maven.org/maven2/com/google/gwt/gwt-user/2.7.0/ Maven search website just doesn't reveal it yet. -- J. -- 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.
Re: GWT 2.7.0 is here
Fantástico! On Thursday, 20 November 2014 11:59:06 UTC+1, Daniel Kurka wrote: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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.
Re: How to use javascript's regular expression by jsni?
\s and \[ (among others) in a JS string are equivalent to s and [,
so you have to escape the backslash.
Also, your escape special characters is messing with your regexp, turning
your [0-9]{1,3} into \[0\-9\]\{1\,3\} (among others) which does not mean
the same thing at all.
Or maybe just use a RegExp literal like you do in Firebug?
On Thursday, November 20, 2014 9:07:24 AM UTC+1, Alex Luya wrote:
Sorry,there is typing mistake in my question:the returning type of
reEmail() isn't boolean but String,and my code is:
private native String reEmail()/-*{
return
^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\...@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$;
}-*/;
and it doesn't work.
On Thursday, November 20, 2014 3:18:32 PM UTC+8, Alex Luya wrote:
Hello:
Similar question has been asked here: How to pass a regular
expression as a function parameter
http://stackoverflow.com/questions/11143702/how-to-pass-a-regular-expression-as-a-function-parameter,
but I can't get it work by JSNI.
This is the string of the regular expression that will be used to test
email:
^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$
))@((%5C[[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C])%7C(([a-zA-Z%5C-0-9]+%5C.)+[a-zA-Z]%7B2,%7D))$
and if putting it to firebug execute like this:
/^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$
))@((%5C[[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C])%7C(([a-zA-Z%5C-0-9]+%5C.)+[a-zA-Z]%7B2,%7D))$/.test(t...@domain.com
t...@domain.com)
it will give what I want,but If wrapping it to a JSNI method:
private native boolean reEmail()/-*{
return
^(([^()[\]\\.,;:\s@\]+(\.[^()[\]\\.,;:\s@\]+)*)|(\.+\))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$
))@((%5C[[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C.[0-9]%7B1,3%7D%5C])%7C(([a-zA-Z%5C-0-9]+%5C.)+[a-zA-Z]%7B2,%7D))$;
}-*/;
then passing it to the function:
private native boolean validate(String value, String regexp)/-*{
//escape special characters
var re=regexp.replace(/([-()\[\]{}+?*.$\^|,:#!\\])/g,
'\\$1').replace(/\x08/g, '\\x08');
return new RegExp(re,'g').test(value)
}-*/;
like this:
validate(t...@domain.com t...@domain.com,reEmail());
It will give me false.Please tell what mistakes I have made,thanks.
--
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.
Re: GWT 2.7.0 is here
I've just updated to 2.7.0 through maven, and each time I run it, the browser gets stuck on the 'Compiling [ModuleName]' screen. In chrome's console, I see this error: Uncaught ReferenceError: moduleName is not defined :9876/ModuleName/ModuleName.recompile.nocache.js:349 I've tried stopping and restarting a few times, no luck. Any ideas? -- 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.
Re: GWT 2.7.0 is here
Great news! We're going to switch to 2.7 in our next sprint Great to see it compiles even faster in the super dev mode On Thursday, November 20, 2014 11:59:06 AM UTC+1, Daniel Kurka wrote: Today we are excited to announce the GWT 2.7.0 release. Thanks to everyone who contributed to this release, especially our non-Google open source contributors. One major feature of this release is a new super fast compilation path in Super Dev mode that replaces the old dev mode. For a run-down of all changes since GWT 2.6.1, read the release notes http://www.gwtproject.org/release-notes.html#Release_Notes_2_7_0. The release is available for download here http://www.gwtproject.org/download.html or on maven central. If you find any issues with this release, please file a bug in our issue tracker. Daniel, on behalf of the GWT team at Google -- 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 compile fails with default Maven directory structure
I'm in the process of Maven-izing my GWT 2.6.1 project (an intermediate step to start using GWT 2.7.0), and as a first step want to switch to maven style directory structure (as suggested by the Maven GWT Plugin documentation http://mojo.codehaus.org/gwt-maven-plugin/user-guide/project.html), so I make two simple moves: [project]/src = [project]/src/main/java [project]/test = [project]/src/test/java But what happens when I do this is that the regular GWT Compile from the Google Plugin for Eclipse fails with the -strict option, because it tries to compile my test classes as GWT source code, and of course can't find the classes they reference, for example (source files names obfuscated with extra ...'s): [ERROR] Errors in 'file:/.../src/test/java/.../...Test.java' [ERROR] Line 20: No source code is available for type org.junit.Assert; did you forget to inherit a required module? (... repeated with many other files) I'm confused because this doesn't happen with my old directory structure, and I don't know why the GWT compiler would go back up into my test directory to compile classes there. Strangely, it also doesn't happen with this structure, which I accidentally moved to once: [project]/src = [project]/src/java/main [project]/test = [project]/src/java/test It almost seems like the GWT compiler is doing something special with the default Maven directory structure. And any of the solutions I can think of are not very clean: - Not use the Google Plugin for Eclipse, but only use the Maven GWT Plugin, but then I lose some features from the Google Plugin for Eclipse that I want - Not compile with -strict, but then I don't catch other warnings as easily - Use an exclude in my *.gwt.xml source paths to exclude **/*Test.java, but then I might still catch some unintended utility classes in my test package - Not use a parallel package structure for my tests, but then it's not possible to test package protected classes and methods - Not make [project]/src/test/java a source directory in Eclipse, but I don't know what the side effects of that are How are people handling this, or am I missing something? -- 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.
Websockets using GWT - Best practice
Hi, I'm currently trying to establish a websocket connection in GWT 2.6 and 2.7 using gwt-ws. *My question:* the Google search points me to the gwt-ws project to implement websocket connections. But the code examples there do not work with the jetty version included in GWT 2.6 and 2.7 Is there a best practice to do it know? Any known code examples you can point me to? *More infos about the problem:* The server (coded as shown at Getting Started https://code.google.com/p/gwt-ws/)throws an AbstractMethodExeption. Here is the full StackTrace java.lang.AbstractMethodError: de.csenk.gwt.ws.server.jetty. JettyWebSocketConnection.onOpen(Lorg/eclipse/jetty/websocket/ WebSocket$Connection;)V at org.eclipse.jetty.websocket.WebSocketConnectionRFC6455.onWebSocketOpen( WebSocketConnectionRFC6455.java:425) at org.eclipse.jetty.websocket.WebSocketServletConnectionRFC6455.handshake( WebSocketServletConnectionRFC6455.java:60) at org.eclipse.jetty.websocket.WebSocketFactory.upgrade(WebSocketFactory. java:323) at org.eclipse.jetty.websocket.WebSocketFactory.acceptWebSocket( WebSocketFactory.java:396) at org.eclipse.jetty.websocket.WebSocketServlet.service(WebSocketServlet. java:104) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java: 501) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java :137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java: 557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler. java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler. java:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428 ) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler. java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler. java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java :135) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper. java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest( AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete( AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler. headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection. java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle( SelectChannelEndPoint.java:668) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run( SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool. java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool. java:543) at java.lang.Thread.run(Thread.java:744) Seems like the onOpen() method was added in the WebSocket interface The implementation de.csenk.gwt.ws.server.jetty.JettyWebSocketConnection seems to implement an older WebSocket interface without onOpen method. thanks in advance!! Andy -- 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.
Re: GWT compile fails with default Maven directory structure
It sounds like you have non-gwt-capable classes in packages meant for GWT - is that deliberate? For example, test classes to make sure the various server components in your project work, but they are in your .client or .shared package? If they are not, then GWT will totally ignore them, as no .gwt.xml as indicated that those packages are able to be compiled at all. On Thursday, November 20, 2014 11:05:27 AM UTC-6, Phineas Gage wrote: I'm in the process of Maven-izing my GWT 2.6.1 project (an intermediate step to start using GWT 2.7.0), and as a first step want to switch to maven style directory structure (as suggested by the Maven GWT Plugin documentation http://mojo.codehaus.org/gwt-maven-plugin/user-guide/project.html), so I make two simple moves: [project]/src = [project]/src/main/java [project]/test = [project]/src/test/java But what happens when I do this is that the regular GWT Compile from the Google Plugin for Eclipse fails with the -strict option, because it tries to compile my test classes as GWT source code, and of course can't find the classes they reference, for example (source files names obfuscated with extra ...'s): [ERROR] Errors in 'file:/.../src/test/java/.../...Test.java' [ERROR] Line 20: No source code is available for type org.junit.Assert; did you forget to inherit a required module? (... repeated with many other files) I'm confused because this doesn't happen with my old directory structure, and I don't know why the GWT compiler would go back up into my test directory to compile classes there. Strangely, it also doesn't happen with this structure, which I accidentally moved to once: [project]/src = [project]/src/java/main [project]/test = [project]/src/java/test It almost seems like the GWT compiler is doing something special with the default Maven directory structure. And any of the solutions I can think of are not very clean: - Not use the Google Plugin for Eclipse, but only use the Maven GWT Plugin, but then I lose some features from the Google Plugin for Eclipse that I want - Not compile with -strict, but then I don't catch other warnings as easily - Use an exclude in my *.gwt.xml source paths to exclude **/*Test.java, but then I might still catch some unintended utility classes in my test package - Not use a parallel package structure for my tests, but then it's not possible to test package protected classes and methods - Not make [project]/src/test/java a source directory in Eclipse, but I don't know what the side effects of that are How are people handling this, or am I missing something? -- 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.
Re: DART vs. GWT
I've been trying to understand the reasons GWT has not become a widespread JS alternative. It has lost a great deal of mindshare; it's pretty much a niche market now. Dart appears to be Google's second crack at the whip (possibly learning from GWT's mistakes?). There is very little discussion on the web about these reasons. Is it really because of Java's reputation for being complicated and difficult? Or could the elephant in the room be issues surrounding compiling to JS? If so, this would be the same obstacle Dart faces. So, why *did* GWT not take the world by storm? On Wednesday, 22 August 2012 18:10:38 UTC-4, Joseph Lust wrote: Frankly the only issue GWT has, which Dart likely does not, is that it requires intelligent Java developers. You know, that language that is all strict and requires you to really understand what you're doing. Generics, oh my! Script kiddies don't much care for XML, unit testing frameworks, Aria, UiBinder, i18n, hyper optmized JS and the like. To them these are hoops. I would not expect frameworks that really are best in class at making RIA's to be the 'most popular' for this reason. And it's not just the kiddies. To others like seasoned JSP developers, many of the concepts are still new in GWT, and why would they want to change? So I'd never expect GWT to become super popular or to surpass PHP/jQuery mashups. But I can say from experience that in the enterprise space, where these features are sought afters, it is continuing to gain popularity. We've got 70 GWT devs in my office alone. Sincerely, Joseph -- 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.
Re: DART vs. GWT
I don't have an answer for you, but here's an interesting description of how Google's Inbox uses Java as a base for building Android, web (via gwt) and iOS (via j2objc) apps. Three separate native apps sharing about two thirds of the source code. http://gmailblog.blogspot.nl/2014/11/going-under-hood-of-inbox.html?m=1 It's hard to see how Dart could do that. Paul On 20 Nov 2014 21:15, Richard Eng horrido.hobb...@gmail.com wrote: I've been trying to understand the reasons GWT has not become a widespread JS alternative. It has lost a great deal of mindshare; it's pretty much a niche market now. Dart appears to be Google's second crack at the whip (possibly learning from GWT's mistakes?). There is very little discussion on the web about these reasons. Is it really because of Java's reputation for being complicated and difficult? Or could the elephant in the room be issues surrounding compiling to JS? If so, this would be the same obstacle Dart faces. So, why *did* GWT not take the world by storm? On Wednesday, 22 August 2012 18:10:38 UTC-4, Joseph Lust wrote: Frankly the only issue GWT has, which Dart likely does not, is that it requires intelligent Java developers. You know, that language that is all strict and requires you to really understand what you're doing. Generics, oh my! Script kiddies don't much care for XML, unit testing frameworks, Aria, UiBinder, i18n, hyper optmized JS and the like. To them these are hoops. I would not expect frameworks that really are best in class at making RIA's to be the 'most popular' for this reason. And it's not just the kiddies. To others like seasoned JSP developers, many of the concepts are still new in GWT, and why would they want to change? So I'd never expect GWT to become super popular or to surpass PHP/jQuery mashups. But I can say from experience that in the enterprise space, where these features are sought afters, it is continuing to gain popularity. We've got 70 GWT devs in my office alone. Sincerely, Joseph -- 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. -- 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.
Re: GWT compile fails with default Maven directory structure
Sounds like a bug or misconfiguration of the GPE. Is the project a Maven project in Eclipse? There might be some hard-coded paths in the GPE (because of limitations of Eclipse) that are only triggered in one or the other mode (Maven vs. simple Eclipse project). E.g. /test being excluded from the GWT Compiler and DevMode classpath in simple projects, and the test sources (defaulting to src/test/java and src/test/resources), as declared in your Maven POM, in Maven projects. Also, this being a GPE issue, you might have better luck in the dedicated Google Group https://groups.google.com/d/forum/google-plugin-eclipse or on StackOverflow. On Thursday, November 20, 2014 6:05:27 PM UTC+1, Phineas Gage wrote: I'm in the process of Maven-izing my GWT 2.6.1 project (an intermediate step to start using GWT 2.7.0), and as a first step want to switch to maven style directory structure (as suggested by the Maven GWT Plugin documentation http://mojo.codehaus.org/gwt-maven-plugin/user-guide/project.html), so I make two simple moves: [project]/src = [project]/src/main/java [project]/test = [project]/src/test/java But what happens when I do this is that the regular GWT Compile from the Google Plugin for Eclipse fails with the -strict option, because it tries to compile my test classes as GWT source code, and of course can't find the classes they reference, for example (source files names obfuscated with extra ...'s): [ERROR] Errors in 'file:/.../src/test/java/.../...Test.java' [ERROR] Line 20: No source code is available for type org.junit.Assert; did you forget to inherit a required module? (... repeated with many other files) I'm confused because this doesn't happen with my old directory structure, and I don't know why the GWT compiler would go back up into my test directory to compile classes there. Strangely, it also doesn't happen with this structure, which I accidentally moved to once: [project]/src = [project]/src/java/main [project]/test = [project]/src/java/test It almost seems like the GWT compiler is doing something special with the default Maven directory structure. And any of the solutions I can think of are not very clean: - Not use the Google Plugin for Eclipse, but only use the Maven GWT Plugin, but then I lose some features from the Google Plugin for Eclipse that I want - Not compile with -strict, but then I don't catch other warnings as easily - Use an exclude in my *.gwt.xml source paths to exclude **/*Test.java, but then I might still catch some unintended utility classes in my test package - Not use a parallel package structure for my tests, but then it's not possible to test package protected classes and methods - Not make [project]/src/test/java a source directory in Eclipse, but I don't know what the side effects of that are How are people handling this, or am I missing something? -- 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.
Re: GWT compile fails with default Maven directory structure
On Thursday, November 20, 2014 8:47:35 PM UTC+1, Colin Alworth wrote: It sounds like you have non-gwt-capable classes in packages meant for GWT - is that deliberate? For example, test classes to make sure the various server components in your project work, but they are in your .client or .shared package? If they are not, then GWT will totally ignore them, as no .gwt.xml as indicated that those packages are able to be compiled at all. Yes, I have my test classes in the same packages as the classes they test, but the test classes are in a different source directory. It's always been that way, and I like it because tests are easy to find and they have access to package protected classes and methods. -- 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.
Re: GWT compile fails with default Maven directory structure
On Friday, November 21, 2014 8:18:19 AM UTC+1, Thomas Broyer wrote: Sounds like a bug or misconfiguration of the GPE. Is the project a Maven project in Eclipse? There might be some hard-coded paths in the GPE (because of limitations of Eclipse) that are only triggered in one or the other mode (Maven vs. simple Eclipse project). E.g. /test being excluded from the GWT Compiler and DevMode classpath in simple projects, and the test sources (defaulting to src/test/java and src/test/resources), as declared in your Maven POM, in Maven projects. Also, this being a GPE issue, you might have better luck in the dedicated Google Group https://groups.google.com/d/forum/google-plugin-eclipse or on StackOverflow. It was created as a Google - Web Application Project. I think you have it here, it seems that when the source folder base name is 'test', it's excluded from the GWT Compiler, but that's not the case for the default Maven style directory structure. Just as a general question, do you keep the GPE installed when you use Maven? Where I'm heading is that maybe I only need GPE for the UiBinder auto-completion and editor features. Compiling, DevMode and testing can all be handled with Maven. GPE doesn't seem to keep up with GWT releases anyway. Thanks for the 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: 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
