Default method returns true for a while, and then returns false? (Possible JVM bug)

Question

I have an issue with the following code, which I isolated to the most closed form, I am using Java 8, which is almost ready for launch (18 March 2014), so I expect no serious issues in the implementation itself, so it may/must be my own code:

Note: The code is written in Java 8, which has all kinds of new features, including default method implementation in interfaces.

public abstract class Drawable implements DrawableInterface {    

}

---

interface DrawableInterface {
    default public boolean isShadowReceiver() {
        return false;
    }

    default public boolean isShadowCaster() {
        return false;
    }
}

---

public interface ShadowDrawable extends DrawableInterface {
    @Override
    default public boolean isShadowReceiver() {
        return true;
    }

    @Override
    default public boolean isShadowCaster() {
        return true;
    }
}

---

public class Box extends Drawable implements ShadowDrawable {

}

---

public class IsolatedBug {
    private final Box box;

    private final List<Drawable> drawables;

    public IsolatedBug() {
        this.box = new Box();
        this.drawables = new ArrayList<>();

        drawables.add(box);
        drawables.forEach(drawable -> System.out.println(drawable + " C=" + drawable.isShadowCaster() + "/R=" + drawable.isShadowReceiver()));
    }

    private void init() throws InterruptedException {
        while (true) {
            drawables.forEach(drawable -> System.out.println(drawable + " C=" + drawable.isShadowCaster() + "/R=" + drawable.isShadowReceiver()));
            Thread.sleep(100);
        }
    }

    public static void main(String[] args) throws InterruptedException {
        new IsolatedBug().init();
    }
}

The code in itself may not make most sense, but that is because I have stripped a load of other irrelevant methods.

However, when you observe the output, you see something strange, at a certain point, for me personally after 30 seconds, I see the following:

isolatedbug.Box@5acf9800 C=true/R=true
isolatedbug.Box@5acf9800 C=true/R=true
isolatedbug.Box@5acf9800 C=true/R=true
isolatedbug.Box@5acf9800 C=true/R=true
isolatedbug.Box@5acf9800 C=false/R=false
isolatedbug.Box@5acf9800 C=false/R=false
isolatedbug.Box@5acf9800 C=false/R=false
isolatedbug.Box@5acf9800 C=false/R=false
isolatedbug.Box@5acf9800 C=false/R=false
isolatedbug.Box@5acf9800 C=false/R=false

The time when it switches from true to false , seems to depend on the number of calls the method, as with longer sleeps in between, it takes longer to switch.

I am running this, for full information on Windows 8 64-bit, with as java -version :

java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b129)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode)

Can anyone explain to me what is going on?
I'd also appreciate if others with Java 8 -any build-, could run and see if they have the same issue.

Some more information after using this code:

  Properties p = System.getProperties();
  p.list(System.out);

Output:

-- listing properties --
java.runtime.name=Java(TM) SE Runtime Environment
sun.boot.library.path=C:\Program Files\Java\jdk1.8.0\jre\bin
java.vm.version=25.0-b69
java.vm.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
path.separator=;
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
file.encoding.pkg=sun.io
user.script=
user.country=NL
sun.java.launcher=SUN_STANDARD
sun.os.patch.level=
java.vm.specification.name=Java Virtual Machine Specification
user.dir=C:\Users\Frank\Dropbox\NetbeansProjec...
java.runtime.version=1.8.0-b129
java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
java.endorsed.dirs=C:\Program Files\Java\jdk1.8.0\jre\li...
os.arch=amd64
java.io.tmpdir=C:\Users\Frank\AppData\Local\Temp\
line.separator=

