Exception in thread “main” java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteB...

Exception in thread “main” java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer

从JDK9开始，ByteBuffer的flip() clear()函数实现发生了变化，如果你在高版本JDK上打包后放在低版本JRE环境上使用，会出现java.lang.NoSuchMethodError:java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer或者java.lang.NoSuchMethodError:java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer。是因为高版本环境中的同名函数的返回值类型变了，这导致高版本环境下生成的字节码在低版本JVM中找不到对应的函数签名。解决方法有三种，见以下原文。

---

I have a method as of below which has been running properly for a long time:

private String loadFromFile(){

    RandomAccessFile inFile = null;
    FileChannel inChannel = null;
    StringBuilder sb = new StringBuilder();
    try {

        inFile = new RandomAccessFile(this.latestImageFile, "r");
        inChannel = inFile.getChannel();

        ByteBuffer bb = ByteBuffer.allocate(2046);
        while( inChannel.read(bb) != -1){
            bb.flip();

            while(bb.hasRemaining()){
                char c = (char) bb.get();   // read character at current position and set the pointer to current position + 1
                sb.append(c);
            }

            bb.clear();
        }

    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        if (inChannel != null) try {inChannel.close(); } catch (IOException e){}
        if (inFile != null ) try { inFile.close(); } catch (IOException e) {}
    }

    return sb.toString();
}

However, today after I have compiled and run the program on a server, below exception was logged when starting the program. It shows a flip() method is not found:

Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
        at com.rt.stream.s.exch.OBWorker.loadFromFile(OBWorker.java:271)
        at com.rt.stream.s.exch.OBWorker.initAndLoadOBs(OBWorker.java:184)
        at com.rt.stream.s.exch.OBWorker.(OBWorker.java:145)
        at com.rt.stream.s.exch.OBWorkerMgr.initFromProperties(OBWorkerMgr.java:217)
        at com.rt.stream.s.exch.OBWorkerMgr.init(OBWorkerMgr.java:132)
        at com.rt.stream.s.exch.OBWorkerMgr.main(OBWorkerMgr.java:511)

Anybody has any idea on it please?

The program running environment specification is like this:

Server:

1. openjdk version "1.8.0_242"

Development:

1. IDE: Version: 2019-09 R (4.13.0)
2. JDK: jdk-11.0.1
3. maven: apache-maven-3.3.3 (with below configuration applied)

   1.8   
   1.8

java java-8 java-11 bytebuffer

---

After searching for a while and verified through switching the installed JDK between 8 and 11, I have found that there are some changes (new overridden methods) applied to several methods (e.g. flip(), clear() ) in ByteBuffer class.

In Java 8, while calling flip() method of ByteBuffer class, since it has no implementation for this method, so it is actually calling the method from extended class, Buffer; which is returning Buffer object as below:

In Buffer class:

public final Buffer flip() {
    limit = position;
    position = 0;
    mark = -1;
    return this;
}

However, in Java 11, ByteBuffer class has implemented its own flip() method, and the returning object is changed from Buffer to ByteBuffer (This change should be started from Java 9):

In ByteBuffer class:

ByteBuffer flip() {
    super.flip();
    return this;
}

Since I'm using JDK 11 (higher JDK version) to compile the program for running on Java 8, the mentioned exception would occasionally encountered accordingly to javadoc:

By default, however, javac compiles against the most-recent version of the platform APIs. The compiled program can therefore accidentally use APIs only available in the current version of the platform. Such programs cannot run on older versions of the platform, regardless of the values passed to the -source and -target options. This is a long-term usability pain point, since users expect that by using these options they'll get class files that can run on the the platform version specified by -target.

The statement could be referenced here: http://openjdk.java.net/jeps/247

---

So, for resolving this kind of problems, the are 2 ways to do so:

Approach 1

One can handle in the duration of compilation, by making use of a newly introduced command-line option:

i.e.
javac --release N 

which is equals to:
for N < 9: -source N -target N -bootclasspath ,  
for N >= 9: -source N -target N --system .  

Approach 2

Or we can handle it in codes, as precaution methods, by explicitly casting the ByteByffer as Buffer before calling corresponding methods:

((Buffer) bb).flip();

which in order to force it calling extended class's method (in case the compilation process hasn't taken the new command-line options into consideration):

private String loadFromFile(){
    
    RandomAccessFile inFile = null;
    FileChannel inChannel = null;
    StringBuilder sb = new StringBuilder();
    try {

        inFile = new RandomAccessFile(this.latestImageFile, "r");
        inChannel = inFile.getChannel();
        
        ByteBuffer bb = ByteBuffer.allocate(2046);
        while( inChannel.read(bb) != -1){
            ((Buffer)bb).flip(); // explicitly casting
            
            while(bb.hasRemaining()){
                char c = (char) bb.get();
                sb.append(c);
            }
            
            ((Buffer) bb).clear(); // explicitly casting
        }
        
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        if (inChannel != null) try {inChannel.close(); } catch (IOException e){}
        if (inFile != null ) try { inFile.close(); } catch (IOException e) {}
    }
    
    return sb.toString();
}

Approach 3

Develop with the same jdk which is used for execution.