views:

392

answers:

3

At the moment Scala runs only on the JVM, with an outdated implementation for the CLR.

But there are some voices at the moment, that Microsoft is interested funding an up-to-date Scala port for .NET.

Considering the lack of any plan or oversight at Oracle's side what to do with Java/the JVM/the ecosystem, how can a Scala developer be prepared that in the end there might be no decent platform left to run Scala on?

Are there any plans to have some "independent" implementation of a Scala VM in the future, which maps Scala's feature to some bytecode/VM, instead of having to live with all these legacy bugs in current VM implementations (no generics, covariant arrays, weird annotations, no tail calls etc.)?

+8  A: 

The current implementation of Scala is very much focused on the JVM. Much in the Scala library depends on classes in the Java standard library and Java classes are also exposed to user programs.

If there are going to be Scala implementations on other platforms such as the CLR or LLVM, then programs written for the current Java-oriented Scala implementation will not be automatically compatible with those other implementations (unless those implementations go to great lengths to support the classes available in Java).

I agree with Randall that the JVM is not going to disappear anytime soon; it's probably the most succesful and widespread virtual machine platform, deployed on billions of devices, from smartcards and handheld devices to the biggest servers. In fact, the Java programming language might disappear much sooner than the JVM itself. There is no reason to fear for the disappearance of the JVM in the forseeable future.

And even in the unlikely case that it does - does it really matter? You'd still be able to program in your favorite programming language Scala, on one of the other platforms.

Jesper
Scala is already available on CLR, although a very old version (I think 1.4).I agree with ur last comment that whether it be JVM or CLR, Scala will be there.
Monis Iqbal
+15  A: 

Here's another view regarding the VM:

While not really Sun's brightest moment if you look the whole picture, slapping the GPL license on JDK/related things has actually caused this wonderful situation where the whole JVM platform is completely independent from Oracle. I mean, the virtual machine isn't tied to Java, the garbage collectors aren't tied to Java and most importantly the Java programmers aren't really tied to Java and thus Oracle.

As a Java programmer, I'd say we won - if Oracle decides to deprecate everything in Java world in hopes of bigger profits, we can just grab the VM and a modern language such as Scala and let Larry Ellison sail to sunset in his yacht for all we care.

Esko
They slapped the BSD on things? I thought it was the GPL.
Ken Bloom
Sssssorry! I must've been out of my mind. Edited to match the truth.
Esko
+4  A: 

I woudn't worry too much about the death of the JVM due to Oracle mismanagement, just as Esko said.

As of now, i do worry about the JVM in another way: The JVM was not constructed as a platform for multiple languages. Most languages running on the JVM use dynamic typing, and are in a way freed from the complexity of compiling to bytecode.

Scala is compiling to bytecode, and was constructed with the JVM in mind by the man (Odersky) who wrote the Java compiler (1.1-1.4). Scala is the only language written by someone with intimate knowledge of the JVM, and we do not really know how hard it was for him to do it.

I worry that the JVM eventually will dwindle in popularity due to the fact that it is not a multi-language platform to begin with.

olle kullberg
The engineers working on the JVM are very much aware that support for other languages than Java is very important. Work is being done for Java 7 to add things like the `invokedynamic` bytecode to the JVM to better support dynamic languages.
Jesper
They introduced invokedynamic because they wouldn't have to think how it would impact Java, they needed the marketing effect against .NET and its DLR and because dynamic languages don't really pose a threat to the position of Java in the VM. Commitment looks diferent, in my opinion...
soc