Can we have an AtomicEnum in Java?

Question 1

Today I saw this utility class for AtomicEnum but I wonder if it is possible to have an atomic enum why it is not included in Java standard libraries?

The AtomicEnum class that you linked to is just wrapping the AtomicReference class which gives concurrent access for any Object.

Really a volatile enumField is all you need if you have multiple threads that are getting and setting it concurrently. The volatile keyword ensures that updates made by one thread are seen by other threads.

You need the AtomicReference if you need to do a compareAndSet(...) type of method – atomically test if the field is a particular value and only then update it. You could use AtomicReference something like the following:

private final AtomicReference<MyEnum> atomicColor = new AtomicReference<>();
...
atomicColor.set(ColorEnum.RED);
...
if (atomicColor.compareAndSet(ColorEnum.RED, ColorEnum.GREEN)) {
   ...
}
...
ColorEnum color = atomicColor.get();

How can I examine if it does the operations atomically?

AtomicReference is part of the java.util.concurrent classes which are well tested.

Is there a tool for seeing the compiled code and be sure that it does really all in only one machine instruction?

That shouldn't be necessary. You can take a look at the AtomicReference source if you care to see what it is doing. Unfortunately the real magic is in the sun.misc.Unsafe native code.

Is it possible to discover it from the code?

That shouldn't be necessary.

So if this Atomic enum works, I can have an attribute AtomicEnum and it will be possible to use it safely without volatile keyword and synchronized getters and setters?

Yes, AtomicReference wraps a volatile V value so you don't have to do it.

Question 2

This AtomicEnum is simply a thin wrapper around an AtomicReference, which makes sense since a n enum value is simply an object (reference).

So if AtomicReference works correctly (and I think we can assume that), the AtomicEnum will work as well.

Question 3

The access to the reference is atomic, but the access to the object is not. So a change in value of reference will be properly propagated across all threads but a change in the actual enum object might not.
Example...

enum Weekdays {
    public int rank = 0;
    MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY;
}

Case 1:

AtomicEnum<Weekdays> today = Weekdays.TUESDAY;

Each thread sharing 'today' will have a reference of Weekdays.TUESDAY

Case 2:

today.rank = 3;

There is no guarantee that each thread will have the updated rank. (rank is not volatile. Everyone maintains separate copy of the object in cache.)

So reference access is atomic but that to object is not.
Note:
1) Atomic access does not mean execution in one machine instruction. But logically it can be thought like this. Although it is indivisible, it can comprise of several instructions.
2) Even if such tool existed, it would be too difficult to test it since the update process is almost unpredictable. So false positive results are possible.

Hope this helps.

Question 4

I think there is no point writing any such class. In fact if you are writing such class you need to rethink about the responsibility of the class. ENUMs are absolutely thread safe so I am not sure why someone need AtominEnum, or is it just some class which is Atomic and also using some enum but then naming it AtomicEnum is very confusing not good in design or naming convention.