JSF core TCK - non-javax classes allowed in api jar?

[Simon Kitching <sk...@apache.org>]

Hi All,

A thought just occurred to me.

The JSF core spec license (and TCK) require that we do not add any class
to the javax.faces namespace which is not in the spec. This is fair, as
doing so would confuse users and lead to unportable code. However this
limitation has caused some real pain, as we would *like* to have helper
methods shared across javax.faces classes which are not in the same package.

Our current solution for this is some very ugly "templating" in the
build tools, where we generate classes in the javax.faces packages so
that we can "paste" the same code into them.

But does anything in the spec or TCK actually say that the
"myfaces-api.jar" file cannot contain classes in the
"org.apache.myfaces" namespace, or that our implementations of
javax.faces classes (eg javax.faces.component.UIComponentBase) cannot
then call static methods on those classes or have instances of them as
private members?

Sun doesn't do that; simply looking at the classes within the
jsf-api.jar file shows that it contains nothing that is not in the
javax.faces namespace. But are we required to do the same? Adding such
classes doesn't seem to me to violate the spirit of JSF at all; the
point is to avoid tricking users into writing non-portable code, but we
wouldn't be doing that. And if you look at the standard java "rt.jar",
it contains lots of "com.sun" classes, and no-one claims that this
forces or deceives people into writing non-portable java.

Being able to add helper classes into the myfaces-api.jar file would
make life simpler in a lot of ways.

In fact, is there any reason why JSF needs to be split into two "api"
and "impl" jar files, rather than just one? Not that I'm suggesting
that; but it does seem possible.

Regards,
Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)

Re: JSF core TCK - non-javax classes allowed in api jar?

[Matthias Wessendorf <ma...@apache.org>]

On Wed, Nov 5, 2008 at 1:43 PM, Simon Kitching <sk...@apache.org> wrote:
> Matthias Wessendorf schrieb:
>> On Wed, Nov 5, 2008 at 10:55 AM, Simon Kitching <sk...@apache.org> wrote:
>>
>>> Hi All,
>>>
>>> A thought just occurred to me.
>>>
>>> The JSF core spec license (and TCK) require that we do not add any class
>>> to the javax.faces namespace which is not in the spec. This is fair, as
>>> doing so would confuse users and lead to unportable code. However this
>>> limitation has caused some real pain, as we would *like* to have helper
>>> methods shared across javax.faces classes which are not in the same package.
>>>
>>> Our current solution for this is some very ugly "templating" in the
>>> build tools, where we generate classes in the javax.faces packages so
>>> that we can "paste" the same code into them.
>>>
>>> But does anything in the spec or TCK actually say that the
>>> "myfaces-api.jar" file cannot contain classes in the
>>> "org.apache.myfaces" namespace, or that our implementations of
>>> javax.faces classes (eg javax.faces.component.UIComponentBase) cannot
>>> then call static methods on those classes or have instances of them as
>>> private members?
>>>
>>
>> hrm, I am not sure on this, but doubt it would be OK.
>> Leo acutally has the TCK, perhaps he just could try to
>> add things like that to see what the binary compatibility
>> hammer tells you.
>>
> Yep, it would be great if Leonardo would be willing to try this out some
> time...
>> That said, I think it would confuse users of the API JAR,
>> if they see stuff in there... that is not part of the spec...
>> they start to use it and have issues when they say
>> "good bye myfaces"... I am not really thrilled to add
>> those vendor locks...
>>
> I think that if anyone has this in their class:
>    import org.apache.myfaces.core._StateHolderHelper;
> then it should be reasonably obvious to them that they are using a
> non-portable feature...

yeah, but... I saw puking horses in front of a drugstore (German saying) :-)

