This question already has answers here:
Best Practice: Java static non final variables
(7 answers)
Closed 9 years ago.
After a couple of years using Java i've just realized that i don't understand what it the use case for non-final static variables. Can someone give me some hints or any example?
Maybe they are needed to be used in static methods? ... or useful to be shared between all instances?
What concerns me is they can be accessed and modified asynchronously by any subclass, or through any instance.
Thanks.
** note **
Sorry about duplication. I did my search before posting and i didn't find it.
As constants they have no use, which I believe is your main trails of thoughts are concentrated around.
But how do you think a static class is going to perform it's operations if there is any need for class scope variables that need to be shared across the method calls?
Or there are instances where data need to be stored in a static class etc.
There are a lot of use cases if you just stop to think about it.
Related
This question already has answers here:
What is the exact meaning of static fields in Java?
(4 answers)
Closed 7 years ago.
I am reading a code one of my friends wrote to store the account of users using arraylist. So he declared private static ArrayList = new ArrayList<>(); I understood this part, but I am not sure why he has declared it as static. That brought me up to this question : When is it a good idea to declare a data structure static?
That's a question that calls for a very delicate answer, but:
When is it a good idea to declare a data structure static?
NEVER
Static members are the root of many evils. They make the class less reusable. They make the class harder/impossible to test. They make the class non thread safe by default, which can be remedied but it's difficult to get right and can cause performance issues. They put the responsibility of managing the resource in the wrong place.
This is a very big OOD topic that's been discussed to great extents, so I'll just point out a commonly used acronym that is worth looking up: SOLID principles.
This question already has answers here:
When should one use final for method parameters and local variables?
(15 answers)
Closed 10 years ago.
I use PMD tool to find errors in java code if any. One common suggestion PMD gives is that "Local variable {local_variable} could be declared final". Is it necessary to declare all local variables as final if it's state is not changed further?
Is it necessary to declare all local variables as final if it's state is not changed further?
No it is not necessary, except in one situation: if you need to access that variable within an anonymous class.
Is it good practice to make all local variable final when they don't change?
This is obviously subjective - I personally think that it clutters the code unnecessarily and that if you follow good coding practice, your methods should be short enough and self-explanatory enough that making your variables final should not be required.
Well it's also a problem of the language design to set variables explicitly to final and to have the final keyword appear all around. In scala the default is to have everything final and immutable, pushing a more functional design. If you wonder why use final, have a look at scala - that should give you some ideas.
I would consider it bad style not to use final by the way. Final variables - well or constants in that sense - cannot be changed. That is kind of a programming contract. You simply have less side-effects in code with final variables. If you leave that out you could also leave out all the private fields. Why bother?
In eclipse you can add all the required final fields and lots of other things considered "cleaner" automatically, when you open the dialog "Source/Clean Up..." (so I guess it's called "Clean Up" because not using final would be considered unclean).
It's up to you - use it - or leave it. Use it - and look especially at the code where the final could not be applied. Maybe that code could be improved to be final?
So: Yes! It is good practice!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why would one mark local variables and method parameters as “final” in Java?
I used PMD in my code and it always tells me to make method local variables final. Can someone tell me how this effects the general performance apart from making the code more readable.
There's no effect on performance and it's debatable whether it's more readable. Java should have made variables final by default.
The biggest value of final is that it prevents programming errors. Regarding performance, I'd think the compiler can figure out the last write to a variable in most cases and do the necessary optimizations.
This question already has answers here:
What is a good use case for static import of methods?
(16 answers)
Closed 2 years ago.
I declare some constant variables in my SQLiteOpenHelper class:
public static final String USERNAME = "user_name";
public static final String PASSWORD = "password";
In an Activity where I create SQL queries, I import these fields:
import com.mygame.ui.login.LoginInfoSQLiteOpenHelper.*;
Is this a good practice?
Or the traditional way of referring to constants better?
LoginInfoSQLiteOpen.USERNAME
If you look at someone's code and see a field like
foo.do(baz, USERNAME);
wut(!), where did that var come from ?
search, grep, where is it declared ?
Using it as ClassName.FIELD makes things much clearer and cleaner.
You avoid confusion, and sometimes it makes more sense to have a proper classname that denotes the field, than a field that came out of nowhere.
well, not everyone uses an IDE, and not everyone reads code through an IDE(maybe through a repository on the web), and even some consider VIM an IDE, and I do use vim a lot(although I don't think of it as an IDE).
So, it's not about what an IDE can or can't do, but more of what code reading is about. Code reading, code quality, expressing ideas in your programming language of choice, in a way through abstractions that make sense and tie well together.
A few years late to the party... but I feel it is worth providing the opposite point of view. There is a reason why Java was designed to have static field imports, and the reason is to hide how the class is implemented to users of the class. This is an important design principle for outwardly facing code. I would agree with c00kiemon5ter take on it, however, there might be situations in which it is worthwhile.
More info on static field importing can be found here: https://docs.oracle.com/javase/1.5.0/docs/guide/language/static-import.html
I recommend the second method, only importing classes not fields. So prefixing your constants with the owning class, like LoginInfoSQLiteOpen.USERNAME. It can become highly redundant, but it is much more readable and maintainable in the long run.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why is String final in Java?
I'm just wondering why java.lang.String is made final? Is it to prevent from being inherited? Why?
Yes indeed. This allows code in security managers and classloaders to work with the String type without having to worry that it's actually dealing with a malicious subclass that's specifically designed to trick it into allowing evil code through.
You should not be extending the string class. Just write your own methods in some other class that manipulate strings.
The reason is that the string class is a stable one which should not be tampered with as you may re-define some methods which would have unknown side effects on some other transactions.
Aside from security aspects that were already mentioned, I suspect performance was another important reason. For older JVMs especially final classes (where all methods are final by definition) made it much easier to inline code on-the-fly. And since String is one of most heavily used objects, which affects overall performance of many applications, this was seen as an area where improvements would have big overall effect.