Better approach on use of enum vs class with constants java

I'm still learning Java, and I have an issue where two, more experienced, engineers are asking me to follow two different approaches.
I'd like an opinion from more experienced java developers to choose one or the other approach and being able to defend that choice.

We're logging events using Log4j2. I've been asked to add categories to each log, as a prefix, as a way to tell where that log was created.

To avoid writing the category each time I was asked first to use a class, something like

public class LogCategory()
{
    public static final String CATEGORY_ONE   = "CategoryOne";
    public static final String CATEGORY_TWO   = "CategoryTwo";
    public static final String CATEGORY_THREE = "CategoryThree";
    ...
}

And it will be called using a log4j2 logger like

private Logger logger = LogManager.getLogger("MyLogger");
logger.info("{}: This is a log", LogCategory.CATEGORY_ONE);

The{} works as the placeholder to prefix the string.

this method works fine. But then, another engineer asked me to replace that class for an enum, since this would be what the enum should be used for.
The enum was then declared like this

public enum LoggingCategory 
{
    CATEGORY_ONE("CategoryOne"),
    CATEGORY_TWO("CategoryTwo"),
    CATEGORY_THREE("CategoryThree"),
    ...

    private final String str;

    LoggingCategory(final String str)
    {
        this.str = str;
    }


    @Override
    public String toString()
    {
        return str;
    }
}

But due to the multiple signature that log4j2 has for loggin methods, the toString method won't work unless explicitly called.
And it will be called using a log4j2 logger like

private Logger logger = LogManager.getLogger("MyLogger");
logger.info("{}: This is a log", LoggingCategory.CATEGORY_ONE.toString());

Now I've been told that this explicit call of the toString method will affect performance, and it would be better to go back to the class.

So, is it true? The explicit call of the method affects performance?

First of all you should avoid this kind of custom logging and instead use appropriate factory method

private static final Logger logger = LogManager.getLogger("HelloWorld");

This will add you appropriate identifier in your log message that will work as the category you want to introduce artificially.

Anyway - due to the good programming practices, however I find using enum here as some kind of overhead then saying that calling toString will affect performance is just a nonsense or, more politely saying, premature optimization.

No matter which approach you will use - both are basically just fine and both are probably not really necessary in this particular scenario.

I always like to go with enums whenever possible because of their type safety. That doesn't apply that much to library classes/methods the signature of which you can't change anyway (which basically is your case). But if it is in your own hands in your code...

I'd use enum's anyway and declare them just as:

public enum LoggingCategory {

    ONE,
    TWO,
    THREE,
    ...
}

Because:

• that each of these represent a category is already stated in the enum's name. Compare the usage LoggingCategory.CATEGORY_ONE to LoggingCategory.ONE.

• the enum doesn't need the members: variable, constructor, toString() since it supplies an implicit toString() which:

  > Returns the name of this enum constant, as contained in the declaration. This method may be overridden, though it typically isn't necessary or desirable. An enum class should override this method when a more "programmer-friendly" string form exists.

• All uppercase for categories' names is better to distinguish them from class names (in the logs).

• If you place your enums in an external (to your business library) commons library they also can be used by others without the burden of importing and referencing (and loading into heap memory implicitily) full-featured business classes.

The performance of the toString() is not an issue. If it has an impact, it is several orders of magnitude smaller than the performance of the logging call.

Using an enum is IMHO an overkill, since you don't really profit from the type safety it introduces. But if you want to use it, you should prefer:

logger.info("{}: This is a log", LoggingCategory.CATEGORY_ONE);

over

logger.info("{}: This is a log", LoggingCategory.CATEGORY_ONE.toString());

since the first line will only call toString() if INFO is enabled.

Note about the general approach

Adding the logging category as a string in the message is probably not the best idea, since you lose most filtering features. I would rather use:

1. Multiple loggers:

   public class Loggers {
       public static final Logger CATEGORY_ONE = LogManager.getLogger("CategoryOne");
       public static final Logger CATEGORY_TWO = LogManager.getLogger("CategoryTwo");
       public static final Logger CATEGORY_THREE = LogManager.getLogger("CategoryThree");
       ...
   }
   

   Loggers are usually named after the class that uses them, but nothing prevents you from using you own names. They have excellent filtering features and are supported by all Log4j API backends. Logging backends are optimized to filter according to logger names.

2. Or I would use markers:

   public class Markers {
       public static final Marker CATEGORY_ONE = MarkerManager.getMarker("CategoryOne");
       public static final Marker CATEGORY_TWO = MarkerManager.getMarker("CategoryTwo");
       public static final Marker CATEGORY_THREE = MarkerManager.getMarker("CategoryThree");
       ...
   }
   

   that you can use as:

   logger.info(Markers.CATEGORY_ONE, "This is a log");
   

   These are only supported by Logback and Log4j 2.x Core, but still offer adequate filtering features, although these come at a slight performance cost.

> "So, is it true? The explicit call of the method affects performance?"

The argument here is whether you're working in a professional environment or not.

If these are merely friends, or acquaintances, who are providing recommendations, then I would simply choose whichever approach offers the more scalable interface, than the other.
The mark in performance would be a millisecond measurement.

If it is a professional environment, then the latter recommendation is correct; that the enum's conversion to a String will decrease performance.
The debate to provide some sort of latency threshold—e.g., 1 ms versus 5 ms—is not a topic, since the performance requirement is simply a standardization among the business.
If it can be displayed on a graph, then it's logical.

I prefer enum classes, they provide the ability to quickly enumerate a set of unique values, while also creating an easily scalable interface.

On the contrary, the first recommendation—of constant string values—can be a trivial design practice.

For example, in another situation, where you may be storing numerical values, in which their sequencing values are depended on, by calling objects.
The scalability is reduced significantly.

The Pattern class uses this concept, to define regular-expression modes.
I've also seen it within the Android API.
And, if I'm not mistaken, I believe the Java AWT framework uses this pattern quite extensively.

Consider the following.

static int VALUE_A = 1;
static int VALUE_B = 2;
static int VALUE_C = 3;
static int VALUE_D = 4;

If, in a future version of the program, I need to remove VALUE_C, it would require me to now edit the value of VALUE_D, along with any subsequent fields.
Which, consequently, would error the program at run-time, if not changed.

Since you are using String values, this isn't the case.  As, you know for a fact that it will work, since the scalability isn't really an issue.
This can be analogous to adding an @SuppressWarnings annotation above a statement.
You know there is a better design, and are telling the compiler to ignore it.

As a final note, I believe that the reason you are being told to choose the more archaic approach is because that is what, essentially, an enum object is converted into, at compile time.
An object with static fields.
Don't quote me on that.