FileChannel incompatibility introduced between 6 and 7 (and possible compiler bug)
David M. Lloyd
david.lloyd at redhat.com
Thu Jul 26 11:44:11 PDT 2012
Ran into a pretty ugly little issue just now. My NIO framework has a
FileChannel subclass that it uses for certain tasks. This works fine on
7, but on 6 I get errors like this:
I found this odd, initially, because I never reference this interface.
I noticed that in 7 this interface was introduced and (sensibly)
retroactively added as a superinterface of FileChannel. Logically this
seems like it should not be a problem; it just means that in 7 we should
have a couple new bridge methods on FileChannel (and we do):
public java.nio.channels.SeekableByteChannel truncate(long) throws
2: invokevirtual #95 // Method
public java.nio.channels.SeekableByteChannel position(long) throws
2: invokevirtual #94 // Method
Note the invokevirtual, which is specifically relevant here.
These methods are obviously necessary as FileChannel covariantly
overrides the new interface methods. However, the trouble started when
I compiled my subclass and noticed, to my surprise, the very same bridge
methods are on it! Thus there's a static linkage from my class directly
to SeekableByteChannel, despite there being no reference to it in the
source code at all.
Now what bugs me about this is that if my class did not have these
bridge methods, it would still work just fine, since the superclass is
using invokevirtual to access the covariantly overridden method! I
could understand this behavior if it were using invokespecial, but it's
not, or if I were actually directly implementing SeekableByteChannel on
my class, which I'm not; the end result is what appears to be a needless
break in compatibility.
Now I do have some options available - I can make mocks of the Java 7
classes I need to compile against, and then compile against 6, or I can
add a build-time step to strip these methods from the class. But this
strikes me as being a somewhat serious, if highly specific, problem. Is
this a compiler bug, or is it an irreparable backwards-compatibility
mistake in NIO?
More information about the nio-dev