On Java 8 - it's not just because of the purpose of interoperability, but also for the runtime improvements. Things like invokeDynamic, ConstantCallSite and others are not in Java 6. Upgrading the requirement means opening the door to performance improvements and is a real concern of many. How much it can be achieved in Scala I don't know, but these improvements in the JVM have made a dramatic difference for other JVM languages.
Going back to Android - it's not right for Android to hold back the Java ecosystem. I've been rooting for Google in their lawsuit with Oracle, but they should also get their act together and improve Android's runtime and toolchain to keep it up to date with the latest Java.
As this is not going to be a problem just for Scala developers - this is going to be a problem for the whole ecosystem, as Java libraries will eventually have good reasons to upgrade from Java 6 too. For example value classes are coming and possibly generic specialization for those value classes in the next versions (like 9 or 10, so it will happen, it's on the roadmap) and there are libraries that desperately want to avoid boxing. So what then? Will we stay with Java 6?
In fact I think this upgrade to Java 8 is sort of anti-enterprise. How many companies have you see with projects running on anything newer than Java 6? There are still companies running with Java 1.4 for that matter. Java 8 is bleeding edge and it will remain to be bleeding edge in 2016.
For example value classes are coming and possibly generic specialization for those value classes in the next versions (like 9 or 10, so it will happen, it's on the roadmap) and there are libraries that desperately want to avoid boxing. So what then? Will we stay with Java 6?
Well, Scala already does value specialization even on Java 6, so that's less urgent. You are right of course, but I think most libraries will simply release new versions that require Java 8, rather than having an intermediate version with no changes except a Java 8 port. But I could be wrong.
In fact I think this upgrade to Java 8 is sort of anti-enterprise. How many companies have you see with projects running on anything newer than Java 6? There are still companies running with Java 1.4 for that matter. Java 8 is bleeding edge and it will remain to be bleeding edge in 2016.
I agree - which makes the Typesafe stance rather perverse. Are there really going to be people in 2016 who want to move their Scala to 2.12 so they can call it from Java 8, but would be put off if 2.12 contained any new features? Who won't have anyone available to fix even the most minor of syntactic changes? (or not even that - Typelevel is talking about a compiler that accepts all valid Typesafe-scala programs, with all the new syntaxes being things that are currently errors). I really don't think including partially applied types, byte/short literals, or singleton types in Scala 2.12 would be a dealbreaker for anyone (though I guess Typesafe has to draw their line in the sand somewhere).
What I expect/hope will happen is that Typesafe will accept pull requests for those pieces and some fixing up of macros, which will be enough to make a Scala I'm happy using until 2017. Then this fork can either become a place for further experimentation like Meta, or quietly die; important libraries will be able to continue to support Typesafe Scala, Typesafe will have accepted the proven features that users want without opening the floodgates to every experimental piece under the sun, and the community can hang together.
I think the idea behind keeping 2.11/2.12 as similar as possible is to enable people to cross-build things more easily, which would drastically improve the life span of the last Java6-compatible release (2.11) until people have found better solutions.
(I can imagine that there will be generic translators from Java8 bytecode to Java6 bytecode, so why should they keep maintaining two backends, if they could maintain one and just leverage a common tool to do the rest?)
Well I have those hopes too - this can be a very positive thing, since it can attract more contributions to Scala.
After all, the Scala core probably has their plate full and could use some help. It's one thing to make a proposal for a feature to a group of developers with their hands full, it's quite another to submit a pull request saying "look, this is useful, people like it" - it changes the equation.
Comments
On Android - I agree it is worrisome.
On Java 8 - it's not just because of the purpose of interoperability, but also for the runtime improvements. Things like invokeDynamic, ConstantCallSite and others are not in Java 6. Upgrading the requirement means opening the door to performance improvements and is a real concern of many. How much it can be achieved in Scala I don't know, but these improvements in the JVM have made a dramatic difference for other JVM languages.
Going back to Android - it's not right for Android to hold back the Java ecosystem. I've been rooting for Google in their lawsuit with Oracle, but they should also get their act together and improve Android's runtime and toolchain to keep it up to date with the latest Java.
As this is not going to be a problem just for Scala developers - this is going to be a problem for the whole ecosystem, as Java libraries will eventually have good reasons to upgrade from Java 6 too. For example value classes are coming and possibly generic specialization for those value classes in the next versions (like 9 or 10, so it will happen, it's on the roadmap) and there are libraries that desperately want to avoid boxing. So what then? Will we stay with Java 6?
In fact I think this upgrade to Java 8 is sort of anti-enterprise. How many companies have you see with projects running on anything newer than Java 6? There are still companies running with Java 1.4 for that matter. Java 8 is bleeding edge and it will remain to be bleeding edge in 2016.
Well, Scala already does value specialization even on Java 6, so that's less urgent. You are right of course, but I think most libraries will simply release new versions that require Java 8, rather than having an intermediate version with no changes except a Java 8 port. But I could be wrong.
I agree - which makes the Typesafe stance rather perverse. Are there really going to be people in 2016 who want to move their Scala to 2.12 so they can call it from Java 8, but would be put off if 2.12 contained any new features? Who won't have anyone available to fix even the most minor of syntactic changes? (or not even that - Typelevel is talking about a compiler that accepts all valid Typesafe-scala programs, with all the new syntaxes being things that are currently errors). I really don't think including partially applied types, byte/short literals, or singleton types in Scala 2.12 would be a dealbreaker for anyone (though I guess Typesafe has to draw their line in the sand somewhere).
What I expect/hope will happen is that Typesafe will accept pull requests for those pieces and some fixing up of macros, which will be enough to make a Scala I'm happy using until 2017. Then this fork can either become a place for further experimentation like Meta, or quietly die; important libraries will be able to continue to support Typesafe Scala, Typesafe will have accepted the proven features that users want without opening the floodgates to every experimental piece under the sun, and the community can hang together.
I think the idea behind keeping 2.11/2.12 as similar as possible is to enable people to cross-build things more easily, which would drastically improve the life span of the last Java6-compatible release (2.11) until people have found better solutions.
(I can imagine that there will be generic translators from Java8 bytecode to Java6 bytecode, so why should they keep maintaining two backends, if they could maintain one and just leverage a common tool to do the rest?)
Well I have those hopes too - this can be a very positive thing, since it can attract more contributions to Scala.
After all, the Scala core probably has their plate full and could use some help. It's one thing to make a proposal for a feature to a group of developers with their hands full, it's quite another to submit a pull request saying "look, this is useful, people like it" - it changes the equation.