myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott O'Bryan <>
Subject Re: [trinidad] cleanup
Date Wed, 05 Oct 2011 13:18:19 GMT
Yeah, I'm not sure we know what third parties might depend on.  I can 
tell you, for instance, which deprications, for instance,  ADFFaces 
depends on.  I can even remove those dependencies.  But the nature of 
Trinidad and client's like ADFFaces is that the Trinidad implementations 
are exposed to end-users.

Further, we've marked things as depricated if there is other 
functionality in JSF2 which replaces it.  There have been some 
refactorings of API's which might provide "safer", "faster", or "more 
correct" implementations of certain functionality.  That's not to say 
the old functions are wrong or that existing applications which use them 
cannot get away with using the old API's, it just means they SHOULD use 
the new implementations if they want to be "clean" and fully correct.

I use the Java Date object as an example.  It's an utterly ridiculous 
class, admittedly, but it works and is there for backward 
compatibility.  There are much more "correct" implementations which 
address more issues such as different calendars and localization, but 
that does not make the date object.. "wrong".  Trinidad has, in the 
past, removed or changed API's that just plain didn't work, but I'm not 
sure that's what we're talking about here.  And certainly, I'm cool with 
removing the deprecated stuff from impl since nobody should be depending 
on it anyway.  My concern is for end users of Trinidad and ADFFaces who 
may not have a voice or resources to monitor changes of this sort in the 
Trinidad developer community.

I don't know, what do other people think?  This is one of those things 
where I think the more voices the better.


On 10/05/2011 06:46 AM, Mark Struberg wrote:
> My intention is not to break something, and I was ONLY talking about the JSF-2 version
of Trinidad.
> If there is code which just makes no sense at all in JSF-2, then we should in MY opinion
kill this code.
> If it doesn't make sense for Trinidad, then it is highly likely that it also don't make
sense for ADF anymore, right?
> IF some parts are still needed by some known 3rd party libs, then those parts can of
course remain.
> But at the end of the day maintaining Trinidad will become more and more problematic
if we don't get rid of long time obsolete stuff.
> Again: only my personal opinion and experience.
> I assume that ADF also has a JSF-1 and a separate JSF-2 branch. All the JSF-1 stuff would
of course remain the way it is currently!
> LieGrue,
> strub
> ----- Original Message -----
>> From: Scott O'Bryan<>
>> To:
>> Cc:
>> Sent: Wednesday, October 5, 2011 2:20 PM
>> Subject: Re: [trinidad] cleanup
>> We could, yes.  But we would force people to migrate apps which, perhaps
>> is not a bad thing but traditionally we've taken a full vote before
>> changing/removing API's in Trinidad because, doing so, incurs additional
>> cost on the other frameworks which are using Trinidad as a foundation.
>> Any company which provides Trinidad as a foundation for other framework
>> code (like Oracle's ADFFaces) benefits from NOT breaking users of the
>> framework every release and, frankly, I see a lot of value in keeping
>> them around 'if possible'.
>> Like I say, I'm not opposed to it, but I suppose I take more of a Java
>> ZEN approach to deprecation of API's.
>> Scott
>> On 10/05/2011 05:41 AM, Mark Struberg wrote:
>>>   I'm not sure if I understand this correctly.
>>>   Trinidad-2 is for JSF-2 upwards exclusively, isn't?
>>>   If so, then we can easily get rid of all the old dust which just confuses
>> people.
>>>   Furthermore there seems to be a few compat problems with JSF-2 f:ajax which
>> can only be resolved by carefully cleaning those areas up.
>>>   Just leave behind the old stuff.
>>>   LieGrue,
>>>   strub
>>>>   ________________________________
>>>>   From: Scott O'Bryan<>
>>>>   To: MyFaces Development<>
>>>>   Sent: Wednesday, October 5, 2011 1:06 PM
>>>>   Subject: Re: [trinidad] cleanup
>>>>   Well just because something is depth aged doesn't mean we can
>> remove it.  It just means that an alternate means is suggested or something may
>> not work exactly as expected if used.
>>>>   A Prime example is ExternalContextUtils.  That guy has been around
>> since JSF 1.1.  It contains lots of functionality that wasn't present in
>> later versions of JSF, but now is.  Use of the native objects should be
>> encouraged, but there is also something to be said about older code being able
>> to migrate easier to a later release.
>>>>   Now I DO agree with removing the JSDoc and possibly the deprecations in
>> the impl, but I think it's important to keep any deprecations in the API for
>> backward compatibility.
>>>>   Sent from my iPhone
>>>>   On Oct 5, 2011, at 4:32 AM, Gerhard
>> Petracek<>   wrote:
>>>>   both - there are just two possibilities: those parts are really
>> deprecated and we remove them (and refactor the rest) or we can't remove
>> them and the information (annotation and/or javadoc) isn't correct.
>>>>>   regards,
>>>>>   gerhard
>>>>>   Your JSF powerhouse -
>>>>>   JSF Consulting, Development and
>>>>>   Courses in English and German
>>>>>   Professional Support for Apache MyFaces
>>>>>   2011/10/5 Scott O'Bryan<>
>>>>>   Gerhard, by deprivation hints, I'm assuming you mean the
>> javadoc deprecations and not the annotations, right?
>>>>>>   Sent from my iPhone
>>>>>>   On Oct 5, 2011, at 3:09 AM, Gerhard
>> Petracek<>   wrote:
>>>>>>   hi @ all,
>>>>>>>   there are still over 400 deprecations (via @Deprecated) and
>> nearly 400 via javadoc (not all of them overlap).
>>>>>>>   a lot of them are in for a long time and some of them were
>> deprecated even before [1].
>>>>>>>   however, some parts are still used and can't be
>> removed.
>>>>>>>   imo we should do a cleanup or remove the deprecation hints.
>>>>>>>   regards,
>>>>>>>   gerhard
>>>>>>>   [1]
>>>>>>>   Your JSF powerhouse -
>>>>>>>   JSF Consulting, Development and
>>>>>>>   Courses in English and German
>>>>>>>   Professional Support for Apache MyFaces

View raw message