Re: Value types - compatibility with existing “value objects”

Vitaly Davidovich vitalyd at gmail.com
Thu Jan 8 14:24:38 UTC 2015


I don't think this has been ignored, certainly not on the recent traffic on
this mailing list.

I think the short answer to the "can existing classes that are value
objects be migrated to value types with no client change" is probably no.
The reason, or one of them, is that there's no way to know (without
analyzing all usages) whether client code uses object features of said
object (e.g. uses reference identity comparison, locks on an instance, etc).

In your rephrasing, "works like a class" implies identity of the object and
can be synchronized on.  That's not what VT is of course.

Sent from my phone
On Jan 8, 2015 9:17 AM, "Palo Marton" <palo.marton at gmail.com> wrote:

> My question is not just about String but about all existing value types.
> There are many of them in current java code (both JDK and user code).
> Current proposal seems to ignore them.
>
> I think that the original idea of VT:
>
> "Codes like a class, works like an int!"
>
> can be changed to:
>
> "Codes like a class, works like class, but can be stored and passed as
> int!"
>
> as the problem with current value objects (like String) is not with the
> fact that they are objects, but in how they are stored in memory and passed
> between functions.
>
>
>
> On Thu, Jan 8, 2015 at 3:02 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> I had a suspicion this would be the gist.  However, I think better
>> solution is to simply change string to have inline storage of the data, so
>> no indirection to the char[].  Ultimately, the string data will have to
>> live on the heap one way or another,  but it'd be nice if String had that
>> data inlined into its storage so when you load address of string you get
>> the data at a small fixed offset from that address.
>>
>> Sent from my phone
>> On Jan 8, 2015 8:54 AM, "Peter Levart" <peter.levart at gmail.com> wrote:
>>
>>> On 01/08/2015 02:50 PM, Vitaly Davidovich wrote:
>>>
>>>> Why do you want string to be value type? What problem (s) will that
>>>> address?
>>>>
>>>
>>> String as a value type would eliminate one indirection. If would
>>> effectively become an immutable char[] with a bunch of operations.
>>>
>>> Peter
>>>
>>>
>>>> Sent from my phone
>>>> On Jan 8, 2015 7:04 AM, "Palo Marton" <palo.marton at gmail.com> wrote:
>>>>
>>>>  Thank you for response. I have read that thread. But apart from first
>>>>> few
>>>>> messages it seems to deal with something else - mutable types.
>>>>>
>>>>> My idea with rewriting String as value is not about changing meaning of
>>>>> java.lang.String. That identifier should still mean heap object with
>>>>> identity, null, etc... The idea is to give a new name for string value,
>>>>> e.g. java.lang.string (lowercase s), or just "string". So "String"
>>>>> will be
>>>>> boxed version of "string" and all old pre-value-types code will use
>>>>> only
>>>>> boxed objects as before and there will be no semantic change. In new
>>>>> code
>>>>> you will use "string" in most cases, but you can use also "String" in
>>>>> places where you need it.
>>>>>
>>>>>  From what I have read there are no plans to support something like
>>>>> that. Am
>>>>> I right?
>>>>>
>>>>> Reason why I am asking this is that some time ago I was thinking about
>>>>> value types in java and how they should be implemented in JVM. My idea
>>>>> about how to implement it in JVM was somehow different, but it can
>>>>> support
>>>>> this old-code / new-code compatibility.
>>>>>
>>>>> On Thu, Jan 8, 2015 at 11:42 AM, Richard Warburton <
>>>>> richard.warburton at gmail.com> wrote:
>>>>>
>>>>>  Hi,
>>>>>>
>>>>>> Will it be possible (within valhalla) to rewrite java String as value
>>>>>>
>>>>> type
>>>>>
>>>>>> in JDK and use it in all places in JDK where it makes sense? (eg.
>>>>>>> Class.forName(string), Object.toString(), Integer.parseInt(string).
>>>>>>> …)
>>>>>>>
>>>>>>> Or more general question:
>>>>>>>
>>>>>>> There are already plenty of “value objects” in existing java code. In
>>>>>>>
>>>>>> JDK
>>>>>
>>>>>> we have, String, File, Point2D,... Also many people have already
>>>>>>>
>>>>>> declared
>>>>>
>>>>>> their own class Point { final x,y; } and similar objects. Once we move
>>>>>>>
>>>>>> to
>>>>>
>>>>>> value types in java, will it be possible to rewrite these to value
>>>>>>> types
>>>>>>> without breaking compatibility with old pre-value-types code? E.g.
>>>>>>> if I
>>>>>>> change my Point object to value type in my library, can this new
>>>>>>> library
>>>>>>> (jar) still be used in other projects that were written before this
>>>>>>> change?
>>>>>>> And without need to recompile those other projects?
>>>>>>>
>>>>>>
>>>>>> See this thread:
>>>>>>
>>>>>>  http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-
>>>>> January/000546.html
>>>>>
>>>>>> regards,
>>>>>>
>>>>>>    Richard Warburton
>>>>>>
>>>>>>    http://insightfullogic.com
>>>>>>    @RichardWarburto <http://twitter.com/richardwarburto>
>>>>>>
>>>>>>
>>>>>>
>>>
>


More information about the valhalla-dev mailing list