Implement boolean expressions

[katcharov]

JAVA-4779

This implements not/and/or/cond for boolean expressions.

[jyemin]

Took a quick first pass. Looking good.

[rozza]

LGTM - I have one question more for my learning than anything else

[rozza]

Like it :)

[rozza]

I'm surprised this doesn't issue an unchecked warning, I don't get why it doesn't?!

[stIncMale]

The unchecked -Xlint javac key deals only with the unchecked narrowing conversions (i.e., it is not related to the fact that the cast may fail at runtime, but is rather about a situation when the cast does not fail at runtime, yet the program is incorrect and has heap pollution). The JLS states that "A narrowing reference conversion from a type S to a parameterized class or interface type T is unchecked, unless at least one of the following is true: All of the type arguments of T are unbounded wildcards. ...".

It's easy to see why the above is fine: a paremetrized type with all type arguments being unbounded wildcards is a type for which the program has no expectation on the type arguments, so there is nothing that javac was required to check but was unable to.

[rozza]

Thanks :)

[stIncMale]

If the type erasure were not a thing, then the conversion could have been checked at runtime (just like casts for non-parametrized types are), and we would not have had to deal with unchecked conversions.

[stIncMale]

While I was away (if you know what I mean), I realized that the argument "the program has no expectation on the type arguments" is applicable to raw types just as it is applicable to types parametrized with ?. However, javac warns us about raw MqlExpression and does not warn when we cast to MqlExpression<?>.

While I can't give a formal explanation, I have a hand-waving explanation via an example. I will have to use List<String> instead of Expression and ArrayList<?> instead of MqlExpression<?> because there is no practical problem with MqlExpression in the code we are discussing, but javac cannot know that, and warns us by following a simple algorithm.

The problem with rawtypes (ArrayList), which we don't have with ?-parametrized types (ArrayList<?>) and therefore, there is no need for a compiler to warn us, is demonstrated with the following example:

List<String> strings = new ArrayList<>();
ArrayList objects = (ArrayList) strings; // javac warning: [rawtypes] found raw type: ArrayList
// pollute the heap
objects.add(42); // javac warning: [unchecked] unchecked call to add(E) as a member of the raw type ArrayList
// enjoy the consequences
strings.get(0); // java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String

the same example won't compile if we use ArrayList<?>:

List<String> strings = new ArrayList<>();
ArrayList<?> objects = (ArrayList<?>) strings;
// try to pollute the heap
objects.add(42); // javac error: incompatible types: int cannot be converted to CAP#1 ... where ... CAP#1 extends Object from capture of ?
// there are no consequences as the code does not compile
strings.get(0);

So not only a ?-paremetrized type expresses no expectation on the type arguments, but also makes the values of the type kinda sorta "unmodifiable" (I have no idea how to formally express this property), which is how it is different from raw types.