[gwt-contrib] Errors during GWTTestCase and uibinder

[Julien Dramaix]

Hi Everyone,

Since yesterday, I'm not able to start any GWTTestCase using uibinder, I've
got the error below.
An idea  ?

Unexpected exception occurred while parsing HTML snippet
org.xml.sax.SAXNotRecognizedException: Feature '
http://cyberneko.org/html/features/scanner/allow-selfclosing-tags' is not
recognized.
at org.apache.xerces.parsers.AbstractSAXParser.setFeature(Unknown Source)
at
com.gargoylesoftware.htmlunit.html.HTMLParser.parseFragment(HTMLParser.java:162)
at
com.gargoylesoftware.htmlunit.html.HTMLParser.parseFragment(HTMLParser.java:129)
at
com.gargoylesoftware.htmlunit.javascript.host.html.HTMLElement.parseHtmlSnippet(HTMLElement.java:1105)
at
com.gargoylesoftware.htmlunit.javascript.host.html.HTMLElement.setInnerHTML(HTMLElement.java:1004)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
net.sourceforge.htmlunit.corejs.javascript.MemberBox.invoke(MemberBox.java:120)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptableObject$GetterSlot.setValue(ScriptableObject.java:295)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptableObject.putImpl(ScriptableObject.java:2796)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptableObject.put(ScriptableObject.java:521)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptableObject.putProperty(ScriptableObject.java:2479)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptRuntime.setObjectProp(ScriptRuntime.java:1569)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptRuntime.setObjectProp(ScriptRuntime.java:1564)
at
net.sourceforge.htmlunit.corejs.javascript.Interpreter.interpretLoop(Interpreter.java:1253)
at
net.sourceforge.htmlunit.corejs.javascript.Interpreter.interpret(Interpreter.java:798)
at
net.sourceforge.htmlunit.corejs.javascript.InterpretedFunction.call(InterpretedFunction.java:105)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$4.doRun(JavaScriptEngine.java:609)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:669)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:602)
at
net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:507)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.callFunction(JavaScriptEngine.java:616)
at
com.google.gwt.dev.shell.HtmlUnitSessionHandler.invoke(HtmlUnitSessionHandler.java:228)
at
com.google.gwt.dev.shell.BrowserChannelClient.reactToMessages(BrowserChannelClient.java:218)
at
com.google.gwt.dev.shell.BrowserChannelClient.reactToMessagesWhileWaitingForReturn(BrowserChannelClient.java:165)
at
com.google.gwt.dev.shell.JavaObject.getReturnFromJavaMethod(JavaObject.java:61)
at com.google.gwt.dev.shell.JavaObject.call(JavaObject.java:122)
at
net.sourceforge.htmlunit.corejs.javascript.Interpreter.interpretLoop(Interpreter.java:1531)
at
net.sourceforge.htmlunit.corejs.javascript.Interpreter.interpret(Interpreter.java:798)
at
net.sourceforge.htmlunit.corejs.javascript.InterpretedFunction.call(InterpretedFunction.java:105)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$4.doRun(JavaScriptEngine.java:609)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:669)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:602)
at
net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:507)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.callFunction(JavaScriptEngine.java:616)
at
com.google.gwt.dev.shell.HtmlUnitSessionHandler.invoke(HtmlUnitSessionHandler.java:228)
at
com.google.gwt.dev.shell.BrowserChannelClient.reactToMessages(BrowserChannelClient.java:218)
at
com.google.gwt.dev.shell.BrowserChannelClient.reactToMessagesWhileWaitingForReturn(BrowserChannelClient.java:165)
at
com.google.gwt.dev.shell.JavaObject.getReturnFromJavaMethod(JavaObject.java:61)
at com.google.gwt.dev.shell.JavaObject.call(JavaObject.java:122)
at
net.sourceforge.htmlunit.corejs.javascript.Interpreter.interpretLoop(Interpreter.java:1531)
at
net.sourceforge.htmlunit.corejs.javascript.Interpreter.interpret(Interpreter.java:798)
at
net.sourceforge.htmlunit.corejs.javascript.InterpretedFunction.call(InterpretedFunction.java:105)
at
net.sourceforge.htmlunit.corejs.javascript.ContextFactory.doTopCall(ContextFactory.java:405)
at
com.gargoylesoftware.htmlunit.javascript.HtmlUnitContextFactory.doTopCall(HtmlUnitContextFactory.java:309)
at
net.sourceforge.htmlunit.corejs.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3031)
at
net.sourceforge.htmlunit.corejs.javascript.InterpretedFunction.call(InterpretedFunction.java:103)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$4.doRun(JavaScriptEngine.java:609)
at
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:669)
at net.sou

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