>>
>>> Sun doesn't do that; simply looking at the classes within the
>>> jsf-api.jar file shows that it contains nothing that is not in the
>>> javax.faces namespace. But are we required to do the same? Adding such
>>> classes doesn't seem to me to violate the spirit of JSF at all; the
>>> point is to avoid tricking users into writing non-portable code, but we
>>> wouldn't be doing that. And if you look at the standard java "rt.jar",
>>> it contains lots of "com.sun" classes, and no-one claims that this
>>> forces or deceives people into writing non-portable java.
>>>
>>> Being able to add helper classes into the myfaces-api.jar file would
>>> make life simpler in a lot of ways.
>>>
>>> In fact, is there any reason why JSF needs to be split into two "api"
>>> and "impl" jar files, rather than just one? Not that I'm suggesting
>>> that; but it does seem possible.
>>>
>>
>> In a tool (JDeveloper, Eclipse, name it) you only want the API, since
>> that is specified. The impl is private and not intended for usage in
>> someones application. If we would mix api and impl into one jar...
>> we would expose the stuff from impl, which is mostly not desired
>> when one cares about writing jsf-based apps...
>>
>
> You are worried about auto-complete offering non-standard classes as
> possible completions?

the general presence of IMPL-based "APIs". A good designed application
shouldn't use IMPL exposed "APIs". Sometimes you need that (vanilla
JPA is not enough)
but than, in those rare cases... there is a good chance, that the devs
know why they used it.

>
> I agree that it would be a bad idea to include a class named
>    org.apache.myfaces.core.FacesContext
> in the myfaces-api.jar file. Some common-sense is needed. Maybe we could

yes, true :-)

> adopt the convention that all non-standard classes in the jar start with
> underscore or similar; that should prevent them popping up when not wanted.
>
> But I don't think that simply having org.apache.myfaces classes in the
> jar is going to confuse anyone that has more than two brain-cells. And
> it would make the implementation a *lot* easier to work on, with less
> "build magic" involved.

I am not convinced that it is a good idea - in terms of thinking about
(happy) users.
I agree on the impl implementation, though.

-M

>
> Regards, Simon
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Re: JSF core TCK - non-javax classes allowed in api jar?

[Simon Kitching <sk...@apache.org>]

Matthias Wessendorf schrieb:
> On Wed, Nov 5, 2008 at 10:55 AM, Simon Kitching <sk...@apache.org> wrote:
>   
>> Hi All,
>>
>> A thought just occurred to me.
>>
>> The JSF core spec license (and TCK) require that we do not add any class
>> to the javax.faces namespace which is not in the spec. This is fair, as
>> doing so would confuse users and lead to unportable code. However this
>> limitation has caused some real pain, as we would *like* to have helper
>> methods shared across javax.faces classes which are not in the same package.
>>
>> Our current solution for this is some very ugly "templating" in the
>> build tools, where we generate classes in the javax.faces packages so
>> that we can "paste" the same code into them.
>>
>> But does anything in the spec or TCK actually say that the
>> "myfaces-api.jar" file cannot contain classes in the
>> "org.apache.myfaces" namespace, or that our implementations of
>> javax.faces classes (eg javax.faces.component.UIComponentBase) cannot
>> then call static methods on those classes or have instances of them as
>> private members?
>>     
>
> hrm, I am not sure on this, but doubt it would be OK.
> Leo acutally has the TCK, perhaps he just could try to
> add things like that to see what the binary compatibility
> hammer tells you.
>   
Yep, it would be great if Leonardo would be willing to try this out some
time...
> That said, I think it would confuse users of the API JAR,
> if they see stuff in there... that is not part of the spec...
> they start to use it and have issues when they say
> "good bye myfaces"... I am not really thrilled to add
> those vendor locks...
>   
I think that if anyone has this in their class:
    import org.apache.myfaces.core._StateHolderHelper;
