What features of Scala cannot be translated to Java?

Question

The Scala compiler compiles direct to Java byte code (or .NET CIL). Some of the features of Scala could be re-done in Java straightforwardly (e.g. simple for comprehensions, classes, translating anonymous/inner functionc etc). What are the features that cannot be translated that way?

That is presumably mostly of academic interest. More usefully, perhaps, what are the key features or idioms of Scala that YOU use that cannot be easily represented in Java?

Are there any the other way about? Things that can be done straightforwardly in Java that have no straightforward equivalent in Scala? Idioms in Java that don't translate?

Good question with good answers. It appears that by comparing Scala to Java, people finally get that _all_ languages are equally powerful but offer different abstractions that have different (dis)advantages. — Raphael, Jan 17 '11 at 08:28

Thomas · Answer 1 · 2010-11-30T01:15:53.183

Traits are one thing that does not have an equivalent. Traits are Interfaces with code in them. You can copy the code to all classes that have a trait mixed in, but that is not the same thing.

Also I believe scala type system is more complete. While it will eventually map to the JVM types (actually suffer erasure). You can express some things in the Scala type system that may not be possible in Java (like variances).

score 11 · Accepted Answer · edited Nov 29 '10 at 18:59

11

This question, in my opinion, misses the point about by asking us to compare JVM languages by looking at their generated bytecode.

Scala compiles to Java-equivalent bytecode. That is, the bytecode could have been generated by code written in Java. Indeed you can even get scalac to output an intermediate form which looks a lot like Java.

All features like traits (via static forwarders), non-local returns (via exceptions), lazy values (via references) etc are all expressible by a Java program, although possibly in a most-ugly manner!

But what makes scala scala and not Java is what scalac can do for you, before the bytecode is generated. What scalac has going for it, as a statically typed language, is the ability to check a program for correctness, including type correctness (according to its type system) at compile time.

The major difference then between Java and scala (as of course Java is also statically typed), therefore, is scala's type system, which is capable of expressing programmatic relations which java-the-language's type system cannot.For example:

class Foo[M[_], A](m : M[A])
trait Bar[+A]

These concept, that M is a type parameter which itself has type parameters or that Bar is covariant, just do not exist in Java-land.

edited Nov 29 '10 at 18:59

Aaron Novstrup

20,967
7
70
108

answered Nov 29 '10 at 17:06

oxbow_lakes

133,303
56
317
449

