RFR: JDK-8236692: static final fields without initializer are accepted by javac

[Maurizio Cimadamore]

On 08/01/2020 13:40, Vicente Romero wrote:
>
>
> On 1/8/20 6:38 AM, Maurizio Cimadamore wrote:
>>
>> The Flow patch looks great and it brings back some sanity into the 
>> code - after all adding the special case for compact constructor is 
>> not so bad, and is now called out in its own special case, which 
>> makes the code more readable.
>>
>> On the test - I'm not sure, why is the test source defined in two 
>> strings - as in
>>
>> "record R() { # }", "static final String x;"
>> Doesn't this mean the second string will be replaced for the "#" ?
>
> yes
>
>> But since there's only one string, why having the replacement at all? 
>> I noted this idiom in most of the negative tests.
>
> yes we can do either, although there are already other cases of one 
> liners using this idiom

To be clear, I'm fine for this changeset, I guess I'm more curious as to 
why the framework is being used in this way - to avoid multiline string?

Maurizio

>
>
>> Maurizio
>
> Vicente
>
>>
>> On 08/01/2020 03:39, Vicente Romero wrote:
>>> Hi,
>>>
>>> I have updated the patch after an offline review with Maurizio, 
>>> basically I have rewritten how Flow deals with the compact 
>>> constructor to isolate it as a special case. The new iteration is at 
>>> [1]. I have basically restored the original code for method 
>>> checkInit and added a special case for the compact constructor.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://cr.openjdk.java.net/~vromero/8236692/webrev.01/
>>>
>>> On 1/7/20 3:18 PM, Vicente Romero wrote:
>>>> Please review the fix for [1] at [2], javac was failing to issue an 
>>>> error for code like:
>>>>
>>>> record R() {
>>>>     public static final int X;
>>>> }
>>>>
>>>> even though `X` was not initialized as the automatic code to 
>>>> generate initializer expressions only apply to the fields generated 
>>>> from the record component. The patch updates the code in Flow that 
>>>> analyzes compact constructors to don't bail out if the variable 
>>>> being analyzed is static.
>>>>
>>>> Thanks,
>>>> Vicente
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8236692
>>>> [2] http://cr.openjdk.java.net/~vromero/8236692/webrev.00/
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200108/53e7c623/attachment.htm>