woot! Must read for people learning Java
awesome anonymous inner classes :)
import javax.swing.*;
import java.awt.*;
publicclass Main
{
publicstaticvoid main(String[] args)
{
JFrame frame =new JFrame();
frame.setSize(400,200);
JPanel panel =new JPanel()
{
publicvoid paintComponent(Graphics g)
{
super.paintComponent(g);
g.fillOval(0,0,40,40);
}
};
frame.add(panel);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setVisible(true);
}
}
wrote it myself
[1172 byte] By [
mnix_a] at [2007-10-2 21:45:33]
WOW! ANONYMOUS INNER CLASSES!THAT IS SOOO COOL! I MUST USE THEM IN MY NEXT PROJECT!!I went through the compiler in a class with no name.
I don't recommend doing this. it makes debugging more difficult, especially for other people. just ask my co-workers :-)
I should add that I meant specifically anonymous inner dialogs and such. a guy I work with spent ages looking for this mysterious dialog that kept popping up, until he finally cracked and asked me :-)
Message was edited by:
georgemc
also java bytecode has no concept of inner classes, so the compiler translates inner classes into ordinary classes that are accessible to any code in the same package. An inner class gets access to the fields of the enclosing outer class梕ven if these fields are declared private梐nd the inner class is translated into a separate class. To let this separate class access the fields of the outer class, the compiler silently changes these fields' scope from private to package. As a result, when you use inner classes, you not only have the inner class exposed, but you also have the compiler silently overruling your decision to make some fields private.
> An inner class gets access to the
> fields of the enclosing outer class梕ven if these
> fields are declared private梐nd the inner class is
> translated into a separate class. To let this
> separate class access the fields of the outer class,
> the compiler silently changes these fields' scope
> from private to package.
> As a result, when you use
> inner classes, you not only have the inner class
> exposed, but you also have the compiler silently
> overruling your decision to make some fields private.
Can you point to a source for this? I thought inner classes get access to the outer class' fields through synthetic accessors (available only to the outer class). Surely the access specifier isn't silently changed from private to package.
Unless you can come up with very strong evidence, I am quire sure the presence of inner classes does not affect the accessibility of a class' fields. Not even under the hood.
Lokoa at 2007-7-14 1:01:07 >
>I thought inner classes get access to the outer class' fields through synthetic accessors This statement is correct - the statement which it refutes is indeed invalid.
> Can you point to a source for this? I thought inner
> classes get access to the outer class' fields through
> synthetic accessors (available only to the outer
> class). Surely the access specifier isn't silently
> changed from private to package.
> Unless you can come up with very strong evidence, I
> am quire sure the presence of inner classes does not
> affect the accessibility of a class' fields. Not even
> under the hood.
http://www.ftponline.com/javapro/2004_03/online/rule2_03_17_04/
http://www.owasp.org/index.php/Publicizing_of_private_data_when_using_inner_classes
http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules_p.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4097812
> Surely the access specifier isn't silently
> changed from private to package.
> Unless you can come up with very strong evidence, I
> am quire sure the presence of inner classes does not
> affect the accessibility of a class' fields. Not even
> under the hood.
This statement is correct.
No modifier is changed.
A package protected accessor (with the name access$nnn - where nnn is some number) is generated.
This provides read-only access for the package, and as mentioned, if such data is critical, sealed packages and security manager should be used.
If you find yourself doing this:
if (foo.access$000(outerClassInstance).equals(GREEN))
...
Then thats your own **** problem.
> > Surely the access specifier isn't silently
> > changed from private to package.
> > Unless you can come up with very strong evidence,
> I
> > am quire sure the presence of inner classes does
> not
> > affect the accessibility of a class' fields. Not
> even
> > under the hood.
>
> This statement is correct.
> No modifier is changed.
>
> A package protected accessor (with the name
> access$nnn - where nnn is some number) is generated.
>
> This provides read-only access for the package, and
> as mentioned, if such data is critical, sealed
> packages and security manager should be used.
> If you find yourself doing this:
> [code]
> if
> (foo.access$000(outerClassInstance).equals(GREEN))
>...
> code]
> Then thats your own **** problem.
And all these people in these articles are idiots who should ve contacted Schneider
http://www.ftponline.com/javapro/2004_03/online/rule2_03_17_04/
http://www.owasp.org/index.php/Publicizing_of_private_data_when_using_inner_classes
http://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules_p.html
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4097812
>And all these people in these articles are idiots who should ve contacted SchneiderNot at all. But if you are going to argue that field modifiers are silently and secretly changed, then I suggest you re-read said articles.
> >And all these people in these articles are idiots
> who should ve contacted Schneider
>
> Not at all. But if you are going to argue that field
> modifiers are silently and secretly changed, then I
> suggest you re-read said articles.
Indeed. Only the 3rd article states that the access is changed, and that's just incorrect. Inner classes use synthetic accessors, as is confirmed in the bug report evaluation.
Lokoa at 2007-7-14 1:01:07 >
