State of javac support for lworld-values.
srikanth.adayapalam at oracle.com
Mon Mar 26 07:39:19 UTC 2018
On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:
>> Thanks for writing that down, Karen.
>>> I believe there are two major open issues:
>>> 1. you identified one - which is the discussion around <init>, which
>>> I think also includes
>>> handling of __MakeDefault
>> Yes, we haven't touched <init> yet. I think the language folks need to
>> decide what value constructors look like before we can start to talk
>> translation strategy. My crystal ball tells me that <init> will be
>> to value types, even though at the source level constructors will be
>> important. ("Codes like a class…") The JVM rules around <init> are
>> just relentlessly pointer-oriented, so we'll probably break new ground
>> for value factories. (If we win big, then that ground will serve for
>> factories on object classes and interfaces too, but that's just my
>> hunch for now.)
> Is there an rfe here?
> So how does instance initialization happen for testing right now
> before this gets resolved?
Here is the present state at the language level:
ATM, javac does continue to generate <init> methods - these are useless
of course and are not called at all. However, source constructors do
play a role in satisfying the "code will not compile unless the all
final fields have been initialized before the constructor finishes" rule.
Attempting to do:
will result in a compile error and one will have to change the code to
(attempting to invoke __MakeDefault while passing arguments will result
in a compile error)
So, the only way to instantiate value instances is by producing default
values and then applying withfield on them successively as needed.
This is obviously an interim point. I believe it does allow us to test
without solving the full question of the role of source constructors and
More information about the valhalla-dev