Community
Participate
Working Groups
The following code compiles with the Eclipse JDT compiler and the Oracle 1.7 compiler but fails with the Oracle 1.6 compiler. @SampleAnnotation({"a", "b",}) public class SampleClass { } The problem is the trailing comma in the element value array initializer. Checking section 9.7 of the JLS [1] the production rule is ElementValueArrayInitializer: { ElementValuesopt ,opt } which leads me to believe the code is legal and this is a compiler bug fixed in the Oracle 1.7 compiler. This is a bit nasty because you can write code that compiles fine in Eclipse but will later fail to compile on the CI server that uses the Oracle compiler. If I read [2] correctly the compiler compliance setting is exactly intended for cases like this. [1] http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.7 [2] http://eclipseandjazz.blogspot.com/2011/11/of-compliance-and-source-settings-in.html
Created attachment 207265 [details] SampleAnnotation.java
Created attachment 207266 [details] SampleClass.java
> If I read [2] correctly the compiler compliance setting is exactly intended for > cases like this. Yes, it is. Although we prefer to change compliance-wise setting when a behaviour changes for a newer version of java and we change eclipse compiler accordingly, so as to not break existing clients. In this case, we will have to buggify eclipse compiler to make it compatible to an old buggy javac behaviour. I do agree with your problem of cross-compiling though, and so I think it should be considered for a fix. Srikanth, what do you think?
(In reply to comment #3) > > If I read [2] correctly the compiler compliance setting is exactly intended for > > cases like this. > > Yes, it is. Although we prefer to change compliance-wise setting when a > behaviour changes for a newer version of java and we change eclipse compiler > accordingly, so as to not break existing clients. In this case, we will have to > buggify eclipse compiler to make it compatible to an old buggy javac behaviour. > I do agree with your problem of cross-compiling though, and so I think it > should be considered for a fix. > > Srikanth, what do you think? See also bug 112433 and all its numerous duplicates. The compliance setting is meant to be used to match up with javac behavior in areas where the spec was found in hindsight to be fuzzy, unclear, ill specified, subject to interpretation to begin with etc and was later clarified. It is not meant to be used to be bug compatible with javac. (See that even within a build stream say JDK6, javac behavior changes at various points, so there is no way to be compliant with all JDK6 builds with a single control). We don't want to introduce blatant bugs to be compatible with javac. Doubly so it that would mean we would stop compiling code that we used to compile. i.e the relaxing case at least is open for consideration, not the tightening case. Closing as WONTFIX.
If you have an issue with Oracle compiler, simply remove the trailing comma. I agree with the resolution.
Verified for 3.8M4 using build I20111202-0800
