Hi,
Simon Kitching napsal(a):
---- Martin Marinschek <[EMAIL PROTECTED]> schrieb:
Hi Simon,
And this approach is not possible for uicomponent classes defined in the
standard as these have defined hierarchies that cannot be modified.
does this stem from actually trying it out? I tried it in the project
I am currently working on, and it worked. I need to admit I did not
check the Java-language specification.
You're quite right, it does work! I had just assumed that creating a public
subclass of a package-scope class would not work. I have updated the wiki.
But all my tests show it functions fine. A public subclass inherits any public
or protected members that the package-private class defines. Subclasses of it
can be declared in other packages, and instances of it can be created and
invoked. The only thing that cannot be done is to cast it to its parent type.
This could lead to few problems:
1. deeper class tree can't use common parent to use it's methods
(instanceof check-based)
2. deeper class in tree would then inherit just "dumb" methods generated
or else we got in deadly circle again - dumb > concrete (component
A)>dumb>concrete class (component B). That would make IDEs complaining
again w/o checking in generated stuff.
Interestingly, generating the normal javadoc doesn't show any trace of the
package-scoped parent at all; anything public/protected the child inherits from
its parent is just listed as if it were defined by the child itself.
This is all exactly what we would want; the parent class is effectively
invisible except in one case: when calling Child.class.getSuperclass(). Then, a
Class instance for the package-scoped parent is returned. Well, I guess
stack-traces will show it too.
There is still the question of whether the TCK would pass if classes in
javax.faces had package-scoped parents that are not defined in the spec. Is
there someone here that can check that? If that is allowable, then this
base-class approach becomes much more interesting...
I don't think it would ever past TCK - if TCK fails even with protected
methods in classes, having more generic acces class in package should
definately fail.
Regards,
Zdenek
Regards, Simon
