Why can't we use uninitialized local variable to access static content of its type?Are static class variables...
Is it safe to unplug a blinking USB drive after 'safely' ejecting it?
Microservices and Stored Procedures
Is a global DNS record a security risk for phpMyAdmin?
Did slaves have slaves?
How could artificial intelligence harm us?
What is the origin of the "being immortal sucks" trope?
What is the word for a person who destroys monuments?
What to do as a player when ranger animal companion dies
Why are two-stroke engines nearly unheard of in aviation?
As an employer, can I compel my employees to vote?
Talk about Grandpa's weird talk: Who are these folks?
Who are the people reviewing far more papers than they're submitting for review?
Does rpcpassword need to be non-obvious in bitcoind?
Is Yang not precluded from conducting his "UBI experiment" as an electoral candidate?
We suspect colleague is stealing company code - what do we do?
EU compensation - fire alarm at the Flight Crew's hotel
Is there an in-universe reason Harry says this or is this simply a Rowling mistake?
In Game Behavior vs. Out of Game Consequences
How to convey to the people around me that I want to disengage myself from constant giving?
Is this adjustment to the Lucky feat underpowered?
Hobby function generators
Problem of Induction: Dissolved
If people's daily habits are reliable then why is the stock market so unpredictable?
What was the deeper meaning of Hermione wanting the cloak?
Why can't we use uninitialized local variable to access static content of its type?
Are static class variables possible in Python?Why is the Java main method static?Why can't I use switch statement on a String?Why can't static methods be abstract in JavaStatic variables in JavaScriptWhy doesn't Java allow overriding of static methods?Can a local variable's memory be accessed outside its scope?Why are static variables considered evil?Why attempt to print uninitialized variable does not always result in an error message
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
class Foo{
public static int x = 1;
public static void main(String[] args) {
Foo foo;
System.out.println(foo.x); // Error: Variable 'foo' might not have been initialized
}
}
While trying to access x
via an uninitialized local variable Foo foo;
I get the compile error Variable 'foo' might not have been initialized
.
It could seem like this error makes sense, but only until we realize that to access a static
member the compiler doesn't use the value of a variable, but only its type.
For instance I can initialize foo
with value null
and this will let us access x
without any problems:
Foo foo = null;
System.out.println(foo.x);//Now it works!!!
Such scenario works because compiler realizes that x
is static and treats foo.x
as it was written Foo.x
(at least that is what I thought until now).
So why compiler suddenly insists on foo
having a value which it will NOT use at that place?
(Disclaimer: This is not code which would be used in real application, just interesting phenomenon which I couldn't find answer to on Stack Overflow so I decided to ask about it.)
java static initialization local-variables jls
|
show 5 more comments
class Foo{
public static int x = 1;
public static void main(String[] args) {
Foo foo;
System.out.println(foo.x); // Error: Variable 'foo' might not have been initialized
}
}
While trying to access x
via an uninitialized local variable Foo foo;
I get the compile error Variable 'foo' might not have been initialized
.
It could seem like this error makes sense, but only until we realize that to access a static
member the compiler doesn't use the value of a variable, but only its type.
For instance I can initialize foo
with value null
and this will let us access x
without any problems:
Foo foo = null;
System.out.println(foo.x);//Now it works!!!
Such scenario works because compiler realizes that x
is static and treats foo.x
as it was written Foo.x
(at least that is what I thought until now).
So why compiler suddenly insists on foo
having a value which it will NOT use at that place?
(Disclaimer: This is not code which would be used in real application, just interesting phenomenon which I couldn't find answer to on Stack Overflow so I decided to ask about it.)
java static initialization local-variables jls
2
I'd say a limitation in the compiler that isn't really worth fixing, given that the code raises a warning anyway.
– manouti
10 hours ago
1
@manouti That is also my guess, but I am still interested in why compiler behaves that way. Which part of specification forces it?
– Pshemo
10 hours ago
I think the compiler is less concerned with initialization (even though that is the warning) as it is with the null pointer exception you are creating. The reference to the initialization is the compiler trying to give reason to why you may have a potential null pointer exception.
– portfoliobuilder
10 hours ago
2
@portfoliobuilder There is no risk of NPE here since as mentioned in question, in case of accessingstatic
member compiler doesn't use value of variable but its type. We can even write((Foo)null).x
and this will compile and work because compiler will recognize thatx
is static (unless I misunderstood your comment).
– Pshemo
10 hours ago
3
Accessing a static variable from a non-static context (such asfoo.x
) should have been a compiler error when Java was first created. Sadly, that ship sailed over 25 years ago and would be a breaking change if they changed it now.
– Powerlord
9 hours ago
|
show 5 more comments
class Foo{
public static int x = 1;
public static void main(String[] args) {
Foo foo;
System.out.println(foo.x); // Error: Variable 'foo' might not have been initialized
}
}
While trying to access x
via an uninitialized local variable Foo foo;
I get the compile error Variable 'foo' might not have been initialized
.
It could seem like this error makes sense, but only until we realize that to access a static
member the compiler doesn't use the value of a variable, but only its type.
For instance I can initialize foo
with value null
and this will let us access x
without any problems:
Foo foo = null;
System.out.println(foo.x);//Now it works!!!
Such scenario works because compiler realizes that x
is static and treats foo.x
as it was written Foo.x
(at least that is what I thought until now).
So why compiler suddenly insists on foo
having a value which it will NOT use at that place?
(Disclaimer: This is not code which would be used in real application, just interesting phenomenon which I couldn't find answer to on Stack Overflow so I decided to ask about it.)
java static initialization local-variables jls
class Foo{
public static int x = 1;
public static void main(String[] args) {
Foo foo;
System.out.println(foo.x); // Error: Variable 'foo' might not have been initialized
}
}
While trying to access x
via an uninitialized local variable Foo foo;
I get the compile error Variable 'foo' might not have been initialized
.
It could seem like this error makes sense, but only until we realize that to access a static
member the compiler doesn't use the value of a variable, but only its type.
For instance I can initialize foo
with value null
and this will let us access x
without any problems:
Foo foo = null;
System.out.println(foo.x);//Now it works!!!
Such scenario works because compiler realizes that x
is static and treats foo.x
as it was written Foo.x
(at least that is what I thought until now).
So why compiler suddenly insists on foo
having a value which it will NOT use at that place?
(Disclaimer: This is not code which would be used in real application, just interesting phenomenon which I couldn't find answer to on Stack Overflow so I decided to ask about it.)
java static initialization local-variables jls
java static initialization local-variables jls
edited 7 hours ago
Andrew Tobilko
35.1k10 gold badges54 silver badges105 bronze badges
35.1k10 gold badges54 silver badges105 bronze badges
asked 10 hours ago
PshemoPshemo
99.7k17 gold badges141 silver badges200 bronze badges
99.7k17 gold badges141 silver badges200 bronze badges
2
I'd say a limitation in the compiler that isn't really worth fixing, given that the code raises a warning anyway.
– manouti
10 hours ago
1
@manouti That is also my guess, but I am still interested in why compiler behaves that way. Which part of specification forces it?
– Pshemo
10 hours ago
I think the compiler is less concerned with initialization (even though that is the warning) as it is with the null pointer exception you are creating. The reference to the initialization is the compiler trying to give reason to why you may have a potential null pointer exception.
– portfoliobuilder
10 hours ago
2
@portfoliobuilder There is no risk of NPE here since as mentioned in question, in case of accessingstatic
member compiler doesn't use value of variable but its type. We can even write((Foo)null).x
and this will compile and work because compiler will recognize thatx
is static (unless I misunderstood your comment).
– Pshemo
10 hours ago
3
Accessing a static variable from a non-static context (such asfoo.x
) should have been a compiler error when Java was first created. Sadly, that ship sailed over 25 years ago and would be a breaking change if they changed it now.
– Powerlord
9 hours ago
|
show 5 more comments
2
I'd say a limitation in the compiler that isn't really worth fixing, given that the code raises a warning anyway.
– manouti
10 hours ago
1
@manouti That is also my guess, but I am still interested in why compiler behaves that way. Which part of specification forces it?
– Pshemo
10 hours ago
I think the compiler is less concerned with initialization (even though that is the warning) as it is with the null pointer exception you are creating. The reference to the initialization is the compiler trying to give reason to why you may have a potential null pointer exception.
– portfoliobuilder
10 hours ago
2
@portfoliobuilder There is no risk of NPE here since as mentioned in question, in case of accessingstatic
member compiler doesn't use value of variable but its type. We can even write((Foo)null).x
and this will compile and work because compiler will recognize thatx
is static (unless I misunderstood your comment).
– Pshemo
10 hours ago
3
Accessing a static variable from a non-static context (such asfoo.x
) should have been a compiler error when Java was first created. Sadly, that ship sailed over 25 years ago and would be a breaking change if they changed it now.
– Powerlord
9 hours ago
2
2
I'd say a limitation in the compiler that isn't really worth fixing, given that the code raises a warning anyway.
– manouti
10 hours ago
I'd say a limitation in the compiler that isn't really worth fixing, given that the code raises a warning anyway.
– manouti
10 hours ago
1
1
@manouti That is also my guess, but I am still interested in why compiler behaves that way. Which part of specification forces it?
– Pshemo
10 hours ago
@manouti That is also my guess, but I am still interested in why compiler behaves that way. Which part of specification forces it?
– Pshemo
10 hours ago
I think the compiler is less concerned with initialization (even though that is the warning) as it is with the null pointer exception you are creating. The reference to the initialization is the compiler trying to give reason to why you may have a potential null pointer exception.
– portfoliobuilder
10 hours ago
I think the compiler is less concerned with initialization (even though that is the warning) as it is with the null pointer exception you are creating. The reference to the initialization is the compiler trying to give reason to why you may have a potential null pointer exception.
– portfoliobuilder
10 hours ago
2
2
@portfoliobuilder There is no risk of NPE here since as mentioned in question, in case of accessing
static
member compiler doesn't use value of variable but its type. We can even write ((Foo)null).x
and this will compile and work because compiler will recognize that x
is static (unless I misunderstood your comment).– Pshemo
10 hours ago
@portfoliobuilder There is no risk of NPE here since as mentioned in question, in case of accessing
static
member compiler doesn't use value of variable but its type. We can even write ((Foo)null).x
and this will compile and work because compiler will recognize that x
is static (unless I misunderstood your comment).– Pshemo
10 hours ago
3
3
Accessing a static variable from a non-static context (such as
foo.x
) should have been a compiler error when Java was first created. Sadly, that ship sailed over 25 years ago and would be a breaking change if they changed it now.– Powerlord
9 hours ago
Accessing a static variable from a non-static context (such as
foo.x
) should have been a compiler error when Java was first created. Sadly, that ship sailed over 25 years ago and would be a breaking change if they changed it now.– Powerlord
9 hours ago
|
show 5 more comments
3 Answers
3
active
oldest
votes
§15.11. Field Access Expressions:
If the field is static:
The Primary expression is evaluated, and the result is discarded. If evaluation of the Primary expression completes abruptly, the field access expression completes abruptly for the same reason.
Where earlier it states that field access is identified by Primary.Identifier
.
This shows that even though it seems to not use the Primary
, it is still evaluated and the result is then discarded which is why it will need to be initialized. This can make a difference when the evaluation halts the access as stated in the quote.
add a comment
|
Chapter 16. Definite Assignment
Each local variable (§14.4) and every blank final field (§4.12.4, §8.3.1.2) must have a definitely assigned value when any access of its value occurs.
It doesn't really matter what you try to access via a local variable. The rule is that it should be definitely assigned before that.
To evaluate a field access expression foo.x
, the primary
part of it (foo
) must be evaluated first. It means that access to foo
will occur, which will result in a compile-time error.
For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs.
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
Since Nexevis was first to show place in specification which forces primary expression (herefoo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.
– Pshemo
8 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
add a comment
|
There is value in keeping the rules as simple as possible, and “don’t use a variable that might not have been initialised” is as simple as it gets.
More to the point, there is an established way of calling static methods - always use the class name, not a variable.
System.out.println(Foo.x);
The variable “foo” is unwanted overhead that should be removed, and the compiler errors and warnings could be seen as helping leading towards that.
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/4.0/"u003ecc by-sa 4.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%2f57964026%2fwhy-cant-we-use-uninitialized-local-variable-to-access-static-content-of-its-ty%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
§15.11. Field Access Expressions:
If the field is static:
The Primary expression is evaluated, and the result is discarded. If evaluation of the Primary expression completes abruptly, the field access expression completes abruptly for the same reason.
Where earlier it states that field access is identified by Primary.Identifier
.
This shows that even though it seems to not use the Primary
, it is still evaluated and the result is then discarded which is why it will need to be initialized. This can make a difference when the evaluation halts the access as stated in the quote.
add a comment
|
§15.11. Field Access Expressions:
If the field is static:
The Primary expression is evaluated, and the result is discarded. If evaluation of the Primary expression completes abruptly, the field access expression completes abruptly for the same reason.
Where earlier it states that field access is identified by Primary.Identifier
.
This shows that even though it seems to not use the Primary
, it is still evaluated and the result is then discarded which is why it will need to be initialized. This can make a difference when the evaluation halts the access as stated in the quote.
add a comment
|
§15.11. Field Access Expressions:
If the field is static:
The Primary expression is evaluated, and the result is discarded. If evaluation of the Primary expression completes abruptly, the field access expression completes abruptly for the same reason.
Where earlier it states that field access is identified by Primary.Identifier
.
This shows that even though it seems to not use the Primary
, it is still evaluated and the result is then discarded which is why it will need to be initialized. This can make a difference when the evaluation halts the access as stated in the quote.
§15.11. Field Access Expressions:
If the field is static:
The Primary expression is evaluated, and the result is discarded. If evaluation of the Primary expression completes abruptly, the field access expression completes abruptly for the same reason.
Where earlier it states that field access is identified by Primary.Identifier
.
This shows that even though it seems to not use the Primary
, it is still evaluated and the result is then discarded which is why it will need to be initialized. This can make a difference when the evaluation halts the access as stated in the quote.
answered 9 hours ago
NexevisNexevis
2,1132 gold badges5 silver badges13 bronze badges
2,1132 gold badges5 silver badges13 bronze badges
add a comment
|
add a comment
|
Chapter 16. Definite Assignment
Each local variable (§14.4) and every blank final field (§4.12.4, §8.3.1.2) must have a definitely assigned value when any access of its value occurs.
It doesn't really matter what you try to access via a local variable. The rule is that it should be definitely assigned before that.
To evaluate a field access expression foo.x
, the primary
part of it (foo
) must be evaluated first. It means that access to foo
will occur, which will result in a compile-time error.
For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs.
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
Since Nexevis was first to show place in specification which forces primary expression (herefoo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.
– Pshemo
8 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
add a comment
|
Chapter 16. Definite Assignment
Each local variable (§14.4) and every blank final field (§4.12.4, §8.3.1.2) must have a definitely assigned value when any access of its value occurs.
It doesn't really matter what you try to access via a local variable. The rule is that it should be definitely assigned before that.
To evaluate a field access expression foo.x
, the primary
part of it (foo
) must be evaluated first. It means that access to foo
will occur, which will result in a compile-time error.
For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs.
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
Since Nexevis was first to show place in specification which forces primary expression (herefoo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.
– Pshemo
8 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
add a comment
|
Chapter 16. Definite Assignment
Each local variable (§14.4) and every blank final field (§4.12.4, §8.3.1.2) must have a definitely assigned value when any access of its value occurs.
It doesn't really matter what you try to access via a local variable. The rule is that it should be definitely assigned before that.
To evaluate a field access expression foo.x
, the primary
part of it (foo
) must be evaluated first. It means that access to foo
will occur, which will result in a compile-time error.
For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs.
Chapter 16. Definite Assignment
Each local variable (§14.4) and every blank final field (§4.12.4, §8.3.1.2) must have a definitely assigned value when any access of its value occurs.
It doesn't really matter what you try to access via a local variable. The rule is that it should be definitely assigned before that.
To evaluate a field access expression foo.x
, the primary
part of it (foo
) must be evaluated first. It means that access to foo
will occur, which will result in a compile-time error.
For every access of a local variable or blank final field x, x must be definitely assigned before the access, or a compile-time error occurs.
edited 9 hours ago
answered 9 hours ago
Andrew TobilkoAndrew Tobilko
35.1k10 gold badges54 silver badges105 bronze badges
35.1k10 gold badges54 silver badges105 bronze badges
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
Since Nexevis was first to show place in specification which forces primary expression (herefoo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.
– Pshemo
8 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
add a comment
|
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
Since Nexevis was first to show place in specification which forces primary expression (herefoo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.
– Pshemo
8 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
I think correct answer is combination of yours and Nexevis. Now I need to figure out which one to accept...
– Pshemo
9 hours ago
Since Nexevis was first to show place in specification which forces primary expression (here
foo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.– Pshemo
8 hours ago
Since Nexevis was first to show place in specification which forces primary expression (here
foo
) to be evaluated regardless of its result I decided to accept his answer. Hope you don't mind.– Pshemo
8 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
@Pshemo I am absolutely fine with your decision :)
– Andrew Tobilko
7 hours ago
add a comment
|
There is value in keeping the rules as simple as possible, and “don’t use a variable that might not have been initialised” is as simple as it gets.
More to the point, there is an established way of calling static methods - always use the class name, not a variable.
System.out.println(Foo.x);
The variable “foo” is unwanted overhead that should be removed, and the compiler errors and warnings could be seen as helping leading towards that.
add a comment
|
There is value in keeping the rules as simple as possible, and “don’t use a variable that might not have been initialised” is as simple as it gets.
More to the point, there is an established way of calling static methods - always use the class name, not a variable.
System.out.println(Foo.x);
The variable “foo” is unwanted overhead that should be removed, and the compiler errors and warnings could be seen as helping leading towards that.
add a comment
|
There is value in keeping the rules as simple as possible, and “don’t use a variable that might not have been initialised” is as simple as it gets.
More to the point, there is an established way of calling static methods - always use the class name, not a variable.
System.out.println(Foo.x);
The variable “foo” is unwanted overhead that should be removed, and the compiler errors and warnings could be seen as helping leading towards that.
There is value in keeping the rules as simple as possible, and “don’t use a variable that might not have been initialised” is as simple as it gets.
More to the point, there is an established way of calling static methods - always use the class name, not a variable.
System.out.println(Foo.x);
The variable “foo” is unwanted overhead that should be removed, and the compiler errors and warnings could be seen as helping leading towards that.
edited 9 hours ago
Pshemo
99.7k17 gold badges141 silver badges200 bronze badges
99.7k17 gold badges141 silver badges200 bronze badges
answered 9 hours ago
racramanracraman
2,7281 gold badge10 silver badges10 bronze badges
2,7281 gold badge10 silver badges10 bronze badges
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%2f57964026%2fwhy-cant-we-use-uninitialized-local-variable-to-access-static-content-of-its-ty%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
2
I'd say a limitation in the compiler that isn't really worth fixing, given that the code raises a warning anyway.
– manouti
10 hours ago
1
@manouti That is also my guess, but I am still interested in why compiler behaves that way. Which part of specification forces it?
– Pshemo
10 hours ago
I think the compiler is less concerned with initialization (even though that is the warning) as it is with the null pointer exception you are creating. The reference to the initialization is the compiler trying to give reason to why you may have a potential null pointer exception.
– portfoliobuilder
10 hours ago
2
@portfoliobuilder There is no risk of NPE here since as mentioned in question, in case of accessing
static
member compiler doesn't use value of variable but its type. We can even write((Foo)null).x
and this will compile and work because compiler will recognize thatx
is static (unless I misunderstood your comment).– Pshemo
10 hours ago
3
Accessing a static variable from a non-static context (such as
foo.x
) should have been a compiler error when Java was first created. Sadly, that ship sailed over 25 years ago and would be a breaking change if they changed it now.– Powerlord
9 hours ago