That's in the list:

> Overflow and implicitly assign byte, short, char and boolean values

Wait, I love learning new things about Java, but I feel in the dark here. What is your example demonstrating?

The valid values of booleans / bytes / shorts / chars are only enforced in the Java compiler, not actually in bytecode.

But the Java compiler assumes values will be in range - i.e. that a boolean will be zero or one, that sort of thing.

And as such it makes some optimizations that are... questionable, if you're interfacing with bytecode that wasn't produced by the Java compiler.

For example, if `flag` is supposedly a boolean, but you gave it the value `2` directly via bytecode, flag==true is false, as it gets compiled down to flag == 1, which is false, but flag?bar:baz will return bar.

This can seriously break static analysis, among other things.

If true is book(1) then the check

    bool(2) == true

will fail but

    bool(2) ? a : b

will act as if bool(2) were true and this inconsistency could lead to unintended execution paths.

Ah, I'm with you. Thanks.