Repository navigation
Convert code to Java 7 #1167
Description
Activity
This can be easily done with IntelliJ, which can warn about possible conversions for the new language features.
At least for some language features eclipse can warn too. but well, what about https://www.jetbrains.com/idea/buy/choose_edition.jsp?license=OPEN_SOURCE ? :)
Great, we could use that. I just also learned about the free student licence for IntelliJ. :)
BTW, how can we do that with Eclipse?
Window > Preferences > Java > Compiler > Errors/Warnings
but on a quick look with filter for "1.7" there are only two related warnings. maybe the others are without that info.
OK, i actually realized we cannot produce 1.6 compatible bytecode from 1.7 source... :(
The question is: can we drop Java 6 compatibility? I am really not sure about that because if someone uses
compileSdkVersion(ortargetinproject.properties) lower than API 19, he/she could not depend on our newer class files. Or is that interesting at all? Since dx will convert our API jar anyway to dex, and dx can understand Java 7 bytecode.Unfortunately i made my changes already before realizing the question above. This is the branch. I hope it was not unnecessary work...
I just tested this compiling this with API 10 and deploying onto on API 10 emulator. There were no problems.
@WonderCsabo which jdk did you use to build the test app? i think this change requries the jdk to build the app becomes 7+. might be a breaking change for some devs out there when they still use JDK 6 to build.
I used JDK8, but JDK7 works of course, i am not sure about JDK6. But JDK6 is EOL since 2012 November, nobody should use it.
well thats true. but maybe some companies are slow upgrading. e.g. until early summer this year we still used JDK6 to build most of our projects. and some of our (internal) app servers still are running on jre6...
while i personally would not care for jdk6 anymore, i just wanted to mention the possible breaking change.
Of course, we have to be very careful about this, and thanks for the reminder. I'll try this with JDK6.
BTW AFAIK Java EE 6 is still supported and maintained by Oracle, Java SE 6 is not.
I quickly installed JDK (SE) 6. It seems everything works fine using the artifacts created with 1.7 target.
Right now there seems to be a compiler error in
org.androidannotations.copyannotations.HasOtherAnnotations: The annotation @addressing is disallowed for this location. This error disappears once I switch to Java SE 1.7.I think that annotation was added after i created the PR related to this issue. I rebase the PR and check this out.
@ened i rebased the PR, and i cannot reproduce that issue with JDK7.
However, this is a big breaking change. I just compiled the project with JDK7, then tried to run the
functional-testproject with JDK6. It yielded the expected error:Unsupported major.minor version 51.0.This mean users with JDK6 will not be able to use AA after this change. Using 1.6 target and compiling with JDK7 will work. So this can only be merged to AA 4.0. The questions is, can we drop JDK6 support at all? I think we can, because it is JDK6 is deprecated and end of life anyway.
@WonderCsabo that is what i said some weeks ago. but imo jdk6 can be dropped with 4.0
A few weeks ago nobody really voted against not doing it. Hence I think let's drop it, release 4.0, and finish the case. :-)
@ened Did you manage to build this branch? If i am correct you had some difficulties.
@WonderCsabo using the Java7 setting in Eclipse (Java Build Path), it all worked, tests are running & passing. Using Java 6, it doesn't due to the unknown/unresolvable
@Addressingannotation.OK so it is not a problem since we change to Java 7 here. ☺ Thanks.
BTW maven update project reads the Java version from the Pom and updates the build path automatically.
Merged.
Currently we use Java 6 compatibility in the source code. Newer JDK versions bring some very comfortable features, so we could use a newer source version and convert the code to use those features. We could also use Java 8 as a source version, and produce Java 1.7 compatible bytecode. We could drop JDK 6 compatibility, since JDK is EOL since November 2012...