RFC: fix problems in jforex charts

[Omair Majid]

On 02/28/2012 03:07 AM, Jiri Vanek wrote:
> 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.
> 

Actually, this patch is not the best way to fix the problem. Please see
Deepak's better patch:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2012-February/017433.html

>>
>> 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.
> 

That's a good point. I didn't want to change existing code, but this
looks prone to failure if the strings are not interned. There are more
instances of this in icedtea-web too. I will try and post a separate
patch to address this.

Cheers,
Omair