java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()

[ahorek]

Environment

java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

Actual behaviour

rvm get head

raises an error

    Installing rvm gem in 1 gemsetsUnhandled Java exception: java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;
           encode at org/jruby/RubyEncoding.java:306
     doEncodeUTF8 at org/jruby/RubyEncoding.java:197
   encodeBytelist at org/jruby/RubyString.java:6191
           <init> at org/jruby/RubyString.java:377
        newString at org/jruby/RubyString.java:468
        newString at org/jruby/Ruby.java:3563
  createFileClass at org/jruby/RubyFile.java:219
         initCore at org/jruby/Ruby.java:1547
        bootstrap at org/jruby/Ruby.java:1318
             init at org/jruby/Ruby.java:1217
      newInstance at org/jruby/Ruby.java:362
      internalRun at org/jruby/Main.java:273
              run at org/jruby/Main.java:234
             main at org/jruby/Main.java:206

the problem is that I have a jruby's binary that was compiled with java 9, but executed with java 8.

Expected behaviour

this should be a workaround
https://jira.mongodb.org/browse/JAVA-2559
https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyEncoding.java#L306

[kares]

should be easy to put up a PR ... mostly about: ((Buffer) buf).clear(); with a comment why its there.

[ahorek]

there's also a problem with java.lang.Math

irb(main):001:0> require 'date'
=> true
irb(main):002:0> DateTime.strptime('-1', '%s')
Traceback (most recent call last):
       16: from org.jruby.internal.runtime.methods.MixedModeIRMethod.call(MixedModeIRMethod.java:191)
       15: from org.jruby.internal.runtime.methods.MixedModeIRMethod.INTERPRET_METHOD(MixedModeIRMethod.java:204)
       14: from org.jruby.ir.interpreter.InterpreterEngine.interpret(InterpreterEngine.java:92)
       13: from org.jruby.ir.interpreter.StartupInterpreterEngine.interpret(StartupInterpreterEngine.java:72)
       12: from org.jruby.ir.interpreter.InterpreterEngine.processCall(InterpreterEngine.java:326)
       11: from org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:201)
       10: from org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:365)
        9: from org.jruby.ext.date.RubyDateTime$INVOKER$s$_strptime.call(RubyDateTime$INVOKER$s$_strptime.gen)
        8: from org.jruby.ext.date.RubyDateTime._strptime(RubyDateTime.java:480)
        7: from org.jruby.ext.date.RubyDate._strptime(RubyDate.java:1623)
        6: from org.jruby.ext.date.RubyDate.parse(RubyDate.java:1629)
        5: from org.jruby.util.RubyDateParser.parse(RubyDateParser.java:59)
        4: from org.jruby.util.StrptimeParser.parse(StrptimeParser.java:279)
        3: from org.jruby.util.StrptimeParser$StringParser.access$100(StrptimeParser.java:309)
        2: from org.jruby.util.StrptimeParser$StringParser.parse(StrptimeParser.java:535)
        1: from org.jruby.util.StrptimeParser$StringParser.readDigitsMax(StrptimeParser.java:696)
Java::JavaLang::NoSuchMethodError (java.lang.Math.multiplyExact(JI)J)

[headius]

Hmm that is harder to avoid ☹️ If we wrap this in another method we may interfere with the VM intrinsic used to optimize these methods.

These cases should be pretty limited, though...we can just cast everything to long in those few places.

I hope there aren't going to be too many more of these; we are not ready to start depending on Java 11. Maybe we need to look into the build using JDK8 runtime library.

[headius]

Ok I looked into the Java 9+ -release flag for javac, and it gets us halfway there. If you specify -release 8 it will only compile against Java 8 APIs, which should solve all these cases in one swoop. Unfortunately, it also does not expose unsupported APIs like all of sun.misc from which we get signal-handling and Unsafe classes. So this might be a dead end, unless we can eliminate all uses of sun.misc in our main codebase (might be able to move to another library).

[headius]

@enebo We might be able to get the -release 8 flag to work if we reincorporate mock libraries for Unsafe and the whole SignalHandler stuff in sun.misc.

[kares]

resolved by 62dc58b (and some previous commits actually)