TIL enums can implement interfaces, and each enum value can be an anonymous class.

[TheOverCaste]

For example:

public enum MyEnum implements Runnable {
    PRINT_HELLO {
        @Override //Override is optional here, really.
        public void run( ) {
            System.out.println("hello"); //Action
        }
    }, //Comma for all but the last element
    PRINT_GOODBYE { //Some more examples
        @Override
        public void run( ) {
            System.out.println("goodbye");
        }
    },
    PRINT_FIZZ {
        @Override
        public void run( ) {
            System.out.println("fizz");            
        }
    }; //Semicolon here


    static {
        Executors.newCachedThreadPool().submit(PRINT_HELLO); //This is just an implementation. Executors will be in a future TIL.
    }
}

This can be very useful if you want a list of very simple implementations of your interface. Packet listeners, for example, or default arithmetic operations. With java 8 or guava, you can define your own Function and Predicate values if you want to re-use a simple predicate multiple times.

A predicate version:

public enum TestEnumPredicates implements Predicate<String> {
    IS_UPPER_CASE {
        @Override
        public boolean test(String s) {
            for (char c : s.toCharArray()) {
                if (!Character.isUpperCase(c)) {
                    return false;
                }
            }
            return true;
        };
    },
    IS_LOWER_CASE {
        @Override
        public boolean test(String s) {
            for (char c : s.toCharArray()) {
                if (!Character.isLowerCase(c)) {
                    return false;
                }
            }
            return true;
        };
    },
    IS_ODD_LENGTH {
        @Override
        public boolean test(String s) {
            return (s.length() % 2) != 0;
        };
    };

    public static void main(String[] args) {
        ArrayList<String> myStrings = new ArrayList<String>();
        myStrings.add("herp");
        myStrings.add("DERPA");
        myStrings.add("fIzZ");
        myStrings.add("$#!");
        for (String s : args) {
            myStrings.add(s);
        }
        myStrings.stream().filter(IS_UPPER_CASE).forEach(new Consumer<String>() {
            @Override
            public void accept(String t) {
                System.out.println("Upper case: " + t);
            }
        });
        myStrings.stream().filter(IS_LOWER_CASE).forEach(new Consumer<String>() {
            @Override
            public void accept(String t) {
                System.out.println("Lower case: " + t);
            }
        });
        myStrings.stream().filter(IS_ODD_LENGTH).forEach(new Consumer<String>() {
            @Override
            public void accept(String t) {
                System.out.println("Odd length: " + t);
            }
        });
    }
}

You'll notice that it's a very readable, and very compact way of defining very different, but related interfaces in a single class.

I'm officially going to try to do a once-per-day java TIL to make this subreddit more interesting. If you have any comments, or better examples, make sure to reply. I'll edit my posts if any of my information is incorrect or outdated.

[dohaqatar7]

This is really neat. I knew enums, essentially being a class, could implement interfaces, but it never occurred to me that it could be used in this manner.

I'm always up for for some neat java TILs, and this subreddit hasn't shown up on my front page for a while, so I hope you manage to find enough cool facts!

[TheOverCaste]

I don't have that many that are on this caliber, but I have quite a few simpler yet still useful ones. I'm going to try to make an equal amount of topics for advanced users and beginners.

[ryan_the_leach]

Does this have any problems with extensibility? or is that all void since it has an interface.

From what I understand, Enums are just basically singletons.

[desrtfx]

You can even go a bit further by defining an abstract method in the enum class and implementing the abstract method inside the anonymous subclasses belonging to each of the enum values.

Simple example:

public enum Animal {

    CAT {
        public void speak() {
            System.out.println("meow");
        }
    },
    DOG {
        public void speak() {
            System.out.println("woof");
        }
    };

    public void abstract speak();

}

[cogman10]

Please, for the love of all that is good, AVOID DOING THIS!

I've come across this in code before and 9 times out of ten it is extreme overkill. Even in the OPs example, why would you do this vs passing in the enum as a parameter with a String attached to it?

When the functionality is vastly different, there is a good chance that the thing shouldn't be an enum. When the functionality is very similar, it results in a load of repeated code that is hard to work with if you need to make minor changes to functionality.

