A wrapper class for storing primitive parameters which are initialized with values. Is it better to use public static or private static with bunch of getters and setters, for these constants?

public class Wrapper {
  // This
  private static int PARAMETER = 100;

   * EDIT:
   * public int getParameter();
   * public void setParameter(int n);
   * Pointed out by @JimmyJames that I forgot the static accessor.

  public static int getParameter();
  public static void setParameter();

  // Or this?
  public static int ANOTHER_PARAMETER = 200;

My observations:
1. These parameter are rarely changed.
2. I feel like it reduces readability when there are a lot of these parameters, if using private static with lots of getters and setters.

Any thoughts on which one is better? Maybe depending on different scenarios?


Pointed out by @JimmyJames that I missed the static accessor on the methods.

I do not think this is related to my question. I should probably phrase my question better, these PARAMETER are more likeCONSTANTS, making them static or even final makes things easier to access directly like doOperation(Wrapper.ANOTHER_PARAMETER) or doOperation(Wrapper.getParameter()).

After reading comments and answer of @Robert Harvey and @JimmyJames, and other readings, I think essentially this is a bad practice that should be avoided (using class to hold constants).
Where do you keep Constants used throughout your application?

What if there are moderate amounts of PARAMETERS/CONSTANTS that are used across a module and they cannot be pinpointed to specific classes, at this time should we consider grouping all these together in a class, and access them through the methods mentioned above(as they will be available when class is loaded)?

  • Possible duplicate of Why shouldn't I be using public variables in my Java class?
    – gnat
    Oct 25, 2019 at 19:07
  • 1
    You're going to get a whole lot of people telling you that you shouldn't use a static class in this manner at all, that you should use an ordinary class with simple dependency injection or a dependency injection framework instead. Oct 25, 2019 at 19:12
  • @gnat That question doesn't have anything about static variables.
    – JimmyJames
    Oct 25, 2019 at 19:44
  • @JimmyJames wonder if you read the code in question. Give it a read please: // This private static int PARAMETER = 100; - and question further proceeds asking to compare: // Or this? public static int ANOTHER_PARAMETER = 200; Just the same as like the code in duplicate. Maybe you are confused by duplicate calling it variables instead of members or as they sometimes say fields?
    – gnat
    Oct 25, 2019 at 20:24
  • @gnat did you read it or the title?
    – JimmyJames
    Oct 25, 2019 at 20:26

1 Answer 1


There's a major problem with the first approach you are showing here. You have static variables but your methods are not static. This is very abnormal in Java and will create a lot of confusion if you are working on a team. It also has some really negative implications if you ever need to multi-thread. Even in a single-threaded app, you could see instabilities if you are not extremely careful. You should some spend time up-front creating robust classes so that you don't incur the cost of having to be careful with how you use them later.

The problem here is that this class needs to be instantiated in order for you to set the class-level variables variables. But there's nothing here preventing more than one instantiation of this class. You could have any number of these objects around and calling a set method will change the value returned by get for all the other instances. This is not typically expected. When you create a object and modify a property, the normal pattern is for it to only change that object.

To resolve this, you could make the getter and setter static. This will make it work in a more expected manner. But as Robert Harvey noted in his comment, using static in this way is widely discouraged. Effectively, you will have created global variables (with some minor caveats.) I'm not going to explain why globals are problematic here as there are many articles and answers about that topic already.

The more popular option here is to (again as mentioned by Robert Harvey) create a normal Java object that you then pass to things that need these parameters. This can be done in code or using various injection frameworks.

  • 1
    mind that there is no way in Java to have true singletons. Any singleton will only be unique within the context of its classloader, and an application can have any number of classloaders. As to have static members used by non-static methods, that's generally fine when dealing with final data members, especially String and primitive finals, as they're then by definition constant and can't be modified by any instance, thus being thread safe. For other things, caution is called for but often it works fine for simple things like loggers.
    – jwenting
    Oct 28, 2019 at 4:51
  • @jwenting Yes, it's having mutable static values shared by objects that's a problem here. I agree that it's useful to return a constant from an instance method.
    – JimmyJames
    Oct 28, 2019 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.