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

[Maurizio Cimadamore]

Hate to be the party pooper :-)

What happens with method calls?

class Test {
public static void main(String[] args) {
    Object o = null;
    o.
     toString(); <-- NPE here
}

}

So, while at some level I sympathize with the argument of not making LNT 
more bloated, I can't help noting the asymmetry between field and method 
access.

Maurizio


On 20/02/2019 14:20, Remi Forax wrote:
> I don't think you need to bloat the line number table for this case 
> because soon the NPE error message will be more precise [1].
>
> Rémi
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8218628
>
> ------------------------------------------------------------------------
>
>     *De: *"Vicente Romero" <vicente.romero at oracle.com>
>     *À: *"Eddie Aftandilian" <eaftan at google.com>
>     *Cc: *"compiler-dev" <compiler-dev at openjdk.java.net>
>     *Envoyé: *Mercredi 20 Février 2019 14:38:45
>     *Objet: *Re: RFR - JDK-8218650: LineNumberTable records for method
>     invocations with arguments
>
>
>
>     On 2/19/19 8:27 PM, Eddie Aftandilian wrote:
>
>         Hi Vicente,
>
>         Thanks for the reply.  Can I ask why you don't think the LNT
>         should contain entries for accesses to fields?  It seems that
>         results in incorrect line numbers in certain cases.  For
>         example, consider the following code:
>
>         1: class LineNumbers {
>         2:
>         3:   static class T {
>         4:     boolean b;
>         5:   }
>         6:
>         7:   static void doIt(boolean... values) {}
>         8:
>         9:   public static void main(String[] args) {
>         10:     T a = new T();
>         11:     T b = null;
>         12:
>         13:     doIt(
>         14:         a.b,
>         15:         b.b);
>         16:   }
>         17: }
>
>         $ javac LineNumbers.java
>         $ java LineNumbers
>         Exception in thread "main" java.lang.NullPointerException
>         at LineNumbers.main(LineNumbers.java:13)
>
>         I would expect the exception to be at line 15, not 13.
>
>
>     having the exception at 13 is plain bad or good enough? It seems
>     to me that you want to do some automation based on the exact line
>     where the exception was produced. I'm just worried that generating
>     LNT entries for every expression would produce, probably
>     unnecessarily, fluffier class files.
>
>
>         Thanks,
>         Eddie
>
>
>     Thanks,
>     Vicente
>
>
>
>
>         On Fri, Feb 15, 2019 at 6:46 PM Vicente Romero
>         <vicente.romero at oracle.com <mailto:vicente.romero at oracle.com>>
>         wrote:
>
>             Hi Eddie,
>
>             Thanks for the patch. But first I'm not sure that there is
>             a bug in the
>             LNT. There is an entry in the LNT, I'm talking about the
>             example at [1],
>             for the invocation of method `id`. What we need to
>             understand is why the
>             stack trace is not referring to that line and is referring
>             to line 12.
>             In any case I don't think that the LNT should contain
>             entries for
>             accesses to fields.
>
>             Thanks,
>             Vicente
>
>             [1] https://bugs.openjdk.java.net/browse/JDK-8218650
>
>             On 2/15/19 8:37 PM, Eddie Aftandilian wrote:
>             > Hi,
>             >
>             > I have attached a patch for JDK-8218650, in which there
>             are missing
>             > line number table entries for field accesses. This is my
>             first attempt
>             > to contribute to OpenJDK, so I'm happy to take
>             feedback.  Please see
>             > the attached patch.
>             >
>             > Bug report: https://bugs.openjdk.java.net/browse/JDK-8218650
>             >
>             > Thanks,
>             > Eddie Aftandilian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190221/c72a8af2/attachment.html>