I hate that we have to do this but I guess there's not really any good choice. However, perhaps it would be better if we put the cast + call for each of these into a utility method? Helpers.clearBuffer(buffer) for example?

my understanding was that only those having a changed return are problematic - so this seems a bit much.
ByteBuffer#limit(int) has an issue but not ByteBuffer#limit() with an int return, same for position()

@kares My concern is having this cast + call pattern all over the place. We would end up having to document every one of these lines so nobody changes it back (most IDEs will show it as an unnecessary cast). If we move them into utility methods and call them that way, we only have to document it there.

And with an import static, "clearBuffer(buf)" is shorter than "((Buffer) buf).clear()" anyway.

FWIW, it's also easier for us when we start depending on Java 11 (maybe in 2020) because we can just have the IDE inline all calls to the method and eliminate the cast.

@ahorek Feel like revisiting these and making them call utility methods, perhaps in org.jruby.util.io.ChannelHelper?

ByteBuffer#limit(int) has an issue but not ByteBuffer#limit() with an int return, same for position()

@kares - the problem is ByteBuffer#limit is overloaded on java 9, but on java 8 this overloaded call-site doesn't exist.

Feel like revisiting these and making them call utility methods, perhaps in org.jruby.util.io.ChannelHelper

@headius - sounds good. I'll do that later today.

after some investigation I'll close this one if you don't mind

other methods like java.lang.Math.multiplyExact have the same problem and it'll be a big maintainance burden

it can be fixed by compiling the source in compatibility mode, otherwise the binary compatibility with older java versions isn't guaranteed
base.java.version and base.javac.version

https://stackoverflow.com/questions/51692748/java-compilation-source-target-and-release-supported-versions/51692749#51692749

@ahorek Actually that post is referring to just the Java code and bytecode resulting from compiling; source specifies the maximum level of Java features allowed and target specifies what minimum JVM the bytecode will work on. The fixes you were making were separate and would require always compiling against Java 8 classes, necessitating having two JDKs installed to build properly.

I think the cast+call fix is still valid but I will look at doing it with a utility method.

ok, reopened #5459