Anonymous-Inner classes showing unwanted modifier
To my understanding, the following code should have printed true
.
However, when I ran this code it is printing false
.
From Java docs of Anonymous Classes 15.9.5. :
An anonymous class is always implicitly final
public class Test {
public static void main(String args) {
Object o = new Object() {
};
System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
}
}
Can some one please help me understand this behavior.
java final anonymous-class jls
add a comment |
To my understanding, the following code should have printed true
.
However, when I ran this code it is printing false
.
From Java docs of Anonymous Classes 15.9.5. :
An anonymous class is always implicitly final
public class Test {
public static void main(String args) {
Object o = new Object() {
};
System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
}
}
Can some one please help me understand this behavior.
java final anonymous-class jls
add a comment |
To my understanding, the following code should have printed true
.
However, when I ran this code it is printing false
.
From Java docs of Anonymous Classes 15.9.5. :
An anonymous class is always implicitly final
public class Test {
public static void main(String args) {
Object o = new Object() {
};
System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
}
}
Can some one please help me understand this behavior.
java final anonymous-class jls
To my understanding, the following code should have printed true
.
However, when I ran this code it is printing false
.
From Java docs of Anonymous Classes 15.9.5. :
An anonymous class is always implicitly final
public class Test {
public static void main(String args) {
Object o = new Object() {
};
System.out.println("Annonymous class is final: " + Modifier.isFinal(o.getClass().getModifiers()));
}
}
Can some one please help me understand this behavior.
java final anonymous-class jls
java final anonymous-class jls
edited Jan 3 at 13:37
Andrew Tobilko
27k104285
27k104285
asked Jan 3 at 9:10
Show StopperShow Stopper
5,1151964
5,1151964
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:
15.9.5. Anonymous Class Declarations:
An anonymous class is never final (§8.1.1.2).
The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).
This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.
The ticket that caused the change says:
Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.
Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.
2
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
1
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
add a comment |
An anonymous class is never
final
(§8.1.1.2).
JLS 11 - 15.9.5. Anonymous Class Declarations
I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.
3
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
add a comment |
Anonymous classes are considered implicitly final
since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL
modifier should be set for anonymous classes.
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
1
@ShowStopper well, it does follow the rules offinal
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.
– Moira
Jan 3 at 10:40
add a comment |
See Javadoc of Class.getModifiers()
:
https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()
It says "...The values of its other modifiers are not determined by this specification".
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54019203%2fanonymous-inner-classes-showing-unwanted-modifier%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:
15.9.5. Anonymous Class Declarations:
An anonymous class is never final (§8.1.1.2).
The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).
This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.
The ticket that caused the change says:
Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.
Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.
2
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
1
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
add a comment |
Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:
15.9.5. Anonymous Class Declarations:
An anonymous class is never final (§8.1.1.2).
The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).
This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.
The ticket that caused the change says:
Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.
Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.
2
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
1
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
add a comment |
Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:
15.9.5. Anonymous Class Declarations:
An anonymous class is never final (§8.1.1.2).
The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).
This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.
The ticket that caused the change says:
Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.
Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.
Note that the wording in the JLS of that particular section has changed significantly since then. It now (JLS 11) reads:
15.9.5. Anonymous Class Declarations:
An anonymous class is never final (§8.1.1.2).
The fact that an anonymous class is not final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (§5.5). It is also of interest in subclassing, in that it is impossible to declare a subclass of an anonymous class, despite an anonymous class being non-final, because an anonymous class cannot be named by an extends clause (§8.1.4).
This change in wording was introduced in JLS 9. The semantics of anonymous classes and the behavior of the methods in the question remained unchanged, the intention was to avoid exactly the kind of confusion this question is about.
The ticket that caused the change says:
Longstanding behavior of javac, since 1.3, has been, for the most part, not to treat the classes as 'final'. To address this inconsistency, the specification should be changed to accurately reflect the reference implementation.
Specifically, anonymous classes are almost never generated with the ACC_FINAL flag set. We can't change this longstanding behavior without impacting some serialization clients (this would be permissible, but is unnecessarily disruptive). And we can't faithfully implement Class.getModifers (which promises to provide the "Java language modifiers") without the class files encoding the language's modifiers.
edited Jan 3 at 9:42
answered Jan 3 at 9:23
HulkHulk
3,04712040
3,04712040
2
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
1
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
add a comment |
2
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
1
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
2
2
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
Though the spec has been updated, I don't think the old one is contradictory - just unclear. Anonymous classes are implicitly final in two senses: inherently (the developer cannot avoid it), and discreetly (not directly expressed - neither by the developer nor the class itself).
– Jacob Raihle
Jan 3 at 16:05
1
1
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
Yeah, the good old “change the specification to match what our … implementation does”…
– Holger
Jan 9 at 11:27
add a comment |
An anonymous class is never
final
(§8.1.1.2).
JLS 11 - 15.9.5. Anonymous Class Declarations
I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.
3
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
add a comment |
An anonymous class is never
final
(§8.1.1.2).
JLS 11 - 15.9.5. Anonymous Class Declarations
I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.
3
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
add a comment |
An anonymous class is never
final
(§8.1.1.2).
JLS 11 - 15.9.5. Anonymous Class Declarations
I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.
An anonymous class is never
final
(§8.1.1.2).
JLS 11 - 15.9.5. Anonymous Class Declarations
I didn't know the reasoning behind this, but, according to @Hulk's answer and this bug report, it seems the specification of previous versions slightly misled us saying that anonymous classes are final.
edited Jan 3 at 9:57
answered Jan 3 at 9:22
Andrew TobilkoAndrew Tobilko
27k104285
27k104285
3
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
add a comment |
3
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
3
3
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
You've linked to exactly the same section as the OP, but a more up-to-date version of the JLS. Perhaps it is worth describing why the discrepancy exists between the two versions rather than simply quoting the newer one.
– Michael
Jan 3 at 9:26
add a comment |
Anonymous classes are considered implicitly final
since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL
modifier should be set for anonymous classes.
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
1
@ShowStopper well, it does follow the rules offinal
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.
– Moira
Jan 3 at 10:40
add a comment |
Anonymous classes are considered implicitly final
since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL
modifier should be set for anonymous classes.
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
1
@ShowStopper well, it does follow the rules offinal
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.
– Moira
Jan 3 at 10:40
add a comment |
Anonymous classes are considered implicitly final
since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL
modifier should be set for anonymous classes.
Anonymous classes are considered implicitly final
since you can't create sub-classes of them. That doesn't mean that the Modifier.FINAL
modifier should be set for anonymous classes.
answered Jan 3 at 9:15
EranEran
281k37455541
281k37455541
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
1
@ShowStopper well, it does follow the rules offinal
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.
– Moira
Jan 3 at 10:40
add a comment |
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
1
@ShowStopper well, it does follow the rules offinal
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.
– Moira
Jan 3 at 10:40
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
When you say implicitly final, Does not that mean it is FINAL and should follow all the rules of Final keyword in java
– Show Stopper
Jan 3 at 10:32
1
1
@ShowStopper well, it does follow the rules of
final
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.– Moira
Jan 3 at 10:40
@ShowStopper well, it does follow the rules of
final
: you can't subclass them, because there's no way to refer to them as a type. I suppose is why they're implicitly final.– Moira
Jan 3 at 10:40
add a comment |
See Javadoc of Class.getModifiers()
:
https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()
It says "...The values of its other modifiers are not determined by this specification".
add a comment |
See Javadoc of Class.getModifiers()
:
https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()
It says "...The values of its other modifiers are not determined by this specification".
add a comment |
See Javadoc of Class.getModifiers()
:
https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()
It says "...The values of its other modifiers are not determined by this specification".
See Javadoc of Class.getModifiers()
:
https://docs.oracle.com/javase/10/docs/api/java/lang/Class.html#getModifiers()
It says "...The values of its other modifiers are not determined by this specification".
answered Jan 3 at 9:40
Prasad KarunagodaPrasad Karunagoda
57936
57936
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54019203%2fanonymous-inner-classes-showing-unwanted-modifier%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown