Recent reports in gitter about issues related to desugaring not working in case of subclasses of ByteBuffer. In particular DirectByteBuffer. Issue caused in not proper VTable for subclass in particular, methods injected into ByteBuffer during desugaring were not available in subclass. This caused wrong method to be invoked (like DirectByteBuffer.load() instead of ByteBuffer.clear()). The reason of this is the way how VTable is build: soot classes are used as source for methods. But these don't include injected/synthetic method (especially if class was build in previous session). Reworking VTable to use classinfo instead of soot class is possible but already looks as overcomplicated thing if comparing to override methods.
The fix
RoboVM's runtime ByteBuffer class was extended with API from Java9, no need in desugaring in this case:
public ByteBuffer flip()
public ByteBuffer clear()
public ByteBuffer mark()
public ByteBuffer reset()
public ByteBuffer rewind()
public ByteBuffer position(int newPosition)
public ByteBuffer limit(int newLimit)
Reason for removal
Recent reports in gitter about issues related to desugaring not working in case of subclasses of ByteBuffer. In particular
DirectByteBuffer
. Issue caused in not proper VTable for subclass in particular, methods injected into ByteBuffer during desugaring were not available in subclass. This caused wrong method to be invoked (likeDirectByteBuffer.load()
instead ofByteBuffer.clear()
). The reason of this is the way how VTable is build: soot classes are used as source for methods. But these don't include injected/synthetic method (especially if class was build in previous session). ReworkingVTable
to useclassinfo
instead of soot class is possible but already looks as overcomplicated thing if comparing to override methods.The fix
RoboVM's runtime
ByteBuffer
class was extended with API from Java9, no need in desugaring in this case:Update 6th July
Added covariant Api to following classes