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

[Palo Marton]

Yes, it could be stored at the beginning of the array (there are 2 hash
codes in current string, so it will need 4 slots).

Benefits of having value string are:

- faster access because of removed indirection
- save memory, as it removes String box object from heap

Drawbacks:

- adds one level of indirection for accessing hash code when using boxed
String

On Thu, Jan 8, 2015 at 2:57 PM, Peter Levart <peter.levart at gmail.com> wrote:

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