RFC: fix problems in jforex charts

[Pavel Tisnovsky]

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

Yeah you are right. In fact it is *sometimes* possible to compare two String references, but
only in cases when both Strings are surely on constant pool on the same JVM. And even in this
cases using String.equals() is not much slower than == because equality operator is used as the
first command in String.equals():

    public boolean equals(Object anObject) {
        if (this == anObject) {
            return true;
        }
...

So in many cases (99%?) using of == or != co compare Strings can be seen as premature
optimization which is - as an IT classic DK said - the root of all evil :-)

Pavel

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