[prev in list] [next in list] [prev in thread] [next in thread] 

List:       taglibs-user
Subject:    Re: Serialising javax.servlet.jsp.jstl.sql.ResultImpl
From:       Pierre Delisle <Pierre.Delisle () Sun ! COM>
Date:       2003-12-17 16:20:40
[Download RAW message or body]

I checked with the gurus, and the conclusion is as expected:
while having ResultImpl implement interface Serializable exposes a 
portability issue, it shouldn't be a spec violation.

I therefore suggest we fix ResultImpl to implement interface Serializable,
and insert a comment in the Release Notes stating that relying on the
serializability of Result objects might not be portable across
different implementations of the JSTL spec.

Please let me know if there is any other related issue.

    -- Pierre

[Shawn, thanks for dropping the law books a few minutes to 
come help us out :-)]



Shawn Bayern wrote:

> On Tue, 16 Dec 2003, Kris Schneider wrote:
> 
> 
>>Thanks for looking into it. To be honest, I'm surprised it took this
>>long to surface ;-). As for whether Result should actually extend
>>Serializable, I'm usually of the mind that an interface shouldn't extend
>>Serializable and that it's an "implementation detail". Consider the core
>>collection interfaces and classes: neither Map nor SortedMap extend
>>Serializable and AbstractMap doesn't implement it. TreeMap, however,
>>does implement it. Another example would be the ResultSet and RowSet
>>interfaces, neither of which extend Serializable.
> 
> 
> The important distinction here isn't between "interface" and
> "implementation" but between "specification" and "implementation."
> Regardless whether an interface should typically be extended by an
> interface or implemented by a class (which I'll address in a moment),
> Pierre's concern here is that the enhancement request shouldn't be
> addressed by an implementation of the JSTL specification on its own.
> 
> While I don't think it would strictly violate the JSTL specification for a
> JSTL implementation to have one of its classes (which implements a
> specified interface) implement another arbitrary interface, it would
> certainly be poor practice for users to rely on this nonstandard behavior
> (and thus probably irresponsible for an implementation to promote it).
> 
> As for the specific point about whether interfaces should extend or
> implementations should implement, I don't think the analogies you raise
> are apposite:  Map indeed doesn't extend Serializable, but this is only
> because there's no call for all implementations of Map to be Serializable.
> The JSTL specification could conceivable require that all implementations
> of a standard interface also implement Serializable, but the most elegant
> way for it to accomplish this is to have the standard interface extend
> Serializable itself.  Indeed, this approach is very common:  note the
> number of subinterfaces to Serializable (i.e., the number of interfaces
> that extend Serializable) in the J2SDK 1.4 API.
> 
> Shawn
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-user-help@jakarta.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]