[Alex White]

+1 to keeping the original system. For an interface a finite number of 
types > infinite number of String parameters. 
Once it gets properly documented on gwtproject.org I doubt people will 
consider it confusing. The problem imo is that most of the existing stuff 
out there is pseudocode.

We just started using JsInterop and the only stumbling block we encountered 
was that at first we weren't using @JsNamespace.
The other thing we have found is really weird bugs in some of the nightlies 
a few days ago, like types deleted from our codebase still existing and 
other new types not existing.
It was from about 4-7 days ago and seems to have stopped now. It may be 
related to the sourcemaps. The emergent behavior was that after a hard 
cache reset Chrome would be trying to fetch a sourcemap for a deleted type. 
If we grepped for that symbol in our codebase, we would find references to 
it despite it being long gone in a cleanly built proj. Does the gwt 
compiler keep some state information hidden somewhere on the hd? Because 
that was weird.


On Wednesday, April 22, 2015 at 4:42:10 AM UTC+10, Goktug Gokdogan wrote:
>
> There is some upcoming changes to JsInteorp in preparation toward v1.0 
> release.
>
> The most major change is to the annotations and their meanings. Here is 
> the doc explaining the changes and the reasoning. We are looking for your 
> feedback, especially on alternatives.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Issues with existing design and annotations 1. @JsExport/@JsType slicing 
> is not intuitive for a lot of people esp. with gwt-exporter background. 
> People are confused about when to use what.2. There is no reason to why 
> @JsType doesn’t have any effect on the static methods. That is only because 
> of the original use cases that the design was tackling only cared about 
> well formed prototypal structures. Diving deeper into Elemental and 
> different javascript output styles, ability to define the full class 
> structure without exporting proves to be useful.3. @JsExport uses @JsType 
> to define the prototype structure. However this imposes unnecessary 
> restriction if/when there will be no javascript implementers of the @JsType 
> contract. @JsType that extends non-JsType is normally ok if it is not 
> implemented in js.4. You always need to fully qualify the name of the 
> export even if you just want to change the simple name.The New Annotation 
> SystemThere will be single annotation called @Js. Applying @Js to a member 
> is making that member available in javascript without any obfuscation. 
> However it is not safe from pruning if there are no references in java 
> code, so one needs to put enable exporting for the type if no pruning 
> wanted. Applying @Js at class level should considered as a shortcut to 
> apply @Js to all members. See following chart for the attributes and their 
> corresponding behavior:@JsType@Js(exports = 
> INSTANCE_MEMBERS)@JsFunction@Js(mode = FUNCTION)@JsLiteral@Js(mode = 
> LITERAL)@JsMethod@Js(name = "myName")@JsProperty@Js(property = 
> true)@Js(name = "myName", property = true)@JsNamespace@Js(namespace = 
> "mynamespace")@JsExport@Js(exports = STATIC_MEMBERS)@Js(name = “A”, exports 
> = ALL)@Js(name = “A”, namespace=”a.b.c.”, exports = ALL)// When applied to 
> a member@Js(export = true)@Js(name = “myName”, export = 
> true)@JsNoExport@Js(ignore=true)@JsOpaque@Js(opaque=true)See Appendix below 
> for a complete comparison to existing annotations.Semantics / 
> Implementation in GWTImplementation: - Apply all Js names as bridge methods 
> (or the reverse if Js extends Java object case 
> 
>  
> needs to be supported).- Optimize away everything with regular optimization 
> rules if the member is not exported.- Generate export statements for all 
> pinned methods/classes.Usage: - Hybrid / Inbox use case needs to use @Js 
> with exports. This will make the whole object exported and not pruned.- 
> Regular library importing should use @Js with interfaces (no exports), if 
> it is a callback the @Js interface should be marked as exported so the 
> methods are not pruned when the object is not pruned.- Elemental needs to 
> use not exported Js types with prototype set and native methods.Checks - 
> mode and exports is only used in types.- export and ignore is only used in 
> members.- property is only used in methods.- name is only used in members 
> and types.- namespace is only used in exported static members, types and 
> packages.- mode=FUNCTION cannot have any attribute set.Considered 
> AlternativesAlternative 1:We could follow the above design but keep using 
> old annotations for class level annotations: - @Js(mode=OBJECT) --> 
> @JsType- @Js(mode=FUNCTION) --> @JsFunction- @Js(mode=LITERAL) --> 
> @JsLiteral- @Js(namespace=”...”) --> @JsNamespace- @JsMember for the 
> rest.Pros: - Reads well . (e.g. @JsType interface Element instead

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

['Ray Cromwell' via GWT Contributors]

There are multiple things JsInterop needs to accomplish:

1) preventing method/field renames
2) pinning methods (preventing code pruning)
3) giving a global name/namespace alias to something
4) auto-converting parameters to allow idiomatic programming
5) allowing GWT objects to extend native objects

