What I'm saying is that at the cost of some added complexity in the BindProcessor, we can (1) bind to subclasses and (2) support binding in untrusted code.
Greg Brown wrote: > 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.