then it should be reasonably obvious to them that they are using a
non-portable feature...
>   
>> Sun doesn't do that; simply looking at the classes within the
>> jsf-api.jar file shows that it contains nothing that is not in the
>> javax.faces namespace. But are we required to do the same? Adding such
>> classes doesn't seem to me to violate the spirit of JSF at all; the
>> point is to avoid tricking users into writing non-portable code, but we
>> wouldn't be doing that. And if you look at the standard java "rt.jar",
>> it contains lots of "com.sun" classes, and no-one claims that this
>> forces or deceives people into writing non-portable java.
>>
>> Being able to add helper classes into the myfaces-api.jar file would
>> make life simpler in a lot of ways.
>>
>> In fact, is there any reason why JSF needs to be split into two "api"
>> and "impl" jar files, rather than just one? Not that I'm suggesting
>> that; but it does seem possible.
>>     
>
> In a tool (JDeveloper, Eclipse, name it) you only want the API, since
> that is specified. The impl is private and not intended for usage in
> someones application. If we would mix api and impl into one jar...
> we would expose the stuff from impl, which is mostly not desired
> when one cares about writing jsf-based apps...
>   

You are worried about auto-complete offering non-standard classes as
possible completions?

I agree that it would be a bad idea to include a class named
    org.apache.myfaces.core.FacesContext
in the myfaces-api.jar file. Some common-sense is needed. Maybe we could
adopt the convention that all non-standard classes in the jar start with
underscore or similar; that should prevent them popping up when not wanted.

But I don't think that simply having org.apache.myfaces classes in the
jar is going to confuse anyone that has more than two brain-cells. And
it would make the implementation a *lot* easier to work on, with less
"build magic" involved.

Regards, Simon

Re: JSF core TCK - non-javax classes allowed in api jar?

[Matthias Wessendorf <ma...@apache.org>]

On Wed, Nov 5, 2008 at 10:55 AM, Simon Kitching <sk...@apache.org> wrote:
> Hi All,
>
> A thought just occurred to me.
>
> The JSF core spec license (and TCK) require that we do not add any class
> to the javax.faces namespace which is not in the spec. This is fair, as
> doing so would confuse users and lead to unportable code. However this
> limitation has caused some real pain, as we would *like* to have helper
> methods shared across javax.faces classes which are not in the same package.
>
> Our current solution for this is some very ugly "templating" in the
> build tools, where we generate classes in the javax.faces packages so
> that we can "paste" the same code into them.
>
> But does anything in the spec or TCK actually say that the
> "myfaces-api.jar" file cannot contain classes in the
> "org.apache.myfaces" namespace, or that our implementations of
> javax.faces classes (eg javax.faces.component.UIComponentBase) cannot
> then call static methods on those classes or have instances of them as
> private members?

hrm, I am not sure on this, but doubt it would be OK.
Leo acutally has the TCK, perhaps he just could try to
add things like that to see what the binary compatibility
hammer tells you.

That said, I think it would confuse users of the API JAR,
if they see stuff in there... that is not part of the spec...
they start to use it and have issues when they say
"good bye myfaces"... I am not really thrilled to add
those vendor locks...

>
> Sun doesn't do that; simply looking at the classes within the
> jsf-api.jar file shows that it contains nothing that is not in the
> javax.faces namespace. But are we required to do the same? Adding such
> classes doesn't seem to me to violate the spirit of JSF at all; the
> point is to avoid tricking users into writing non-portable code, but we
> wouldn't be doing that. And if you look at the standard java "rt.jar",
> it contains lots of "com.sun" classes, and no-one claims that this
> forces or deceives people into writing non-portable java.
>
> Being able to add helper classes into the myfaces-api.jar file would
> make life simpler in a lot of ways.
>
> In fact, is there any reason why JSF needs to be split into two "api"
> and "impl" jar files, rather than just one? Not that I'm suggesting
> that; but it does seem possible.

In a tool (JDeveloper, Eclipse, name it) you only want the API, since
that is specified. The impl is private and not intended for usage in
someones application. If we would mix api and impl into one jar...
we would expose the stuff from impl, which is mostly not desired
when one cares about writing jsf-based apps...

>
> Regards,
> Simon

-M
>
> --
> -- Emails in "mixed" posting style will be ignored
> -- (http://en.wikipedia.org/wiki/Posting_style)
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf