Often, we need a discrete domain of related values, such as to indicate types of things (customer type, transaction type, state, etc.) or for flags. Before Enums, a common technique was to declare the field/member as "int" and use constants (public static final int) to define the specific expected values. The problem is that, while there is type safety (int), there is no "value safety"; since the field is defined int, it can take ANY int value – even values not defined in the constants. You can add validation to methods to ensure the value passed is one of the set of "magic" values (as defined by the constantr to achieve run-time "value safety", but there is nothing that prevents the author of "client" code from trying to send a bad value.
Using Enums, you define a specific class with (effectively) a discrete set of static singletons to represent the complete domain of all possible values for a particular purpose. This provides both compile-time and run-time type-safety and "value safety" – while still being usable in a switch/case statement – and allowing for encapsulation of other useful behaviors such as for printing (override Object.toString) and sorting (implement Comparable.compareTo).
Constants (public static final) are still useful where your code can legitimately accept ANY value of the defined type (e.g. int, double, etc.) but where there are certain "magic" values that are used more often and so you want to define convenient constants for easier reference … or to help document key literals in your algorithms … e.g. PI=3.14159 or LINE_SEPARATOR="\n". .