Exception in thread "main" java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/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;
}

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 <source files>

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

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();
}