Possibly. The bind processor populates a bind() overload in each
Bindable subclass that uses @Bind annotations. It is this method that
gives us access to the private members of a bound class. The processor
could still do this, even without a Bindable base class.
It's still a bit sketchy since it relies on undocumented javac
features, but we overlooked that before and could conceivably continue
to do so now. My question is - is it worth it? Does binding offer
sufficient value to justify reliance on undocumented compiler
features, plus the additional cost of maintaining the bind processor
code?
On Jun 9, 2009, at 10:15 AM, Noel Grandin wrote:
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.