I would have thought that it is not necesarily the case that all Java byte code possibilites can be generated from a Java source program? Thus there may be cases that Scalac can generate that javac cannnot, and vice versa. – The Archetypal Paul Nov 29 '10 at 17:13
That is true but scala has specifically *not* taken this route. Almost everything byte that scala emits could have been emitted from a Java program. But the fundamental point is that it is not the *bytes* which define scala and what scala can do for you – oxbow_lakes Nov 29 '10 at 18:01
Agreed. I am curious about the differences, nonetheless (Background: I know (very) little Java, and I'm learning Scala. I like what I know of Scala so far, but I'm wondering how much frustration I'm setting myself up for when returning to Java. It's like when I learnt Lisp - that changed the way I wrote in all languages, but some things in Lisp are almost impossible in languages like C. – The Archetypal Paul Nov 29 '10 at 20:39
1

Speaking from experience, you're setting yourself up for _a lot_ of frustration if you're forced to use Java. :) The difference in expressiveness is not quite as dramatic as that between Lisp and C; Scala doesn't have macros after all, and at least Java _has_ a type system albeit a relatively crippled one. I think you'll miss the concise functional syntax even if you can represent functions as Java objects. Beyond that, the weak type system and the lack of multiple implementation inheritance are probably the most frustrating when returning to Java (and they're _very_ frustrating). – Aaron Novstrup Nov 29 '10 at 21:32

Steve · Answer 3 · 2010-11-29T14:40:52.573

4

I think, there is no equivalent for dynamically mix in some Traits. In Scala you can add at the time you're creating new objects some Traits, which are mixed in.

For example, we create one dog which is hungry and thirsty and one dog which is just hungry.

val hungryThirstyDog = new Dog with Hungry with Thirsty
val onlyHungryDog = new Dog with Hungry

I don't know an equivalent way to do this in Java. In Java, the inheritance is statically defined.

edited Nov 29 '10 at 14:40

answered Nov 29 '10 at 14:28

Steve

18,660
4
34
27

Is there a way to solve the same design problem in Java, using some other technique? – The Archetypal Paul Nov 29 '10 at 16:18
@Paul Define "solve", "easily represented", "express naturally", etc. Concerning mixin composition, similar problems are handled in Java by using object (has-a) composition and dependency injection, but these techniques introduce unnecessary dependencies and/or require more boilerplate. – Aaron Novstrup Nov 29 '10 at 20:04
I'm not going down the path of defining all the terms. I'll assume the reader can interpret. Thanks for the response. – The Archetypal Paul Nov 29 '10 at 20:23
I didn't really intend for you to define all the terms. :) My point was simply that the question is somewhat ill-defined because these terms are so broad. I certainly would not consider the kind of code reuse that mixin composition enables to be something that is "easily represented" in Java, but it sounds like you might. To the extent that design problems are optimization problems, does the Java "solution" fail to solve the design problem if the Scala solution is far more satisfying? Does the C "solution" qualify? – Aaron Novstrup Nov 29 '10 at 20:55

score 4 · Answer 4 · answered Nov 29 '10 at 14:40

4

Implicit conversions don't have a straightforward equivalent in Java.

answered Nov 29 '10 at 14:40

Nowaker

12,154
4
56
62

But presumably explicit ones could be done? So this is a convenience (a useful one to be sure) rather than a difference in expressiveness. I'm interested in exploring to what extent Scala allows you to express things more "naturally' (for certain values of "natural") – The Archetypal Paul Nov 29 '10 at 16:20
1

When we express ourselves in natural language, we often elide aspects of the context that are taken for granted by both speaker and hearer (common ground). Similarly, when programming in Scala I find it quite natural to elide parameters or conversions that are clear from the context or from default assumptions. – Aaron Novstrup Nov 29 '10 at 20:16

score 4 · Answer 5 · edited May 23 '17 at 12:01

One feature of scala that I have found a good use for is type reification through Manifests. Since the JVM strips out all type information from generics, scala allows you to conserve this information in variables. This is something that Java reflection AFAIK can't handle, since there are no arguments to types in the bytecode.

The case I needed them was to pattern match on a type of List. This is, I had a VertexBuffer object which stored data on the GPU, that could be constructed from a List of floats or integers. The Manifest code looked approximately like this:

class VertexBuffer[T](data:List[T])(implicit m:Manifest[T]) {
  m.toString.match {
    case "float" => ...
    case "int" => ...
  }
}

This link links to a blog post with more information.

There are plenty of SO pages with more information too, like this one.

Of course, you could require the caller to explicitly pass a `Class` in Java. — Aaron Novstrup, Nov 29 '10 at 21:37
Or any identifier like an enum. Scala's is cleaner, but I guess it is not a huge difference. — nullspace, Nov 29 '10 at 22:30

score 3 · Answer 6 · answered Nov 30 '10 at 00:37

3

Three words: higher kinded types.

answered Nov 30 '10 at 00:37

Apocalisp

34,834
8
106
155

score 0 · Answer 7 · answered Dec 05 '10 at 12:25

0

Your topic is not clear wehther you mean Java the JVM or Java the language. Given that Scala runs on the JVM, the q makes no sense, as we all know Scala runs on the JVM.

answered Dec 05 '10 at 12:25

mP.

18,002
10
71
105

I think it's clear already, but for clarity I mean Java the language – The Archetypal Paul Dec 05 '10 at 12:49
Then by definition its possible to express any scala construct in java even if theres alot of boilterplate and noisy. – mP. Dec 06 '10 at 04:00
1

No, that's only true if there is a Java program that can produce all valid bytecode sequences. I've no idea if that's true, but it's not a given. And I did use the word "straighforward" in the question. Java and Scala are equivalent in that both are Turing complete, but expressiveness, clarity and so on may differ. That's what I was after – The Archetypal Paul Dec 06 '10 at 21:34
Java is turing complete, anything can – mP. Dec 07 '10 at 03:41

score 0 · Answer 8 · answered Jan 17 '11 at 04:43

0

Scala has a "native" support for XML. You can build the XML, find elements, match directly in the Scala code.

Examples: http://programming-scala.labs.oreilly.com/ch10.html

answered Jan 17 '11 at 04:43

Nowaker

12,154
4
56
62

What features of Scala cannot be translated to Java?

8 Answers8