RFC: fix problems in jforex charts

[Jiri Vanek]

On 02/27/2012 10:02 PM, Omair Majid wrote:
> Hi,
>
> The attached patch fixes a problem with icedtea-web throwing exceptions
> when presented with certain javscript results.
>
> The following applet reproduces the problem:
> http://www.fxstreet.com/rates-charts/forex-charts/?fxcm=1
>
> The plugin log shows the following:
>
> Consumption (priority=false) completed by consumer thread 0
>    PIPE: appletviewer read: context 0 reference 39 JavaScriptCall
> Waiting for data...
> Found free worker (false) with id 0
> Consumer thread 0 woken...
> Consumer (priority=false) thread 0 consuming context 0 reference 39
> JavaScriptCall
> readPair: 'context' - '0' 10
> readPair: 'reference' - '39' 23
> readPair: 'JavaScriptCall' - 'null' 23
> Breakdown -- type: context identifier: 0 reference: 39 src: null
> privileges: null rest: "JavaScriptCall "

I have not tested the patch itself, but the length test looks fundamental.

>
> There is no value after JavaScriptCall, and the Java side fails to
> handle such a case and throws an exception.
>
> Okay to commit to HEAD/1.2? (Any others?)
shoud be 1.1.,1.2 and head, if possible
>
> Thanks,
> Omair
>
>
> handle-null-responses.patch
>
>
> diff --git a/plugin/icedteanp/java/sun/applet/GetMemberPluginCallRequest.java b/plugin/icedteanp/java/sun/applet/GetMemberPluginCallRequest.java
> --- a/plugin/icedteanp/java/sun/applet/GetMemberPluginCallRequest.java
> +++ b/plugin/icedteanp/java/sun/applet/GetMemberPluginCallRequest.java
> @@ -50,7 +50,7 @@
>           String[] args = message.split(" ");
>           // FIXME: Is it even possible to distinguish between null and void
>           // here?
> -        if (args[3] != "null"&&  args[3] != "void")
> +        if (args.length>  3&&  args[3] != "null"&&  args[3] != "void")
                               ^                    ^   spaces would fit, but how you wish.. O:)
>               object = AppletSecurityContextManager.getSecurityContext(0).getObject(Integer.parseInt(args[3]));
>           setDone(true);
>       }
>

But what I'm really wondering  about is comparing of Strings by == / != ...(!!)... There should be used  equals(...)! Or is it some plugin-java-c bridge featture?
Also, when we do not this method to throw an exception, maybe also possible exception thrown by Integer.parseInt(args[3]) should be cought?
Both cases ( length<3 and possible caught parsing of number) should go out in  debug mode.

I do not insists   on above points, but I'm throwing them out for discussion.

Thanx for fix,

Best Regards to thermostat team :)
     J.