Community
Participate
Working Groups
Created attachment 278787 [details] Reproducer See attachement, compare output of `mvn clean install` (javac) and `mvn clean install -Decj.version=3.17` (ECJ). You can also see the logs of both commands on Travis: https://travis-ci.com/yrodiere/eclipse-bugs/builds/113604107
Could you please try with ecj 3.18 (4.12 release M3 or RC1).
(In reply to Yoann Rodiere from comment #0) > See attachement, compare output of `mvn clean install` (javac) and `mvn > clean install -Decj.version=3.17` (ECJ). My apologies, the actual command to compile using ECJ is: `mvn clean install -Decj.version=3.17.0`.
org.eclipse.jdt:ecj:3.18.0 is not available on Maven central.
(In reply to Yoann Rodiere from comment #3) > org.eclipse.jdt:ecj:3.18.0 is not available on Maven central. It is now, but the result is the same with 3.18.0: https://travis-ci.com/yrodiere/eclipse-bugs/jobs/230982845
The problem occurs since ecj version 3.6.0. JLS §6.6.1 is very clear on this: "Otherwise, the member or constructor is declared private, and access is permitted if and only if it occurs within the body of the top level type (§7.6) that encloses the declaration of the member or constructor." In fact we allow the following definition of a member of PrivateConstantBug: String myConst = InnerClass.CONSTANT; Thus the bug is specific to field references used inside an annotation.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
The problem is still present in ECJ 3.26.0. With the attached reproducer: > mvn clean install -Decj.version=3.26.0 > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile (default-testCompile) on project jdk-bugs: Compilation failure > [ERROR] /home/yrodiere/workspaces/testcases/eclipse-playground/src/test/java/org/hibernate/eclipse/bugs/privateconstant/PrivateConstantBug.java:[10,292] The field PrivateConstantBug.InnerClass.CONSTANT is not visible
The code that causes trouble is in Scope#findField() which for some reason considers "insideTypeAnnotations" in determining whether or not the invocation site can see/access the field. This code was introduced by bug 316456 first. If you are wondering why insideTypeAnnotations is true, then that seems to be the effect of SourceTypeBinding.initAnnotationTagBits(). This was more recently added for bug 551426. Stephan, probably you have some idea about this?
Clarification regarding the name insideTypeAnnotations: this is not about TYPE_USE annotations, but about an annotation on a type declaration. In bug 316456 we had that problem that a field reference inside a member-value pair of such an annotation could illegally see private members of the type being annotated. Illegal, because the annotation is not "within" the type, where private members are visible. Perhaps, all this could have been resolved by resolving the annotation in the enclosing scope not the current class scope - but then I'm not sure if that would break legal access to non-private inherited members. So, it was decided to introduce this flag, which in a way signals, we're in this type, but not within its body. Considering insideTypeAnnotations within Scope.findField() is the original business of bug 316456, but I see us jumping to a wrong conclusion: if the flag is true, we completely ignore currentType and directly jump to the package assuming that the field must be visible within the package. This is wrong in the case of a nested type. Before consulting visibility to the package we must check visibility to the enclosing type. One question remains: is the enclosing type relevant for static and non-static nested types alike? I don't see bug 551426 being relevant here, it just "re-structured the code a bit". The general logic we present before. As a matter of style: I really would have to dig into the spec to be sure how this pattern (in Scope.findField) is evaluated: if (x || y ? s : t) I suggest to add a pair of parens for readability :)
