Enum Best Practices

Enum Best Practices

There are different options to implement enums in Scala. The landscape is roughly:

1. scala.Enumeration

Pros: Library code only. Does not create a class per enum value for simple enums without behaviour.
Cons: need to use dependent types to refer to the type of an enum. Mechanism to list all enums by name is a bit fragile (it depends on Java reflection).

2. Use Java enums.

Pros: Does not create a class per enum value for simple enums without behaviour. Pattern matching on these types checks exhaustiveness. Can be used naturally by Java clients.
Cons: Have to write a few .java files

3. Use sealed case class heirarchies (aka Algebraic Data Types)

Pros: Pattern matching checks exhaustiveness. Easy to customize behaviour in subclasses (overriding methods or introducing new methods)
Cons: Always creates a class for each case. More verbose options 1 and 2. No support to list all cases or to look up a case by name.

4. Use something like Viktor’s enhanced version of scala.Enumeration, see https://gist.github.com/viktorklang/1057513

Pros: as per the description in the Gist. Not a lot of code to copy/paste into your utils package.
Cons: non standard solution.

There have been a few proposals to add language support for true enums to a future version of Scala. Ideally these would emit bytecode that javac would see as a true java enumeration, would support enumeration of the cases and lookup by name, and not require multiple classes per bytecode. However, these proposals so far have been prototyped with experimental additions to the compiler (macro annotations). These are not on our roadmap for the production Scala compiler. So it is a little hard to predict if and when the proposal will be incorporated.


In support, we tend to suggest options 3, and option 2 selectively if reducing bytecode size or Java interop demands it.


    • Related Articles

    • Error Handling Best Practices

      The best overview of the error handling options in the standard library we are aware of is tersesystems.com/2012/12/27/error-handling-in-scala, by Will Sargent, a former Lightbender. Digression: One topic he doesn’t cover is why checked exceptions ...
    • Best practices for picking number of shards for Aggregate Event Tags

      Lagom's  documentation states that you should not change the number of shards for a given AggregateEventTag that you have sharded. What is a good baseline number of shards to pick? What sort of impact does the number of shards have in terms of ...
    • Code Analysis Tools

      Lightbend Analysis Products Security Analysis Lightbend has partnered with Micro Focus to create a product to scan your code for security issues - the Fortify Scala plugin. You can check out the documentation on the Lightbend Tech Hub. The Fortify ...
    • Can I use the Lightbend Fortify plugin for my Java code?

      The simple answer is no. However the good news is that you do not need the plugin for that, as Fortify scans Java more natively (see chapter 4 on “Translating Java Code”).  If you are utilizing our Fortify security plugin to generate Fortify analysis ...
    • What can I ask of Lightbend Support?

      Your subscription entitles you to request assistance for a number of development and system questions. Our assistance can help you succeed from your early planning phases all the way through production maintenance. Below are some general guidelines: ...