Java 8 - converting an Integer to a long compilati

Question

I have the following abstract generic data holder in my project (simplified):

public abstract static class Value<E> {

    E value;

    public void setValue(E value) {
        this.value = value;
    }

    public E getValue() {
        return this.value;
    }

    public String toString() {
        return "[" + value + "]";
    }
}

Along with an InputCollection which contains a list of Objects:

public static class InputCollection {

    private ArrayList<Object> values;

    public InputCollection() {
        this.values = new ArrayList<>();
    }

    public void addValue(Value<?> value) {
        System.out.println("addding " + value + " to collection");
        this.values.add(value);
    }

    public <D> D getValue(Value<D> value, D defaultValue) {
        int index = this.values.indexOf(value);
        if (index == -1) 
            return defaultValue;

        Object val = this.values.get(index);
        if (val == null) {
            return defaultValue;
        }

        return ((Value<D>)val).getValue();
    }
}

The idea behind this is to be able to define a set of final variables which implements this abstract Value<E> in a so-called 'state', like so:

public static final class Input<E> extends Value<E> {
    public static final Input<String> STRING_ONE = new Input<String>();
    public static final Input<Integer> INTEGER_ONE = new Input<Integer>();
}

Then, adding these variables to an instance of InputCollection, which in turn is shared by many 'states' or 'processes'. The value of an Input<E> can then be changed by a different state, and then be retrieved when needed by the original state. A kind of shared memory model.

This concept has been working fine for years (yea, this is legacy), but we recently started moving over to Java 8, and this created compilation errors, even though the implementation worked on Java 7.

Add the following main to the above code samples:

public static void main (String [] args) {

    InputCollection collection = new InputCollection();
    //Add input to collection
    collection.addValue(Input.STRING_ONE);
    collection.addValue(Input.INTEGER_ONE);

    //At some later stage the values are set
    Input.INTEGER_ONE.setValue(1);
    Input.STRING_ONE.setValue("one");

    //Original values are then accessed later
    long longValue = collection.getValue(Input.INTEGER_ONE, -1);

    if (longValue == -1) {
        System.out.println("Error: input not set");
    } else { 
        System.out.println("Input is: " + longValue);
    }
}

If the Compiler Compliance level in eclipse is set to 1.7, there is no compilation issues, and the output will correctly be:

addding [null] to collection
addding [null] to collection
Input is: 1

but if it is set to 1.8 compilation error Type mismatch: cannot convert from Integer to long on the line

long longValue = collection.getValue(Input.INTEGER_ONE, -1);

But if I access the value doing this:

long longVal = Input.INTEGER_ONE.getValue();

there are no compilation issues, which is confusing.

It can be solved with a cast, but this is used all over the project and would require quite a bit of mandatory testing to change every occurrence.

What changed in Java 8 that requires the cast? Did compilation get stricter somehow? And why does the compiler not moan if the value is access directly and not through the collection?

I read How do I convert from int to Long in Java? and Converting Integer to Long , but didn't really get satisfying answers to my question.

Answer 1

A known Eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=440019

Fixed in Eclipse 4.5 M3.

Answer 2

According to the JLS for Java 8 this should not happen:

5.1.2. Widening Primitive Conversion

19 specific conversions on primitive types are called the widening primitive conversions:

[..]

• int to long, float, or double

[..]

5.1.8. Unboxing Conversion

[..]

• From type Integer to type int

What should happen is an unboxing from Integer to int, and then a widening conversion to long. This is actually happening as expected in Oracle JDK (1.8.0.25).

I believe you came across a compiler bug into your JDK. You should probably try an updated version or file a bug with the maintainers.