Translating Scala to Java

Sam,

Most of the aspects you mention are also goals of the Scala to Java
translator I'm working on:

- accept the full Scala language,
- be released under a permissive open source license
- be able to translate the Scala library
- do without dedicated dedicated runtime JARs
- avoid runtime interpretation
- when translating Scala programs, any calls to external libraries (e.g.,
JDK) are left as-is.

As to the non-goals, most likely there won't be full binary compatibility
between the toolchains:
(a) nsc -> bytecode;
(b) nsc with s2j plugin -> javac -> bytecode.

In making public the work-in-progress I'm trying to motivate others to
contribute solutions to open sub-problems.

As to those open-subproblems, they are basically two: object initialization
semantics and conversion of block expressions. Both require knowledge of the
Scala compiler in order to address them. (I'm assuming I'll complete the
translation of pattern matching within a month).

For now, what I can say is that I'll keep working on this project, and if
you know other Scala developers keen on learning internals of the compiler,
please let them know :-) Other than that, you may also contribute by posting
your questions (thanks!) which will help shape requirements for future
versions.

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/ScalaCompilerCorner

Samuel Robert Reid wrote:
> Scala Team,
>
> In order to mitigate risk for my company's investment in Scala, I've
> been looking into techniques for automatically translating Scala to
> Java. I've tried running decompilers on the compiled Scala code with
> varying degrees of success in terms of readability. In this case, I'm
> not sure whether it is better to include the Scala library as a
> dependency JAR, or whether the Scala API should also be translated to Java.

Are you thinking about using the Scala to Java converter as a tool in case you
decide to go back to Java (for a one time conversion) or ongoingly in your
project as part of the build?

If the later, it seems that you've actually increased your risk because instead
of just relying upon Scala you're dependent upon two systems, Scala and the
Scala to Java converter. Scala has a lot more eyes on it than the Scala to Java
converter. In the company I work for (Sony Imageworks) we decided to do a brand
new project in Scala so the risk would be isolated.

Not to poo-poo the converter, I'm looking forward to it because we could
potentially write GWT code in Scala.

Regards,
Blair

On Tue, Feb 9, 2010 at 6:38 PM, Samuel Robert Reid wrote:
> Scala Team,
>
> In order to mitigate risk for my company's investment in Scala, I've been
> looking into techniques for automatically translating Scala to Java.  I've
> tried running decompilers on the compiled Scala code with varying degrees of
> success in terms of readability.  In this case, I'm not sure whether it is
> better to include the Scala library as a dependency JAR, or whether the
> Scala API should also be translated to Java.
>
> I've also been following the threads on GenJava and Miguel's project for
> emitting Java code from the Scala compiler.  Is the Scala->Java code emitter
> ready for real-world projects?  How do I download/run it?  Is pattern
> matching the only feature still under development?  How does this project
> handle dependencies on the scala-library API?  Again, there is the question
> of whether it should be included as a dependent JAR after translation is
> complete, or if the Scala library (and possibly scala-swing) should also be
> translated.  I'm also wondering about how the emitted Java code might be
> superior to decompiled bytecode.
>
> Are there other tool sets, resources or recommendations about how to
> automatically translate Scala to Java?
>
I agree that a translator Scala -> Java would be highly desirable both
as a exit insurance for timid adopters and as a bridge to GWT.
Unfortunately, a complete solution is suprisingly hard, even though I
believe it would be doable. Pattern matching is not the only stumbling
block; there are several others more. Miguel has done some nice
summing up and Lex Spoon has also done an exploration of the issues
previously. I believe that to get a fully functional Scala -> Java
translator would take about 2 person years for a person who knows what
she is doing. As always the latest 1%% is the hardest in this game. So
if one were to settle for a more heuristic translator that would
require manual intervention once every 1000 lines of source code or
so, this could probably be done in one person year or less.

Right now I do not see a concerted effort doing it. It's not in the
core mission of the EPFL team, so we'd need to explore alternative
funding models.

Cheers

Thanks all for your critical feedback on translating Scala to Java.
Just a few follow-up questions and comments:

>Are you thinking about using the Scala to Java converter as a tool in
case you decide to go back to Java (for a one time conversion) or
ongoingly in your project as part of the build?

This would be a one-time conversion (rather than a recurring part of the
build chain) in case we need to switch our Scala projects to Java.
Hopefully, we don't end up in that situation, but I want to know our
options since this kind of safety-net (even if not perfect) might
mitigate the risk enough to allow us to continue with Scala.

What about using a decompiler? Are there constructs in the scalac
output that are known to not be compatible with bytecode->java
decompilation? Or is the decompiled code simply too
unreadable/complicated to be useful? I was planning on investigating
decompilation as a mechanism for Scala -> Java further, but was
wondering if anybody had been down this path before and had any words of
wisdom.

Thanks again for your feedback,
Sam Reid

Even Java compiled to byte code decompiled to Java is, um, less than perfect. http://www.program-transformation.org/Transform/DecompilationJadTest


On Tue, Feb 9, 2010 at 1:12 PM, Samuel Robert Reid <Reids [at] colorado [dot] edu> wrote:

