问题
Scala is a wonderful language, but I wonder how could be improved if it had it's own runtime?
I.e. what design choices were made because of JVM choice?
回答1:
This article is a discussion with Martin Odersky (Scala's creator) and includes the compromises that were made in Scala for compatibility with Java. The article mentions:
- Static overloading of methods
- Having both traits and classes
- Inclusion of
nullpointers.
回答2:
The two most important compromises I know about are:
- type erasure ("reflecting on Type"): It has to manage a Manifest to get around the Java compilation (independent of the JVM, for backward compatibility reason).
- collection of primitive type: e.g.: arrays
new scheme of handling arrays in Scala 2.8. Instead of boxing/unboxing and other compiler magic the scheme relies on implicit conversions and manifests to integrate arrays
Those are the two main JVM limitations, when it comes to manage generic type (with bounds): The Java JVM does not keep the exact type use in a generic object, and it has "primitive" types.
But you could also consider:
- Tail-call optimization is not yet full supported by the JVM, was hard to do anyway (and yet Scala 2.8 introduces the @tailrec annotation)
- UAP (universal Access Principle) needs to be emulated (not supported by Java), and will be soon completed for Value Holder (@proxy)
- the all mix-in mechanism needs also to be emulated
- more generally, the huge number of static types introduced by Scala need (for most of them) to be generated in Java:
In order to cover as many possibilities as possible, Scala provides:
- Conventional class types,
- Value class types,
- Nonnullable types,
- Monad types,
- Trait types,
- Singleton object types (procedural modules, utility classes, etc.),
- Compound types,
- Functional types,
- Case classes,
- Path-dependent types,
- Anonymous types,
- Self types,
- Type aliases,
- Generic types,
- Covariant generic types,
- Contravariant generic types,
- Bounded generic types,
- Abstract types,
- Existential types,
- Implicit types,
- Augmented types,
- View bounded types, and
- Structural types which allow a form of duck typing when all else fails
回答3:
Less an issue with the runtime than a cultural hangover: universal equality, hashing, toString.
More deeply tied to the VM: strict by default evaluation, impure functions, exceptions.
来源：https://stackoverflow.com/questions/2682673/what-compromises-scala-made-to-run-on-jvm