Usages included for a method accepting a lambda

[dmitry-timofeev]

Overview

If a method is included with block:<method_name> and this method is used in the same file with a lambda with curly braces, such usages are included as well.

E.g., with a file:

public final class Run {

  public static void main(String[] args) {
    var message = foo(() -> {
      return "hello, world!";
    });
    System.out.println(message);
  }

  private static String foo(Supplier<String> s) {
    return s.get();
  }
}

and a include declaration

<!--codeinclude-->
[Test](HelloWorld.java) block:foo
<!--/codeinclude-->

the following result will be produced:

    var message = foo(() -> {
      return "hello, world!";
    });

⋯

  private static String foo(Supplier<String> s) {
    return s.get();
  }

Workaround

There is a workaround using inside_block.

Patched source (note ci-foo tag):

public final class Run {

  public static void main(String[] args) {
    var message = foo(() -> {
      return "hello, world!";
    });
    System.out.println(message);
  }

  // ci-foo {
  private static String foo(Supplier<String> s) {
    return s.get();
  }
  // }
}

include delcaration:

<!--codeinclude-->
[Test](HelloWorld.java) inside_block:ci-foo
<!--/codeinclude-->

I wonder if that is the expected behaviour?

[rnorth]

Yes, this is actually intentional. The inclusion is intended to collect every block that is 'adjacent' to the matching substring.

It's simplistic and may not always be desirable, but I felt that it was a simple solution that (worst case) collects too much content, rather than having a complex solution to pick out which of many possible blocks is the right one.

I'm not sure if this could be made easier to work with, but would consider any suggestions!

[dmitry-timofeev]

I see, that makes perfect sense! Doing anything Java-specific will make it harder to support any source language.

[rnorth]

I'll mark this as closed, as the workaround you outline is probably just 'the way it should be used'.