La classe anonyme Java est très similaire à la fermeture Javascript, mais Java l'implémente de manière différente. (vérifier la réponse d'Andersen)
Donc, afin de ne pas confondre le développeur Java avec le comportement étrange qui peut se produire pour ceux qui viennent de l'arrière-plan Javascript. Je suppose que c'est pourquoi ils nous obligent à utiliser final
, ce n'est pas la limitation JVM.
Regardons l'exemple Javascript ci-dessous:
var add = (function () {
var counter = 0;
var func = function () {
console.log("counter now = " + counter);
counter += 1;
};
counter = 100; // line 1, this one need to be final in Java
return func;
})();
add(); // this will print out 100 in Javascript but 0 in Java
En Javascript, la counter
valeur sera 100, car il n'y en a qu'uncounter
variable du début à la fin.
Mais en Java, s'il n'y en a pas final
, il s'imprime 0
, car pendant la création de l'objet interne, la 0
valeur est copiée dans les propriétés cachées de l'objet de classe interne. (il y a deux variables entières ici, une dans la méthode locale, une autre dans les propriétés cachées de la classe interne)
Donc, tout changement après la création de l'objet intérieur (comme la ligne 1), cela n'affectera pas l'objet intérieur. Cela créera donc une confusion entre deux résultats et comportements différents (entre Java et Javascript).
Je crois que c'est pourquoi, Java décide de le forcer à être définitif, de sorte que les données sont «cohérentes» du début à la fin.