4 ms·

Question (maybe stupid, not a Java guy nowadays...): will bytecode coming from code using Java 8 features be runable on older VMs? Or, to put it otherwise, are

by nnq 14y ago

Question (maybe stupid, not a Java guy nowadays...): will bytecode coming from code using Java 8 features be runable on older VMs? Or, to put it otherwise, are new features like lambdas just syntactic sugar / compiler sugar, or have they significantly changed the bytecode and VM to make them work?

guard-of-terra 14y ago
They add new instructions with each release so the bytecode is not backwards compatible. But it does not matter much because most of jvm code is deployed on the server, and the rest is delivered with bundled jvm. However, you can have compiler generate lower version bytecode for you. If you have a Java 8 compiler but want Java 1.4 bytecode - no problem, just ask compiler to target 1.4. It will warn you if you use any >1.4 features. Maybe it will even let you use lambdas (maybe not, I'm not sure). Java is very backwards compatible. That's why it progresses so slowly perhaps.
- ZoFreX 14y ago
  Bytecode is not made incompatible with every release, actually - for example the generics added in 1.5 use type erasure, and so are a compile-time-only feature, leaving the bytecode still compatible with 1.4 JVMs.
  - guard-of-terra 14y ago
    You're confusing JVM versions with Java versions. A JVM class compiled for JVM 6 target will not run under JVM 1.4. It will fail to load because of version mismatch. However, you can use Java 6 compiler to compile Java 6 code to JVM 1.4 bytecode. That's what you are talking about.
    - ZoFreX 14y ago
      Yes, I am. I got confused over what you meant by " It will warn you if you use any >1.4 features" - I thought you meant language >1.4, not bytecode spec >1.4. Thanks for setting me straight :)
      - guard-of-terra 14y ago
        I actually meant "language features that require bytecode spec >1.4". Varargs and enums perhaps?
joshAg 14y ago
At a bytecode level, everything including and above assembler is syntactic sugar. I don't think there's any theoretical reason for the bytecode or the bytecode assembler language to need to change. Just like there's no reason lisp and c can't both be compiled to IA32 bytecode, even though lisp has lambdas and c does not. Rather the issue is going to be at the compilation stage, where support for anonymous methods will need to be added. From my limited knowledge of compilers two ways it could be done are: * just give the lambda methods a namespace that is unique from the namespace programmers have access to (eg a variable with a space or a tab in its name). Now lambdas will be handled like regular named methods, but the namespace for them will be invisible to the programmer, and the compiler will be modified to have two method namespaces/an expanded namespace for functions. * Make all methods lambdas and then bind method variables to the lambda methods similar to how atomic/primitive (eg integer, float, chars) and other non-atomic/reference (objects, arrays) variables are bound to their anonymous objects. This is similar to how anonymous objects are handled. An anonymous object is what's returned by constructors, which are then bound to some variable. In this case the compiler needs to support methods that aren't bound to a variable. That said, it's entirely possible that making changes to the bytecode and the jvm will allow for faster running code, but those changes wouldn't be required out of some theoretical necessity for supporting lambdas.
- nnq 14y ago
  Yes, the reasoning makes sense. I was actually thinking at this from a "language evolvability" p.o.v. : if, hypothetically, a language like Python would be bytecode compiled and the bytecode compatible v2 to v3, you could evolve the language syntax much faster without the worry for complicated "transitions": You could then use python 2 libraries in a python 3 program and so on... I'm in the initial stages of a (not so serious) language design project - a language "designed for accelerated evolution of both syntax and semantics", and I was considering the hypothesis that a "bytecode" compiled language could evolve much faster than either an interpreted or compiled-to-machine-code one.
wyuenho 14y ago
I have a better question: when is the Oracle JVM going to support caching of JIT'ed code profiles from the last run so the JVM can start up faster and doesn't have to warm up? This will make running Eclipse soooo much smoother.
- thebluesky 14y ago
  The gains for this approach are usually marginal as disk IO is expensive vs generating code in memory using the JIT.
aardvark179 14y ago
The lambda implementation requires the MethodHandle/invokeDynamic work introduced at 7, and run time components introduced at 8. There is also some significant work being done on the inliner to support better optimisation for lambdas. Further to that 8 introduces default implementations to interfaces to allow lambda exploiting features to be added to the standard Java APIs while allowing old code to be run without requiring recompilation. Though changes to the instruction set do not happen at every release there are normally changes to the class file format - so although generics were implemented by type erasure at Java 5 so did not need an instruction set change new signature information was added to the class file format to describe the type parameters, and annotations were introduced which required further class file format changes.

