{"id":1347,"date":"2012-07-12T22:43:54","date_gmt":"2012-07-12T20:43:54","guid":{"rendered":"http:\/\/doanduyhai.wordpress.com\/?p=1347"},"modified":"2012-07-12T22:43:54","modified_gmt":"2012-07-12T20:43:54","slug":"java-8-lambda-in-details-part-ii-scoping-of-this-and-effectively-final-variable-semantic","status":"publish","type":"post","link":"https:\/\/www.doanduyhai.com\/blog\/?p=1347","title":{"rendered":"Java 8 Lambda in details part II : Scoping of “this” and “effectively final” variable semantic"},"content":{"rendered":"

In this second post, we’ll look at the scoping of the this<\/strong> keyword inside a lambda expression and the semantic of the so called “effectively final<\/em>” local variables.
\n<\/p>\n

DISCLAIMER: all the details exposed in this post were observed related to the JDK 8 demo version as of July 10th 2012<\/font>. Since the JDK is still in beta, some assertions may not hold in future<\/strong>\n<\/p><\/blockquote>\n

Please note that all the example code in this post can be found on my GitHub repository https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a><\/p><\/blockquote>\n

 <\/p>\n

I Scoping of “this”<\/h1>\n

First, as a reminder, below are the principal variable scopes in Java<\/p>\n

    \n
  1. class level scope<\/strong>: the variable is accessible anywhere in the class, either statically or dynamically at class instance creation<\/li>\n
  2. Method scope<\/strong>: the variable is accessible only in the declaring method<\/li>\n
  3. Code block scope<\/strong>: the variable is accessible only in the declaring code block. A code block is a portion of code enclosed in braces {…}<\/strong>. Loops like for<\/strong>, do<\/strong>, while<\/strong> as well as static<\/strong> and synchronized<\/strong> blocks are considered code block <\/li>\n<\/ol>\n

    Unlike anonymous functions, a lambda expression can be considered as a simple code block with regarde to variable scoping. Consequently all scoping rules for code blocks also apply to lambda expression.<\/p>\n

    Let’s look at the below code:<\/p>\n

    \npublic class MutableObject\n{\n\tprivate String content = &quot;default_content&quot;;\n\t...\n}\npublic class ScopingOfThis\n{\n\tfinal public MutableObject mutable = new MutableObject();\n\n\tpublic VariableCaptureInClosureSAM createClosure()\n\t{\n\t\tVariableCaptureInClosureSAM lambda = ()-&gt;\n\t\t{\t\t\n\t\t\tMutableObject mutable = new MutableObject();\n\t\t\tmutable.setContent(&quot;from_closure&quot;);\n\t\n\t\t\treturn this.mutable;\n\t\t};\n\n\t\treturn lambda;\n\t}\n\n\tpublic VariableCaptureInClosureSAM createAnonymous()\n\t{\n\t\tVariableCaptureInClosureSAM anonymousClass = new VariableCaptureInClosureSAM()\n\t\t{\n\t\t\tMutableObject mutable = new MutableObject();\n\n\t\t\t@Override\n\t\t\tpublic MutableObject retrieveMutable()\n\t\t\t{\n\t\t\t\tthis.mutable.setContent(&quot;from_anonymous&quot;);\n\t\t\t\treturn this.mutable;\n\t\t\t}\n\n\t\t};\n\n\t\treturn anonymousClass;\n\n\t}\n\n\tpublic static void main(String[] args)\n\t{\n\t\tScopingOfThis scopingOfThis = new ScopingOfThis();\n\t\tVariableCaptureInClosureSAM sam = scopingOfThis.createClosure();\n\n\t\tMutableObject mutableFromClosure = sam.retrieveMutable();\n\t\tSystem.out.println(&quot;nmutableFromClosure content = &quot; + mutableFromClosure.getContent());\n\n\t\tMutableObject mutableFromAnonymous = scopingOfThis.createAnonymous().retrieveMutable();\n\t\tSystem.out.println(&quot;mutableFromAnonymous content = &quot; + mutableFromAnonymous.getContent());\n\t\tSystem.out.println(&quot;&quot;);\n\t}\n}\n<\/pre>\n
     At line 17<\/strong> in the lambda expression, the this keyword is used to distinguish the class level mutable field from the local mutable (“from_closure”) field.<\/p>\n
     At line 33<\/strong> in the anonymous class, the this<\/strong>.mutable<\/em> refers to the mutable field declared in the anonymous class only (line 27<\/strong>)<\/p>\n
     Not surprisingly, the output gives<\/p>\n
    \nmutableFromClosure content = default_content<\/strong>
    \nmutableFromAnonymous content = from_anonymous<\/strong>\n<\/p><\/blockquote>\n
     Now, what if we declare a local mutable field in the createClosure()<\/em> method before creating the lambda expression ?<\/p>\n
    \n\tpublic VariableCaptureInClosureSAM createClosure()\n\t{\t\n\t\tMutableObject mutable = new MutableObject();\n\t\t\n\t\tVariableCaptureInClosureSAM lambda = ()-&gt;\n\t\t{\t\n\t\t\tMutableObject mutable = new MutableObject();\n\t\t\tmutable.setContent(&quot;from_closure&quot;);\n\t\t\t\n\t\t\treturn this.mutable;\n\t\t};\n\n\t\treturn lambda;\n\t}\n<\/pre>\n
     The compilation will fail with the error<\/p>\n
    \nScopingOfThis.java:16: error: variable mutable is already defined in method createClosure()
    \n        MutableObject mutable<\/strong> = new MutableObject();
    \n                                   ^\n<\/p><\/blockquote>\n
     No surprise here. As in a normal code block you cannot declare a local variable with the same name (the type doesn’t matter) if it already exists in the current lexical scope<\/strong>.<\/p>\n
    The above code example can be found on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the ScopingOfThis.bat(ScopingOfThis.sh)<\/strong> script<\/p><\/blockquote>\n
     <\/p>\n
    II “Effectively final” semantic for local variables<\/h1>\n
     In the JDK 7, variable from enclosing class can be used in anonymous functions only if they are declared final<\/strong>. With the JDK 8 this constraint has been relaxed both for lambda expressions and inner classes<\/strong>. It is so called “effectively final<\/strong>” if the variable initial value does not change. But what is the initial value ? It is its reference ? Is it its state ? The litterature is very vague about the fact (http:\/\/cr.openjdk.java.net\/~briangoetz\/lambda\/lambda-state-4.htm<\/a> chapter 7)<\/p>\n
     The best way to clarify it is testing.<\/p>\n
    \npublic class LocalEffectivelyFinalVariable\n{\n\tpublic VariableShadowingSAM retrieveVariableShadowingSAM()\n\t{\n\t\tList&lt;String&gt; textList = new ArrayList&lt;String&gt;();\n\t\ttextList.add(&quot;default&quot;);\n\t\tVariableShadowingSAM sam = () -&gt;\n\t\t{\n\t\t\treturn textList.get(0);\n\t\t};\n\n\t\ttextList.clear();\n\t\ttextList.add(&quot;changed_default&quot;);\n\t\treturn sam;\n\t}\n\n\tpublic static void main(String... args)\n\t{\n\t\tLocalEffectivelyFinalVariable variableShadowing = new LocalEffectivelyFinalVariable();\n\t\tString text = variableShadowing.retrieveVariableShadowingSAM().process();\n\t\tSystem.out.println(&quot;nnttext = &quot; + text);\n\t\tSystem.out.println(&quot;&quot;);\n\n\t}\n}\n<\/pre>\n
     In the above code, after initializing the list with “default<\/strong>” (line 6<\/strong>), the lambda expression is created and returns the first element of this list (line 9<\/strong>).<\/p>\n
     Right after lambda declaration, the list is cleared and initialized to “changed_default” (lines 12-13<\/strong>).<\/p>\n
     How is the local “effectively final<\/strong>” textList<\/em> variable captured ? 2 implementations are possible:<\/p>\n
      \n
    1. either the lambda catures the reference on the returned object, which is the “default<\/strong>” string (testList.get(0)<\/em>). It means that any subsequent change in the textList<\/em> would not affect the returned value at runtime<\/li>\n
    2. or the lambda only captures the reference on the textList<\/em> variable and delays get(0)<\/em> invocation at runtime. This second implementation makes the returned value unpredictable since the textList<\/em> can be changed after lambda definition<\/li>\n<\/ol>\n
       The output displays:<\/p>\n
       text = changed_default<\/strong><\/p><\/blockquote>\n
       This result clearly demonstrates that the second implementation has been chosen for JDK 8. The lambda only keeps the reference on local variable and method invocation is performed at runtime !<\/strong><\/p>\n
      Now what if we change the reference on the textList<\/em> variable after lambda expression creation ?<\/p>\n
      \n\tpublic VariableShadowingSAM retrieveVariableShadowingSAM()\n\t{\n\t\tList&lt;String&gt; textList = new ArrayList&lt;String&gt;();\n\t\ttextList.add(&quot;default&quot;);\n\t\tVariableShadowingSAM sam = () -&gt;\n\t\t{\n\t\t\treturn textList.get(0);\n\t\t};\n\t\ttextList = new ArrayList&lt;String&gt;();\n\t\ttextList.add(&quot;new_instance&quot;);\n\n\t\treturn sam;\n\t}\n<\/pre>\n
      The output displays:<\/p>\n
       text = default<\/strong><\/p><\/blockquote>\n
       This result confirms our previous analysis. The lambda keeps the reference on the old textList<\/em> instance. Even though the local textList<\/em> has been assigned a new instance of ArrayList with a “new_instance<\/strong>” value, the lambda execution at runtime still displays “default<\/strong>“. <\/p>\n
       This is the true meaning of “effectively final”. The lambda capture the reference of your local variable in its declaration. No matter how the variable is assigned a new reference afterward, the old reference is still hold by the lambda. It is as if the variable was declared final in the end.<\/font><\/strong><\/p>\n
       It is interesting to compare JDK 8 closure implementation with Javascript implementation<\/strong>. If you’re familiar with Javascript internals you should know that a closure in Javascript keeps reference to the local variables through scope chain<\/strong>.<\/p>\n
      \nfunction getClosure()\n{\n    var text=&quot;default&quot;;\n\n    var closure = function()\n    {\n        return text;\n    }\n\n    text=&quot;changed_default&quot;;\n\n    return closure;\n}\n<\/pre>\n
      \n>getClosure()();
      \n
      \n>”changed_default”\n<\/p><\/blockquote>\n
      At runtime, when the closure is invoked, it will look for the text<\/em> variable in its scope chain. Since the getClosure <\/strong>function (object) is in the chain, the text<\/em> reference is returned. The displayed value corresponds to the last known value for text<\/em>, which was “changed_default<\/strong>“.<\/p>\n
       It is very similar to the capture of the this<\/strong> reference by lambda expression in Java discussed in the previous article.<\/p>\n
      The above code example can be found on GitHub at https:\/\/github.com\/doanduyhai\/Java8_Lambda_In_Details<\/a>. Just execute the LocalEffectivelyFinalVariable.bat(LocalEffectivelyFinalVariable.sh)<\/strong> script<\/p><\/blockquote>\n
      To be continued …
      \n 
      \n <\/p>\n","protected":false},"excerpt":{"rendered":"
      In this second post, we’ll look at the scoping of the this keyword inside a lambda expression and the semantic of the so called “effectively final” local variables.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,8],"tags":[],"_links":{"self":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1347"}],"collection":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1347"}],"version-history":[{"count":0,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1347\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.doanduyhai.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}