Hacker News new | ask | show | jobs
by ptx 3387 days ago
My impression from the post was that they were going back to the old (standard) way of letting the standard javac compile Java to bytecode and then letting dx convert it to Dalvik bytecode, but now with the addition of Java 8 bytecode support in dx. Their stated reason is precisely what you bring up: compatibility with tools that work with the bytecode, like the Scala compiler.

Is this impression incorrect? Are they doing something special with the Java source code instead of processing the byte code? Are they doing their own javac compiler?

1 comments

At second glance it looks like you're right. When they say "add support for Java 8 language features directly into the current javac and dx set of tools" I read that as directly adding Java 8 language support into the javac already in the toolchain, but the comment bitmapbrother quoted links to a tool that operates on Java 8 bytecode[1]. I guess they are adding Java 8 bytecode translation as a part of dx or as a build step between javac and dx.

If they aim to translate all valid Java 8 bytecode (and not just classes emitted by javac) then the situation is at least as good as we would have got with Jill.

[1] "Command-line tool to desugar Java 8 constructs that dx doesn't know what to do with, in particular lambdas and method references." https://github.com/bazelbuild/bazel/blob/master/src/tools/an...