Do we need static fields in Spring Beans?
I have seen general practice to create Logger instance as static properties of a class annotated with any of the Spring's Annotation ( @Component, @Service ).
Since, all beans created are by default singleton in nature. Do we really need static fields in this scnerio as there is only going to be once instance after all ?
java spring spring-framework-beans
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
|
show 3 more comments
I have seen general practice to create Logger instance as static properties of a class annotated with any of the Spring's Annotation ( @Component, @Service ).
Since, all beans created are by default singleton in nature. Do we really need static fields in this scnerio as there is only going to be once instance after all ?
java spring spring-framework-beans
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency.
– Michael
Nov 19 '18 at 8:45
static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all.
– dognose
Nov 19 '18 at 8:45
Spring@Components can be@RequestScopedtoo. In that case they won't be singletons, so your first assumption isn't completely right.
– BackSlash
Nov 19 '18 at 8:46
1
@Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ?
– dognose
Nov 19 '18 at 8:48
@dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them
– Michael
Nov 19 '18 at 8:49
|
show 3 more comments
I have seen general practice to create Logger instance as static properties of a class annotated with any of the Spring's Annotation ( @Component, @Service ).
Since, all beans created are by default singleton in nature. Do we really need static fields in this scnerio as there is only going to be once instance after all ?
java spring spring-framework-beans
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
I have seen general practice to create Logger instance as static properties of a class annotated with any of the Spring's Annotation ( @Component, @Service ).
Since, all beans created are by default singleton in nature. Do we really need static fields in this scnerio as there is only going to be once instance after all ?
java spring spring-framework-beans
java spring spring-framework-beans
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
asked Nov 19 '18 at 8:41
ParasParas
1,94032237
1,94032237
What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency.
– Michael
Nov 19 '18 at 8:45
static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all.
– dognose
Nov 19 '18 at 8:45
Spring@Components can be@RequestScopedtoo. In that case they won't be singletons, so your first assumption isn't completely right.
– BackSlash
Nov 19 '18 at 8:46
1
@Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ?
– dognose
Nov 19 '18 at 8:48
@dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them
– Michael
Nov 19 '18 at 8:49
|
show 3 more comments
What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency.
– Michael
Nov 19 '18 at 8:45
static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all.
– dognose
Nov 19 '18 at 8:45
Spring@Components can be@RequestScopedtoo. In that case they won't be singletons, so your first assumption isn't completely right.
– BackSlash
Nov 19 '18 at 8:46
1
@Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ?
– dognose
Nov 19 '18 at 8:48
@dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them
– Michael
Nov 19 '18 at 8:49
What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency.
– Michael
Nov 19 '18 at 8:45
What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency.
– Michael
Nov 19 '18 at 8:45
static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all.
– dognose
Nov 19 '18 at 8:45
static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all.
– dognose
Nov 19 '18 at 8:45
Spring
@Components can be @RequestScoped too. In that case they won't be singletons, so your first assumption isn't completely right.– BackSlash
Nov 19 '18 at 8:46
Spring
@Components can be @RequestScoped too. In that case they won't be singletons, so your first assumption isn't completely right.– BackSlash
Nov 19 '18 at 8:46
1
1
@Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ?
– dognose
Nov 19 '18 at 8:48
@Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ?
– dognose
Nov 19 '18 at 8:48
@dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them
– Michael
Nov 19 '18 at 8:49
@dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them
– Michael
Nov 19 '18 at 8:49
|
show 3 more comments
1 Answer
1
active
oldest
votes
I think the same question can be asked for finals: "Why would declare a variable as final if I know I won't touch it through the code?"
Thing is, you are not the only one touching or reading the code. Giving the proper semantic meaning is essential for a readable and maintainable code. You may know that the service and/or controller will be a Singleton, so no real need to put the variables inside static, but in this way you are explicitly declaring it.
Addition:
how are you going to log something during the construction of your singleton, if construction fails :-)
I quote @dognose comment just to make the answer more complete. There is a practical problem that making the logger static addresses: logging during creation.
Follow-up:
I simply wanted to know why would we need final static Logger instead of just final Logger. What justifies a logger to be static member instead of just being class member?
Let's assume your class is not a Singleton. In this scenario, the Logger must just log. It has nothing to do with the objects, it is a class property. This means that if you instantiate one or a thousand objects, the logger does not change. So you can just share it, between all the objects, hence make it static.
Let's assume your class is a Singleton. There will be always only one instance. Is static still useful? From a practical point of view, no. You will have only one class instance, so only one logger, static or not. Still, if you declare it static, you are declaring that you want that logger to be a property of the class, not of the objects of that class. You are making your intentions and design explicit, hence improving the quality of your code.
Hope this answers your question.
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
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%2f53370995%2fdo-we-need-static-fields-in-spring-beans%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think the same question can be asked for finals: "Why would declare a variable as final if I know I won't touch it through the code?"
Thing is, you are not the only one touching or reading the code. Giving the proper semantic meaning is essential for a readable and maintainable code. You may know that the service and/or controller will be a Singleton, so no real need to put the variables inside static, but in this way you are explicitly declaring it.
Addition:
how are you going to log something during the construction of your singleton, if construction fails :-)
I quote @dognose comment just to make the answer more complete. There is a practical problem that making the logger static addresses: logging during creation.
Follow-up:
I simply wanted to know why would we need final static Logger instead of just final Logger. What justifies a logger to be static member instead of just being class member?
Let's assume your class is not a Singleton. In this scenario, the Logger must just log. It has nothing to do with the objects, it is a class property. This means that if you instantiate one or a thousand objects, the logger does not change. So you can just share it, between all the objects, hence make it static.
Let's assume your class is a Singleton. There will be always only one instance. Is static still useful? From a practical point of view, no. You will have only one class instance, so only one logger, static or not. Still, if you declare it static, you are declaring that you want that logger to be a property of the class, not of the objects of that class. You are making your intentions and design explicit, hence improving the quality of your code.
Hope this answers your question.
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
add a comment |
I think the same question can be asked for finals: "Why would declare a variable as final if I know I won't touch it through the code?"
Thing is, you are not the only one touching or reading the code. Giving the proper semantic meaning is essential for a readable and maintainable code. You may know that the service and/or controller will be a Singleton, so no real need to put the variables inside static, but in this way you are explicitly declaring it.
Addition:
how are you going to log something during the construction of your singleton, if construction fails :-)
I quote @dognose comment just to make the answer more complete. There is a practical problem that making the logger static addresses: logging during creation.
Follow-up:
I simply wanted to know why would we need final static Logger instead of just final Logger. What justifies a logger to be static member instead of just being class member?
Let's assume your class is not a Singleton. In this scenario, the Logger must just log. It has nothing to do with the objects, it is a class property. This means that if you instantiate one or a thousand objects, the logger does not change. So you can just share it, between all the objects, hence make it static.
Let's assume your class is a Singleton. There will be always only one instance. Is static still useful? From a practical point of view, no. You will have only one class instance, so only one logger, static or not. Still, if you declare it static, you are declaring that you want that logger to be a property of the class, not of the objects of that class. You are making your intentions and design explicit, hence improving the quality of your code.
Hope this answers your question.
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
add a comment |
I think the same question can be asked for finals: "Why would declare a variable as final if I know I won't touch it through the code?"
Thing is, you are not the only one touching or reading the code. Giving the proper semantic meaning is essential for a readable and maintainable code. You may know that the service and/or controller will be a Singleton, so no real need to put the variables inside static, but in this way you are explicitly declaring it.
Addition:
how are you going to log something during the construction of your singleton, if construction fails :-)
I quote @dognose comment just to make the answer more complete. There is a practical problem that making the logger static addresses: logging during creation.
Follow-up:
I simply wanted to know why would we need final static Logger instead of just final Logger. What justifies a logger to be static member instead of just being class member?
Let's assume your class is not a Singleton. In this scenario, the Logger must just log. It has nothing to do with the objects, it is a class property. This means that if you instantiate one or a thousand objects, the logger does not change. So you can just share it, between all the objects, hence make it static.
Let's assume your class is a Singleton. There will be always only one instance. Is static still useful? From a practical point of view, no. You will have only one class instance, so only one logger, static or not. Still, if you declare it static, you are declaring that you want that logger to be a property of the class, not of the objects of that class. You are making your intentions and design explicit, hence improving the quality of your code.
Hope this answers your question.
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
I think the same question can be asked for finals: "Why would declare a variable as final if I know I won't touch it through the code?"
Thing is, you are not the only one touching or reading the code. Giving the proper semantic meaning is essential for a readable and maintainable code. You may know that the service and/or controller will be a Singleton, so no real need to put the variables inside static, but in this way you are explicitly declaring it.
Addition:
how are you going to log something during the construction of your singleton, if construction fails :-)
I quote @dognose comment just to make the answer more complete. There is a practical problem that making the logger static addresses: logging during creation.
Follow-up:
I simply wanted to know why would we need final static Logger instead of just final Logger. What justifies a logger to be static member instead of just being class member?
Let's assume your class is not a Singleton. In this scenario, the Logger must just log. It has nothing to do with the objects, it is a class property. This means that if you instantiate one or a thousand objects, the logger does not change. So you can just share it, between all the objects, hence make it static.
Let's assume your class is a Singleton. There will be always only one instance. Is static still useful? From a practical point of view, no. You will have only one class instance, so only one logger, static or not. Still, if you declare it static, you are declaring that you want that logger to be a property of the class, not of the objects of that class. You are making your intentions and design explicit, hence improving the quality of your code.
Hope this answers your question.
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
edited Nov 19 '18 at 9:04
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
answered Nov 19 '18 at 8:46
Tu.maTu.ma
807219
807219
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
add a comment |
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ?
– Paras
Nov 19 '18 at 8:58
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
I added some more comments in the answer.
– Tu.ma
Nov 19 '18 at 9:04
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%2f53370995%2fdo-we-need-static-fields-in-spring-beans%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
What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency.
– Michael
Nov 19 '18 at 8:45
static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all.
– dognose
Nov 19 '18 at 8:45
Spring
@Components can be@RequestScopedtoo. In that case they won't be singletons, so your first assumption isn't completely right.– BackSlash
Nov 19 '18 at 8:46
1
@Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ?
– dognose
Nov 19 '18 at 8:48
@dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them
– Michael
Nov 19 '18 at 8:49