2016-10-05 2 views
2

Avec javac 1.8.0_77 cette classe ne compile pas:Pourquoi les lambas Java sont-ils traités différemment des classes imbriquées en ce qui concerne l'initialisation du champ d'instance?

import java.util.function.*; 
public class xx { 
    final Object obj; 

    final Supplier<Object> supplier1 = new Supplier<Object>() { 
     @Override 
     public Object get() { 
      return xx.this.obj; 
     } 
    }; 

    final Supplier<Object> supplier2 =() -> { return this.obj; }; 

    xx(Object obj) { 
     this.obj = obj; 
    } 
} 

est ici l'erreur:

xx.java:12: error: variable obj might not have been initialized 
    final Supplier<Object> supplier2 =() -> { return this.obj; }; 
                 ^
1 error 

Questions:

  1. est la génération de cette erreur correcte selon le JLS ? Si oui, quel est le raisonnement derrière le JLS traitant une implémentation @FunctionalInterface lamba (supplier2) différemment de son implémentation de classe interne équivalente (supplier1) à cet égard?

Merci.

Répondre

1

Naviguer à travers les changements JLS de JSR 335, cela ressemble à une omission de moi:

En fait, le seul changement est Chap.16 (en utilisant caractères gras pour les ajouts):

Throughout the rest of this chapter, we will, unless explicitly stated otherwise, write V to represent an in-scope (6.3) local variable or a blank final field (for rules of definite assignment) or a blank final variable (for rules of definite unassignment).

la ligne du bas, les compilateurs semblent être raison de ne pas se plaindre dans le lambda mais pour des raisons de cohérence, JLS devrait probablement être modifié pour couvrir également ce cas.

Éditer:: OpenJDK a déjà un spec bug pour cela, des changements sont proposés en ce moment même.

+0

Merci pour la référence de bogue. – Archie

+0

Le bug de spécification a été résolu, javac 9-ea + 142 rejette toujours le programme. –

+0

Avez-vous répondu à votre question? _ (Indice: accepter la réponse serait bien :)) _. –