That's true. I only added the code snippet for clarification.
Whether or not this will be picked up in a more generic way doesn't
matter that much to me.
But before "overdesiging" this, it might be useful to think of other
use cases besides the one in the original issue. It would not be the
first "too generic" API in Java.
With only one use case (the one posted), I think a simple utility
class will probably work fine.
Ps. When declared final, backwards compatibility will also be no issue AFAICS.
/Jan-Kees
2009/11/4 Ed Burns <Ed.Burns_at_sun.com>:
>>>>>> On Tue, 03 Nov 2009 16:29:22 +0100, Matthias Wessendorf <matzew_at_apache.org> said:
>
> MW> On Tue, Nov 3, 2009 at 4:24 PM, Ed Burns <Ed.Burns_at_sun.com> wrote:
>>>>>>>> On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf <matzew_at_apache.org> said:
>>>
> MW> Hi Jan-Kees,
> MW> thanks for creating this ticket. I'd like to see something like this.
> MW> Sounds (to me) very useful...
>>>
>>> Note that there is a precedent for doing this kind of discovery without
>>> requiring a Java language signature: the way properties are conveyed to
>>> the standard XML parsers in Java. I would rather avoid introducing a
>>> signature for this because it needs to be very fluid over time.
>
> MW> fair enough, so let's keep it to be part of the implementation.
> MW> In myfaces we have several non public classes, big issue here
> MW> (in this particular) case is that we actually have to duplicate the
> MW> code. Oh well :-)
>
> I'm not saying we can't have an API, I'm just saying that the API
> doesn't have to be encoded using Java language signatures such as an
> interface. This is a broader question of allowing the JSF runtime to
> expose metadata, such as configuration and capabilities. There is lots
> of prior art on how to do this without using Java language signatures.
>
> Ed
>
> --
> | ed.burns_at_sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>