Scala 2.11 may require Java 7

2,045 views
Skip to first unread message

Adriaan Moors

unread,
Mar 7, 2013, 12:11:42 PM3/7/13
to scala-i...@googlegroups.com, scala-user
Hi,

Is Java 6 support important for you to have in Scala 2.11?
If so, time to speak up: http://www.scala-lang.org/node/30977 (the poll takes approximately 3500ms to answer).

We are considering moving to Java 7 in 2.11 so that we can compile functions using MethodHandles.

To keep things simple (for you and ourselves), we'd rather not (officially) support two incompatible class formats in one Scala release (i.e., Java 6 & 7), as this would result in a fragmented eco system, where artifacts would have to indicate which Java version they're targeting in addition to the Scala version.

cheers
adriaan

Simon Ochsenreither

unread,
Mar 7, 2013, 12:15:30 PM3/7/13
to scala-i...@googlegroups.com, scala-user
I think the wording of the poll is fundamentally flawed and the results are therefore next to useless.

I could word the question as “should Scala 2.11 drop Android support?” and get the opposite outcome.

Michael Swierczek

unread,
Mar 7, 2013, 12:27:33 PM3/7/13
to Simon Ochsenreither, scala-i...@googlegroups.com, scala-user
Are there any killer features coming in 2.11 that Scala developers on
Android must have? If not, then what does it matter?

-Mike


> --
> You received this message because you are subscribed to the Google Groups
> "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scala-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Alec Zorab

unread,
Mar 7, 2013, 12:28:02 PM3/7/13
to scala-i...@googlegroups.com, scala-user
Disagree. Android applications can still be written in 2.10 - nobody is taking away the right to use versions other than 2.11


