Question

Are there currently (Java 6) things you can do in Java bytecode that you can’t do from within the Java language?

I know both are Turing complete, so read “can do” as “can do significantly faster/better, or just in a different way”.

I’m thinking of extra bytecodes like invokedynamic, which can’t be generated using Java, except that specific one is for a future version.

Answer 1

As far as I know there are no major features in the bytecodes supported by Java 6 that are not also accessible from Java source code. The main reason for this is obviously that the Java bytecode was designed with the Java language in mind.

There are some features that are not produced by modern Java compilers, however:

• The ACC_SUPER flag:

  This is a flag that can be set on a class and specifies how a specific corner case of the invokespecial bytecode is handled for this class. It is set by all modern Java compilers (where "modern" is >= Java 1.1, if I remember correctly) and only ancient Java compilers produced class files where this was un-set. This flag exists only for backwards-compatibility reasons. Note that starting with Java 7u51, ACC_SUPER is ignored completely due to security reasons.

• The jsr/ret bytecodes.

  These bytecodes were used to implement sub-routines (mostly for implementing finally blocks). They are no longer produced since Java 6. The reason for their deprecation is that they complicate static verification a lot for no great gain (i.e. code that uses can almost always be re-implemented with normal jumps with very little overhead).

• Having two methods in a class that only differ in return type.

  The Java language specification does not allow two methods in the same class when they differ only in their return type (i.e. same name, same argument list, …). The JVM specification however, has no such restriction, so a class file can contain two such methods, there’s just no way to produce such a class file using the normal Java compiler. There’s a nice example/explanation in this answer.