J'ai un problème avec le code suivant, j'ai isolé le plus fermé la forme, je suis à l'aide de Java 8, qui est presque prêt pour le lancement (18 Mars 2014), donc je m'attends pas à de graves problèmes dans la mise en œuvre elle-même, de sorte qu'il peut/doit être mon propre code:
Remarque: Le code est écrit en Java 8, qui a toutes sortes de nouvelles fonctionnalités, y compris default méthode mise en œuvre dans les 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();
}
}
Le code en lui-même ne peut pas faire plus de sens, mais c'est parce que j'ai dépouillé un charge d'autres sans pertinence des méthodes.
Toutefois, lorsque vous observez le résultat, vous voyez quelque chose d'étrange, à un certain point, pour moi personnellement, après 30 secondes, je vois les suivantes:
isolatedbug.Box@5acf9800 C=vrai/R=true
isolatedbug.Boîte@5acf9800 C=vrai/R=true
isolatedbug.Boîte@5acf9800 C=vrai/R=true
isolatedbug.Boîte@5acf9800 C=vrai/R=true
isolatedbug.Boîte@5acf9800 C=false/R=false
isolatedbug.Boîte@5acf9800 C=false/R=false
isolatedbug.Boîte@5acf9800 C=false/R=false
isolatedbug.Boîte@5acf9800 C=false/R=false
isolatedbug.Boîte@5acf9800 C=false/R=false
isolatedbug.Boîte@5acf9800 C=false/R=false
Le moment où il passe de true de false, semble dépendre du nombre d'appels de la méthode, comme dort plus, il prend plus de temps pour passer.
Je suis en cours d'exécution ce, pour des informations complètes sur Windows 8 64-bit, en 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, en mode mixte)
Quelqu'un peut-il m'expliquer ce qui se passe?
Je voudrais aussi apprécier si d'autres personnes avec Java 8-toute accumulation, pourrait courir et voir si ils ont le même problème.
Plus d'information après l'utilisation de ce code:
Properties p = System.getProperties();
p.list(System.out);
Sortie:
-- 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
J'ai aussi vérifié l' -Xint VM option, lorsque cela a été utilisé, il retourne true comme prévu.
Donc, la conclusion semble être que dans mon cas d'utilisation particulier, de les interpréter et JIT compilé/inline variantes du code ne sont pas les mêmes, et il est donc possible qu'après l'interprété le code est compilé il passe d'interprété compilé et donc à clarifier le commutateur de sortie.
L'ajout de l' -Xint option pour le programme actuel dans lequel le bug s'est produit, a également résolu le problème.
L'officiel rapport de bug a été acceptée: JIRA Bug JDK-8036100
