Community
Participate
Working Groups
Hi, Take the following code: class Test { private int privateField; public abstract static class GenericClass<V extends Test> { abstract V m(); public void f() { V v = m(); v.privateField = 3; } } } If compile with ecj-4.7M3, it compiles without error with -source 1.5 and -source 1.6 but starts to fails from -source 1.7: $java -jar ecj-4.7M3.jar -source 1.7 -nowarn -cp rt.jar Test.java ---------- 1. ERROR in Test.java (at line 10) v.privateField = 3; ^^^^^^^^^^^^ The field Test.privateField is not visible ---------- 1 problem (1 error) With a javac of a JDK starting from 1.7, the error is raised whatever the source level: $javac-7 -source 1.6 Test.java warning: [options] bootstrap class path not set in conjunction with -source 1.6 /ssd/jmhenaff/workspace/eclipse-46-ub-jack-3/ZZTop/src/Test.java:10: error: privateField has private access in Test v.privateField = 3; ^ 1 error 1 warning But, if an older JDK is taken, the error disappears. These links show it is considered a bug to let it pass: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6246814 https://bugs.openjdk.java.net/browse/JDK-7072895 And this page specifies the change of behavior of JDK 7 and above about this: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html (Ctrl+F "Compiler No Longer Allows Access to Private Members of Type Variables") So I just wanted to know whether it can be considered a bug that ecj continues let this error pass for source level below 1.7, or if it is intended for compatibility matters. Thanks.
Thanks for your comprehensive research. The current situation is deliberate, see bug 334622. It is our common strategy: whenever we copy a javac bug into ecj for compatibility, we keep it for all compliance level corresponding to a buggy version of javac. There is no way to distinguish compatibility modes to mimic your choice of: - javac version 1.5, and - javac version 1.7 with -source 1.5. If javac of version 1.5 had the bug and there is no service release fixing the bug, then that is the behavior we mimic at -1.5. The assumption is: if you really need to stay at an older version, then you should be using that version of JDK anyway. (Aside: it's painful enough having to manage another implementation's bugs, too)
