JEP 401: Implications of migrating a class to a primitive one

[Glavo]

Hey, you can see this JEP draft:

    https://openjdk.java.net/jeps/8277163

It allows you to declare identity free reference type classes.

Tim Feuerbach <feuerbach at spell.work> 于2022年1月11日周二 23:49写道：

> Hi,
>
> after reading JEP 401, I have a couple of questions regarding the
> conversion of existing classes into primitive classes, specifically: is
> this change (bytecode) compatible or not?
>
> Let's assume we have a Point class like in the JEP, but not yet declared
> as primitive. There's also another class, PointHolder:
>
> class PointHolder {
>      Point point;
>      boolean isInitialized() {
>          return Objects.nonNull(point);
>      }
> }
>
> (I used Objects.nonNull since I didn't know whether you want to make
> "non-ref'd primitive == null" a compile time error).
>
> Before primitive class conversion, after compiling both Point and
> PointHolder, I run the following program:
>
> PointHolder ph = new PointHolder();
> System.out.println(ph.isInitialized()); // false
>
> Now I add "primitive" to the Point class and recompile *only the Point
> class*.
>
>      1. Does the program still run after that change?
>
>  From my understanding, the "point" field in PointHolder was an L type
> and therefore the JVM will happily initialize the field to null. The
> output is still "false".
>
>      2. Can I recompile PointHolder without errors?
>
> I assume yes, and the Point field (which was implicitly Point.ref) will
> now refer to the primitive Q type. However, since this will result in
> the field being initizialized with Point.default, the semantics of the
> program will change (isInitialized() returns true). This seems like a
> source for potential errors and would mean once I published a type, I
> should never migrate it to a primitive (I can however choose to migrate
> to a value class, as is planned for LocalDate etc.). Also, it's counter
> intutitive that the program will break only once I recompile the
> consumer of a changed class, not the changed class itself.
>
> JEP 402 gets away with making Integer etc. primitives and not breaking
> existing code by declaring Integer an alias of int.ref. Users will not
> have this ability (for now).
>
>      3. Are there plans for the (distant) future to bring primitive
> aliasing capabilities to the user space as well?
>
> For example, the following fictitious syntax would make the change above
> semantically compatible:
>
> primitive class point ref-alias Point {...}
>
>
> Tim
>
>