One could always go the awt route:
public interface CharSequence2 extends CharSequence {
...new methods here...
}
then change things to implement CharSequence2 instead, using covariance as
appropriate (thus at least somewhat avoiding the casting problem). At
least then the program would fail early :-)
- DML
On 10/17/2008 04:54 PM, Brian Duff wrote:
This doesn't just introduce a source incompatibility (requiring code to
be recompiled), it also introduces a binary incompatibility. If any
object receives a CharSequence instance that happened to have been
compiled against an older version of the platform, it will have no way
of knowing that this method does not exist on the object.
Java hasn't (to my knowledge) ever broken compatibility with an
interface in the platform API before. I consider that a great strength
of the platform.
Brian
On Oct 17, 2008, at 13:26, "Paulo Levi" <[EMAIL PROTECTED]> wrote:
Can't be changed? No user of the api is currently using getChars on a
Charsequence (because it doesn't exist!)
If you're talking about other implementers of Charsequence than the
jdk, well, i don't see why do we have to suffer ignominious interface
incompleteness just because someone doesn't want to compile the code
ever again.
And couldn't it be made to work anyway?
