For the same reason that there is no integer NaN in any other language.
Modern computers use a binary representation with two additions for integers, and this representation does not matter NaN. (All values ββin the scope of the view type represent specific integers.)
It follows that the computer integer arithmetic equipment does not recognize any representation of NaN.
In theory, someone could invent an alternative representation for integers that includes NaN (or INF, or some other exotic meaning). However, arithmetic using this representation will not be supported by hardware. Although it would be possible to implement it in software, it would be overly expensive 1 ... and undesirable in other respects to also include this support in the Java language.
1 - This, of course, is relative, but I would expect that the software implementation of NaNs would be (at least) an order of magnitude slower than the hardware. If you really, really needed it, then that would be acceptable. But the vast majority of integer arithmetic codes do not need this. In most cases, throwing an exception for "division by zero" is just fine and slows down by an order of magnitude in all integer arithmetic operations ... is unacceptable.
In contrast to this:
- "unused" values ββin the presentation space already exist
- The NaN and INF values ββare part of the IEE floating point standard and
- they are (usually) implemented using the embedded hardware implementation of floating point arithmetic
source share