My lambda leftovers

Remi Forax forax at
Fri Oct 6 11:16:19 UTC 2017

Hi all,
The JEP 302 list some improvements but I think some are missing, obviously, it's up to debate :)

So here is my list of left leftovers:
- support throw statement as a lambda expression

  I think we have already discussed informally about this one.
  The compiler should allow to have a lambda expression that starts with throw.

  so a code like this will become valid
  merge(key, value, (_, _) -> throw new IllegalStateException("key " + key + " already present));

- allow void to be converted to Void (by returning null)
  This proposal is perhaps more controversial, currently there is no way to simply convert a lambda statement to a lambda expression.
  So a code like will compile

   <T, R> R sync(T initial, Function<? super T, ? extends R> fun) {
    synchronized(lock) {
      return fun.apply(initial);

  Consumer<String> c = System.out::println;
  sync("foo", c::accept);     // the compiler should generate a synthetic static method that returns null 
  This proposal is problematic because:
  - it implicitly produces a null, which is a bad idea
  - if there are several overloads, a lambda statement can now match more methods so the compiler may reject code that was previously working or worst call another method that the one that was originally selected.
 The other question is should the conversion be extended to work with non lambda code,
 i.e. consider that 'return' or an implcit 'return' can be trasformed to a return null by the compiler. 

  Void m() {
    return;     // the compiler generates return null;

  Void m() { }  // the compiler generates return null;

 On the positive side, it mix well with the switch expression proposed in the Pattern Matching JEP.

  Supplier<Void> supplier =
      () -> switchexpr(someValue) {
                case 0 -> System.out.println("foo");
                default -> { /* empty */ }



More information about the amber-spec-experts mailing list