JDK-8188144 regression in method reference type-checking

[Maurizio Cimadamore]

Hi John,
there are few things to considered when backporting a bug fix; not all 
bugs are created equals, so, for instance, types system issues (such as 
this one) require more 'bake time' to make sure the fix doesn't 
accidentally introduce further regressions; in this case, I see that the 
bug has been fixed in October, so one could argue that we had enough 
bake time.

Another factor that we consider is how severe the bug appears to be; are 
there workarounds? Is it likely to impact a lot of developers? If the 
answer is likely to be negative on both fronts, then it's typically not 
worth the risk backporting the fix (given it might also have a chance to 
unsettle things),

That said, these judgements do not occur in a vacuum - that is, they are 
affected by emails we receive and other bugs we see reported - so, if a 
bug has 12 duplicates, we can infer that there's a demand for the fix; 
if we receive many complaints over a specific bug in the mailing list we 
might equally infer that it's worth backporting.

In this case it was a close call; there was indeed a duplicate, but 
looking a the test case, they didn't strike us as something that was in 
urgent need to be fixed - which might or might not have been the right 
call (with with not much data it's always hard to get it right).

I think what you did was fine - it was just bad luck; note that for 
every new release there will be two updates, and that updates take place 
quarterly (Jan, Apr, Jul, Oct), so it should be easy to figure out, from 
release date of JDK N, what the last update of N would be (and workout 
some kind of 'deadline' for bug reports that you would like to see 
making through the update).

I hope this helps
Maurizio



On 28/01/18 02:40, John Napier wrote:
> Thanks very much for the follow up, Maurizio.
>
> I’m sad to hear that, as this bug bit me fairly severely, but c'est la vie. I’m glad at least it will be fixed in 10.
>
> For my own edification, how early could I have reported it do you think for it to have made it in to the 9 patch release? I knew about it for a few weeks before I got up the energy to try to shrink the problem down to the least amount of essential code and put together a proper test case. I ask because there are other bugs I’d like to report that are of the same ilk, and I’m curious to know what kind of time line I should be observing (relative to the release schedule) to maximize my chance of getting them fixed in the next release.
>
> Did it miss the patch because of severity, or because it missed some 6 month cut off, or some combination of the two?
>
> Thanks again, cheers!
>
>> On Jan 15, 2018, at 3:02 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> Hi John,
>> unfortunately the only planned update to JDK 9 is shipping very soon, and it's too late now to integrate fix on it. So, the next planned release with the fix is gonna be JDK 10 (unless a new maintainer for JDK 9 is going to step forward) - see:
>>
>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2017-November/000024.html
>>
>> Also, a related (and recent) thread (thanks to Sean Coffey to point that out):
>>
>> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-January/000028.html
>>
>> Thanks
>> Maurizio
>>
>>
>>
>>
>> On 14/01/18 21:38, John Napier wrote:
>>> Hello Maurizio,
>>>
>>> I was the original reporter of JDK-8188144 to the JetBrains folks, who ultimately forwarded it over to you all, where it seems you’ve fixed it (Thank you!).  It’s logged as a P3 that is targeting 10 but was resolved in build b26; wasn’t that one of the old Java9 early access builds? Is this bug fix planned for the next patch release of 9, or is it only targeted for 10?
>>>
>>> Cheers,
>>> John