Edit: It also seems to be dropping autoincrement/decrement, and random other blocks of code I've looked at, so I guess it's still in a fairly early stage.
I also noticed this in IntelliJ when I went to copy some Java into a Scala project. As I began converting the Java code to Scala after the copy I was extremely confused when I found that the pasted code was already converted for me.
That being said, it doesn't work very well in many circumstances. I'm not sure if they're using Scalagen under the hood or their own home-baked stuff. It's impressive as-is, regardless of the issues.
Earnest question: who is the target audience here? If Java and Scala can be intermixed in the JVM, and the generated Scala code is not very idiomatic, then how would this be used?
1. Someone still learning Scala syntax (and already knows Java)
2. Let's say you already have an existing Scala code base and you want to try out some new Java library which has examples in Java but you want to use it in your Scala code.
Every single Java developer that I introduce to Scala-- every single one-- six months later, they tell me "please don't make me go back to Java".
The "disenchanted" piece, I think, comes from the fact that if you're just writing Java-OO-style in Scala, you're losing almost all the benefits. Once you start working with the FP style, understanding Options, working with fold, list comprehensions, and the resulting massive reduction in lines of code, you start seeing how FP Scala code becomes the last refactoring you'll ever need to do, because it's so concise.
Since everyone else seems to disagree, I'll explain why I agree:
-- Scala advocates a completely different style of programming. You have to rethink how you code to match Scala's functional style. This is not a trivial thing if you have a bunch of Java developers you need to convert.
-- I find the Scala documentation is less readable than Java's docs. They are cluttered with type conversion functions and unreadable operator overloads (the filtering helps a bit here, but it's extra work). Documentation is also split between the object/class/trait pages.
-- There's a whole class of immutable data structures whose performance characteristics I need to learn, since I'm supposed to be using them.
-- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code.
-- I'm not convinced that a project preferring only immutable data is easier to maintain.
-- Programs seem to take longer to compile (sbt is especially slow).
Now that I think about it, Scala in relation to Java is a lot like C++ in relation to C. Scala sits on top of Java, so you need to know Java, and then you need to know all of Scala's features as well. However, (as someone who knows Java) I think C++ adds useful abstractions that are non-existant in C (templating, inheritance), whereas most of Scala's features are just syntactical changes of what already exists in Java.
I don't think this is true at all. There was the one team at Yammer, but overall, it seems as if Netflix and LinkedIn are pushing forward with Scala adoption, and Twitter, FourSquare, Tumblr, Klout, Gravity, and many others are already committed scala shops.
This is a neat project. I have a giant codebase I'd like to try this on. Depending on the output, this might be the kick in the pants I need to get in to scala full time.
Scala that's been autoconverted from Java doesn't tend to be very idiomatic scala, and there's no way to convert back. I'd recommend writing bits of your code (particularly code that needs to convert between datastructures, or code where you need better control over effects) in scala first and see how you get on with it.
Intellij IDEA has had Java to Scala conversion built into it for a while (as well as Java to Kotlin, Jetbrain's new JVM Scala-like language). I'm not sure how Jetbrain's tool compares to the one in the link above, but the conversion result in Intellij varies by how complicated and dependent the code is on other packages/libraries. Converting an entire class file tends to work out much better than a single method.
I initially used it to convert some Android code in Java to Scala, but much of the time you have to end up rewriting that as well, since it's generally results in very non-idiomatic Scala code. Still useful for someone learning Scala though as others have pointed out.
The Scala plugin is free though and comes with the community edition of Intellij for anyone wanting to try it out. Basically you just copy/paste some Java code from the current project into a Scala file or right click on the Java file and select "convert."
So now I am really wondering. What is the sub java parts of the JVM that need to be implemented to completely free Scala from the JVM ( i.e. what C interfaces are needed to allow scalc to compile to LLVM or comparable VM)
Why would you want to? The JVM is pretty awesome. There's already a scala implementation for .net, so it's got at least some level of VM independence, but the JVM is the primary target and I'd expect it to remain so.
As well as the VM there's the runtime library to consider. There was a project recently here that compiled scala to javascript to use on web pages, but unfortunately it needed a 16mb standard library.
Huge amounts. Practical scala apps leverage huge parts of the Java infrastructure. The Scala types are often thin wrappers over the Java types, JDBC, NIO, etc. It'd be a bit like trying to write a C++ app without access to, say, the STL, or Boost.
Unlike Scala, having Java-style code in Clojure yields no advantages. You just end up with something like Java, but with less type safety and more parentheses. It also makes a lousy start for refactoring since effective Clojure is so much about figuring out how to shape your code into nested S-Expressions, so you'll end up nuking most of your auto-converted Java "statements".
Clojure doesn't lend itself to doing that. Perhaps the easiest (albeit simplistic) way to describe the difference between Clojure and Scala -- Scala supports OOP and FP, and Clojure supports FP only as part of a holistic (and refreshing) vision of how high-level programming is done.
Even if it were possible to do so in Clojure, you probably wouldn't want to. There are usually ways to do the same things in Clojure that makes your code simpler, and as a result, in much less code.
Part of the Clojure philosophy is to make things simpler, even if it isn't always 'easy' at first relative to the individual talking. Even though using a code translation tool is easy, figuring out how to use functions and macros to abstract away repetitious code blocks and patterns from your code is well worth it in the medium- and long-term.
I think you would have to check converted code for all the well documented interop issues: annotations, static members, checked exceptions etc. The Manning books "In Depth" and "In Action" cover these really well,
[+] [-] scottjad|12 years ago|reply
I kind of wished this site was written in Java and run through scalagen with the output being run as an additional meta-demonstration.
[+] [-] ben0x539|12 years ago|reply
Edit: It also seems to be dropping autoincrement/decrement, and random other blocks of code I've looked at, so I guess it's still in a fairly early stage.
Definitely a cool project though :)
[+] [-] tommorris|12 years ago|reply
The closest I'd wrote in Scala to your example is something like this:
Ideally, the switch (42) {} should be removed as it's not doing anything.[+] [-] adandy|12 years ago|reply
[+] [-] Xorlev|12 years ago|reply
[+] [-] unclebucknasty|12 years ago|reply
[+] [-] lukax|12 years ago|reply
1. Someone still learning Scala syntax (and already knows Java)
2. Let's say you already have an existing Scala code base and you want to try out some new Java library which has examples in Java but you want to use it in your Scala code.
[+] [-] ExpiredLink|12 years ago|reply
[+] [-] mark242|12 years ago|reply
Every single Java developer that I introduce to Scala-- every single one-- six months later, they tell me "please don't make me go back to Java".
The "disenchanted" piece, I think, comes from the fact that if you're just writing Java-OO-style in Scala, you're losing almost all the benefits. Once you start working with the FP style, understanding Options, working with fold, list comprehensions, and the resulting massive reduction in lines of code, you start seeing how FP Scala code becomes the last refactoring you'll ever need to do, because it's so concise.
[+] [-] quacker|12 years ago|reply
Since everyone else seems to disagree, I'll explain why I agree:
-- Scala advocates a completely different style of programming. You have to rethink how you code to match Scala's functional style. This is not a trivial thing if you have a bunch of Java developers you need to convert.
-- I find the Scala documentation is less readable than Java's docs. They are cluttered with type conversion functions and unreadable operator overloads (the filtering helps a bit here, but it's extra work). Documentation is also split between the object/class/trait pages.
-- There's a whole class of immutable data structures whose performance characteristics I need to learn, since I'm supposed to be using them.
-- I'm not convinced that the overhead of copying immutable data doesn't outweigh the benefits of the ability to trivially parallelize the code.
-- I'm not convinced that a project preferring only immutable data is easier to maintain.
-- Programs seem to take longer to compile (sbt is especially slow).
Now that I think about it, Scala in relation to Java is a lot like C++ in relation to C. Scala sits on top of Java, so you need to know Java, and then you need to know all of Scala's features as well. However, (as someone who knows Java) I think C++ adds useful abstractions that are non-existant in C (templating, inheritance), whereas most of Scala's features are just syntactical changes of what already exists in Java.
[+] [-] runT1ME|12 years ago|reply
[+] [-] eranation|12 years ago|reply
[+] [-] amk7|12 years ago|reply
[+] [-] agibsonccc|12 years ago|reply
[+] [-] lmm|12 years ago|reply
[+] [-] eip|12 years ago|reply
[+] [-] yareally|12 years ago|reply
I initially used it to convert some Android code in Java to Scala, but much of the time you have to end up rewriting that as well, since it's generally results in very non-idiomatic Scala code. Still useful for someone learning Scala though as others have pointed out.
The Scala plugin is free though and comes with the community edition of Intellij for anyone wanting to try it out. Basically you just copy/paste some Java code from the current project into a Scala file or right click on the Java file and select "convert."
[+] [-] zidar|12 years ago|reply
[+] [-] edofic|12 years ago|reply
[+] [-] dkhenry|12 years ago|reply
[+] [-] lmm|12 years ago|reply
As well as the VM there's the runtime library to consider. There was a project recently here that compiled scala to javascript to use on web pages, but unfortunately it needed a 16mb standard library.
[+] [-] gtani|12 years ago|reply
- compiler backend page (info about CLR: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded...
- scala to JS (one of multiple projects): http://www.infoq.com/news/2013/06/scalajs
- akka is (i think) tightly bound to Oracle JVM/openJDK, https://groups.google.com/forum/#!msg/akka-user/0Z-9_Bmt8p4/...
[+] [-] TylerE|12 years ago|reply
[+] [-] ensmotko|12 years ago|reply
[+] [-] lukax|12 years ago|reply
[+] [-] mark_eijsermans|12 years ago|reply
[+] [-] zeckalpha|12 years ago|reply
[+] [-] orph|12 years ago|reply
[+] [-] mcav|12 years ago|reply
[+] [-] cynicalkane|12 years ago|reply
[+] [-] elangoc|12 years ago|reply
Even if it were possible to do so in Clojure, you probably wouldn't want to. There are usually ways to do the same things in Clojure that makes your code simpler, and as a result, in much less code.
Part of the Clojure philosophy is to make things simpler, even if it isn't always 'easy' at first relative to the individual talking. Even though using a code translation tool is easy, figuring out how to use functions and macros to abstract away repetitious code blocks and patterns from your code is well worth it in the medium- and long-term.
[+] [-] zindlerb|12 years ago|reply
[+] [-] anonymoushn|12 years ago|reply
[+] [-] gtani|12 years ago|reply