Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #28877 > unrolled thread

Assumed final?

Started byKnute Johnson <eternal@knutejohnson.com>
First post2014-06-30 10:28 -0700
Last post2014-07-01 18:54 +0800
Articles 3 — 3 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  Assumed final? Knute Johnson <eternal@knutejohnson.com> - 2014-06-30 10:28 -0700
    Re: Assumed final? markspace <markspace@nospam.nospam> - 2014-06-30 11:25 -0700
      Re: Assumed final? Peter <mcheung63@gmail.com> - 2014-07-01 18:54 +0800

#28877 — Assumed final?

FromKnute Johnson <eternal@knutejohnson.com>
Date2014-06-30 10:28 -0700
SubjectAssumed final?
Message-ID<los6o2$e1d$1@dont-email.me>
I always thought the code below would have generated a error on compile 
that frame wasn't final.  But I see when I compile it now with JDK 8 
that there is no error unless I make another assignment to frame.  If I 
uncomment the frame = null; statement, then I get the error;

C:\Users\Knute Johnson>javac test9.java
test9.java:17: error: local variables referenced from an inner class 
must be final or effectively final
                         frame.dispose();
                         ^
1 error

So it appears that the Java 8 compiler has gotten smarter or I haven't 
been paying enough attention :-).

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class test9 extends JPanel {
     public test9() {
         setPreferredSize(new Dimension(320,180));
         setBackground(Color.BLUE);
     }

     public static void main(String... args) {
         EventQueue.invokeLater(new Runnable() {
             public void run() {
                 JFrame frame = new JFrame("test9");
                 frame.addWindowListener(new WindowAdapter() {
                     public void windowClosing(WindowEvent we) {
                         frame.dispose();
                     }
                 });
                 frame.add(new test9(),BorderLayout.CENTER);
                 frame.pack();
                 frame.setVisible(true);

                 //frame = null;
             }
         });
     }
}


-- 

Knute Johnson

[toc] | [next] | [standalone]


#28879

Frommarkspace <markspace@nospam.nospam>
Date2014-06-30 11:25 -0700
Message-ID<losa30$abh$1@dont-email.me>
In reply to#28877
On 6/30/2014 10:28 AM, Knute Johnson wrote:

> So it appears that the Java 8 compiler has gotten smarter or I haven't
> been paying enough attention :-).
>

Gotten smarter, I think.  This was added for Java 8 lambdas.  So now 
instead of having to declare you variables final for anonymous inner 
classes/lambdas, the compiler can figure out if it is "effectively 
final" (note the text of your error message) and just assume you meant 
"final".

Handy for lambdas because it makes them less verbose in some situations 
and a bit more like their aged cousins, closures.

[toc] | [prev] | [next] | [standalone]


#28881

FromPeter <mcheung63@gmail.com>
Date2014-07-01 18:54 +0800
Message-ID<lou416$3a5$1@speranza.aioe.org>
In reply to#28879
於 1/7/14上午2:25, markspace 提到:
> On 6/30/2014 10:28 AM, Knute Johnson wrote:
>
>> So it appears that the Java 8 compiler has gotten smarter or I haven't
>> been paying enough attention :-).
>>
>
> Gotten smarter, I think.  This was added for Java 8 lambdas.  So now
> instead of having to declare you variables final for anonymous inner
> classes/lambdas, the compiler can figure out if it is "effectively
> final" (note the text of your error message) and just assume you meant
> "final".
>
> Handy for lambdas because it makes them less verbose in some situations
> and a bit more like their aged cousins, closures.

nice

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web