java.lang.__Value ??

[Paul Benedict]

Brian, food for thought from me.

I am not sure what would be the consequences of this, but the so-called
future interface shared between Values and Objects, could also define
universal boxing and unboxing methods:
1) Boxing an object would return itself
2) Unboxing an object ??? / TBD

Even if there are not universal semantics for #2,
Boolean/Byte/Character/Short/Double/Enum/Integer/Long/Short could take
advantage of this to return their intrinsic value.


Cheers,
Paul

On Mon, Nov 23, 2015 at 10:40 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> [ 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.
>>
>
>