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.
