On 2015-01-30, Gary Gregory wrote:
> On Fri, Jan 30, 2015 at 6:06 AM, Stefan Bodewig <bode...@apache.org> wrote:
>> The superclass of ZCompressorInputStream has changed from one we've
>> removed with the old __internal__ package to a new one in the now
>> supported lzw package.
> Well, we cannot break BC in a minor release for a public class. Are
> we sure BC breaks?
Well, not as much as my intuition had told me:
public static void main(String[] args) throws Exception {
try (InputStream in = new FileInputStream(args[0]);
OutputStream out = new FileOutputStream(args[1]);
ZCompressorInputStream zin = new ZCompressorInputStream(in) {
@Override
public void close() throws IOException {
System.err.println("closing with code size " + codeSize);
setClearCode(12);
super.close();
}
}) {
IOUtils.copy(zin, out);
}
}
accesses a protected field and a protected method of
InternalLZWInputStream when compiled against 1.9, a class that is no
longer there in 1.10. When run against trunk (without recompiling) it
still works. This is in line with something I once read up in the JLS
(oh my, nine years ago, time flies)[1]. The compiler says "call the
protected setClearCode method taking an int arg" and at runtime it
starts searching for that method with the most derived class. So
changing superclasses doesn't seem to affect things.
Of course we will break someting like
InternalLZWInputStream s = new ZCompressorInputStream(in)
but then again you'd have used a class that we had explicitly marked as
internal.
Unless anybody comes up with a case where the change in superclass
causes a problem, I'd say we are fine.
Stefan
[1]
http://stefan.samaflost.de/blog/en/dotNet/difference_between_java_and_csharp.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
