Enum Tricks: Customized valueOf

I don't generally use valueOf in my enum classes. You may have a look at the following code, in case it may give you some ideas related to tricks around enum classes.

<code>
package org.jptools.tools.system.utils;

import java.util.EnumSet;
import java.util.HashMap;
import java.util.Map;
import javax.swing.UIManager;
import javax.swing.UIManager.LookAndFeelInfo;

public enum JavaVersion {

    JDK1_0 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.0.") >= 0;
        }

        @Override
        public int getID() {
            return 10;
        }
    },
    JDK1_1 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.1.") >= 0;
        }

        @Override
        public int getID() {
            return 11;
        }
    },
    JDK1_2 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.2.") >= 0;
        }

        @Override
        public int getID() {
            return 12;
        }
    },
    JDK1_3 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.3.") >= 0;
        }

        @Override
        public int getID() {
            return 13;
        }
    },
    JDK1_4 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.4.") >= 0;
        }

        @Override
        public int getID() {
            return 14;
        }
    },
    JDK1_5 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.5.") >= 0;
        }

        @Override
        public int getID() {
            return 15;
        }
    },
    JDK1_6 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.6.") >= 0 && !JDK1_6N.isJDK(javaVersion);
        }

        @Override
        public int getID() {
            return 16;
        }
    },
    JDK1_6N {

        @Override
        boolean isJDK(String javaVersion) {
            boolean result = false;
            if (javaVersion.indexOf("1.6.") >= 0) {
                for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
                    if ("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel".equals(info.getClassName())) {
                        result = true;
                        break;
                    }
                }
            }
            return result;
        }

        @Override
        public int getID() {
            return 1610;
        }
    },
    JDK1_7 {

        @Override
        boolean isJDK(String javaVersion) {
            return javaVersion.indexOf("1.7.") >= 0;
        }

        @Override
        public int getID() {
            return 17;
        }
    };
    private static final String jdkVersionName;
    private static final Map<Integer, JavaVersion> lookup;

    static {
        jdkVersionName = System.getProperty("java.version");
        lookup = new HashMap<Integer, JavaVersion>();
        for (JavaVersion versionNumber : EnumSet.allOf(JavaVersion.class)) {
            lookup.put(versionNumber.getID(), versionNumber);
        }
    }

    abstract boolean isJDK(String javaVersion);

    public abstract int getID();

    public static String getCurrentVersionName() {
        return jdkVersionName;
    }

    public static int getJavaVersion(String javaVersion) {
        int version = 13;
        for (JavaVersion id : EnumSet.allOf(JavaVersion.class)) {
            if (id.isJDK(javaVersion)) {
                version = id.getID();
                break;
            }
        }
        return version;
    }

    public static JavaVersion getField(final Integer versionNumber) {
        return lookup.get(versionNumber);
    }
}
</code>

I really urge you to not assume that the map version is faster than the iterative lookup version.  If the number of values in an enum class are small, the iterative search may well be faster.  Measure it for different sizes.

I agree that the map may be initialized in static block. This is the difference between static and lazy initialization. I absolutely agree with bullet #2.

OK, i understand that in some rare case you really need the a String representation of an Enum.
But why in gods name do you want such a code bloat! Don't you guys follow the KISS principle. The solution presented destroys this.
Within the enum is allowed to have multiple fields so the sample from carlos can be:

public enum JavaVersion {
   private String name;
   private int version;

  JavaVersion(name, version) {
     this.name = name;
     this.version = version)
  }

    JDK1_0("1,0",10)
    JDK1_2("1,2", 12)
   .....
   String toString() {
       return name;
   }

   int getCode() {
     return this.code;
   }

Plain and simple. And more important it does not implement logic into the enumeration. IMHO this is evil! Did't you learn the lesson about "separations of concerns"?
This may read like a flame it is not intention. I have seen a similar solution in production code and it was a nightmare to resolve. Functionality was everywhere and very hard to read. hence the KISS and SOC principles.

Pieter, thank you for reply. Your example does not contain method valueOf(int code) that returns JDK1_0 for code 10 and JDK1_2 for code 12. If you have to implement this you need some kind of lookup table. If you have 5 fields like code you need 5 lookup tables. If you are required to implement 10 enums like JavaVersion with 5 fields like code you need 50 lookup table. Every time you have to write similar code. My article is an attempt to reduce your efforts and save your time.

Pieter, no offense at all! :-)

I took that piece of code to better explain there are different approaches, to solve the problem of getting an enum field out of its contents.

In fact, the real production code consists of two enums -the posted and another one- and a helper class as a public API. The problem is: when you ask the JVM for its version, it doesn`t return a simple "1.7" string, so there's a need for some logic to check out which one is. The problem with 1.6N is even worse.

The goal by using those enum is to keep the public API which does the actual check as clean and lean as possible, while hidding into those enum classes the bulk of detection logic.

enum classes are just a collection of singleton classes, disguised as "fields", so you may use them as any other Java class. The logic has to be somewhere: you may keep enum as simple as possible, but then you have to place the required logic somewhere else. That means helper classes, or move the logic to the public API class.

I doubt what you gain by keeping enum simple, won't be even worse by spreading the logic into other classes.

I tend to encapsulate logic as much as possible, in order to have public API simple to use, to maintain and to understand. It's an strategy as valid or as problematic as others. I use enum classes as I would do with singletons. Is it questionable?, maybe! But I don't see anything incorrect in that design methodology.

I also can be too quick on the keyboard ;-)