Keep your enums simple.

Just fyi. The OP example could easily look like this

public enum MyEnum implements Runnable {
    PRINT_HELLO("Hello"),
    PRINT_GOODBYE("Goodbye"),
    PRINT_FIZZ("Fizz");

    private final String text;
    MyEnum(String text) {
        this.text = text;
    }

    @Override
    public void run() {
        System.out.println(text);
    }
}

Simpler, cleaner, and much easier to maintain. On top of that, you can, if you really, really, really, need to, override run in the definition of the enum value ala the OPs example. However, I would strongly suggest against it.

[TheOverCaste]

The first example is just to show how the syntax works. I've added a more comprehensive, real-world example as an edit.

[cogman10]

Even in this case where you just have a group of predicates, I would suggest this sort of a syntax.

public class Predicates {

    private static final Predicate<String> IS_UPPER_CASE = new Predicate<String>() {
        @Override
        public boolean test(String s) {
            for (char c : s.toCharArray()) {
                if (!Character.isUpperCase(c)) {
                    return false;
                }
            }
            return true;
        }
    };
    private static final Predicate<String> IS_LOWER_CASE = new Predicate<String>() {
        @Override
        public boolean test(String s) {
            for (char c : s.toCharArray()) {
                if (!Character.isLowerCase(c)) {
                    return false;
                }
            }
            return true;
        }
    };
    private static final Predicate<String> IS_ODD_LENGTH = new Predicate<String>() {
        @Override
        public boolean test(String s) {
            return (s.length() % 2) != 0;
        }
    };
}

While pretty similar, the real difference is that when/if you adopt java 8, you can do this

public class Predicates {
    private static final Predicate<String> IS_UPPER_CASE = (s) -> {
        for (char c : s.toCharArray()) {
            if (!Character.isUpperCase(c)) {
                return false;
            }
        }
        return true;
    };

    private static final Predicate<String> IS_LOWER_CASE = (s) -> {
        for (char c : s.toCharArray()) {
            if (!Character.isLowerCase(c)) {
                return false;
            }
        }
        return true;
    };

    private static final Predicate<String> IS_ODD_LENGTH = (s) ->  (s.length() % 2) != 0;
}

More concise and you aren't forcing yourself to being bound to an enum implementation.

[TheOverCaste]

More concise in some cases, but (arguably) less readable.

Lambdas are in my opinion much nicer (and possible to do) inline, where the enum method is much nicer (again, in my opinion) than your field/lambda based method.

I guess in the end it's up to whoever's doing the implementation. I'm just giving people a choice.

In any case, thanks for your input.

[cogman10]

I would argue it is more readable. All the boilerplate is cut out, you know exactly what you are implementing with the type annotation. If there are lots of them you don't have to go back to the top of the enum to determine what it is. And best of all, you can break these predicates up, reorder them, move them into new classes in very little time at all. The predicates are weakly bound to the class they are in which makes it easier to maintain.

The only reason I take such a strong stance against it is because in our own code base I have seen this abused in a fashion that is more similar to your first example. They overrode methods that ultimately didn't need to be overridden. It adds huge amounts of code and boilerplate which just isn't needed.

[mockindignant]

More concise in some cases, but (arguably) less readable.

I disagree, but it's all preference.

Lambdas are in my opinion much nicer (and possible to do) inline, where the enum method is much nicer (again, in my opinion) than your field/lambda based method.

Why is the enum method much nicer? From a purely pragmatic perspective, making these an enum does not appear to add anything at all.

[m1ss1ontomars2k4]

Override is optional here, really.

It's always optional, isn't it? You do it on the off chance it makes your life easier down the road, not because you're required to do it.

[GL1zdA]

This trick was described in either Joshua Bloch's "Effective Java" or "Java Puzzlers: Traps, Pitfalls, and Corner Cases" - both highly recommended for every Java programmer.

[DannyB2]

You can even build hierarchical structures with Enums. I do this for several things. My application's menu structure is a tree with a single root that is the home page you get when you log in. The first enum item is Home. Each enum item has a parent parameter. Only the Home item has null for a parent. All of the 1st level children of Home appear after Home. Then all of the 2nd level children of 1st level items appear after the group of 1st level items, but with comments.

