State of javac support for lworld-values.

[Karen Kinnear]

Thank you - that addresses my concern in theory. I added this to a list of test experiments we’ll want
to run.

thanks,
Karen

> On Mar 26, 2018, at 3:07 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> 
> 
> On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:
>> more embedded:
>> 
>>> On Mar 13, 2018, at 8:53 PM, John Rose <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
>>> 
>>> On Mar 13, 2018, at 3:04 PM, Karen Kinnear <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> wrote:
>>> 
>>> 
>>>> 1. Frederic made a good point - a value type can not have an inner class, i.e. a non-static nested class, since it does not have identity.
>>> 
>>> Putting on my Mr. Inner Classes hat, I say, not so fast!
>>> 
> [...]
>>> At the VM level, an inner class has a this$0 reference to the
>>> outer instance.  For a value outer class, the this$0 is a flattenable
>>> copy of the outer instance.  We could be clever and make it
>>> not flat, but I think that's taking a legitimate decision away
>>> from the user.
>> This was not about flattenable or nullability. This was a question about identity.
>> Perhaps I misunderstand and an experiment would help here. If this$0 refers
>> to an outer instance - not sure what happens if we are now operating on a copy
>> of that instance?
> 
> From https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html <https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html>:
> 
> "Instances of a value-based class ... 
> are freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior."
> would the above address your concern ?
> 
> Srikanth
>