You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2023. It is now read-only.
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...
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 (or target in project.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.
@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.
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.
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.
@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-test project 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 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 @Addressing annotation.
Activity
WonderCsabo commentedon Oct 28, 2014
This can be easily done with IntelliJ, which can warn about possible conversions for the new language features.
dodgex commentedon Oct 29, 2014
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 ? :)
WonderCsabo commentedon Oct 29, 2014
Great, we could use that. I just also learned about the free student licence for IntelliJ. :)
BTW, how can we do that with Eclipse?
dodgex commentedon Oct 29, 2014
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.
WonderCsabo commentedon Nov 8, 2014
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.@DayS @yDelouis WDYT?
[-]Convert code to Java 7 (or 8)[/-][+]Convert code to Java 7[/+]WonderCsabo commentedon Nov 8, 2014
Unfortunately i made my changes already before realizing the question above. This is the branch. I hope it was not unnecessary work...
WonderCsabo commentedon Nov 9, 2014
I just tested this compiling this with API 10 and deploying onto on API 10 emulator. There were no problems.
dodgex commentedon Nov 20, 2014
@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.
WonderCsabo commentedon Nov 20, 2014
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.
dodgex commentedon Nov 20, 2014
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.
WonderCsabo commentedon Nov 20, 2014
Of course, we have to be very careful about this, and thanks for the reminder. I'll try this with JDK6.
WonderCsabo commentedon Nov 20, 2014
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.
ened commentedon Dec 6, 2014
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.WonderCsabo commentedon Dec 6, 2014
I think that annotation was added after i created the PR related to this issue. I rebase the PR and check this out.
WonderCsabo commentedon Dec 6, 2014
@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.
@yDelouis @DayS WDYT?
dodgex commentedon Dec 6, 2014
@WonderCsabo that is what i said some weeks ago. but imo jdk6 can be dropped with 4.0
ened commentedon Dec 7, 2014
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. :-)
WonderCsabo commentedon Dec 7, 2014
@ened Did you manage to build this branch? If i am correct you had some difficulties.
ened commentedon Dec 8, 2014
@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.WonderCsabo commentedon Dec 8, 2014
OK so it is not a problem since we change to Java 7 here. ☺ Thanks.
WonderCsabo commentedon Dec 8, 2014
BTW maven update project reads the Java version from the Pom and updates the build path automatically.
yDelouis commentedon Jun 10, 2015
Merged.