28

Which features of JDK 7 (excluding invokedynamic because it is not used by java) causing a new class file version which is not compliant with JDK 6. It seams that all features could be implemented by compiler generating glue codes. For example String in switch statement could be implemented using repeated ifeq statements generated by the compiler. I want to able to give -source 1.7 -target 1.6 flags to compiler to be compliant with jre 6 and at the same time use project coin features in jdk 7.

Deniz
  • 1,575
  • 1
  • 16
  • 27
  • If you look at bytecodes with javap or use a decompiler and reverse engineer the .class file generated with JDK 7 compiler, you will see that generated code of "try with resource", "binary literals", "unserscore in literals", "diamond operator" are also valid JRE 6 codes. But multi-catch is wrong. – Deniz Jul 14 '11 at 22:12
  • 13
    Now JDK 7 is officially out and it clearly does not support compiling Java 7 sources to Java 6 class files: `javac -source 1.7 -target 1.6 Test.java` gives `javac: source release 1.7 requires target release 1.7`. I would also be interested in learning why this is the case. – narthi Aug 02 '11 at 08:42
  • 1
    See here: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html – scravy Jul 05 '12 at 08:59
  • "String in switch statement could be implemented using repeated ifeq". Actually for performance it hashes the constant strings and uses the constants in a switch (landing with the if check). This would be difficult for developers to do on their own. – ChrisCantrell Oct 15 '12 at 15:34

2 Answers2

8

I haven't read the code for the compiler, but some of the new features must obviously have an impact on the bytecode.

"Simplified varargs method invocation" is really just a warning suppression, but it must leave some marker in the bytecode so that client code can display warnings differently.

"Try-with-resources" generates code that can handle a normal exception plus a second exception thrown during the finally block. The extra exception is stored using the new addSuppressed() method. This isn't exactly a class-file format change, but it clearly wouldn't work on earlier VMs.

"Multi-catch" also produces bytecode that's subtly different than any previous compiler could produce. Multiple entries in the exception table will now point to the same catch body.

Craig P. Motlin
  • 26,452
  • 17
  • 99
  • 126
0

So let me make sure I understand this. You want to run a specific class in your application against a different JRE then all of your other classes? I suppose this could be theoretically possible if on every use of the class that you don't want to use a different version you spin up a separate JVM. This would involve a level of complexity that is equivalent of passing information between two JVMs in disjoint applications. Out of the box it doesn't work this way because the execution environment in 6 would not know about project coin features. IIRC you can't use generics in a 1.4 runtime, so how is this different? At the end of the day it truly does not seem worth it, then again maybe I missed your point entirely.

Woot4Moo
  • 23,987
  • 16
  • 94
  • 151
  • Agree with Woot4Moo. Why not just recompile on JDK 7 (especially when it comes out end of month)? Why stay on 6? Do you have constraints that you have not specified? Even so, it is probably more work than it is worth. If you want things like String switches, then just code simple if-else statements. They are just as readable and get you what you need in 6. – Chris Aldrich Jul 14 '11 at 20:27
  • 5
    @Woot4Moo - I think you may have misinterpreted the question. It sounded more like the OP wants to use COIN features with a 1.7 *compiler*, while still generating code that could run in a 1.6 *JRE*. @Chris, there are sometimes good reasons to compile for compatibility with an older version of the Java JRE and libraries. – Andy Thomas Jul 14 '11 at 21:03
  • Yes as said by Andy Thomas-Cramer, I want to learn what is the technical reason that I could not compile with 1.7 compiler specifying -target 1.6 and use project coin features. – Deniz Jul 14 '11 at 21:19
  • @Deniz they are two separate run times. How would you expect a car engine to work in a plane? If you compile against Java6 you get Java6 compliance and if you compile against Java7 you get Java7 compliance. The reason why you can compile against multiple versions is there is no guarantee in deployment that everyone will have the same execution environment and you want to be mindful of it. – Woot4Moo Jul 14 '11 at 21:38
  • @Woot4Moo I think your example is not a good one. I perfectly know that I could not do it, but I would like to learn which features from JDK 7 are not backward compatible with JDK 6. From my experiments I could say try with resource, binary literals, underscores in numbers are all ok. A decompiled JDK 1.7 class is perfectly valid JDK 1.6 class. This shows if JDK 7 compiler puts a suitable class version in .class file, they will work in JRE 6. But multi-catch feature is not backward compliant, decompiled class is wrong. Just try to decompile JDK 7 features and see generated codes. – Deniz Jul 14 '11 at 21:51
  • @Deniz like I said as a comment to your original post, JDK7 is not completed yet so once it is released this would be a better question. I think you are making more work for yourself than it is worth, imo – Woot4Moo Jul 14 '11 at 21:53
  • 7
    @Woot4Moo - You have not answered this question, and your presumptions are false. First, it has been both feasible and useful in past versions of Java to compile for an earlier JRE with the -target flag. Second, JDK7 is expected to be released in two weeks, and the final release candidate is available. Speculation is no longer required. – Andy Thomas Jul 14 '11 at 22:08
  • @Andy by all means please answer the OP's question properly, as I have failed to do so. – Woot4Moo Jul 15 '11 at 00:01
  • 1
    @Woot4Moo - I don't know the answer. It's okay to say that. – Andy Thomas Jul 15 '11 at 03:51
  • 1
    If it is any help, I found this documentation: http://download.oracle.com/javase/7/docs/technotes/tools/windows/javac.html. Not sure what the point of this argument/exercise is. It was not apparent you were just trying to figure out how the features compile down compatibly or not. I guess I generally just try to target compiling to the target deployment environment. And if code could run on more than one, we write code that is compliant with an earlier version. And yes, I know you can compile 6 on 7. We have done this before as well. I just don't understand why the arguing here..... – Chris Aldrich Jul 15 '11 at 12:55