On 3/29/02 11:05 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Sat, 30 Mar 2002 02:48, Geir Magnusson Jr. wrote:
>> On 3/29/02 10:40 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
>>> On Sat, 30 Mar 2002 02:36, Danny Angus wrote:
>>>>> Now that you can (well, soon) legally implement JSR47's, you
>>>>> might was well
>>>>> support their interfaces and semantics, and then 'embrace and
>>>>> extend'.  Just
>>>>> do the JSR47 stuff better :)
>>>> 
>>>> Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
>>>> about all this..)
>>> 
>>> Not really and nor could you "embrace and extend". Soon we will be
>>> allowed access to the TCKs (fingers crossed) which means we can implment
>>> the spec legally. However there has not been any change to any of the
>>> licenses regarding the specification materials which means it is still a
>>> violation of the license if you were to try and "corrupt" a spec or
>>> "embrace and extend" a spec by poorly-implementing it (and failing the
>>> TCK). However now we can at least implement the spec(s).
>> 
>> I can't believe that's true.
>> 
>> I can't see how they can prevent you from extending.  I mean, every J2EE
>> implementation 'embraces and extends' the J2EE spec because the specs leave
>> out a lot.  For example, you can't make a really useful JMS broker until
>> you add proprietary extensions for clustering, load balancing, etc...
>> Anyone that includes any functioning taglibs with a servlet container / jsp
>> implementation is extending the spec as there are no useful tags in the
>> spec.
>> 
>> I can't see how anyone can complain if you pass the TCK.
> 
> Passing the TCK - thats the trick. Given that most (all?) TCKs require that
> the public interface conform exactly to that which is specified and that
> JSR47 is not made up of interfaces but instead made up of classes it would be
> difficult to pass the TCK if you added anything to it.

Of course you would want to implement the API exactly....

> You could create new
> output targets/appenders/whatever but they could not be in the java.**
> namespace. 

True.  But you would still be able to offer a better implementation, and
offer extensions if you desired.
 
> JSR47 should not be considered in the same category as the servlet/JMS/ejb
> specs - more in the same category as the Collection API.

That's true but irrelevant - if the JSR47 leaves out features that people
deem necessary, there is no reason why those can't be added as a 'vendor
extension', unless the JSR is so broken you can't extend it w/o violating
the API. (Like hardcoding the possible output targets choices as methods
into the API...)

-- 
Geir Magnusson Jr.                                     [EMAIL PROTECTED]
System and Software Consulting

The cost of synchronization is much less that the cost of stupidity.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to