@JsType actually combines #1/#2/#5 (although it only pins methods if the
object is instantiated)
@JsExport combines #2 and #3 (it not only pins a method, but treats the
type as instantiable, plus it gives it a global alias)

#4 is handled by @JsConvert/JsAware/JsFunction

#5 is handled by @JsType(prototype="...")

Goktug is trying separate out the behavior into the 5 types of interop
semanics:

1) a way of indicating a method/field should not be renamed
2) a way of indicating not to prune something
3) a way of indicating giving a global alias to something
4) a way of indicating something extends a native object

There are cases where you want to prevent renaming, but allow dead code
elimination.

You could make these separate annotations, that's matter of aesthetics, e.g.

@JsPin
@JsExport
@JsName
@JsPrototype

etc



On Sat, May 9, 2015 at 2:34 PM, Alex White  wrote:

> +1 to keeping the original system. For an interface a finite number of
> types > infinite number of String parameters.
> Once it gets properly documented on gwtproject.org I doubt people will
> consider it confusing. The problem imo is that most of the existing stuff
> out there is pseudocode.
>
> We just started using JsInterop and the only stumbling block we
> encountered was that at first we weren't using @JsNamespace.
> The other thing we have found is really weird bugs in some of the
> nightlies a few days ago, like types deleted from our codebase still
> existing and other new types not existing.
> It was from about 4-7 days ago and seems to have stopped now. It may be
> related to the sourcemaps. The emergent behavior was that after a hard
> cache reset Chrome would be trying to fetch a sourcemap for a deleted type.
> If we grepped for that symbol in our codebase, we would find references to
> it despite it being long gone in a cleanly built proj. Does the gwt
> compiler keep some state information hidden somewhere on the hd? Because
> that was weird.
>
>
>
> On Wednesday, April 22, 2015 at 4:42:10 AM UTC+10, Goktug Gokdogan wrote:
>
>> There is some upcoming changes to JsInteorp in preparation toward v1.0
>> release.
>>
>> The most major change is to the annotations and their meanings. Here is
>> the doc explaining the changes and the reasoning. We are looking for your
>> feedback, especially on alternatives.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Issues with existing design and annotations 1. @JsExport/@JsType slicing
>> is not intuitive for a lot of people esp. with gwt-exporter background.
>> People are confused about when to use what.2. There is no reason to why
>> @JsType doesn’t have any effect on the static methods. That is only because
>> of the original use cases that the design was tackling only cared about
>> well formed prototypal structures. Diving deeper into Elemental and
>> different javascript output styles, ability to define the full class
>> structure without exporting proves to be useful.3. @JsExport uses @JsType
>> to define the prototype structure. However this imposes unnecessary
>> restriction if/when there will be no javascript implementers of the @JsType
>> contract. @JsType that extends non-JsType is normally ok if it is not
>> implemented in js.4. You always need to fully qualify the name of the
>> export even if you just want to change the simple name.The New Annotation
>> SystemThere will be single annotation called @Js. Applying @Js to a member
>> is making that member available in javascript without any obfuscation.
>> However it is not safe from pruning if there are no references in java
>> code, so one needs to put enable exporting for the type if no pruning
>> wanted. Applying @Js at class level should considered as a shortcut to
>> apply @Js to all members. See following chart for the attributes and their
>> corresponding behavior:@JsType@Js(exports =
>> INSTANCE_MEMBERS)@JsFunction@Js(mode = FUNCTION)@JsLiteral@Js(mode =
>> LITERAL)@JsMethod@Js(name = "myName")@JsProperty@Js(property =
>> true)@Js(name = "myName", property = true)@JsNamespace@Js(namespace =
>> "mynamespace")@JsExport@Js(exports = STATIC_MEMBERS)@Js(name = “A”, exports
>> = ALL)@Js(name = “A”, namespace=”a.b.c.”, exports = ALL)// When applied to
>> a member@Js(export = true)@Js(name = “myName”, export =
>> true)@JsNoExport@Js(ignore=true)@JsOpaque@Js(opaque=true)See Appendix below
>> for a complete comparison to existing annotations.Semantics /
>> Implementation in GWTImplementation: - Apply all Js names as bridge methods
>> (or the reverse if Js extends Java object case
>> 
>> needs to be supported)