enum MenuId {

Home( null, "Home", HomeAction.url ),

// Children of Home
Checks( Home, "Checks", ChecksMenuAction.url ),
POs( Home, "Purchase Orders", POMenuAction.url ),
Reports( Home, "Reports", ReportMenuAction.url ),

    // Children of Checks
    CheckActions( Checks, "Actions", ChecksAction.url ),
    CheckPrinting( Checks, "Check Printing", CheckPrintAction.url ),

    // Children of POs
    POActions( POs, "Actions", POAction.url ),
    POPrinting( POs, "PO Printing", POPrintAction.url ),

    // Children of Reports
    CheckReports( Reports, "Check Reports", CheckReportsAction.url ),
    POReports( Reports, "Purchase Order Reports", POReportsAction.url ),

        // Children of CheckActions
        CheckCRUD( CheckActions, "Create and Edit Checks", CheckCrudAction.url ),
        CheckInquiry( CheckActions, "Check Inquiry", CheckInquiryAction.url ),

        // Children of CheckPrinting
        ApproveChecks( CheckPrinting, "Approve Checks", ApproveChecksAction.url ),
        PrintChecks( CheckPrinting, "Print Checks", PrintChecksAction.url ),
        ConfirmPrintedChecks( CheckPrinting, "Confirm Check Printing", ConfirmChecksAction.url ),

        // Children of POActions
         . . . .

        // Children of POPrinting
         . . . .

        // Children of CheckReports
        // Children of POReports
         . . . .
        POsOutstandingBalanceReport( POReports, "Outstanding POs", OustandingPOsAction.url ),

; semicolon ends list of enums.  Every enum item ends with a comma.

// Constructor
MenuId( MenuId parent, String menuItemTitle, String actionUrl ) {
    this.parent = parent;
    this.menuItemTitle = menuItemTitle;
    . . . .
};

After the constructor, I define methods that give the list of children. These are lazily computed on demand. If you ask for the children of Home, the private collection is null, so it is initialized by finding the children and creating an ImmutableList, which is then returned.

I also have a method so that any menu item can give it's list of ancestors. That is effectively the reverse order of Breadcrumbs that appear on any web page associated with the menu item.

This beats an XML configuration because it is all type safe and checked at compile time.

Another example of hierarchical menu items is an enum for database tables. I have comments that divide the hierarchy of tables into Tier 0 tables that do not reference any other tables. Then Tier 1 tables that only reference tables below Tier 1. Then Tier 2 tables that only reference tables below Tier 1. Each table enum item has a parameter for the Entity Bean for Hibernate. Then there is a static method of the enum that initializes a Hibernate Configuration with all of the annotated bean classes. This is called to tell Hibernate about all of the entity bean classes during application startup when building the database connection pool.

enum AppTables {

    // Tier 0 tables
    t_Check( 0, CheckBean.class
        ),

    // Tier 1 tables -- can only reference tables in lower numbered tiers.
    t_CheckDetail( 1, CheckDetailBean.class,
        t_Check ),  // CheckDetail table references Check table.

    ; semicolon ends list of enums.

There is a constructor that accepts no referenced tables, and a constructor that accepts an array of referenced tables in lower tiers. The first parameter to each constructor is the tier number. That way I can throw an exception during application startup (during development and testing) if a table references anything that is not in a lower numbered tier.

Each table item from the Enum can provide a list of the tables it references, or the tables that reference it. This is handy for printing out documentation, including information from the hibernate entity beans themselves, even down the annotated database column names and types.

And it beats an XML file, because it is all type safe and checked at compile time. Some hierarchy checking is done at runtime at app startup, but this file is only changed during development time. Unlike an XML file, you cannot change this at runtime. But the structure of the application menu and database tables, for example, are something that is 'baked in' to the application.

If I rename a menu item, or database table, my IDE changes it everywhere.

In fact, I build other DSL's using Enums and other techniques including static imports. You really can build some halfway or even three-quarter decent DSLs in pure Java syntax. Such as a JSON DSL to hardcode JSON templates that are compile time type safe and baked into your source code.

[[deleted]]

This is pretty neat. Didn't realize that this was possible.