JEP update: Classes for the Basic Primitives

[Brian Goetz]

> * Could the doc make a clearer distinction (throughout) between which 
> facts about int/Integer are happening because we expect *all* bucket-3 
> classes to work that way, vs. which are special one-off tweaks for the 
> 8 predefined types?

A "how are int/Integer special" section would indeed be useful.  And I 
think we haven't finished enumerating what goes in it; in the 
discussions over inference, for example, several folks have been heard 
mumbling "maybe we're trying to push the int/Integer analogy too far."

> * I'm curious whether it would be /possible/ to make `int` no longer a 
> keyword, just a special kind of type alias that normal people don't 
> get to declare. I'm /not/ claiming that'd be worth actually doing; 
> just wanting to understand what forces would act to prevent it, as 
> part of understanding everything that makes the 8 builtin types 
> "irredeemably special".

In a previous world, `int` could have been an alias for `Integer.val`.  
But we (happily) have banished .val from the world.

I think this is a useful exercise anyway, though; we have stumbled over 
type-vs-class in a lot of places already with respect to B3, and int has 
similar problems; most uses of `int` are types, but there's also 
`int.class`, which means ... something.  What exactly? And how does that 
differ from Point.class / Point.ref.class / 
Point.class.noNotThatClassTheOtherClass() ?

> * I assume the reason "the JVM type Qjava/lang/Double cannot be 
> encoded with a Class object" is because the distinction between it and 
> D is intentional implementation detail.

Worse :(   The J and D carriers use two slots, so even if we wanted to 
abstract over the primitive carriers, this is kind of a dead end.  The 
java/lang/Double class allows us to encode List<double> with a class 
that carries a double but fits in one slot.

> * Since I think/hope it is /not/ true that `int` will be a subtype of 
> `Integer`, it's not 100% clear whether the phrase "array covariance" 
> in the doc is referring to the (desirable) property that `int[] <: 
> Integer[]`. I think it is.

int will not be a subtype of Integer, nor will Point be a subtype of 
Point.ref.  (It was this way in a previous iteration; the VM still 
believes the latter, but we're probably going to disabuse it of same.)  
Traditional array covariance is tied to subtyping:

       T <: U
     ----------  T-Cov
     T[] <: U[]

But, we're going to modify this rule somewhat.  We define a relation 
between types, called "extends".

     A extends B = A <: B        if A is a reference type
                   A.ref <: B    otherwise

(We could write this more concisely as "A extends B == A.ref <: B", 
since the .ref operator is idempotent.)  We use "extends" for things 
like bounds conformance; if we have Foo<T extends Comparable>, we treat 
Foo<int> as being in bounds.

So our modified covariance is:

       T extends U
     --------------  T-Cov-Ext
       T[] <: U[]

which gives us int[] <: Integer[], even though we don't have int <: 
Integer.

This is no mere flourish; without it, erased generics don't work:

     class Box<T> {
         T value();
         T[] asArray();
     }

This erases to returning Object[], and if we want to specialize 
Box<int>, asArray() should return int[], but to be compatible with 
erasure, we need int[] <: Object[].

> * I said in the meeting that "I don't think anyone cares" what kind of 
> exception gets thrown if trying to store null in an `Integer[]` which 
> is secretly an `int[]`. Well, I'm sure that's not at all true. :-) Sorry.

You're lucky they didn't show you their scars.

> * Re: "a basic primitive class may declare an instance field of its 
> own primitive" -- does it really need that field, or can we nuke it 
> and just s/value/this/g throughout the file? If that could work, it 
> would be so much less confusing -- nothing circular! The only magic 
> would be "where are the actual bits??" but you don't see the bits of 
> an object header in `Object.java` either and the number of people this 
> bothers is a very round number.

Seems plausible :)