Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8144168

No type annotations generated for nested lambdas

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 8, 9
    • Fix Version/s: 9
    • Component/s: tools
    • Subcomponent:
    • Introduced In Version:
      8
    • Resolved In Build:
      b104
    • CPU:
      x86
    • OS:
      windows_8
    • Verification:
      Verified

      Description

      FULL PRODUCT VERSION :
      java version "1.8.0_60"
      Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
      Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      Windows 10

      A DESCRIPTION OF THE PROBLEM :
      For next class only two first lambdas will be marked with type annotations (in compiled bytecode). Thirst and fourth lambdas will be compiled without any type annotations information.

      package org.jcoro;

      import java.lang.annotation.ElementType;
      import java.lang.annotation.Retention;
      import java.lang.annotation.RetentionPolicy;
      import java.lang.annotation.Target;

      public class TestClass {
          @Target({ElementType.METHOD, ElementType.TYPE_USE})
          @Retention(RetentionPolicy.RUNTIME)
          public @interface TypeAnn {
              String value() default "";
          }

          public static void main(String[] args) {
              Runnable one = (@TypeAnn("1") Runnable) () -> {
                  Runnable two = (@TypeAnn("2") Runnable) () -> {
                      Runnable three = (@TypeAnn("3") Runnable) () -> {
                          Runnable four = (@TypeAnn("4") Runnable) () -> {
                          };
                      };
                  };
              };
          }
      }


      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      1. Compile the test example
      2. Disassemble class file using command
      javap -v -l -p -c -s -sysinfo -constants

      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      All of invokedynamic calls should be annotated with something like this:

      RuntimeVisibleTypeAnnotations:
              0: #18(#19=s#22): CAST, offset=0, type_index=0

      ACTUAL -
      Only two lambdas are annotated.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      package org.jcoro;

      import java.lang.annotation.ElementType;
      import java.lang.annotation.Retention;
      import java.lang.annotation.RetentionPolicy;
      import java.lang.annotation.Target;

      public class TestClass {
          @Target({ElementType.METHOD, ElementType.TYPE_USE})
          @Retention(RetentionPolicy.RUNTIME)
          public @interface TypeAnn {
              String value() default "";
          }

          public static void main(String[] args) {
              Runnable one = (@TypeAnn("1") Runnable) () -> {
                  Runnable two = (@TypeAnn("2") Runnable) () -> {
                      Runnable three = (@TypeAnn("3") Runnable) () -> {
                          Runnable four = (@TypeAnn("4") Runnable) () -> {
                          };
                      };
                  };
              };
          }
      }
      ---------- END SOURCE ----------

        Issue Links

          Activity

          Hide
          mcimadamore Maurizio Cimadamore added a comment -
          This looks like a bug - I initially thought it was a duplicate of this:

          https://bugs.openjdk.java.net/browse/JDK-8140279

          But then I noted that the example in this report is about annotations in cast involving lambdas, not annotations in lambda parameters themselves.

          I also note a problem with the lambda generated names:

          lambda$main$3
          lambda$null$0
          lambda$null$1
          lambda$null$2

          So, nested lambdas get bogus names and the annotations in their bodies are lost. I wonder if the underlying issue is the same (tested with b93)
          Show
          mcimadamore Maurizio Cimadamore added a comment - This looks like a bug - I initially thought it was a duplicate of this: https://bugs.openjdk.java.net/browse/JDK-8140279 But then I noted that the example in this report is about annotations in cast involving lambdas, not annotations in lambda parameters themselves. I also note a problem with the lambda generated names: lambda$main$3 lambda$null$0 lambda$null$1 lambda$null$2 So, nested lambdas get bogus names and the annotations in their bodies are lost. I wonder if the underlying issue is the same (tested with b93)
          Hide
          sadayapalam Srikanth Adayapalam added a comment -
          There are at least three problems here:

          (1) Type annotations are dropped in some instances.
          (2) lambda names appear bogus in some instances
          (3) compiler should not optimize the cast away if the cast carries type annotations on them.
          Show
          sadayapalam Srikanth Adayapalam added a comment - There are at least three problems here: (1) Type annotations are dropped in some instances. (2) lambda names appear bogus in some instances (3) compiler should not optimize the cast away if the cast carries type annotations on them.
          Show
          sadayapalam Srikanth Adayapalam added a comment - See also: http://mail.openjdk.java.net/pipermail/compiler-dev/2015-December/009878.html
          Hide
          sadayapalam Srikanth Adayapalam added a comment -
          A correction to the earlier comment:

              (3) compiler should not optimize the cast away if the cast carries type annotations on them.

          While this sounds seductively logical, this can lead to problems for example in this case:

              int x = (@TA int) expression;

          Since checkcast can only work on reference types, we would generate a bad class file if we resort
          to this approach.

          The specification is being mended so that the offset involved will point to the checkcast where
          the cast is present and when not, it would point to slot where the checkcast would have been
          had it not been optimized.
          Show
          sadayapalam Srikanth Adayapalam added a comment - A correction to the earlier comment:     (3) compiler should not optimize the cast away if the cast carries type annotations on them. While this sounds seductively logical, this can lead to problems for example in this case:     int x = (@TA int) expression; Since checkcast can only work on reference types, we would generate a bad class file if we resort to this approach. The specification is being mended so that the offset involved will point to the checkcast where the cast is present and when not, it would point to slot where the checkcast would have been had it not been optimized.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3a9a4b5eabe4
          User: sadayapalam
          Date: 2016-01-28 03:39:46 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/3a9a4b5eabe4 User: sadayapalam Date: 2016-01-28 03:39:46 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/3a9a4b5eabe4
          User: lana
          Date: 2016-02-03 20:54:44 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/3a9a4b5eabe4 User: lana Date: 2016-02-03 20:54:44 +0000

            People

            • Assignee:
              sadayapalam Srikanth Adayapalam
              Reporter:
              webbuggrp Webbug Group
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: