RFR - JDK-8218650: LineNumberTable records for method invocations with arguments

[Brian Goetz]

I agree. Without a clear target for what LNT should and should not be used for, the current situation is not obviously optimal, so its not really fair to use loaded terms like “bloat” or “throw away information” for adding to / removing from the LNT.  

This is a good example of a situation that comes up often, which is: we start discussing a solution before we’ve got a shared understanding of the problem.  So I agree with the path of: let’s step back for a moment, discuss the problem, convince ourselves it is a problem, explore solutions, and then, assuming there’s consensus, drive towards implementing the best of the solutions explored.  

> On Feb 21, 2019, at 12:02 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 21/02/2019 16:49, Maurizio Cimadamore wrote:
>> 
>> I guess what I'm arguing is not that we should add LNT - but that I see no solid basis for doing this for methods, but not for field access. If 8218628 will cure us from all sins :-) then the same argument surely could be applied to method access?
>> 
> Where I'm truly going with this is - we never really collected a list of use cases as to when it would be nice to have a LNT generated; there are many use cases out there, from debuggers to static analysis tools (code coverage, findbugs...) and each of these might be affected in subtle ways. Heck, once we've even stumbled upon a bug where missing LNT entry was causing the JRockit VM to crash ;-)
> 
> So, I think that, stepping back from this specific issue, we should try (with the help of the community :-)) to identify the conditions under which it would be desirable to have a LNT entry, and come up with some sort of informal javac spec for that.
> 
> Maurizio
> 
>