java.vm.specification.vendor=Oracle Corporation
user.variant=
os.name=Windows 8.1
sun.jnu.encoding=Cp1252
java.library.path=C:\Program Files\Java\jdk1.8.0\bin;C:...
java.specification.name=Java Platform API Specification
java.class.version=52.0
sun.management.compiler=HotSpot 64-Bit Tiered Compilers
os.version=6.3
user.home=C:\Users\Frank
user.timezone=
java.awt.printerjob=sun.awt.windows.WPrinterJob
file.encoding=UTF-8
java.specification.version=1.8
user.name=Beheerder
java.class.path=C:\Users\Frank\Dropbox\NetbeansProjec...
java.vm.specification.version=1.8
sun.arch.data.model=64
java.home=C:\Program Files\Java\jdk1.8.0\jre
sun.java.command=isolatedbug.IsolatedBug
java.specification.vendor=Oracle Corporation
user.language=nl
awt.toolkit=sun.awt.windows.WToolkit
java.vm.info=mixed mode
java.version=1.8.0
java.ext.dirs=C:\Program Files\Java\jdk1.8.0\jre\li...
sun.boot.class.path=C:\Program Files\Java\jdk1.8.0\jre\li...
java.vendor=Oracle Corporation
file.separator=\
java.vendor.url.bug=http://bugreport.sun.com/bugreport/
sun.cpu.endian=little
sun.io.unicode.encoding=UnicodeLittle
sun.desktop=windows
sun.cpu.isalist=amd64

I have also checked the -Xint VM option, when this has been used, it returns true as expected.

So the conclusion seems to be that in my particular use case, the interpreted and JIT compiled/inlined variants of the code are not the same and hence it is a possibility that after the interpreted code is compiled it switches from interpreted to compiled and thus clarifying the switch in output.

Adding the -Xint option to the actual program in which the bug occured, has also fixed the issue there.

The official bug report has been accepted: JIRA Bug JDK-8036100

Answer 1

This is a known bug in Java8.

See this Jira: CHA ignores default methods during analysis leading to incorrect code generation

This blog entry is enlightening ....

Update / Summary:

• issue identified before b127, and fixed in b127 ( JDK-8031695 )
• issue reappeared (or a similar issue appeared) in b129 ( JDK-8036100 )
• issue has been 'worked around' ( disable the optimization that was failing ) in b132 ( available here )
• issue also logged for a 'proper' fix for later ( JDK-8036153 )

---

Previous Notes

I have reproduced this issue with:

Claims that this issue is resolved in b127 are confusing since I see it clearly in b129 (unless I am confused about the JVM version conventions...)

 C:\\Java8\\jdk-1.8.0_01\\bin>java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b129) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode) C:\\Java8\\jdk-1.8.0_01\\bin> 

Adding System.out.println(System.getProperties());

 { java.runtime.name=Java(TM) SE Runtime Environment, java.runtime.version=1.8.0-b129, java.vm.specification.name=Java Virtual Machine Specification, java.vm.name=Java HotSpot(TM) 64-Bit Server VM, java.vm.version=25.0-b69, java.vm.vendor=Oracle Corporation, java.vendor.url=http://java.oracle.com/, java.vm.specification.version=1.8, java.specification.name=Java Platform API Specification, java.specification.version=1.8, java.specification.vendor=Oracle Corporation, java.class.version=52.0, sun.boot.library.path=C:\\Java8\\jdk-1.8.0_01\\jre\\bin, sun.java.launcher=SUN_STANDARD, sun.os.patch.level=Service Pack 1, java.endorsed.dirs=C:\\Java8\\jdk-1.8.0_01\\jre\\lib\\endorsed, os.arch=amd64, java.vm.specification.vendor=Oracle Corporation, os.name=Windows 7, sun.jnu.encoding=Cp1252, java.library.path=C:\\Java8\\jdk-1.8.0_01\\bin;......, sun.management.compiler=HotSpot 64-Bit Tiered Compilers, os.version=6.1, file.encoding=UTF-8, sun.java.command=fromso.IsolatedBug, java.home=C:\\Java8\\jdk-1.8.0_01\\jre, sun.arch.data.model=64, user.language=en, java.ext.dirs=C:\\Java8\\jdk-1.8.0_01\\jre\\lib\\ext;C:\\windows\\Sun\\Java\\lib\\ext, sun.boot.class.path=C:\\Java8\\jdk-1.8.0_01\\jre\\lib\\resources.jar;......, java.vendor=Oracle Corporation, file.separator=\\, java.vendor.url.bug=http://bugreport.sun.com/bugreport/, sun.io.unicode.encoding=UnicodeLittle, sun.cpu.endian=little, sun.desktop=windows, sun.cpu.isalist=amd64 }