Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java 8 compiler bug with Stream and reduce

Tags:

java

java-8

I am writing a small program to generate some random numbers and wanted to get statistical information about them. I have a List<AtomicInteger> that I want to use for outputting some information.

I tried using following code to reduce the list to its total (e.g. the sum of the values of all the AtomicIntegers):

// not my real initialization code, just for illustration purposes
List<AtomicInteger> values = new ArrayList<>();
for(int i = 0; i < 10; i++) {
    values.add(new AtomicInteger());
}

// this is the problematic reduce
int total = values
    .parallelStream()
    .reduce(0, 
        (currentValue, currentAtomic) 
            -> currentValue + currentAtomic.get(),
        (combiner1, combiner2) -> combiner1 + combiner2);

My IDE (IntelliJ) has no problems with this line at all but with my current javac version (1.8.0_31) this line results in a NullPointerException in the compiler:

An exception has occurred in the compiler (1.8.0_31). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.NullPointerException
    at com.sun.tools.javac.code.Types.isConvertible(Types.java:290)
    at com.sun.tools.javac.comp.Check.assertConvertible(Check.java:922)
    at com.sun.tools.javac.comp.Check.checkMethod(Check.java:876)
    at com.sun.tools.javac.comp.Attr.checkMethod(Attr.java:3838)
    at com.sun.tools.javac.comp.Attr.checkIdInternal(Attr.java:3615)
    at com.sun.tools.javac.comp.Attr.checkMethodIdInternal(Attr.java:3522)
    at com.sun.tools.javac.comp.Attr.checkMethodId(Attr.java:3501)
    at com.sun.tools.javac.comp.Attr.checkId(Attr.java:3488)
    at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3370)
    at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
    at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:607)
    at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1843)
    at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
    at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:607)
    at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:649)
    at com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:1093)
    at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:852)
    at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:607)
    at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:676)
    at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:692)
    at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1142)
    at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:909)
    at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:607)
    at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:676)
    at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:1035)
    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:778)
    at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:607)
    at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:676)
    at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:4342)
    at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4252)
    at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4181)
    at com.sun.tools.javac.comp.Attr.attrib(Attr.java:4156)
    at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1248)
    at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:901)
    at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:860)
    at com.sun.tools.javac.main.Main.compile(Main.java:523)
    at com.sun.tools.javac.main.Main.compile(Main.java:381)
    at com.sun.tools.javac.main.Main.compile(Main.java:370)
    at com.sun.tools.javac.main.Main.compile(Main.java:361)
    at com.sun.tools.javac.Main.compile(Main.java:56)
    at com.sun.tools.javac.Main.main(Main.java:42)

I know that there are probably other ways to accomplish the same reduce, but I would really like to retain the parallel nature of the stream (since my original code has a lot of values). Can anyone suggest me another parallel reduce option that will not crash my compiler and can accomplish the same result?

I would also like to know if this is just a problem I'm encountering or if other people can reproduce this compiler bug.

like image 278
mhlz Avatar asked Mar 03 '15 09:03

mhlz


2 Answers

Alternatively, instead of using reduce, you can use mapToInt and sum:

int total = values.stream().mapToInt(AtomicInteger::get).sum();
like image 164
Alexis C. Avatar answered Nov 04 '22 06:11

Alexis C.


Version that does not crash compiler:

// not my real initialization code, just for illustration purposes
        List<AtomicInteger> values = new ArrayList<>();
        for(int i = 0; i < 10; i++) {
            values.add(new AtomicInteger());
        }

// this is the problematic reduce
        BiFunction<Integer, AtomicInteger, Integer> accumulator = 
                (currentValue, currentAtomic) -> currentValue + currentAtomic.get();
        BinaryOperator<Integer> combiner = (combiner1, combiner2) -> combiner1 + combiner2;
        int total = values
                .parallelStream()
                .reduce(0, accumulator, combiner);
like image 40
vbezhenar Avatar answered Nov 04 '22 08:11

vbezhenar