Java – Why do some projects not use generics

There's one thing that you can do concisely and efficiently in Java that you can't in Scala: enumerations. For everything else, even for constructs that are slow in Scala's library, you can get efficient versions working in Scala.

So, for the most part, you don't need to add Java to your code. Even for code that uses enumeration in Java, there's often a solution in Scala that is adequate or good -- I place the exception on enumerations that have extra methods and whose int constant values are used.

As for what to watch out for, here are some things.

• If you use the enrich my library pattern, always convert to a class. For example:

  // WRONG -- the implementation uses reflection when calling "isWord"
  implicit def toIsWord(s: String) = new { def isWord = s matches "[A-Za-z]+" }
  
  // RIGHT
  class IsWord(s: String) { def isWord = s matches "[A-Za-z]+" }
  implicit def toIsWord(s: String): IsWord = new IsWord(s)
  

• Be wary of collection methods -- because they are polymorphic for the most part, JVM does not optimize them. You need not avoid them, but pay attention to it on critical sections. Be aware that for in Scala is implemented through method calls and anonymous classes.

• If using a Java class, such as String, Array or AnyVal classes that correspond to Java primitives, prefer the methods provided by Java when alternatives exist. For example, use length on String and Array instead of size.

• Avoid careless use of implicit conversions, as you can find yourself using conversions by mistake instead of by design.

• Extend classes instead of traits. For example, if you are extending Function1, extend AbstractFunction1 instead.

• Use -optimise and specialization to get most of Scala.

• Understand what is happening: javap is your friend, and so are a bunch of Scala flags that show what's going on.

• Scala idioms are designed to improve correctness and make the code more concise and maintainable. They are not designed for speed, so if you need to use null instead of Option in a critical path, do so! There's a reason why Scala is multi-paradigm.

• Remember that the true measure of performance is running code. See this question for an example of what may happen if you ignore that rule.

As far as I can tell, the question is why wrapping String constants into enum hasn't been considered sufficient to cover the needs of language users. This has been addressed in the official feature proposal announced at JDK 7 (project Coin) mailing list.

Per my reading of the proposal, alternative of using enums has been dismissed on the ground that it introduces types bloat. For your convenience, relevant part of the proposal is quoted below, with the statement addressing enums quoted in bold:

MAJOR ADVANTAGE: What makes the proposal a favorable change?

More regular coding patterns can be used for operations selected on the basis of a set of constant string values; the meaning of the new construct should be obvious to Java developers.

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

Potentially better performance for string-based dispatch code.

MAJOR DISADVANTAGE: There is always a cost.

Some increased implementation and testing complexity for the compiler.

ALTERNATIVES: Can the benefits and advantages be had some way without a language change?

No; chained if-then-else tests for string equality are potentially expensive and introducing an enum for its switchable constants, one per string value of interest, would add another type to a program without good cause...