On 7 March 2013 17:24, Jesper Nordenberg <mega...@yahoo.com> wrote:
Agreed. As long as Android (and alternative JVM's like Avian) doesn't support invokedynamic it would be a mistake to drop support for Java 6 IMHO.

/Jesper Nordenberg



--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.

Josh Suereth

unread,
Mar 7, 2013, 12:32:33 PM3/7/13
to scala-i...@googlegroups.com, scala-user

Well, if bug fixes stop hitting 2.10, it could be a burden.

Plus, android could benefit a lot from modularisation on the horizon....

To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

Simon Ochsenreither

unread,
Mar 7, 2013, 12:41:48 PM3/7/13
to scala-i...@googlegroups.com, scala-user

Disagree. Android applications can still be written in 2.10 - nobody is taking away the right to use versions other than 2.11

I think nobody is disagreeing with that. I still think that dropping support for the most vibrant “Java” ecosystem out there is absolutely the wrong approach.

Especially because I think it is only a matter of time until Google adds Java 7 support, so having to announce that we drop support for Android and then having to back-pedal some time later will add a lot of confusion.

Considering how bad Scala's platform support currently is, it would suck to loose yet another platform.

Additionally, I think stuff is moving to fast here ... we only deprecated Java 5 support/moved to Java 6 as a baseline in the last release, right?

I think Josh's point about modularization is also important. ProGuard takes a lot of time, not having to do during development would be great.
Additionally, I think a lot of the backend improvements in 2.11 will be even more helpful to Android than to OpenJDK.

Rex Kerr

unread,
Mar 7, 2013, 12:42:35 PM3/7/13
to Michael Swierczek, Simon Ochsenreither, scala-i...@googlegroups.com, scala-user
On Thu, Mar 7, 2013 at 12:27 PM, Michael Swierczek <mike.sw...@gmail.com> wrote:
On Thu, Mar 7, 2013 at 12:15 PM, Simon Ochsenreither
<simon.och...@gmail.com> wrote:
> I think the wording of the poll is fundamentally flawed and the results are
> therefore next to useless.
>
> I could word the question as “should Scala 2.11 drop Android support?” and
> get the opposite outcome.
>

Are there any killer features coming in 2.11 that Scala developers on
Android must have?  If not, then what does it matter?

2.11 is supposed to be the performance release.  Nowhere is performance more critical than on mobile devices.  Not having the high-performance Scala working on the biggest ecosystem where high performance is needed seems unwise.

_Personally_ I won't need 2.11 on 1.6; I'll migrate by then or stick with 2.10.  But _strategically_ it seems like a significant blunder.  If it is a blunder necessitated by available resources and ecosystem fragmentation, well, fair enough, but that doesn't make it desirable.

(I also don't know if 2.11 is actually going to have the scale of performance improvements that will really make one desperate for it instead of 2.10.  I'm really encouraged by what I see so far, but it's mostly a few percent here and there, not factors of 2 or more like you could have with e.g. specialized or macroed collections.)

  --Rex

Mark Harrah

unread,
Mar 7, 2013, 12:42:44 PM3/7/13
to scala-i...@googlegroups.com, scala-user
The poll question itself is exactly what the Scala team wants to know the answer to. Biasing respondents towards one particular disadvantage of two of the options doesn't help answer that fundamental question. Perhaps the survey should have linked to a discussion of advantages and disadvantages, but it is otherwise a neutral question and the right question to ask in my opinion.

-Mark

Adriaan Moors

unread,
Mar 7, 2013, 1:20:37 PM3/7/13
to scala-i...@googlegroups.com, scala-user

On Thu, Mar 7, 2013 at 9:41 AM, Jesper Nordenberg <mega...@yahoo.com> wrote:
- What's the time plan for the 2.11 release?
 
- How long will the 2.10 branch be maintained?
Forever. Or did you mean by Typesafe? It depends on the business case, but I think it's safe to say 2.9's lifespan is a good indicator. We hope to provide more frequent minor releases in 2.10, especially if we decide to require Java 7 in 2.11.
 
- What features in Java 7 besides invokedynamic would be beneficial (or are planned) for Scala to depend upon?
That's the big one (faster closures, potentially faster structural types,...).
Not having our own fork/join jar in the dist will be a nice bonus.

cheers
adriaan

Simon Ochsenreither

unread,
Mar 7, 2013, 1:25:38 PM3/7/13
to scala-i...@googlegroups.com, scala-user

The poll question itself is exactly what the Scala team wants to know the answer to.  Biasing respondents towards one particular disadvantage of two of the options doesn't help answer that fundamental question.  Perhaps the survey should have linked to a discussion of advantages and disadvantages, but it is otherwise a neutral question and the right question to ask in my opinion.

I disagree completely. The question itself isn't even clear. Does “target” mean “support”? “require”? “establish as a new baseline?”

The only thing the question currently asks is “could you please pick the shiniest version number?”.

Instead of discussing about other peoples' issues and causing problems for them without asking, I just sent a mail to the scala-on-android list. Let's see what their opinion is.

Andrzej Giniewicz

unread,
Mar 7, 2013, 2:20:27 PM3/7/13
to Simon Ochsenreither, scala-user
I can speak for myself, but I decided to learn Scala only because of possibility to develop cross-platform to Android. Otherwise I was happy with features Haskell has offered - I even had to accept some trade-offs of Scala like lack of effect isolation with monads and other features I'm used to from Haskell. On the other hand, I believe we are just week after End of Line for Java 6 from Oracle, meaning it's dead horse (other implementation aren't so widespread), so staying with Java 6 also isn't perfect (for enterprise solutions at least).

I looked but haven't found any statement from Google. Squeezing some informations from them about their plans in relation to Java 7 might be good? If they add support for Java 7 before 2013 ends, when Scala 2.11 arrives it would be longer an issue, so maybe we don't have to be worried? Someone knows anything about it? Unfortunately "Java 7 support" ticket on Google Android tracker - http://code.google.com/p/android/issues/detail?id=33201 - has like 15 votes only, while lots has like thousands - I already added by star to it and some comments - giving link to this thread as evidence about the imminent move to Java 7 features everywhere, but I doubt if this is such rarely requested feature they will care about it.

That's why without any knowledge if Google will support Java 7 features, I voted to keep the version at 6.0, at least for now, or at least as an option. I'd be happy to get slower code with a compiler switch to be able to deploy to Android platform - it's a huge market. Entering closed road isn't good, even if we know that we will hit the wall two years from now, it's too risky when you use some technology as base for business, so arguments like "stay with old version then" aren't speaking to me either - support for it will likely end way before I plan to stop supporting my apps.

Alexandru Nedelcu

unread,
Mar 8, 2013, 1:45:25 AM3/8/13
to Andrzej Giniewicz, Simon Ochsenreither, scala-user
On Thu, Mar 7, 2013 at 9:20 PM, Andrzej Giniewicz <ggi...@gmail.com> wrote:
> I looked but haven't found any statement from Google. Squeezing some
> informations from them about their plans in relation to Java 7 might be
> good? If they add support for Java 7 before 2013 ends, when Scala 2.11
> arrives it would be longer an issue, so maybe we don't have to be worried?

To add my 2 cents ... it doesn't really matter if Google adds or not
support for Java 7, if that support implies newer versions of Android
OS. We still develop for Android 2.2.

JRuby is able to run on both versions and on Android and it's more
complicated for JRuby to have such support, as the internal mechanism
for doing method dispatch is more complicated for a dynamic language,
relying on runtime bytecode generation.

Btw, running apps compiled for Java 7 on top of JDK 6 should be
possible by backporting invokeDynamic and method handles. I remember
seeing a functional backport of JSR 292 by Rémi Forax that made use of
a virtual machine agent to pull it off. Unfortunately Android doesn't
have a JVM and is much more limited than Java 6.

--
Alexandru Nedelcu
http://bionicspirit.com

Rich Oliver

unread,
Mar 8, 2013, 7:30:55 AM3/8/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
Surely we can't delay the the whole development of Scala just because Android might not have got round to implementing it by the time 2.11 comes out. Would it not be better for Scala Android developers to try and get some sense of urgency in the java Android developer community. Will none of Andoid's competitors support Java 7 even if its just the new Ubuntu phone? Once one operating system provides it that then you can start talking about possible security risks from Java 6. Pressure can be brought to bear against companies operating in a highly competitive consumer market.

It seems that Oracle has been good for Java and the JVM. Things are really moving after years of stagnation. Scala needs to adjust to the new reality. There really is a new version coming down the pipe every two years. If 2.11 is going to support two versions I'd like it to be 7 and 8. It would be great if Scala could start targeting and supporting ScalaFX as its primary GUI. It would also be nice to see forward movement with eclipse. Will Juno suppport Java 8? Or do should we be thinking about support for Kepler?

Lukas Rytz

unread,
Mar 8, 2013, 7:42:00 AM3/8/13
to scala-i...@googlegroups.com, scala...@googlegroups.com
Also: (http://en.wikipedia.org/wiki/Java_version_history)
 - Java 6: December 11, 2006
 - Java 7: July 28, 2011

 - "After February 2013, Oracle will no longer post updates of Java SE 6 to its public download sites"
Though:
 - "For enterprise customers, who need continued access to critical bug fixes and security fixes as
   well as general maintenance for Java SE 6 or older versions, long term support is available"



--

sterglee

unread,
Mar 8, 2013, 7:45:25 AM3/8/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
Hi all,

it seems to me that each version of Scala introduces many new features
to the way the Scala interpreter can be utilized programmatically.

This is of course very positive, and a consequence of the continuous and
fast improvements but not without side effects.

In particular, when I try to interface ScalaLab to run with a new Scala
version (e.g. Scala 2.11), I have a lot of problems.

I would like to ask,
if there is a standard Scala Interpreter API to study.

Also, what is the recommended path of study in order to understand some
more details about the implementation of the Scala compiler?
It's a very advanced compiler and with a try to understand it, I become
rather confused!!



Best Regards

Stergios


Simon Ochsenreither

unread,
Mar 8, 2013, 7:55:35 AM3/8/13
to scala-i...@googlegroups.com, scala...@googlegroups.com

Surely we can't delay the the whole development of Scala just because Android might not have got round to implementing it by the time 2.11 comes out.

It is not about delaying “the whole development”, but about whether we want to be a general purpose language or just some Oracle add-on provider.

Scala will not be successful if we keep artificially decreasing the number of potential users. Scala on .NET is more or less dead, Scala on LLVM is probably years apart from a mature environment, there have been multiple abandoned attempts for JavaScript backend, ...

We are basically down to OpenJDK/Oracle and Android. Do we really want to kill yet another platform?

I have nothing against moving the base-line for Scala 2.12 to Java 7 or 8, (my impression is that 7 isn't really interesting as a target) as long as we keep support for Java 6 class files indefinitely and make it easy in SBT to do source-only builds.

 
Would it not be better for Scala Android developers to try and get some sense of urgency in the java Android developer community. Will none of Andoid's competitors support Java 7 even if its just the new Ubuntu phone?

I don't think so. After Oracle's recent behavior it seems that everyone, who isn't as deeply invested in Java already as Google was, keeps the hell away from Java. Which means: A lot more platforms on which Scala WON'T run.


TLDR: Do what you want with Scala 2.12, as long as you keep the Java 6 backend available and make it easy for people to build libraries themselves.

Johannes Rudolph

unread,
Mar 8, 2013, 8:31:21 AM3/8/13
to scala-i...@googlegroups.com, scala-user
I see Java 5/6 bytecode as a defacto standard platform for almost the
last decade. That's why Android choose it. On the other side, the
compatibility issue raised here is a major one. Scala has to make
progress and some of this progress is only to be made with the
additions of Java 7/8. But, you can't support both Java 6 and 7
without splitting the whole Scala universe. These are the facts as I
see them.

If you see Scala as just another language on the established platform
of Java 6 Scala should probably try to stay compatible with this
platform as long as possible.

If you see the whole Scala ecosystem as the platform itself, progress
is only made by going forward (that doesn't mean not to maintain older
versions for a while, of course).

If I compare how I am using Scala mostly and where I profit most from
Scala it's by using the current Scala language and the stack and
ecosystem to build self-contained applications than run on a platform
I control. I tried Scala on Android and I did my share to make it
somewhat work but I never got productive enough to build something
real.

If I should choose between a possible speedup with Java 7 for 99% of
the code I'm writing vs. a theoretical compatibility with the Android
of now which never was fully compatible in practice I'd choose speed,
features and going forward.

Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Aliaksandr Zhuhrou

unread,
Mar 8, 2013, 8:46:50 AM3/8/13
to scala-i...@googlegroups.com, scala-user
I think that scala simple can't afford moving forward even more slowly that Java. 
This argument alone looks to be sufficient.  


2013/3/8 Johannes Rudolph <johannes...@googlemail.com>
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.





--
Contacts:
  telephone: +375291637178
  skype: zhygr34

Simon Ochsenreither

unread,
Mar 8, 2013, 8:52:45 AM3/8/13
to scala-i...@googlegroups.com, scala-user, johannes...@googlemail.com

I see Java 5/6 bytecode as a defacto standard platform for almost the
last decade. That's why Android choose it. On the other side, the
compatibility issue raised here is a major one. Scala has to make
progress and some of this progress is only to be made with the
additions of Java 7/8. But, you can't support both Java 6 and 7
without splitting the whole Scala universe. These are the facts as I
see them.

I'm not saying that we can't make any progress. I certainly want all those improvements, too. It is just that I think Scala 2.11 is too early. There are so many things moving around and changing at the moment that I think it is a mistake to make such decisions without knowing how things are settling down in the end.
We have no idea how Google will react when masses of their developers will start demanding support for lambdas.
We have no idea if any alternative JVM implementation will ever implement the invokedynamic/MethodHandle/Lambda stuff at all.


If I compare how I am using Scala mostly and where I profit most from
Scala it's by using the current Scala language and the stack and
ecosystem to build self-contained applications than run on a platform
I control. I tried Scala on Android and I did my share to make it
somewhat work but I never got productive enough to build something
real.

If I should choose between a possible speedup with Java 7 for 99% of
the code I'm writing vs. a theoretical compatibility with the Android
of now which never was fully compatible in practice I'd choose speed,
features and going forward.

It's not only Android. We are pretty much dropping support for anything non-Oracle (or Oracle-derived).
Am I the only one who thinks that betting the whole farm on Oracle is a hysterically bad move?

When I could describe how this feels like to me, I would say it is like the excitement of COBOL developers when COBOL 2002 was released. It was absolutely great for them, but because they lived in a bubble they didn't realize it was completely irrelevant for almost anybody else.
Scala will face irrelevancy too, if the only thing we can say is “it's nicer than Java”. For an increasing number of developers out there, Java is not a problem because they don't use it in the first place.

Scala has tons of good reasons why non-Java people should consider it. We completely fail to capture that opportunity.
We will loose out on tons of brilliant people, innovation and fresh ideas if we keep closing down Scala's target market to “Java programmers running on Oracle's latest and greatest stuff”.

Andrzej Giniewicz

unread,
Mar 8, 2013, 8:59:54 AM3/8/13
to Adriaan Moors, scala-user
Just one short extra question then.

If 2.11 is performance release instead of feature release, can it at least guarantee source code compatibility between 2.11 and 2.10? I know that there will be no binary compatibility, but could any valid 2.11 program be recompiled with 2.10? At least in form of optional flags for 2.10.

This would extend the support for platform running 500.000.000 devices (and possible clients for some of us) running Android by another year and maybe by then Android 292 will be done ( https://bitbucket.org/jpilliet/android-292 ).

Rodrigo Cano

unread,
Mar 8, 2013, 11:16:31 AM3/8/13
to Andrzej Giniewicz, Adriaan Moors, scala-user
FWIW, I'm with Simon Ochsenreither. Restricting even more the potential use cases of scala its going to push back its adoption.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

Adriaan Moors

unread,
Mar 8, 2013, 12:18:39 PM3/8/13
to Andrzej Giniewicz, scala-user

On Fri, Mar 8, 2013 at 5:59 AM, Andrzej Giniewicz <ggi...@gmail.com> wrote:
If 2.11 is performance release instead of feature release, can it at least guarantee source code compatibility between 2.11 and 2.10?
Source compatibility is best effort (our very best, though) and modulo deprecation. We don't have tools to verify compatibility here like we do for binary compatibility, so it's hard to make stronger promises than this.

We're working on building more open source projects automatically as an additional test suite, because we do strive to make a major upgrade as easy as recompiling (once your dependencies have done the same). That is, assuming you've not been ignoring those deprecation warnings.

cheers
adriaan

James Moore

unread,
Mar 8, 2013, 12:54:45 PM3/8/13
to scala...@googlegroups.com, Andrzej Giniewicz
Speaking as an Android developer, here's my take.

Java 7 is a experiment, not the main line of development.  Not only that, but it's very unlikely that it will _ever_ be the main line of development.  Think of it as a very, very exotic fork.  Possibly it's interesting to some people, but it's not even close to mainstream.  The mainstream isn't even talking about Java 7, much less implementing it.

I think it would be appropriate to add experimental support in Scala for experimental features in exotic Java environments.  It would be a terminal, horrible mistake to make any mainstream Scala environment dependent on a (possibly doomed) Java fork.

Dinotzar Tzar

unread,
Mar 8, 2013, 1:25:08 PM3/8/13
to scala...@googlegroups.com
On Fri, Mar 8, 2013 at 6:54 PM, James Moore <ja...@banshee.com> wrote:
Speaking as an Android developer, here's my take.

Java 7 is a experiment, not the main line of development.  Not only that, but it's very unlikely that it will _ever_ be the main line of development.  Think of it as a very, very exotic fork.  Possibly it's interesting to some people, but it's not even close to mainstream.  The mainstream isn't even talking about Java 7, much less implementing it.


Certainly, you mean "Java 8"...?

Java 7 is definitely not vapor ware (go to java.com if you don't believe me, and check out what version they recommend you to download.)

D.

 

I think it would be appropriate to add experimental support in Scala for experimental features in exotic Java environments.  It would be a terminal, horrible mistake to make any mainstream Scala environment dependent on a (possibly doomed) Java fork.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

Dinotzar Tzar

unread,
Mar 8, 2013, 1:27:17 PM3/8/13
to scala...@googlegroups.com
On Fri, Mar 8, 2013 at 7:25 PM, Dinotzar Tzar <dino...@gmail.com> wrote:


On Fri, Mar 8, 2013 at 6:54 PM, James Moore <ja...@banshee.com> wrote:
Speaking as an Android developer, here's my take.

Java 7 is a experiment, not the main line of development.  Not only that, but it's very unlikely that it will _ever_ be the main line of development.  Think of it as a very, very exotic fork.  Possibly it's interesting to some people, but it's not even close to mainstream.  The mainstream isn't even talking about Java 7, much less implementing it.


Certainly, you mean "Java 8"...?

Java 7 is definitely not vapor ware (go to java.com if you don't believe me, and check out what version they recommend you to download.)


Argh... sorry. I missed the first part, "[s]peaking as an Android developer".

I take my last email back.

D.

 

Jesper Nordenberg

unread,
Mar 8, 2013, 4:11:13 PM3/8/13
to scala...@googlegroups.com, Andrzej Giniewicz, scala-user
Adriaan Moors skrev 2013-03-08 18:18:
>
> On Fri, Mar 8, 2013 at 5:59 AM, Andrzej Giniewicz
> <ggi...@gmail.com
> <mailto:ggi...@gmail.com>> wrote:
>
> If 2.11 is performance release instead of feature release, can it at
> least guarantee source code compatibility between 2.11 and 2.10?
>
> Source compatibility is best effort (our very best, though) and modulo
> deprecation. We don't have tools to verify compatibility here like we do
> for binary compatibility, so it's hard to make stronger promises than this.

You're talking about source compatibility from 2.10 to 2.11, not the
other way around, right? Andrzej meant source compatibility from 2.11 to
2.10.

/Jesper Nordenberg

Adriaan Moors

unread,
Mar 8, 2013, 6:26:40 PM3/8/13
to scala-i...@googlegroups.com, scala-user
We met with John Rose today and he mentioned there's a backport of Java 7 on Java 6: http://weblogs.java.net/blog/forax/archive/2009/07/jsr292_backport.html

Also, since our use of invokedynamic would be pretty regular, it shouldn't be too hard to use ASM to statically rewrite Scala 2.11.x bytecode into something Dalvik/Java 6 can deal with (that is, assuming Google doesn't catch up over the next 12 months and this will actually be necessary).

cheers
adriaan


On Thu, Mar 7, 2013 at 11:04 AM, Jesper Nordenberg <mega...@yahoo.com> wrote:
Yep, supporting two variants of 2.11 would be quite a burden.

IMO, Android's lack of support for invokedynamic is the major stumbling block here as it will be virtually impossible to write a Scala app that wouldn't use it. I have no idea when and how Google plans to implement support for invokedynamic in Dalvik and if they will make it possible to use it on existing Android versions (not being able to do so would be a huge problem). Invokedynamic has not been commonly used yet (JRuby being the exception?), but with Java 8 planned to be release later this year and every Java developer wanting to use lambdas on Android I don't see how they can hold off the pressure much longer. So, my guesstimation is that at the latest a few months after Java 8 is released Android will have support for invokedynamic. Given the time plan for Scala 2.11 it looks plausible that that will happen before the final 2.11 release.

/Jesper Nordenberg

James Iry skrev 2013-03-07 19:23:

IF we move to Java 7 as the base line then the entire library would be compiled with it and would not run under Java 6. So "-target6" wouldn't be very useful even as a backstop.

IF we stick to Java 6 as the base line then we could add a "-target7" flag but could not compile the library with it because then it wouldn't work under 6. Similarly, most libraries would need to target 6.

UNLESS we were willing to have two entire distributions, one for 6 and one for 7, and similarly ask library authors to release two distributions. And nobody wants that.

On Mar 7, 2013, at 9:41 AM, Jesper Nordenberg <mega...@yahoo.com> wrote:

Alright, we might need some more background information here:


- What's the time plan for the 2.11 release?

- How long will the 2.10 branch be maintained?

- What features in Java 7 besides invokedynamic would be beneficial (or are planned) for Scala to depend upon?

If the migration to Java 7 is only done because of invokedynamic and method handles I don't see a major problem with adding a scalac compiler flag that enables output of Java 6 compatible class files.

/Jesper Nordenberg


Alec Zorab skrev 2013-03-07 18:28:
Disagree. Android applications can still be written in 2.10 - nobody is
taking away the right to use versions other than 2.11


On 7 March 2013 17:24, Jesper Nordenberg
<mega...@yahoo.com
<mailto:mega...@yahoo.com>> wrote:

    Simon Ochsenreither skrev 2013-03-07 18:15:

        I think the wording of the poll is fundamentally flawed and the
        results
        are therefore next to useless.

        I could word the question as “should Scala 2.11 drop Android
        support?”
        and get the opposite outcome.


    Agreed. As long as Android (and alternative JVM's like Avian)
    doesn't support invokedynamic it would be a mistake to drop support
    for Java 6 IMHO.

    /Jesper Nordenberg



    --
    You received this message because you are subscribed to the Google
    Groups "scala-internals" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to scala-internals+unsubscribe@__googlegroups.com
    <mailto:scala-internals%2Bunsu...@googlegroups.com>.
    For more options, visit https://groups.google.com/__groups/opt_out
    <https://groups.google.com/groups/opt_out>.




--
You received this message because you are subscribed to the Google
Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Grzegorz Kossakowski

unread,
Mar 8, 2013, 6:33:22 PM3/8/13
to Adriaan Moors, scala-i...@googlegroups.com, scala-user
On 8 March 2013 15:26, Adriaan Moors <adriaa...@typesafe.com> wrote:
We met with John Rose today and he mentioned there's a backport of Java 7 on Java 6: http://weblogs.java.net/blog/forax/archive/2009/07/jsr292_backport.html

Also, since our use of invokedynamic would be pretty regular, it shouldn't be too hard to use ASM to statically rewrite Scala 2.11.x bytecode into something Dalvik/Java 6 can deal with (that is, assuming Google doesn't catch up over the next 12 months and this will actually be necessary).

Specifically, what we could have is simple bytecode processor that scans for invokedynamic calls related to lambda construction and rewrites those into call of anonymous class that would be synthesized for each lambda. The end result would be bytecode similar to what Scala compiler generates at the moment.

The translation itself would be very simple and local so ASM-based processor could be written to be extremely fast. Since you have to run progouard already, adding another processor doesn't really change the picture that much.

--
Grzegorz Kossakowski
Scalac hacker at Typesafe
twitter: @gkossakowski

Jesper Nordenberg

unread,
Mar 9, 2013, 4:00:26 AM3/9/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
I like the idea. Writing such a tool would be a limited amount of work,
and it wouldn't require much maintenance. It would also enable us to use
the latest Scala version (and possibly Java 8) on pretty much all
available Android versions (which will not be the case if Google updates
Dalvik). It sounds like a reasonable and practical solution. :)

The only other problem would be if you use Java 7 classes/methods in the
Scala stdlib not present in Java 6 or the Android SDK. That is mainly
important for core libraries like collections. But that issue is much
easier to control and could be checked by some automatic test case that
builds against the Android SDK.

/Jesper Nordenberg

Grzegorz Kossakowski skrev 2013-03-09 00:33:
> Specifically, what we could have is simple bytecode processor that scans
> for invokedynamic calls related to lambda construction and rewrites
> those into call of anonymous class that would be synthesized for each
> lambda. The end result would be bytecode similar to what Scala compiler
> generates at the moment.
>
> The translation itself would be very simple and local so ASM-based
> processor could be written to be extremely fast. Since you have to run
> progouard already, adding another processor doesn't really change the
> picture that much.
>
> --
> Grzegorz Kossakowski
> Scalac hacker at Typesafe <http://www.typesafe.com/>
> twitter: @gkossakowski <http://twitter.com/gkossakowski>
> github: @gkossakowski <http://github.com/gkossakowski>
>
> --
> You received this message because you are subscribed to the Google
> Groups "scala-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
> scala-user+...@googlegroups.com.

Andrzej Giniewicz

unread,
Mar 9, 2013, 7:14:28 AM3/9/13
to Adriaan Moors, scala-user
JSR292 isn't available on Davik, but if second option is doable and it will be easy to turn it on with some compiler option, that's great news - it means I can continue to develop for my platform of choice in Scala and for now not worry about product maintenance in near future. Thanks, If I could I would change my vote to Java 7 in such case, as it removes last obstacle in my case.

Simon Ochsenreither

unread,
Mar 9, 2013, 7:59:48 AM3/9/13
to scala...@googlegroups.com, Adriaan Moors, scala-i...@googlegroups.com

The translation itself would be very simple and local so ASM-based processor could be written to be extremely fast. Since you have to run progouard already, adding another processor doesn't really change the picture that much.

Does this mean one could take a bundle of existing jars compiled for Java 7 and make them work on Java 6/Android without needing a recompilation/the sources?

Dinotzar Tzar

unread,
Mar 9, 2013, 8:24:24 AM3/9/13
to scala...@googlegroups.com
Probably my destiny is to post stupidly on Scala lists. Here we go:

When discussing Scala on Android... how big portion of Scala developers are programming for Android? (I know, hopeless question. I just wonder if it's a hand-full or a larger crowd.)

Is there any well-known/significant/interesting Android software produced using Scala?
(I don't know of any Scala Android applications, but this is a genuine question, and absolutely not intended as flame-bait.)

D.

Fernando Racca

unread,
Mar 9, 2013, 9:29:45 AM3/9/13
to scala-i...@googlegroups.com, scala-user
Java 6 is already EOL, so a move is justified in that aspect. If a backport is available that allows for a more aggressive move towards Java 7, then by all means, make Java 7 a minimum requirement. 

Android is no doubt an important platform, but pressure is already building on Google and co to move forward. 

Scala 2.11 is, as mentioned in previous posts, aimed at improving performance, so it seems fit not only that Java 7 is made a baseline, but also because it paves the way for taking advantage of Java 8 and so on in subsequent releases. Given that Oracle has a 2 years release cycle, JVM vendors that don't adapt will be pushed aside.

I'm all up for Java 7 support in 2.11

Fernando

Rex Kerr

unread,
Mar 9, 2013, 10:34:28 AM3/9/13
to scala-i...@googlegroups.com, scala-user
On Sat, Mar 9, 2013 at 9:29 AM, Fernando Racca <fra...@gmail.com> wrote:
Given that Oracle has a 2 years release cycle, JVM vendors that don't adapt will be pushed aside.

I wouldn't necessarily assume this is true.  Fragmentation and lack of adoption are, I think, equally likely.  There are a _lot_ of people using Java to develop for Android.  Oracle doesn't have the leverage to force them to upgrade that it does with the server customers.  Look at how Objective C has gone from a who-cares language to top 4 in all of about three years: the TIOBE index shows it taking off mid-2009 and passing C# for the #4 spot in early 2012.

  http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
 
It is not at all clear to me that Dalvik-Java isn't going to have more muscle than SunJVM-Java in the near future (if indeed it doesn't already).

Now IBM--IBM needs to get J9 upgraded to 1.7/1.8 soon or J9 will be irrelevant because IBM is also in the server space (likewise with Azul and others).  But all of these may end up being in the minority.

If the bytecode transformation will actually work (I worry that it will be a bigger hassle than envisioned, though I was about to suggest the same thing, so I also obviously agree it has merits) then this allows the Scala community to straddle both trends with Java, at least for a while.

  --Rex

Simon Ochsenreither

unread,
Mar 9, 2013, 10:52:30 AM3/9/13
to scala-i...@googlegroups.com, scala-user

I wouldn't necessarily assume this is true.  Fragmentation and lack of adoption are, I think, equally likely.  There are a _lot_ of people using Java to develop for Android.

And it is not only restricted to Android. It is very likely that Java 6 will be the last widely supported class file version. Re-implementing invoke dynamic support is a huge amount of work which I don't expect to happen for non Oracle-licensees in the next few years.

In my opinion, regardless of the approach chosen, having a supported, maintained solution to generate Java 6 bytecode is absolutely critical. If there is a way to target Java 7 while being able to deploy on Java 6 without requiring a recompilation of every jar file involved, that's fine for me. too.

Dropping Java 6 support would mean forcing a decision between proper tail calls and nicer closures.
Personally, if I can't have both, I'll choose tail calls every time.

Kevin Wright

unread,
Mar 9, 2013, 10:53:05 AM3/9/13
to scala-i...@googlegroups.com, scala-user
It's a fair point.  If Google don't upgrade dalvik with support for JVM7/closures then it won't stop people from programming for Android.

OTOH, Oracle already have demonstrated examples of Android and iOS apps running with an embedded JVM.  They're going to continue pushing in this direction as part of JavaFX and Google must surely be aware of the risk of losing mindshare here.  Once devs migrate to an embedded JVM model then what's to stop them further migrating that model to another platform (Windows mobile/Ubuntu mobile/iOS).  JavaFX on the raspberry pi shows that it's already *very* possible even on limited hardware.

Java developers *will* want to migrate to having lambdas once the articles start coming out en-masse and they realise what it's all about, even more so once they see the interaction of lambdas and the events that lie at the heart of most mobile platform models.

Sure fragmentation is a risk, but it's mostly a risk to Google, not to Oracle.  I have no doubt that Android will be updated to be compatible with JVM7.  Otherwise, Google risk winning the crown of slothfulness back from Oracle, which is not something I'd expect of a company wanting to market themselves as a tech leader :)



--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Simon Ochsenreither

unread,
Mar 9, 2013, 11:01:22 AM3/9/13
to scala...@googlegroups.com, scala-i...@googlegroups.com

Sure fragmentation is a risk, but it's mostly a risk to Google, not to Oracle.  I have no doubt that Android will be updated to be compatible with JVM7.

The question is “when”? They could have shipped support for Java 7 one year ago already. I think it is very likely that Google's lawyers told them not to do anything which could further complicate their court case against Oracle.
Considering that Oracle decided to keep fighting, it might take years until this matter is resolved.

Ðavîd L

unread,
Mar 9, 2013, 12:41:30 PM3/9/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
On Saturday, March 9, 2013 10:34:28 AM UTC-5, Rex Kerr wrote:

Now IBM--IBM needs to get J9 upgraded to 1.7/1.8 soon or J9 will be irrelevant because IBM is also in the server space (likewise with Azul and others).  But all of these may end up being in the minority.

IBM released Java 7 a few months after Oracle if I remember correctly. They've also had 8 beta available for a while now. 

Rex Kerr

unread,
Mar 9, 2013, 12:46:01 PM3/9/13
to Ðavîd L, scala...@googlegroups.com, scala-i...@googlegroups.com
Oops, that tells you just how old the cached version of IBM's J9 page is in my browser....

Azul's stuff is still 1.6 as far as I know, though.

  --Rex

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

Adriaan Moors

unread,
Mar 9, 2013, 1:25:01 PM3/9/13
to Simon Ochsenreither, scala-user, scala-i...@googlegroups.com

On Sat, Mar 9, 2013 at 4:59 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
Does this mean one could take a bundle of existing jars compiled for Java 7 and make them work on Java 6/Android without needing a recompilation/the sources?

Steven Barnes

unread,
Mar 9, 2013, 3:32:54 PM3/9/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
I am a Java server programmer, and also a mobile developer.  Here's what I think about Android:  Google didn't want to play by Sun's rules, so they pulled a dick-move, and created a "Java that isn't Java" and called it Android / Dalvik.  Now they are reaping what they have sown, via massive lawsuits from Oracle.  Who cares whether our Java byte codes are compatible with Dalvik?  This is Google's problem, not mine.

I became interested in Scala, because I finally admitted to myself that the Java language was antiquated and cumbersome.  I don't want my Scala ecosystem hobbled by some sense of obligation to support Android.

Now on to mobile...  I was a J2ME developer for about 6 years.  I have never had any interest in Android, because it seems Google learned nothing from the mistakes of J2ME.  While I don't want to turn this into an Android vs iOS flame war, it is clearly obvious that there is money to be made in iOS, and very little to be made with Android.  Any app that I develop will have to first run on iOS, then as an after thought, perhaps might someday be ported to Android.  So from my perspective, it would be really great if Scala could target iOS.  Until that day happens, I am not going to develop Android-compatible apps with Scala; I am going to use either C++, or some kind of portability framework like Unity.

So if you want Scala to be a player in mobile, get some serious development going on LLVM support.  Android is a niche.

Simon Ochsenreither

unread,
Mar 10, 2013, 7:33:07 AM3/10/13
to scala-i...@googlegroups.com, Ðavîd L, scala...@googlegroups.com
Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced it has transitioned into a leadership role for the OpenJDK 6 project, effectively extending support for the technology and its users.

http://www.redhat.com/about/news/press-archive/2013/3/red-hat-reinforces-java-commitment

Detering Dirk

unread,
Mar 11, 2013, 4:03:19 AM3/11/13
to Simon Ochsenreither, scala...@googlegroups.com, scala-i...@googlegroups.com
> -----Ursprüngliche Nachricht-----
> Von: scala...@googlegroups.com [mailto:scala...@googlegroups.com]
> Im Auftrag von Simon Ochsenreither
>> I have no doubt that Android will be updated to be compatible with
> >JVM7.
>
> The question is "when"? They could have shipped support for Java 7 one
> year ago already. I think it is very likely that Google's lawyers told them not to
> do anything which could further complicate their court case against Oracle.

Yep, and so there are people that urge Google to provide a Dart port for Android.
This _may_ be a backdoor for Google reg. Java/Android issues, and then Scala would
be washed from Android together with Java.


BITMARCK Software GmbH
Firmensitz: Paul-Klinger-Strasse 15, 45127 Essen
Geschaeftsfuehrer: Andreas Strausfeld
Registergericht: Amtsgericht Essen HRB 20680


***********************************************************************

Die Information in dieser E-Mail ist vertraulich und ist ausschliesslich
fuer den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
E-Mail durch andere Personen als den/die benannten Adressaten ist
nicht gestattet. Sollten Sie nicht der benannte Adressat sein, loeschen
Sie bitte diese E-Mail.

Dennis Haupt

unread,
Mar 11, 2013, 4:27:14 AM3/11/13
to Detering Dirk, Simon Ochsenreither, scala...@googlegroups.com, scala-i...@googlegroups.com
i don't *really* see a problem here - scala compiles to java bytecode now, but it could "just" compile to other backends instead in case java died. could be c, javascript, dart....

Gesendet: Montag, 11. März 2013 um 09:03 Uhr
Von: "Detering Dirk" <Dirk.D...@bitmarck.de>
An: "Simon Ochsenreither" <simon.och...@gmail.com>, "scala...@googlegroups.com" <scala...@googlegroups.com>
Cc: "scala-i...@googlegroups.com" <scala-i...@googlegroups.com>
Betreff: AW: [scala-user] Re: [scala-internals] Re: Scala 2.11 may require Java 7
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

Simon Ochsenreither

unread,
Mar 11, 2013, 7:57:41 AM3/11/13
to scala...@googlegroups.com, Detering Dirk, Simon Ochsenreither, scala-i...@googlegroups.com

i don't *really* see a problem here - scala compiles to java bytecode now, but it could "just" compile to other backends instead in case java died. could be c, javascript, dart....

There is not a single, supported backend existing except for the OpenJDK one. I think that's my poin: If we want multiple platform support, we shouldn't keep dropping backends.

Michael Swierczek

unread,
Mar 11, 2013, 9:51:29 AM3/11/13
to Dennis Haupt, Detering Dirk, Simon Ochsenreither, scala...@googlegroups.com, scala-i...@googlegroups.com
On Mon, Mar 11, 2013 at 4:27 AM, Dennis Haupt <h-s...@gmx.de> wrote:
> i don't *really* see a problem here - scala compiles to java bytecode now,
> but it could "just" compile to other backends instead in case java died.
> could be c, javascript, dart....
>

So many existing Scala projects rely upon Java libraries and the Maven
repositories that I can't imagine the language will ever divorce
itself from the Java back end. Now that there is a court battle
between Google and Oracle, I would prefer if Scala was associated with
an ecosystem with less legal baggage. I do not think it is likely.

-Mike

Alexandru Nedelcu

unread,
Mar 11, 2013, 6:03:33 PM3/11/13
to Steven Barnes, scala...@googlegroups.com, scala-i...@googlegroups.com
On Sat, Mar 9, 2013 at 10:32 PM, Steven Barnes <copr...@gmail.com> wrote:
> I am a Java server programmer, and also a mobile developer. Here's what I
> think about Android: Google didn't want to play by Sun's rules, so they
> pulled a dick-move, and created a "Java that isn't Java" and called it
> Android / Dalvik. Now they are reaping what they have sown, via massive
> lawsuits from Oracle. Who cares whether our Java byte codes are compatible
> with Dalvik? This is Google's problem, not mine.

That lawsuit was already won by Google. Oracle could continue of
course with appeals or other lawsuits, but having lost the copyright
argument, patents are too weak and Google can counter-sue with their
own patents.

Java was advertised as a standard, when in fact JCP is not a real
standards body and Java(TM) is not a standard with RAND licensing, as
other standards are (including C++, C# and Javascript). Nothing can
get licensed under the Java trademark without getting a license for
the JCK, a test compatibility kit that's not part of JCP and is
subject to Oracle's own discriminatory terms (as Apache Harmony found
out).

Unfortunately for Oracle you cannot copyright APIs in general,
especially APIs that were advertised as being a standard, because
estoppel applies. And if they had their way with the listed software
patents, then you couldn't fork OpenJDK either, because the implicit
patents grant in GPLv2 is too weak outside the US. If Oracle would
have won that lawsuit, then Java would be a completely proprietary
platform and I for one am glad that there are dicks like Google
around.

--
Alexandru Nedelcu
http://bionicspirit.com

Adriaan Moors

unread,
Mar 12, 2013, 1:31:07 AM3/12/13
to scala-i...@googlegroups.com, scala-user, Detering Dirk, Simon Ochsenreither
2.10 will be maintained for quite some time to come.

Lots of people are happily using 2.9 (and will continue to do so) while 2.10 is out.

Given our limited resources, we may (jury's still out!) have to ask people to move to Java 7 as they upgrade to Scala 2.11.

Those who stay on Java 6 have 2.10.x. (I think a byte code re-writing tool could be a great compromise.) 
As the Android tool chain already includes proguard, adding one more step shouldn't be a show stopper.

Also, we'll be more than happy to take community contributions for backports of 2.11 features you'd miss in 2.10 (as long as they're binary compatible).
Let me also emphasize that 2.11 won't introduce that many new features.
At Typesafe, we're focussed on improved performance of the compiler and of compiled code. 

If MethodHandles prove to bring a significant performance boost, I think that makes the case for moving to Java 7 quite compelling.
Again, the jury is still out, as I feel we should think this through carefully, benchmark it thoroughly, and have everybody weigh in.

cheers
adriaan


On Mon, Mar 11, 2013 at 4:57 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

i don't *really* see a problem here - scala compiles to java bytecode now, but it could "just" compile to other backends instead in case java died. could be c, javascript, dart....

There is not a single, supported backend existing except for the OpenJDK one. I think that's my poin: If we want multiple platform support, we shouldn't keep dropping backends.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

Lukas Rytz

unread,
Mar 12, 2013, 2:30:45 AM3/12/13
to scala-i...@googlegroups.com, scala-user, Detering Dirk, Simon Ochsenreither
On Tue, Mar 12, 2013 at 6:31 AM, Adriaan Moors <adriaa...@typesafe.com> wrote:
2.10 will be maintained for quite some time to come.

Lots of people are happily using 2.9 (and will continue to do so) while 2.10 is out.

Given our limited resources, we may (jury's still out!) have to ask people to move to Java 7 as they upgrade to Scala 2.11.

Those who stay on Java 6 have 2.10.x. (I think a byte code re-writing tool could be a great compromise.) 
As the Android tool chain already includes proguard, adding one more step shouldn't be a show stopper.

Also, we'll be more than happy to take community contributions for backports of 2.11 features you'd miss in 2.10 (as long as they're binary compatible).

This point (and only this one!) is moot: with backward and forward binary compatibility, you cannot add
anything to a library. Do we care about source compatibility? Then you cannot add language features
either. So you're really left with bugfixes.

Oliver Ruebenacker

unread,
Mar 12, 2013, 6:14:45 AM3/12/13
to Alexandru Nedelcu, Steven Barnes, scala...@googlegroups.com, scala-i...@googlegroups.com
Hello,

On Mon, Mar 11, 2013 at 6:03 PM, Alexandru Nedelcu <m...@alexn.org> wrote:
> Java was advertised as a standard, when in fact JCP is not a real
> standards body and Java(TM) is not a standard with RAND licensing, as
> other standards are (including C++, C# and Javascript).

As some one involved with some community standards (BioPAX, SBML,
SBPAX), I'm just curious, what is a real standards body?

Take care
Oliver

--
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement

Fernando Racca

unread,
Mar 12, 2013, 6:34:24 AM3/12/13
to scala-i...@googlegroups.com, scala-user, Detering Dirk, Simon Ochsenreither
I believe those are reasons strong enough to target the next version of the language to keep moving forward. As said several before, Android users in the worst case can still use Scala 2.10, potentially with back-ported libraries.

Android is a very important platform, but when viable options are available to support those users, I think is important to consider what can make the biggest impact for the users that want Scala to be a replacement of Java, not just another library. 

Some work is already under way to add Invoke dynamic to Android, although not quite there yet...


I would imagine that an invoke dynamic work would probably focus in the areas where most of the benefit can be had at the beginning. So probably should start of as a very localized branch, where a proof of concept can show what impact can it make performance wise, and at that point make the call of whether to go ahead and drop support for Java 6 or to defer it.
Android is not the only one still relying on Java 6, tons of financial companies are still running components on Java 6. But after Oracles EOL, is time to move on, and change is on the way.

Fernando

Alexandru Nedelcu

unread,
Mar 12, 2013, 6:51:58 AM3/12/13
to Oliver Ruebenacker, Steven Barnes, scala...@googlegroups.com, scala-i...@googlegroups.com
On Tue, Mar 12, 2013 at 12:14 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:
> As some one involved with some community standards (BioPAX, SBML,
> SBPAX), I'm just curious, what is a real standards body?

A standards body is an organization whose purpose is to develop and
coordinate the development of technical specifications and license
those specifications to third-parties interested in implementing them.

The JCP is not a standards body because the Java TCK is not part of
it, the licensing of the Java trademark, patents and other related IP
is not part of it and because the votes given by third-parties on
specification requests (JSRs) don't really matter as Oracle doesn't
really give a damn about those votes (as plainly state when they
released Java SE 7), which is why the Apache Software Foundation left
the executive committee. Apache begged for a license from Sun and now
Oracle for years, licensing that never happened as Oracle wants
restrictions on mobile-related usage, which goes against the
definition of open-source and is not compatible with the Apache
license. Even MPEG LA that licenses the patents related to
H.264/MPEG-4 has more reasonable terms than that.

The bottom line, a real standards body is one you can trust for
developing, coordinating and licensing a standard.
ISO is a real standards body, the JCP is not.

Oliver Ruebenacker

unread,
Mar 12, 2013, 7:57:06 AM3/12/13
to Alexandru Nedelcu, Steven Barnes, scala...@googlegroups.com, scala-i...@googlegroups.com
Hello,

Thanks for the explanation. Sounds like we can be a real standards
body as long as we play nicely.

Take care
Oliver

Eric Kolotyluk

unread,
Mar 12, 2013, 8:58:06 AM3/12/13
to scala...@googlegroups.com
"Oracle wants restrictions on mobile-related usage"

What is the matter with Oracle? Are they determine to kill the goose the
laid the golden egg?

Cheers, Eric

Michael Swierczek

unread,
Mar 12, 2013, 9:15:55 AM3/12/13
to Eric Kolotyluk, scala-user
On Tue, Mar 12, 2013 at 8:58 AM, Eric Kolotyluk
<eric.ko...@gmail.com> wrote:
> "Oracle wants restrictions on mobile-related usage"
>
> What is the matter with Oracle? Are they determine to kill the goose the
> laid the golden egg?
>
> Cheers, Eric

The specific details are not clear to me, but I believe the original
Sun Microsystems business model for Java included that. I think Sun
distributed the standard Java runtime environment and SDK for free,
but wanted to charge licensing fees for the use of Java Micro Edition,
which was developed for embedded uses including phones.

-Mike

Matthew Pocock

unread,
Mar 12, 2013, 9:32:27 AM3/12/13
to Alexandru Nedelcu, Steven Barnes, scala...@googlegroups.com, scala-i...@googlegroups.com
On 11 March 2013 22:03, Alexandru Nedelcu <m...@alexn.org> wrote:
That lawsuit was already won by Google. Oracle could continue of
course with appeals or other lawsuits, but having lost the copyright
argument, patents are too weak and Google can counter-sue with their
own patents.

I agree with the people who see Android as a major platform. I am probably atypical but for me the only machines I care about running .class files on are enterprise-class servers for scary compute-heavy jobs and Androids for UIs. On the servers we're running debian VMs so have the latest Java installed. On android, well, it's whatever it has. I see the argument for an iOS-compatible target, and if there was one that supported JavaFX/ScalaFX, I think that would also be compelling. Same for HTML5 (svg + js + ...) as a target. But, life is short, resources scarce, and without a cash investment from a company that really, really cares about a specific target, I don't see it being practical to target more than the oldest JVM that won't be EOLed during the projected lifetime of a scala platform release.

I really don't buy the 'android is 1.6' argument - I strongly suspect that by the time Sun^h^h^hOracle Java 1.6 is EOLed that android will be perfectly happy reading 1.7 bytecode, and if not, there will be a well-oiled hack. The problem is that maintaining multiple back-ends able to target different platforms is really, really hard work and requires skills that you simply don't find in most people. As an example, while great things have been done recently with optimizing the compiler, much of the speed-up has come from the details of the emitted bytecode, with optimizations performed at that level. Now, imagine a backend that targets iOS - you'd have to be both an expert in this platform and also know the compiler intimately to start to do the same sort of performance tuning in a way that would get past the app store ogres, and for this to survive you going on holiday or having a child or writing up your thesis, you need 5 of you. Good luck with that.

Matthew


--
Alexandru Nedelcu
http://bionicspirit.com

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.





--
Dr Matthew Pocock
Integrative Bioinformatics Group, School of Computing Science, Newcastle University
skype: matthew.pocock
tel: (0191) 2566550

Nils Kilden-Pedersen

unread,
Mar 12, 2013, 10:47:17 AM3/12/13
to Eric Kolotyluk, scala...@googlegroups.com
On Tue, Mar 12, 2013 at 7:58 AM, Eric Kolotyluk <eric.ko...@gmail.com> wrote:
"Oracle wants restrictions on mobile-related usage"

What is the matter with Oracle? Are they determine to kill the goose the laid the golden egg?

Oracle's problem, which they inherited from Sun, is that they're not getting any of that gold, so ultimately killing the goose will be of no loss to them.

 

Cheers, Eric
--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.

Simon Ochsenreither

unread,
Mar 12, 2013, 12:21:33 PM3/12/13
to scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes, scala...@googlegroups.com

I really don't buy the 'android is 1.6' argument - I strongly suspect that by the time Sun^h^h^hOracle Java 1.6 is EOLed that android will be perfectly happy reading 1.7 bytecode, and if not, there will be a well-oiled hack.

Java 1.6 was EOL'ed 12 days ago. I neither see a 1.7 compatible dexer nor a hack available.

 
Now, imagine a backend that targets iOS - you'd have to be both an expert in this platform and also know the compiler intimately to start to do the same sort of performance tuning in a way that would get past the app store ogres, and for this to survive you going on holiday or having a child or writing up your thesis, you need 5 of you. Good luck with that.

Just like Android, native compilation more or less works already. I'm arguing for not breaking stuff which already works.

Steven Barnes

unread,
Mar 12, 2013, 12:46:03 PM3/12/13
to Simon Ochsenreither, scala-i...@googlegroups.com, Alexandru Nedelcu, scala...@googlegroups.com
So it is settled then.  Scala will never target a new JVM, until Google updates their non-standard VM.

When Microsoft did this (see "embrace and extend"), they crippled Java as a browser app platform, and forced Java applet developers to target Java 1.1 for years.

Matthew Pocock

unread,
Mar 12, 2013, 12:55:37 PM3/12/13
to scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes, scala...@googlegroups.com
On 12 March 2013 16:21, Simon Ochsenreither <simon.och...@gmail.com> wrote:

I really don't buy the 'android is 1.6' argument - I strongly suspect that by the time Sun^h^h^hOracle Java 1.6 is EOLed that android will be perfectly happy reading 1.7 bytecode, and if not, there will be a well-oiled hack.

Java 1.6 was EOL'ed 12 days ago. I neither see a 1.7 compatible dexer nor a hack available.

That's what you get for taking a holiday! My bad. It surprises me though that there's nothing in-place.
 

 
Now, imagine a backend that targets iOS - you'd have to be both an expert in this platform and also know the compiler intimately to start to do the same sort of performance tuning in a way that would get past the app store ogres, and for this to survive you going on holiday or having a child or writing up your thesis, you need 5 of you. Good luck with that.

Just like Android, native compilation more or less works already. I'm arguing for not breaking stuff which already works.

Sure, but there's a big gap between getting scala to compile down to something that runs on iOS and getting that to run efficiently. Getting it to run is only the first 10% of the job. Most of the hard work comes after that.

Matthew
 

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Simon Ochsenreither

unread,
Mar 12, 2013, 1:15:38 PM3/12/13
to scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes, scala...@googlegroups.com

Just like Android, native compilation more or less works already. I'm arguing for not breaking stuff which already works.

Sure, but there's a big gap between getting scala to compile down to something that runs on iOS and getting that to run efficiently. Getting it to run is only the first 10% of the job. Most of the hard work comes after that.

That shouldn't be a reason to make the first 10% harder. Really, with the current state of things we shouldn't be wondering why people don't pour their resources and time in porting Scala.

Adriaan Moors

unread,
Mar 12, 2013, 7:01:58 PM3/12/13
to scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes, scala-user

On Tue, Mar 12, 2013 at 10:15 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
Really, with the current state of things we shouldn't be wondering why people don't pour their resources and time in porting Scala.
I don't think you're doing anybody a favor with such sweeping generalizations. The main reason is that these things are hard and time consuming.

We're working hard on making Scala 2.11 a platform that developers can build on. Macros are an example of that.
The modularization effort going on in master right now is an example of that. Etc, etc.

We still have a (deprecated) java-1.5 back-end in Scala 2.10, but I'm not hearing much about that.

We're talking about the *default*, *officially supported* platform for Scala 2.11. If that becomes Java 7, you're still welcome to compile with the (then-deprecated) 1.6 backend.
Sure, you'll also have to recompile your dependencies yourself, but is that really enough of a cost to outweigh all the benefits that Java 7 brings to everyone else?

cheers
adriaan

Nicholas Sterling

unread,
Mar 13, 2013, 2:03:13 PM3/13/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
I would think that if the Scala folks commit to fixing bugs in the 2.10 train for as long as it takes for Android to get Java 7 support, there is no point in impeding progress on the server and desktop. If MethodHandles make Scala better, go for it; it will be all goodness for Android too once it gets over the Java 7 hump.

Simon Ochsenreither

unread,
Mar 14, 2013, 10:35:07 AM3/14/13
to scala...@googlegroups.com, scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
Ok, so I tried to sleep over it for a few days, but my original reaction didn't really change.
What follows is my honest opinion which I'm trying to voice in the friendliest way possible regarding the situation.



Really, with the current state of things we shouldn't be wondering why people don't pour their resources and time in porting Scala.
I don't think you're doing anybody a favor with such sweeping generalizations. The main reason is that these things are hard and time consuming.

... and that's why we need to break working platforms, including one with an ecosystem with half a billion of Scala-capable devices and the possibility of native compilation, dependency-free deployment and embedding?
I guess that will surely motivate people to spend more hard and time consuming work on it, right?

 
We're working hard on making Scala 2.11 a platform that developers can build on. Macros are an example of that.
The modularization effort going on in master right now is an example of that. Etc, etc.

Not relevant at all.

 
We still have a (deprecated) java-1.5 back-end in Scala 2.10, but I'm not hearing much about that.
 
Yes, because there is pretty much no effort needed to update tools which work with Java 5 class files to support Java 6 class files, too.
Java 7 is a totally different story.


If that becomes Java 7, you're still welcome to compile with the (then-deprecated) 1.6 backend.

WUT?! This gets even worse than I imagined. Who comes up with ideas like this?
So we tell all people using Scala for non-Oracle-related stuff that they are not only second-class citizens, but that they should get lost, too?


Sure, you'll also have to recompile your dependencies yourself, but is that really enough of a cost to outweigh all the benefits that Java 7 brings to everyone else?
 
That's completely impractical. Neither the ecosystem, the tools, nor the people are even remotely prepared to switch from a binary distribution model to a source distribution model.

If you think “everyone else” means “only those who use Oracle's newest stuff actually count”, then please fix Scala's description, because it is misleading: “Scala is a general purpose programming language [...]” => “Scala is a productivity add-on for Oracle-specific products targeting frustrated Java developers.”

Really, If the guy who is usually one of the first to deprecate, remove, cut out, slim down (me) has a completely different position, one should wonder why that is that way.

I still can't possible imagine how people can propose dropping support for two platforms with millions of devices, dozens of potential use-cases not supported by OpenJDK, thousands of potential Scala developers and keep claiming it's not a big deal.

Maybe I'm living in the wrong parallel universe, but in my world Scala doesn't have 90% adoption rate. Those plans are pretty much killing adoption for everyone who is not a frustrated Java developer. Could we throw out that selection bias and be a bit more welcoming to people coming from elsewhere?

Lukas Rytz

unread,
Mar 14, 2013, 11:04:19 AM3/14/13
to scala-i...@googlegroups.com, scala...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 3:35 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
Ok, so I tried to sleep over it for a few days, but my original reaction didn't really change.
What follows is my honest opinion which I'm trying to voice in the friendliest way possible regarding the situation.



Really, with the current state of things we shouldn't be wondering why people don't pour their resources and time in porting Scala.
I don't think you're doing anybody a favor with such sweeping generalizations. The main reason is that these things are hard and time consuming.

... and that's why we need to break working platforms, including one with an ecosystem with half a billion of Scala-capable devices and the possibility of native compilation, dependency-free deployment and embedding?


so what exactly are is breaking?
 - android seems not to be a problem
 - joel dice says avian will support 1.7 classfiles
 - 1.6 is eol, 1.7 out for 1.5 years (just because you call it "Oracle's newest stuff")
 - openjdk, avian, android, all open source
 - how does a change in backend X make implementing a new backend Y (llvm, javascript, .net) harder?

currently people are running scala code on jvm and android. none of the two breaks, and supporting other
platforms does not become more difficult.


 
I guess that will surely motivate people to spend more hard and time consuming work on it, right?

 
We're working hard on making Scala 2.11 a platform that developers can build on. Macros are an example of that.
The modularization effort going on in master right now is an example of that. Etc, etc.

Not relevant at all.

 
We still have a (deprecated) java-1.5 back-end in Scala 2.10, but I'm not hearing much about that.
 
Yes, because there is pretty much no effort needed to update tools which work with Java 5 class files to support Java 6 class files, too.
Java 7 is a totally different story.


If that becomes Java 7, you're still welcome to compile with the (then-deprecated) 1.6 backend.

WUT?! This gets even worse than I imagined. Who comes up with ideas like this?
So we tell all people using Scala for non-Oracle-related stuff that they are not only second-class citizens, but that they should get lost, too?


Sure, you'll also have to recompile your dependencies yourself, but is that really enough of a cost to outweigh all the benefits that Java 7 brings to everyone else?
 
That's completely impractical. Neither the ecosystem, the tools, nor the people are even remotely prepared to switch from a binary distribution model to a source distribution model.

If you think “everyone else” means “only those who use Oracle's newest stuff actually count”, then please fix Scala's description, because it is misleading: “Scala is a general purpose programming language [...]” => “Scala is a productivity add-on for Oracle-specific products targeting frustrated Java developers.”

Really, If the guy who is usually one of the first to deprecate, remove, cut out, slim down (me) has a completely different position, one should wonder why that is that way.

I still can't possible imagine how people can propose dropping support for two platforms with millions of devices, dozens of potential use-cases not supported by OpenJDK, thousands of potential Scala developers and keep claiming it's not a big deal.

Maybe I'm living in the wrong parallel universe, but in my world Scala doesn't have 90% adoption rate. Those plans are pretty much killing adoption for everyone who is not a frustrated Java developer. Could we throw out that selection bias and be a bit more welcoming to people coming from elsewhere?

--

Rex Kerr

unread,
Mar 14, 2013, 11:11:16 AM3/14/13
to scala-i...@googlegroups.com, scala...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 11:04 AM, Lukas Rytz <lukas...@epfl.ch> wrote:

 - how does a change in backend X make implementing a new backend Y (llvm, javascript, .net) harder?

Many good points, but this one is so rhetorically misdirected that I have to comment:  a change in backend X makes implementing a new backend Y harder because you probably want to use X as a starting point for Y, which is gets increasingly difficult the more features X takes advantage of that Y does not have.

For example, suppose you switch your backend from targeting C to Javascript.  Now we decide to target x86 assembly.

Yay?

  --Rex

Lukas Rytz

unread,
Mar 14, 2013, 11:26:14 AM3/14/13
to scala-i...@googlegroups.com, scala...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 4:11 PM, Rex Kerr <ich...@gmail.com> wrote:
On Thu, Mar 14, 2013 at 11:04 AM, Lukas Rytz <lukas...@epfl.ch> wrote:

 - how does a change in backend X make implementing a new backend Y (llvm, javascript, .net) harder?

Many good points, but this one is so rhetorically misdirected that I have to comment:  a change in backend X makes implementing a new backend Y harder because you probably want to use X as a starting point for Y, which is gets increasingly difficult the more features X takes advantage of that Y does not have.

Sure, agree. But also the changes in question are not in the C-to-JS order of magnitude :)
 

For example, suppose you switch your backend from targeting C to Javascript.  Now we decide to target x86 assembly.

Yay?

  --Rex

Adriaan Moors

unread,
Mar 14, 2013, 1:44:53 PM3/14/13
to scala-i...@googlegroups.com, scala-user, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 7:35 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
trying to voice in the friendliest way possible regarding the situation.
Thanks for clarifying.


We're working hard on making Scala 2.11 a platform that developers can build on. Macros are an example of that.
The modularization effort going on in master right now is an example of that. Etc, etc.

Not relevant at all.
Sure it is, by lowering the entry barrier to doing compiler hacking (or the like -- macro authors are scalac hackers in my opinion)

 
We still have a (deprecated) java-1.5 back-end in Scala 2.10, but I'm not hearing much about that.
 
Yes, because there is pretty much no effort needed to update tools which work with Java 5 class files to support Java 6 class files, too.
Java 7 is a totally different story.
Please qualify "totally different". I've already pointed you to a tool that statically rewrites Java 7 bytecode to Java 6 bytecode in general.
It should be even easier to use ASM to write a similar tool that only deals with Scala-generated bytecode, which will use Java 7 bytecode in a very specific way.
We'll be happy to assist anyone who's willing to write that tool, or we may end up doing it ourselves.
 

If that becomes Java 7, you're still welcome to compile with the (then-deprecated) 1.6 backend.

WUT?! This gets even worse than I imagined. Who comes up with ideas like this?
I do.
 
So we tell all people using Scala for non-Oracle-related stuff that they are not only second-class citizens, but that they should get lost, too?
No, please stay! I don't know where you got this feeling from. I'm sorry if something I said caused this.
Our jenkins builds run on various JDKs and platforms. We're planning to add J9, but haven't had a chance yet.

 
Sure, you'll also have to recompile your dependencies yourself, but is that really enough of a cost to outweigh all the benefits that Java 7 brings to everyone else?
 
That's completely impractical. Neither the ecosystem, the tools, nor the people are even remotely prepared to switch from a binary distribution model to a source distribution model.

If you think “everyone else” means “only those who use Oracle's newest stuff actually count”, then please fix Scala's description, because it is misleading: “Scala is a general purpose programming language [...]” => “Scala is a productivity add-on for Oracle-specific products targeting frustrated Java developers.”
Oh, I thought MethodHandles were also supported in J9, and OpenJDK. Maybe Avian will add support as well?
Whatever your personal feelings about oracle, I don't think you're interpreting my original message entirely fairly.

Really, If the guy who is usually one of the first to deprecate, remove, cut out, slim down (me) has a completely different position, one should wonder why that is that way.
Believe me, I am wondering.
 
I still can't possible imagine how people can propose dropping support for two platforms with millions of devices, dozens of potential use-cases not supported by OpenJDK, thousands of potential Scala developers and keep claiming it's not a big deal.
This is only true under the assumption that those platforms won't catch up with the Java world.
How can those platforms not consider adding support for this?


Maybe I'm living in the wrong parallel universe, but in my world Scala doesn't have 90% adoption rate. Those plans are pretty much killing adoption for everyone who is not a frustrated Java developer.
Really? I think we also attract happy Java developers. Again, I don't think unqualified statements like this contribute to the discussion. 
 
Could we throw out that selection bias and be a bit more welcoming to people coming from elsewhere?
I always thought of ourselves as a relatively welcoming motley crew.


cheers
adriaan

Nils Kilden-Pedersen

unread,
Mar 14, 2013, 2:04:52 PM3/14/13
to scala-i...@googlegroups.com, scala-user, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 12:44 PM, Adriaan Moors <adriaa...@typesafe.com> wrote:
On Thu, Mar 14, 2013 at 7:35 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
I still can't possible imagine how people can propose dropping support for two platforms with millions of devices, dozens of potential use-cases not supported by OpenJDK, thousands of potential Scala developers and keep claiming it's not a big deal.
This is only true under the assumption that those platforms won't catch up with the Java world.

I still fail to see how a Scala 2.11 supporting Java 7 is any different from Java 7 itself (or 8 for that matter). Should Scala now all of the sudden be behind Java?

So if you want cutting edge byte code, you do Java, not Scala? Seems a weird proposition.

How about if you want Java 6 compatibility, you code Java 6 or Scala 2.10, and if you want higher, you go higher in either language.

James Moore

unread,
Mar 14, 2013, 4:36:43 PM3/14/13
to Adriaan Moors, scala-i...@googlegroups.com, scala-user, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 7:44 AM, Adriaan Moors <adriaa...@typesafe.com> wrote:
I still can't possible imagine how people can propose dropping support for two platforms with millions of devices, dozens of potential use-cases not supported by OpenJDK, thousands of potential Scala developers and keep claiming it's not a big deal.
This is only true under the assumption that those platforms won't catch up with the Java world.
How can those platforms not consider adding support for this?

I suggest you assume that Dalvik thinks of Java 7 as an unimportant fork.  It's not the future and it's definitely not the present.  The safe path is to assume that Dalvik won't take on features from Java 7, Java 8, etc.  I've never seen anything from Google that would suggest otherwise.  They very well might starting adding their own stuff, of couse; Dalvik isn't dead.

Unless, of course, you have inside-Google intel that leads you to believe otherwise.  But publicly, they've said nothing that I know about, and Java 7 has been around (in dev and release) for quite a while.  (I have absolutely no inside info here; they could announce Java 7 stuff today for all I know.)

Definitely my preference would be to abandon Java 7 plans for 2.11, or at least only do it as an experimental option.  It seems like resources are going to be challenging; the people and time to keep the 6 code up to date with the 7 branch are exactly the same people you'd probably like to be working on other great scala features.  At the very least don't make any decisions until after Google IO (May 15-17) - it's not that far away, and they might clarify Dalvik plans then.

It really depends on what you think of Android, though.  If it I worked at Typesafe, my door would be covered with hockey-stick graphs of Android growth rates and a sign saying "Java 7 doesn't run here and never will."  Few people have called me subtle :-].

-- 
James Moore
ja...@restphone.com
http://blog.restphone.com/
http://www.linkedin.com/in/jamesmmooreiv

Steven Barnes

unread,
Mar 14, 2013, 4:45:13 PM3/14/13
to James Moore, Adriaan Moors, scala-i...@googlegroups.com, scala-user, Alexandru Nedelcu
Again, it is not the job of the Scala community to support Dalvik, it is Google's job to maintain compatibility with modern JVMs, and/or provide translation tools.

I also seriously doubt that the majority of Scala developers work on Android.  I suspect the majority are involved in web site and server development.

Regardless of the popularity of Android, the majority of mobile developers have to think about cross-platform support for iOS and Windows RT (or whatever it is called today), and so are unlikely to use Java or Scala.

James Moore

unread,
Mar 14, 2013, 5:06:29 PM3/14/13
to Steven Barnes, Adriaan Moors, scala-i...@googlegroups.com, scala-user, Alexandru Nedelcu
On Thu, Mar 14, 2013 at 10:45 AM, Steven Barnes <copr...@gmail.com> wrote:
Again, it is not the job of the Scala community to support Dalvik, it is Google's job to maintain compatibility with modern JVMs, and/or provide translation tools.

That's the entire argument right there, though.  Who defines what a modern JVM is?  For lots of people and devices, Dalvik is the definition, and stuff coming from Oracle is an interesting experiment.

I'm just arguing that Dalvik's growth rate is interesting enough to say that picking up the minor benefits of Java 7 isn't worth the large cost. 
 
I also seriously doubt that the majority of Scala developers work on Android.  I suspect the majority are involved in web site and server development.

Yes, you're absolutely correct.  But the total number of Scala developers is still tiny across all environments; the point is to make it much larger, and a mobile + server story is more interesting than a server-only story.
 
Regardless of the popularity of Android, the majority of mobile developers have to think about cross-platform support for iOS and Windows RT (or whatever it is called today)

True, but it's a huge pain point.  I'm currently spending the vast majority of my time writing C++ and C for exactly that reason (when I'm not on vacation, like now - why am I reading this in Hawaii???), and it's miserable.  In any case, having cross-platform code that works on Android and the server is a big win, even if it can't (yet) target iOS.

It's too bad the LLVM backend doesn't work on iOS yet, AFAIK.  I can't imagine this thread would exist if Scala had a cross-platform story across Android, iOS and server.  Now _that_ would be interesting .

Jonathan Merritt

unread,
Mar 14, 2013, 5:14:12 PM3/14/13
to scala-user
Something I've been wondering: roughly how much of a performance improvement is expected via the use of Java 7 or 8 features?

The "Android camp" in this debate seem to be arguing that what may be gained through using JVM 7/8 is not worth the loss of "easy" Android compatibility.  The "other camp" seem to be arguing that Android compatibility won't really be lost anyway for those who want it, at least not immediately (albeit a little more work may be required).

I consider myself backend-agnostic (I do numerical processing work, and could do without much of the Java ecosystem if I had to).  However, I don't want to lose performance improvements if those might be quite considerable in a switch to JVM 7/8.  It seems as though running Scala on Android already requires jumping through some hoops, and it's hard for me to see how an extra bytecode processing step would really make that so much more difficult that the current or potential Android users would abandon Scala.

Jonathan Merritt.


--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

Simon Ochsenreither

unread,
Mar 14, 2013, 5:50:14 PM3/14/13
to scala...@googlegroups.com, Steven Barnes, Adriaan Moors, scala-i...@googlegroups.com, Alexandru Nedelcu

It's too bad the LLVM backend doesn't work on iOS yet, AFAIK.  I can't imagine this thread would exist if Scala had a cross-platform story across Android, iOS and server.  Now _that_ would be interesting.

It's already technically possible to deploy Scala across Android, iOS, Windows (Phone) 8. If the Java 6 back-end is dropped, that will be broken for the foreseeable future, too.

James Moore

unread,
Mar 14, 2013, 6:08:59 PM3/14/13
to Jonathan Merritt, scala-user
On Thu, Mar 14, 2013 at 11:14 AM, Jonathan Merritt <j.s.m...@gmail.com> wrote:
Something I've been wondering: roughly how much of a performance improvement is expected via the use of Java 7 or 8 features?

The "Android camp" in this debate seem to be arguing that what may be gained through using JVM 7/8 is not worth the loss of "easy" Android compatibility.  The "other camp" seem to be arguing that Android compatibility won't really be lost anyway for those who want it, at least not immediately (albeit a little more work may be required).

I consider myself backend-agnostic (I do numerical processing work, and could do without much of the Java ecosystem if I had to).  However, I don't want to lose performance improvements if those might be quite considerable in a switch to JVM 7/8.  It seems as though running Scala on Android already requires jumping through some hoops, and it's hard for me to see how an extra bytecode processing step would really make that so much more difficult that the current or potential Android users would abandon Scala.

There's probably a bit too much fear of the unknown from me - sorry about that.  It's just that my immediate reaction when this first started was "Android is doomed" - and I'm trying hard to remember that's not true.

I agree that if it's just an extra step to tweek some bytecodes, then I probably shouldn't be so worried; that's a solvable problem.  Clearly there's a perception issue (it has to be clear that Dalvik matters to the Scala community), but again, that's solvable.

The only scary part is in how much work is going to be required to do the conversion from 7 > 6, and keep it up to date.  Ideally, it'd be simple (and from the mail here, that seems to be the likely case) and wouldn't cause ongoing maintenance issues.  If it turns out to take a week to write and needs little or no upkeep, then everyone's happy (and I promise to buy everyone a beer who had to take the time to read my mail :-]).  If it turns out there are lots of edge cases here, then it's a more significant problem.

Simon Ochsenreither

unread,
Mar 14, 2013, 6:14:27 PM3/14/13
to scala...@googlegroups.com, scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
Hi,


We still have a (deprecated) java-1.5 back-end in Scala 2.10, but I'm not hearing much about that.
Yes, because there is pretty much no effort needed to update tools which work with Java 5 class files to support Java 6 class files, too.
Java 7 is a totally different story.
Please qualify "totally different". I've already pointed you to a tool that statically rewrites Java 7 bytecode to Java 6 bytecode in general.
It should be even easier to use ASM to write a similar tool that only deals with Scala-generated bytecode, which will use Java 7 bytecode in a very specific way.
We'll be happy to assist anyone who's willing to write that tool, or we may end up doing it ourselves.
 
As already mentioned, if it is seamlessly possible to automatically and transparently convert Scala's Java 7 byte code back to Java 6 code, this would be a solution which would be perfectly fine for me (and I think everyone else, too).

What makes me very concerned is that the planning seems to be completely based on speculation, wishful thinking and assumptions that other people will do the work for us.


Oh, I thought MethodHandles were also supported in J9, and OpenJDK. Maybe Avian will add support as well?
Whatever your personal feelings about oracle, I don't think you're interpreting my original message entirely fairly.

All companies who implement MethodHandles currently are licensees of Oracle and all of them pretty much suffer from the same (and/or different) issues Hotspot does  (e. g. no native compilation, no iOS/Android support, no proper tail calls, no embedding, not open-source, ...).


This is only true under the assumption that those platforms won't catch up with the Java world.

This is a completely valid assumption. And even if Android/etc. would add support for "Java 7/Java 8/Lambdas" there is no guarantee that it would help us in any way (e. g. making up their own Dalvik-specific bytecode, emitting anonymous classes, ...).

 
How can those platforms not consider adding support for this?

Oracle is actively trying to discourage/prevent/kill alternative implementations. The circumstances under which people implemented Java 5/6 implementations/runtimes are not comparable anymore with the current situation. People have seen what happened to Google and will think hard whether they have more money and better lawyers than Google before pissing off Oracle.

 
Maybe I'm living in the wrong parallel universe, but in my world Scala doesn't have 90% adoption rate. Those plans are pretty much killing adoption for everyone who is not a frustrated Java developer.
Really? I think we also attract happy Java developers. Again, I don't think unqualified statements like this contribute to the discussion.

We currently don't address anyone who is using Python, Ruby, F#, Erlang, Go, JavaScript, etc etc etc. And in those seldom situations where Scala was adopted by those people, it's more of an afterthought of "we need a stable, mature runtime, but we don't want to deal with Java", not "let's use Scala because it let's us develop better".

Nils Kilden-Pedersen

unread,
Mar 14, 2013, 6:29:44 PM3/14/13
to scala-i...@googlegroups.com, scala...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
On Thu, Mar 14, 2013 at 5:14 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
Hi,


We still have a (deprecated) java-1.5 back-end in Scala 2.10, but I'm not hearing much about that.
Yes, because there is pretty much no effort needed to update tools which work with Java 5 class files to support Java 6 class files, too.
Java 7 is a totally different story.
Please qualify "totally different". I've already pointed you to a tool that statically rewrites Java 7 bytecode to Java 6 bytecode in general.
It should be even easier to use ASM to write a similar tool that only deals with Scala-generated bytecode, which will use Java 7 bytecode in a very specific way.
We'll be happy to assist anyone who's willing to write that tool, or we may end up doing it ourselves.
 
As already mentioned, if it is seamlessly possible to automatically and transparently convert Scala's Java 7 byte code back to Java 6 code, this would be a solution which would be perfectly fine for me (and I think everyone else, too).

What makes me very concerned is that the planning seems to be completely based on speculation, wishful thinking and assumptions that other people will do the work for us.


Oh, I thought MethodHandles were also supported in J9, and OpenJDK. Maybe Avian will add support as well?
Whatever your personal feelings about oracle, I don't think you're interpreting my original message entirely fairly.

All companies who implement MethodHandles currently are licensees of Oracle and all of them pretty much suffer from the same (and/or different) issues Hotspot does  (e. g. no native compilation, no iOS/Android support, no proper tail calls, no embedding, not open-source, ...).


This is only true under the assumption that those platforms won't catch up with the Java world.

This is a completely valid assumption. And even if Android/etc. would add support for "Java 7/Java 8/Lambdas" there is no guarantee that it would help us in any way (e. g. making up their own Dalvik-specific bytecode, emitting anonymous classes, ...).

 
How can those platforms not consider adding support for this?

Oracle is actively trying to discourage/prevent/kill alternative implementations. The circumstances under which people implemented Java 5/6 implementations/runtimes are not comparable anymore with the current situation. People have seen what happened to Google and will think hard whether they have more money and better lawyers than Google before pissing off Oracle.

Why would they need better lawyers and more money? Since Google won, even less skilled lawyers should be able to pull a win with Google's victory as precedent.
 

 
Maybe I'm living in the wrong parallel universe, but in my world Scala doesn't have 90% adoption rate. Those plans are pretty much killing adoption for everyone who is not a frustrated Java developer.
Really? I think we also attract happy Java developers. Again, I don't think unqualified statements like this contribute to the discussion.

We currently don't address anyone who is using Python, Ruby, F#, Erlang, Go, JavaScript, etc etc etc. And in those seldom situations where Scala was adopted by those people, it's more of an afterthought of "we need a stable, mature runtime, but we don't want to deal with Java", not "let's use Scala because it let's us develop better".

--

Michael Bayne

unread,
Mar 15, 2013, 2:49:52 PM3/15/13
to scala-i...@googlegroups.com, scala-user, Steven Barnes, Adriaan Moors, Alexandru Nedelcu
On Thu, Mar 14, 2013 at 2:50 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:
It's already technically possible to deploy Scala across Android, iOS, Windows (Phone) 8. If the Java 6 back-end is dropped, that will be broken for the foreseeable future, too.

Are you referring to using IKVM to deploy Scala to iOS (via MonoTouch) and Windows Phone 8? Jeroen started working on MethodHandle support in IKVM in August 2011:


The MethodHandle support is still having bugs ironed out, but it's not "broken for the forseeable future".

I'm the maintainer of the IKVM fork that works with the limited CLR profile available on MonoTouch and Windows Phone 7/8. I'll be happy to field test the functioning of MethodHandles on an iOS/WinPhone build whenever I have a Scala build that's generating them.

-- m...@samskivert.com

Michael Bayne

unread,
Mar 15, 2013, 2:55:02 PM3/15/13
to scala-i...@googlegroups.com, scala-user, Steven Barnes, Adriaan Moors, Alexandru Nedelcu

On Fri, Mar 15, 2013 at 11:49 AM, Michael Bayne <m...@samskivert.com> wrote:
I'm the maintainer of the IKVM fork that works with the limited CLR profile available on MonoTouch and Windows Phone 7/8. I'll be happy to field test the functioning of MethodHandles on an iOS/WinPhone build whenever I have a Scala build that's generating them.

Though I should caveat that I haven't looked into whether he's implementing MethodHandle support via runtime code generation, which will be incompatible with both iOS and WinRT. I'll check into that.

-- m...@samskivert.com

Michael Bayne

unread,
Mar 15, 2013, 8:50:27 PM3/15/13
to scala-i...@googlegroups.com, scala-user, Steven Barnes, Adriaan Moors, Alexandru Nedelcu

On Fri, Mar 15, 2013 at 11:55 AM, Michael Bayne <m...@samskivert.com> wrote:
Though I should caveat that I haven't looked into whether he's implementing MethodHandle support via runtime code generation, which will be incompatible with both iOS and WinRT. I'll check into that.

Looking at the IKVM code, it does appear to be generating, and compiling on the fly, IL to create an appropriately typed delegate (in the case of MH.invokeExact, which I presume to be the mechanism Scala will use).

To convert Scala's closure creation and call sites directly over to delegates would require IKVM to recognize scalac's exact approach to encoding closures into method handles and then converting everything over wholesale. That's probably not going to happen unless some Scala enthusiast dug into the IKVM internals and wrote and maintained this bit of magic. Such energies would probably be better expended on cutting out the middle man, and resurrecting and maintaining the Scala CLR backend.

So I take back my comment about things not being broken for the forseeable future.

That said, the bytecode rewriting will work just fine for this case as well. Getting Scala onto iOS via IKVM is already a process that requires conversion of all your bytecodes, so running said bytecodes through a MethodHandle-to-anonymous-inner-class converter prior to running them through IKVM is not especially onerous.

-- m...@samskivert.com

Rich Oliver

unread,
Mar 16, 2013, 1:41:18 PM3/16/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
Scala 2.9 was released in May 2011. Its still being supported. I don't know if there will be a 2.9.4 but 2.9.3 was only just released. My guess would be that 2.11 will end up being released in January 2014 a year after 2.10. That means we can expect 2.11 to still be going strong into 2016. Is 2.11 really not going to provide an official Java 8 target? If 2.11 is to end up officially targeting two Java versions then surely they should be 7 and 8. In the poll 86% of voters wanted 7 or 8 as opposed to 14% who prioritised 6. If the Scala team wants to improve the Scala Java 6 target would it not make sense to back port things like the new macros into 2.10 and let runtime improvements for Scala use method handles.

At the very least why not make Java 7 the initial target and then see what the demand is for a Java 6 target, after Scala 2.11.0 is released. Is there any reason that those still needing to target Java 6 have to upgrade to 2.11 on day one. If Java 6 targeting really is still so vital to Scala by the beginning of next year why not produce a special Java 6 version? Why waste time, energy and resources now on a problem that may never arrive?

On Thursday, March 7, 2013 5:11:42 PM UTC, Adriaan Moors wrote:
Hi,

Is Java 6 support important for you to have in Scala 2.11?
If so, time to speak up: http://www.scala-lang.org/node/30977 (the poll takes approximately 3500ms to answer).

We are considering moving to Java 7 in 2.11 so that we can compile functions using MethodHandles.

To keep things simple (for you and ourselves), we'd rather not (officially) support two incompatible class formats in one Scala release (i.e., Java 6 & 7), as this would result in a fragmented eco system, where artifacts would have to indicate which Java version they're targeting in addition to the Scala version.

cheers
adriaan

Alan Burlison

unread,
Mar 17, 2013, 10:51:33 AM3/17/13
to Simon Ochsenreither, scala...@googlegroups.com, scala-i...@googlegroups.com, Alexandru Nedelcu, Steven Barnes
On 14/03/2013 14:35, Simon Ochsenreither wrote:

> ... and that's why we need to break working platforms, including one with
> an ecosystem with half a billion of Scala-capable devices and the
> possibility of native compilation, dependency-free deployment and embedding?
> I guess that will surely motivate people to spend more hard and time
> consuming work on it, right?

As far as I can tell, nobody is talking about stopping 2.10 working on
Android and as 2.11 is all about performance then the same Scala code
should be able to run under either 2.10 or 2.11. Interpreting the
proposal to have 2.11 require JSE7 as equivalent to breaking Scala on
Android is I believe an overreach.

And I think the half-a-billion devices argument is a little weak. If
there's a numbers-based discussion to be had it needs to be around the
*actual* number of Scala applications on Android versus 'traditional'
JVMs, and the numbers of deployments of those applications. From what I
see on this mailing list, Scala on Android isn't the canonical scenario
for Scala use.

Preventing much-needed performance improvements for the majority of
users of Scala solely to keep a minority platform on the leading edge
doesn't seem to me to be the right decision. There clearly isn't a
decision that will be best for everyone, but what you are arguing for is
the best for only a small subset of Scala users.

The current EOL of JSE7 is July 2014 which is only 16 months away [1].
If the switch to JSE7 isn't made soon then Scala will potentially face a
jump straight from 6 to 8, so sticking with JSE6 for Scala 2.11 seems
like it would just be storing up even more work for the future.

[1] http://www.oracle.com/technetwork/java/eol-135779.html

Disclaimer: I work for Oracle but not in the Java sphere. I'm speaking
here in a completely personal capacity as someone interested in Scala
and I know no more about the Java plans than I read in the external
announcements and press.

--
Alan Burlison
--

Alan Burlison

unread,
Mar 17, 2013, 11:00:59 AM3/17/13
to James Moore, Steven Barnes, Adriaan Moors, scala-i...@googlegroups.com, scala-user, Alexandru Nedelcu
On 14/03/2013 21:06, James Moore wrote:

> That's the entire argument right there, though. Who defines what a modern
> JVM is? For lots of people and devices, Dalvik is the definition, and
> stuff coming from Oracle is an interesting experiment.

Technically Dalvik isn't a JVM as it doesn't run Java bytecode, it's
translated from one to the other by dx. There are also significant
architectural differences in the VMs, for example the JVM is stack-based
whereas DVM is register-based.

--
Alan Burlison
--

Dave

unread,
Mar 17, 2013, 11:51:11 AM3/17/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
I think jumping from java6 to java8 would be wise thing to do because there is also Java EE 6 and java EE 7. The latter has become publicly available for review only recently. Also java EE 7 JSR standardization is not complete. Things are postponed to java EE 8 (spring 2015).
Why would an enterprise exchange a well-tested well running stack for something that is incomplete and not well-tested and which is replaced after two years for the full spec anyway?

Oracle is just releasing to keep up with schedule.

https://blogs.oracle.com/theaquarium/entry/java_ee_7_roadmap

Don't burn your ship behind you before you got a better one.

Op zondag 17 maart 2013 15:51:33 UTC+1 schreef Alan Burlison het volgende:

Alan Burlison

unread,
Mar 17, 2013, 12:19:07 PM3/17/13
to Dave, scala...@googlegroups.com, scala-i...@googlegroups.com
On 17/03/2013 15:51, Dave wrote:

> I think jumping from java6 to java8 would be wise thing to do because there
> is also Java EE 6 and java EE 7. The latter has become publicly available
> for review only recently. Also java EE 7 JSR standardization is not
> complete. Things are postponed to java EE 8 (spring 2015).

I think you are confusing J2SE and J2EE versions, they aren't the same
thing.

--
Alan Burlison
--

Dave

unread,
Mar 17, 2013, 12:39:55 PM3/17/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
I know that JDK7 can be downloaded with the java EE 6 SDK but I guess that java EE 7 SDK has the java 7 features.

Op zondag 17 maart 2013 17:19:07 UTC+1 schreef Alan Burlison het volgende:

Miguel Garcia

unread,
Mar 17, 2013, 2:10:13 PM3/17/13
to scala-i...@googlegroups.com, scala...@googlegroups.com

Without hard data on the payoff (MethodHandles on JDK7) it's hard to gauge the pros and cons. Initial benchmarks based on a modified version of the new backend don't suggest MHs to be a clear win just yet for Scala:

  https://groups.google.com/d/msg/scala-internals/uBxprJixpwk/jG78X1k_92IJ

The backend in question (minus the experimental support for MH discussed in that URL) is covered at

  http://magarciaepfl.github.com/scala/

  https://groups.google.com/d/msg/scala-internals/N1wnQcjcDvk/bnxrAQMxSsQJ


Miguel



On Sunday, March 17, 2013 9:25:30 AM UTC+1, Wang Yuan wrote:
Can not agree more on the last question: "Why waste time, energy and resources now on a problem that may never arrive?"

Keep scala ecosystem functional, compact and evolution day by day (even pioneer the industry) should be the top priorities, and then app developers should know how to survival case by case.

Regards,
Wang Yuan

Adriaan Moors

unread,
Mar 18, 2013, 12:30:24 AM3/18/13
to scala-i...@googlegroups.com, scala-user

On Sat, Mar 16, 2013 at 10:41 AM, Rich Oliver <rzi...@gmail.com> wrote:
At the very least why not make Java 7 the initial target and then see what the demand is for a Java 6 target, after Scala 2.11.0 is released.

Binary compatibility. Artifacts released with Java 7/8-specific bytecode can't run on Java 6.
We already encode the Scala version in the artifact name.
Adding another dimension to the version space does not seem appealing.

How does the Java world handle parallel releases of the same library for multiple class formats?

In any case, we're already working on Java 7 support. The discussion is about defaults as far as I'm concerned.
The default default will be to stay with Java 6 as our official back-end, except if there's overwhelming evidence of
a) performance improvements or b) increased Scala adoption if we switch to Java 7. (I haven't seen exhibit A or B.)

cheers
adriaan

--
See you at Scala Days (June 10–12, NYC)!

Ismael Juma

unread,
Mar 18, 2013, 4:40:09 AM3/18/13
to Adriaan Moors, scala-i...@googlegroups.com, scala-user
On Mon, Mar 18, 2013 at 4:30 AM, Adriaan Moors <adriaa...@typesafe.com> wrote:
In any case, we're already working on Java 7 support. The discussion is about defaults as far as I'm concerned.
The default default will be to stay with Java 6 as our official back-end, except if there's overwhelming evidence of
a) performance improvements or b) increased Scala adoption if we switch to Java 7. (I haven't seen exhibit A or B.)

I think this is they key point, moving to Java 7 as the default back-end makes sense if a significant performance improvement can be had by doing that. Otherwise, it probably doesn't.

For me the interesting questions are:

1. If we can achieve a significant performance improvement, would it be worth it to move to Java 7 as the default back-end?
2. What would be a significant performance improvement? (This should probably be broken down into areas like compilation speed, runtime performance, memory usage, start-up time and jar size)
3. Is it worth investing the time to do work required to get the desired answers given the chance of a favourable outcome?

Personally, I would say yes to 1 and 3 and would need to think some more before answering 2.

Best,
Ismael

Fernando Racca

unread,
Mar 18, 2013, 6:50:42 AM3/18/13
to scala-i...@googlegroups.com, Adriaan Moors, scala-user
I support these comments. The work that Miguel did on initial benchmarks of Method Handles is the way to go. Measure as much as you can up front, see where are the sweet spots, identify how much you are likely to gain, and wait at least until Google I/O event, while requesting  Google to come clean about invoke dynamic. 

If at that time, the evidence suggests that there is a clear performance win, and ideally MH is  supported  in Dalvik, then definitely go for it.
Otherwise, evaluate how much of an impact this is for users to depend on backported 2.10, as opposed to 2.11.
Otherwise, move to java 7, but without MH / invoke dynamic until it's actually supported (or never). this shouldn't cause major issues.

Fernando

Rich Oliver

unread,
Mar 18, 2013, 8:01:15 AM3/18/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
On Monday, March 18, 2013 4:30:24 AM UTC, Adriaan Moors wrote:

On Sat, Mar 16, 2013 at 10:41 AM, Rich Oliver <rzi...@gmail.com> wrote:
At the very least why not make Java 7 the initial target and then see what the demand is for a Java 6 target, after Scala 2.11.0 is released.

Binary compatibility. Artifacts released with Java 7/8-specific bytecode can't run on Java 6.
Yes I understand that. To clarify, I guess I'm saying that if we were looking at a long term situation, maybe 3 -5 years where Android and possibly other environments are going to be supporting Java 6 but not Java 7 or 8, then Scala should be forked. My particular axe is ScalaFx. I'd really love to see it integrated into Scala. JavaFx is going to be tightly integrated into Java 8. It seems like there is some real trust starting to build out there that Oracle can be trusted on JavaFx and its not just going to be another passing UI deployment fad. However, my impression is that the bulk of Scala work is for the server, and that client side Scala development is a minority pursuit whatever the form factor. Hence the lack of concern about a Scala GUI. Scala Swing is dead. Deader than WPF.

Nils Kilden-Pedersen

unread,
Mar 18, 2013, 8:53:58 AM3/18/13
to scala-i...@googlegroups.com, scala-user
On Sun, Mar 17, 2013 at 11:30 PM, Adriaan Moors <adriaa...@typesafe.com> wrote:
How does the Java world handle parallel releases of the same library for multiple class formats?

They usually just stick with the lowest common denominator they want to support. This is feasible, because Java bytecode is forward compatible.
 

In any case, we're already working on Java 7 support. The discussion is about defaults as far as I'm concerned.
The default default will be to stay with Java 6 as our official back-end, except if there's overwhelming evidence of
a) performance improvements or b) increased Scala adoption if we switch to Java 7. (I haven't seen exhibit A or B.)

cheers
adriaan

--
See you at Scala Days (June 10–12, NYC)!

--

James Moore

unread,
Mar 18, 2013, 11:58:24 AM3/18/13
to scala-i...@googlegroups.com, Adriaan Moors, scala-user
On Mon, Mar 18, 2013 at 3:50 AM, Fernando Racca <fra...@gmail.com> wrote:
I support these comments. The work that Miguel did on initial benchmarks of Method Handles is the way to go. Measure as much as you can up front, see where are the sweet spots, identify how much you are likely to gain, and wait at least until Google I/O event, while requesting  Google to come clean about invoke dynamic. 

If at that time, the evidence suggests that there is a clear performance win, and ideally MH is  supported  in Dalvik, then definitely go for it.

Is there an impact on other backends - does using methodhandles make life significantly harder for the LLVM port, for example, or .Net?

(I ask knowing nothing about the state of LLVM+Scala, I just wish that someday I'll be able to stop writing Objective C for iOS.)

Simon Ochsenreither

unread,
Mar 18, 2013, 12:48:16 PM3/18/13
to scala-i...@googlegroups.com, Adriaan Moors, scala-user

Is there an impact on other backends - does using methodhandles make life significantly harder for the LLVM port, for example, or .Net?
(I ask knowing nothing about the state of LLVM+Scala, I just wish that someday I'll be able to stop writing Objective C for iOS.)

There is not much (any?) work happening on LLVM and .NET the last time I looked.
Anyway, I'm more worried about those platforms which actually work right now and will stop working when targeting Java 7, namely Android and native targets.

Xuefeng Wu

unread,
Mar 25, 2013, 9:57:32 PM3/25/13
to scala...@googlegroups.com, scala-i...@googlegroups.com
Sorry That I'm not sure if compiler can support both?
If compiler can accept parameter the decide using MethodHandles or not. 

在 2013年3月8日星期五UTC+8上午1时11分42秒,Adriaan Moors写道:

Simon Ochsenreither

unread,
Mar 26, 2013, 12:10:23 AM3/26/13
to scala-i...@googlegroups.com, scala...@googlegroups.com

Sorry That I'm not sure if compiler can support both?
If compiler can accept parameter the decide using MethodHandles or not.

Sure, supporting multiple backends is pretty much what happens today with the target argument.
People are discussing which one should be the default one for the next release (and whether to deprecate/get rid of the Java6 one).

Adriaan Moors

unread,
Mar 27, 2013, 1:51:51 PM3/27/13
to scala-i...@googlegroups.com, scala-user
First off, many thanks to everyone who's contributed to this thread.

I think it's time for a (two-folded) conclusion: (1) the bytecode we emit by default, and (2) the Java version we interoperate with.

(1)
Scala 2.11 will target Java 6 by default, but will provide an "experimental" Java 7 back-end.
Scala 2.12's default target will move past Java 6, probably straight to Java 8 (Java 8's adoption rate permitting).

Note that only the default back-end should be used to publish artifacts. We're working hard to make 2.11's experimental back-end fully functional, and representative of what will become 2.12's default back-end, but please keep it in mind it will be experimental in 2.11.

(2)
Scala 2.11 will provide the best Java 8 inter-op story we can implement modulo source compatibility requirements. (Please see the other thread I started about this on scala-internals regarding accepting SAMs in higher-order methods.)
Scala 2.12 will be able to provide a better story here, as it will target the same bytecode version as Java 8.


cheers
adriaan

Fernando Racca

unread,
Mar 27, 2013, 5:46:15 PM3/27/13
to scala-i...@googlegroups.com, scala-user
Sounds like a very good comprise. 

Very interested to see how this unfolds !

Cheers,
Fernando 

Josh Suereth

unread,
Mar 27, 2013, 10:53:19 PM3/27/13
to scala-internals, scala-user
Sounds like an excellent plan.


--
Reply all
Reply to author
Forward
0 new messages