pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: [DISCUSS] WTKX binding
Date Tue, 09 Jun 2009 13:47:00 GMT
Bound member variables may be private, and reflection code isn't  
allowed to set them in an unsigned applet. The bind processor rewrites  
the code at compile and inserts methods into the Bindable subclasses  
that can see the private members. So, we need Bindable to support  
binding in untrusted code. I'm suggesting that we get rid of it  
because we can't use it to meet a common use case (binding to Window  
subclasses), and it relies on undocumented features of javac. Also,  
the code itself is non-trivial.

Although we couldn't use it in untrusted code, the reflection code  
would still work fine, which is why I suggested that we might want to  
keep it. However, it doesn't really save the developer that much work,  
so we could just as easily eliminate it.


On Jun 9, 2009, at 9:34 AM, Noel Grandin wrote:

> Why exactly do we need that?
>
> It seems to me that it should be possible to create a AppletBindable
> interface,
> and for the BindProcessor to add that interface to the relevant  
> classes,
> and inject some code (as it does currently).
>
> Am I missing something?
>
> Greg Brown wrote:
>> We actually do need a Bindable base class in order to support binding
>> in untrusted code. However, if we decide to drop support for that, we
>> could move the bind() method to WTKXSerializer and eliminate  
>> Bindable.
>> Is that consistent with what you are suggesting?
>>
>> On Jun 9, 2009, at 2:36 AM, Noel Grandin wrote:
>>
>>> Hi
>>>
>>> How about
>>> (3) Drop Bindable as a class altogether, and make the binding  
>>> process
>>> work without it.
>>> I don't see that class really need to implement it anyhow.
>>> Either that or make it an interface, and make the necessary classes
>>> implement it.
>>>
>>> Regards, Noel.
>


Mime
View raw message