Value types - compatibility with existing “value objects”

[Peter Levart]

On 01/08/2015 02:54 PM, Peter Levart 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.
>

The only problem being the 'hash' field, which is mutable (cache). But 
that could be encoded in char[] as 1st two slots, or computed uprfont in 
constructor.

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