by nnq 14y ago

guard-of-terra 14y ago

They add new instructions with each release so the bytecode is not backwards compatible. But it does not matter much because most of jvm code is deployed on the server, and the rest is delivered with bundled jvm. However, you can have compiler generate lower version bytecode for you. If you have a Java 8 compiler but want Java 1.4 bytecode - no problem, just ask compiler to target 1.4. It will warn you if you use any >1.4 features. Maybe it will even let you use lambdas (maybe not, I'm not sure). Java is very backwards compatible. That's why it progresses so slowly perhaps.

ZoFreX 14y ago
Bytecode is not made incompatible with every release, actually - for example the generics added in 1.5 use type erasure, and so are a compile-time-only feature, leaving the bytecode still compatible with 1.4 JVMs.
- guard-of-terra 14y ago
  You're confusing JVM versions with Java versions. A JVM class compiled for JVM 6 target will not run under JVM 1.4. It will fail to load because of version mismatch. However, you can use Java 6 compiler to compile Java 6 code to JVM 1.4 bytecode. That's what you are talking about.
  - ZoFreX 14y ago
    Yes, I am. I got confused over what you meant by " It will warn you if you use any >1.4 features" - I thought you meant language >1.4, not bytecode spec >1.4. Thanks for setting me straight :)
    - guard-of-terra 14y ago
      I actually meant "language features that require bytecode spec >1.4". Varargs and enums perhaps?

joshAg 14y ago

At a bytecode level, everything including and above assembler is syntactic sugar. I don't think there's any theoretical reason for the bytecode or the bytecode assembler language to need to change. Just like there's no reason lisp and c can't both be compiled to IA32 bytecode, even though lisp has lambdas and c does not. Rather the issue is going to be at the compilation stage, where support for anonymous methods will need to be added. From my limited knowledge of compilers two ways it could be done are: * just give the lambda methods a namespace that is unique from the namespace programmers have access to (eg a variable with a space or a tab in its name). Now lambdas will be handled like regular named methods, but the namespace for them will be invisible to the programmer, and the compiler will be modified to have two method namespaces/an expanded namespace for functions. * Make all methods lambdas and then bind method variables to the lambda methods similar to how atomic/primitive (eg integer, float, chars) and other non-atomic/reference (objects, arrays) variables are bound to their anonymous objects. This is similar to how anonymous objects are handled. An anonymous object is what's returned by constructors, which are then bound to some variable. In this case the compiler needs to support methods that aren't bound to a variable. That said, it's entirely possible that making changes to the bytecode and the jvm will allow for faster running code, but those changes wouldn't be required out of some theoretical necessity for supporting lambdas.

nnq 14y ago
Yes, the reasoning makes sense. I was actually thinking at this from a "language evolvability" p.o.v. : if, hypothetically, a language like Python would be bytecode compiled and the bytecode compatible v2 to v3, you could evolve the language syntax much faster without the worry for complicated "transitions": You could then use python 2 libraries in a python 3 program and so on... I'm in the initial stages of a (not so serious) language design project - a language "designed for accelerated evolution of both syntax and semantics", and I was considering the hypothesis that a "bytecode" compiled language could evolve much faster than either an interpreted or compiled-to-machine-code one.

wyuenho 14y ago

I have a better question: when is the Oracle JVM going to support caching of JIT'ed code profiles from the last run so the JVM can start up faster and doesn't have to warm up? This will make running Eclipse soooo much smoother.

thebluesky 14y ago
The gains for this approach are usually marginal as disk IO is expensive vs generating code in memory using the JIT.

aardvark179 14y ago

The lambda implementation requires the MethodHandle/invokeDynamic work introduced at 7, and run time components introduced at 8. There is also some significant work being done on the inliner to support better optimisation for lambdas. Further to that 8 introduces default implementations to interfaces to allow lambda exploiting features to be added to the standard Java APIs while allowing old code to be run without requiring recompilation. Though changes to the instruction set do not happen at every release there are normally changes to the class file format - so although generics were implemented by type erasure at Java 5 so did not need an instruction set change new signature information was added to the class file format to describe the type parameters, and annotations were introduced which required further class file format changes.