commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [digester] update Rule classes using deprecated methods?
Date Sun, 04 Apr 2004 17:46:39 GMT
On 4 Apr 2004, at 18:02, Craig McClanahan wrote:

> robert burrell donkin wrote:
>
>> from my reading of the java specification, moving methods upwards in 
>> the inheritance hierarchy is backwards compatible (in binary terms). 
>> (hopefully someone will correct me if i've made a mistake.)
>>
> It's "recompile compatible" (i.e. it works if you recompile the 
> calling program against the new classes, but not "binary compatible".  
> I'm not sure I would sweat it on this particular point (as long we we 
> made people aware of the requirement in release notes), but your 
> second issue is more important.

<ot>
interesting. here's the section (in the 2.0 language specification):

"... here is a list of some important binary compatible changes that 
the Java programming language supports:

...
Moving a method upwards in the class hierarchy"

i had taken this as meaning that an implementation in a subclass can be 
removed so long as the superclass provides an implementation for that 
method.
</ot>

>> it's possible that there are some cases of symantic incompatibility 
>> for user subclasses (overriding the deprecated methods that will 
>> never be called if the rule implementations are changed). since the 
>> methods have been deprecated for a long time now (digester 1.4, i 
>> think), for me, this isn't such an issue (as it once was) provided 
>> that it was strongly highlighted in the release documents.
>>
> If we were to stop calling the deprecated versions, we've definitely 
> changed the semantics.  It would essentially have the same semantic 
> effect as actually removing the methods, so I think we should continue 
> to call them until a 2.x series of Digester builds.
>
> Maybe it's time to consolidate what we've learned from the 1.x 
> versions of both beanutils and digester into more streamlined APIs, 
> and start down that path?

+0 (for digester, beanutils needs more thought)

i think that maybe the time is right for digester 2 and i'd be very 
happy to see people starting work on it.

personally speaking, though, i do have a small number of improvements 
that i'd like to see to the original digester in particular supporting 
processing instructions and better resolution of relative entities. 
this would (for me) bring digester to a state where the application was 
(in some ways) a completion of the original design. i like the idea of 
leaving digester in a complete-but-design-limited state. (this 
shouldn't impede any push for a new digester.)

but to be honest i probably don't have the energy required to push 
something like digester 2 through right now. a lot would depend on 
whether others were willing to step up.

- robert


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


Mime
View raw message