java.lang.__Value ??

[Brian Goetz]

[ adding background ]

The __Value type as it currently stands is simply a placeholder for the 
current round of compiler experiments (hence the deliberately horrible 
name).

In the long run, we need:
  - A place to put Object methods that pertain to values (e.g., equals 
and hashCode, but not wait and notify)
  - Possibly a place to put top-level methods that do NOT pertain to 
Object (not completely sure what these would be, but its possible we'll 
want some, perhaps boxing and unboxing would be surfaced here)
  - Possibly a type to use as a bound in some contexts (though not clear 
this is needed)
  - Possibly a type to unify what is common between objects and values 
(the current thinking here is something like Objectible / Objectifiable 
/ Objectionable / ObjectionYourHonor, which could be an interface 
implemented by both Object and values.)

I suspect the __ByValue modifier is there to prevent reference classes 
from implementing it, though that can easily be accomplished by other 
means such as compiler restrictions for now (and, since its just a 
placeholder, this is fine); the final modifier does seem suspect.

I think its fair to say that everything about this class (its name, its 
modifiers, whether its a class or an interface, or even whether it 
exists) will eventually change...



On 11/23/2015 3:40 AM, Srikanth wrote:
>
> Hello !
>
> valhalla/src/java.base/share/classes/java/lang/__Value.java
>
> starts with:
>
> package java.lang;
>
> /**
>  * Base class of all value types in prototype implementation.
>  */
> __ByValue final public class __Value {
> // ...
> }
>
> It seems to me that this class (a) should not be final (b) not carry 
> the decoration
> __ByValue. (c) Is better named just Value rather than __Value - this 
> being a type
> name in a name space controlled by JDK. (d) should perhaps be declared 
> abstract.
>
> Also,
>
> Given:
>
> __ByValue final class X {
>     public static void main(String [] args) {
>         System.out.println("Hello");
>     }
> }
>
> at the moment the class file generated by javac[*] encodes an explicit 
> super type:
>
> final value class X extends java.lang.__Value
>
> It would appear the right behavior is to leave the supertype implicit 
> and be
> inferred from the ACC_VALUE flag bit being set.
>
>
> [*] The class file generated cannot be run as of now - since 'Q' in 
> signatures is not digested
> by the VM yet. But using a modified version of javac that emits 'L' 
> even for value types
> I am able to run the program above triggering:
>
> Exception in thread "main" java.lang.VerifyError: Cannot inherit from 
> final class
>
> Srikanth.