What about using a decompiler?  Are there constructs in the scalac output that are known to not be compatible with bytecode->java decompilation?  Or is the decompiled code simply too unreadable/complicated to be useful?  I was planning on investigating decompilation as a mechanism for Scala -> Java further, but was wondering if anybody had been down this path before and had any words of wisdom.

Hi, Sam,

I'm just sort of wondering, what is the principle perceived risk of
staying with Scala?

Kris

On Tue, Feb 9, 2010 at 2:12 PM, Samuel Robert Reid wrote:
> Thanks all for your critical feedback on translating Scala to Java.  Just a
> few follow-up questions and comments:
>
>>Are you thinking about using the Scala to Java converter as a tool in case
>> you decide to go back to Java (for a one time conversion) or ongoingly in
>> your project as part of the build?
>
> This would be a one-time conversion (rather than a recurring part of the
> build chain) in case we need to switch our Scala projects to Java.
>  Hopefully, we don't end up in that situation, but I want to know our
> options since this kind of safety-net (even if not perfect) might mitigate
> the risk enough to allow us to continue with Scala.
>
> What about using a decompiler?  Are there constructs in the scalac output
> that are known to not be compatible with bytecode->java decompilation?  Or
> is the decompiled code simply too unreadable/complicated to be useful?  I
> was planning on investigating decompilation as a mechanism for Scala -> Java
> further, but was wondering if anybody had been down this path before and had
> any words of wisdom.
>
> Thanks again for your feedback,
> Sam Reid
>

On Tue, Feb 9, 2010 at 11:27 PM, Kris Nuttycombe <kris [dot] nuttycombe [at] gmail [dot] com> wrote:

Hi, Sam,

I'm just sort of wondering, what is the principle perceived risk of
staying with Scala?

Never wanting to go back to Java, ever.
I think Scala has made me physically allergic to boilerplate :/
 

Kris

On Tue, Feb 9, 2010 at 2:12 PM, Samuel Robert Reid <Reids [at] colorado [dot] edu> wrote:
> Thanks all for your critical feedback on translating Scala to Java.  Just a
> few follow-up questions and comments:
>
>>Are you thinking about using the Scala to Java converter as a tool in case
>> you decide to go back to Java (for a one time conversion) or ongoingly in
>> your project as part of the build?
>
> This would be a one-time conversion (rather than a recurring part of the
> build chain) in case we need to switch our Scala projects to Java.
>  Hopefully, we don't end up in that situation, but I want to know our
> options since this kind of safety-net (even if not perfect) might mitigate
> the risk enough to allow us to continue with Scala.
>
> What about using a decompiler?  Are there constructs in the scalac output
> that are known to not be compatible with bytecode->java decompilation?  Or
> is the decompiled code simply too unreadable/complicated to be useful?  I
> was planning on investigating decompilation as a mechanism for Scala -> Java
> further, but was wondering if anybody had been down this path before and had
> any words of wisdom.
>
> Thanks again for your feedback,
> Sam Reid
>

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang

Never wanting to go back to Java, ever.
I think Scala has made me physically allergic to boilerplate :/

I'll be switching from Scala back to Java about the same time that I give up git and go back to svn. ;)

- Colin

Only one member of our 4-person development team speaks Scala, so there
is risk that too much information is consolidated in one individual's
skills for our production projects. There's also the cost of training
our existing team members in Scala, and the caveat that it's currently
easier to hire good Java developers than good Scala+Java developers.
Based on my personal experience, I have had difficulty quantifying the
learning curve and cost-benefit analysis of using Scala. It's easy to
quantify in terms of number of lines of code reduced (and hence ease of
writing/reading/understanding), but not in terms of a claim like "if you
invest X hours learning Scala, then it will make you Y% more productive
in your daily tasks and you will break even in your investment Z months
down the road". Since we have many pressing deadlines for deliverables,
X and Z would have to be pretty low for us to be able to make the
investment.

Sam Reid

On 2/9/2010 3:27 PM, Kris Nuttycombe wrote:
> Hi, Sam,
>
> I'm just sort of wondering, what is the principle perceived risk of
> staying with Scala?
>
> Kris
>
> On Tue, Feb 9, 2010 at 2:12 PM, Samuel Robert Reid wrote:
>
>> Thanks all for your critical feedback on translating Scala to Java. Just a
>> few follow-up questions and comments:
>>
>>
>>> Are you thinking about using the Scala to Java converter as a tool in case
>>> you decide to go back to Java (for a one time conversion) or ongoingly in
>>> your project as part of the build?
>>>
>> This would be a one-time conversion (rather than a recurring part of the
>> build chain) in case we need to switch our Scala projects to Java.
>> Hopefully, we don't end up in that situation, but I want to know our
>> options since this kind of safety-net (even if not perfect) might mitigate
>> the risk enough to allow us to continue with Scala.
>>
>> What about using a decompiler? Are there constructs in the scalac output
>> that are known to not be compatible with bytecode->java decompilation? Or
>> is the decompiled code simply too unreadable/complicated to be useful? I
>> was planning on investigating decompilation as a mechanism for Scala -> Java
>> further, but was wondering if anybody had been down this path before and had
>> any words of wisdom.
>>
>> Thanks again for your feedback,
>> Sam Reid
>>
>>