Which low level tasks can be accomplished on the JVM, but not expressed in java?

Question

Which useful (for performance or otherwise) constructions are valid bytecode, but not expressable in Java?

Answer 1

JVM bytecode is a stack-oriented programming language, so most of the stack management instructions don't make sense in Java, e.g. dup, swap, etc. Arbitrary goto, of course, is also not expressible in Java.

Something like JSR 292 proposes support for dynamically typed languages, which I don't think Java is planning to become.

I think something needs to be addressed here, though: your question seems to be at least partially motivated by the issue of performance. In practice, bytecodes are JIT-compiled to assembly. Whether or not there's a super magical bytecode instruction is really quite moot.

Answer 2

I have read that the bytecode method signatures support multiple dispatch on return types, whereas Java only allows for methods of the same name to dispatch on parameter types.

Answer 3

The opposite is also true sometimes.

For example, Java's visibility of inner classes cannot be represented in bytecode. The JVM only knows package-protected, protected, public and private visibility. So the Java compiler has to use a hack: It generates synthetic wrapper methods (which are package-visible) to expose the private fields and methods of inner classes to the outer class.

Answer 4

1. You can throw any object, not just exception.
2. You can overload on return type.
3. You can throw any exception without declaring it in throws.