Survey on primitive type test patterns

Survey on primitive type test patterns

Brian Goetz brian.goetz at oracle.com
Fri Nov 3 16:53:33 UTC 2017

You may have seen a survey float by a few days ago, aimed at probing at 
developer intuition about the semantics of primitive type test patterns. 
  The results are here, with over 1000 answers:

     https://www.surveymonkey.com/results/SM-87Y6K3BY8/


BACKGROUND

The real goal of this survey was to probe at how deep the Stockholm 
Syndrome between Java developers and primitive boxes goes (with an eye 
towards evaluating the semantic options for how to interpret primitive 
type-test patterns).  And the unfortunate answer was, not surprisingly, 
pretty deep.

The seam introduced by boxing is deep and terrible; it messes with the 
most fundamental foundations of computing, numeric equality.  Given:

     Long zl = 0L;
     Byte zb = (byte) 0;

We have

     zl == 0

and

     zb == 0

but not

     zl == zb

as we would expect from equality being transitive.  (The odd bits of 
floating point, like NaN, mess with this too, but this corner case is 
more likely to stay in the corner where it belongs.)

Which brings us to question 1; what should a constant pattern 0 match?

     Object anObject = ...
     switch (anObject) {
         case 0: ...
     }

There are basically three options here:
  - It matches (Integer) 0, but not (Long) 0, (Short) 0, etc.
  - It matches all the primitive zeros, because, well, they're all the 
same zero.
  - Punt; don't allow numeric constant patterns unless we know more 
about the target type.

The first elevates the primitive boxes (which are really the tail, not 
the dog) to being the "real" numeric types in this case.  This feels 
like bug bait.

The second recognizes that types are merely a convenient way of 
reasoning about value sets, and the value 0 is a member of the Long 
value set, the Integer value set, etc.

The third hides our head in the sand.

Question 2 is the same, just one level up; how do we interpret "case 
int" as a type test pattern (or "x matches int", or "x instanceof int")? 
  And again we have the same choices:

  - Pretend "case int" is really "case Integer" (all hail, primitive box 
types);
  - Interpret "case int" as "are you a member of the value set described 
by int";
  - Don't allow that question to be asked.


INTERPRETATION OF THE RESULTS

There were three choices that corresponded to "instanceof is about 
types, full stop": 1/2/4.  Each of these choices said, in some manner, 
that asking "are you an instance of int" was a dumb question.  The 
fourth choice (#3), treated "instanceof int" as "are you an int".

#3 is strictly more expressive than the others; it allows you to ask a 
sensible question that was previously hard to ask, and get a reasonable 
answer.  (#1 and #2 let you ask a dumb question and get a dumb answer; 
#4 tells you "that was a dumb question.")

The thing we were trying to get at was, whether if we have a Long that 
holds a number, people think the more important characteristic is that 
it is a Long (vs Integer, Short, Byte, or Character), or its value.

This poll told us that: the Stockholm Syndrome is so strong that, when 
given the option to treat boxed numbers as numbers, rather than 
instances of accidental boxes, 85% chose the latter.

More information about the amber-spec-experts mailing list

</body