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.
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.
Disagree. Android applications can still be written in 2.10 - nobody is taking away the right to use versions other than 2.11
On Thu, Mar 7, 2013 at 12:15 PM, Simon OchsenreitherAre there any killer features coming in 2.11 that Scala developers on
<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.
>
Android must have? If not, then what does it matter?
- 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?
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.
--
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?
--
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.
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 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.
--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.
If 2.11 is performance release instead of feature release, can it at least guarantee source code compatibility between 2.11 and 2.10?
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.
--
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.
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.)
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.
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.htmlAlso, 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).
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.
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.
--
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.
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.
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.
--
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.
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?
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.
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....
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.
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).
That lawsuit was already won by Google. Oracle could continue ofcourse with appeals or other lawsuits, but having lost the copyright
argument, patents are too weak and Google can counter-sue with their
own patents.
--
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.
"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
--
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.
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.
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.
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.
--
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.
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.
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.Really, with the current state of things we shouldn't be wondering why people don't pour their resources and time in porting Scala.
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.
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?
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.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.Really, with the current state of things we shouldn't be wondering why people don't pour their resources and time in porting Scala.
... 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?
--
- how does a change in backend X make implementing a new backend Y (llvm, javascript, .net) harder?
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
trying to voice in the friendliest way possible regarding the situation.
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?
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 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?
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)
--
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.
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.
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.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).
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.
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.
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.
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".
--
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.
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.
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.cheersadriaan
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
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.
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 ofa) performance improvements or b) increased Scala adoption if we switch to Java 7. (I haven't seen exhibit A or B.)
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.
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 ofa) performance improvements or b) increased Scala adoption if we switch to Java 7. (I haven't seen exhibit A or B.)cheersadriaan--See you at Scala Days (June 10–12, NYC)!
--
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.)
Sorry That I'm not sure if compiler can support both?If compiler can accept parameter the decide using MethodHandles or not.
--