Community
Participate
Working Groups
The following class fails to compile under Eclipse 3.6, but works fine with Eclipse 3.5 and javac. The methods are distinguished by the different return type, as having the same return type makes javac report two compilation errors as well. bc.. package com.example; import java.util.List; public class ErasureBug { public String output(List<Integer> integers) { return ""; } public void output(List<Double> doubles) { } }
This doesn't compile any longer with JDK7 javac. Srikanth, duplicate of bug 293615 ?
(In reply to comment #1) > This doesn't compile any longer with JDK7 javac. > Srikanth, duplicate of bug 293615 ? This is due to the fix for bug# 273862 (Note: the defect title is missing the word NOT, it should read, " ... should not be used ...") which was made in response to javac behavior change introduced by http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182950. The fix for bug# 273862 special cased the new behavior for compliance level 1.7, but after deliberation, eclipse compiler implemented the new behavior for all compliance levels (via the fix for bug# 289247). The current eclipse behavior is the correct one and so closing this defect as INVALID.
*** Bug 317762 has been marked as a duplicate of this bug. ***
*** Bug 318247 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This is due to the fix for bug# 273862 (Note: the defect title > is missing the word NOT, it should read, " ... should not be used ...") I have since fixed the title.
*** Bug 319342 has been marked as a duplicate of this bug. ***
*** Bug 320514 has been marked as a duplicate of this bug. ***
Verified for 3.7M1
*** Bug 322371 has been marked as a duplicate of this bug. ***
*** Bug 323927 has been marked as a duplicate of this bug. ***
*** Bug 326108 has been marked as a duplicate of this bug. ***
*** Bug 327571 has been marked as a duplicate of this bug. ***
*** Bug 328125 has been marked as a duplicate of this bug. ***
*** Bug 328910 has been marked as a duplicate of this bug. ***
> The fix for bug# 273862 special cased the new behavior for compliance > level 1.7, but after deliberation, eclipse compiler implemented the > new behavior for all compliance levels (via the fix for bug# 289247). > > The current eclipse behavior is the correct one and so closing this > defect as INVALID. Declaring this bug as INVALID does not seem like a proper solution to me. Code that compiles with 1.6 javac should compile in Eclipse with compliance level 1.6. Why can this not be fixed properly? Is there any workaround that can be employed (such as using javac instead of the built in compiler)?
(In reply to comment #15) > Declaring this bug as INVALID does not seem like a proper solution to me. Code > that compiles with 1.6 javac should compile in Eclipse with compliance level > 1.6. Why can this not be fixed properly? Is there any workaround that can be This would be true if this is not a bug in javac 1.6. Are you saying that we should have the same bug in 1.6 compliance as javac has ? This has been fixed and reported as a bug against javac. It has been fixed only in 1.7 stream right now. If Oracle decides to backport it to 1.6 stream, then it won't compile for you as well. We try to keep the same behavior when this is not directly related to a bug.
*** Bug 330434 has been marked as a duplicate of this bug. ***
I dont think you should mark this as invalid. Yes you are addressing a javac bug but you are not really apperciating Eclipse or javac mixed usage in the industry. People will be building code, patching old code etc etc, in Eclipse and deploying with ant builds using javac. Discrepancies in their behaviours causes massive headaches, time and money loss world wide. Perhaps you should actually poll you user base to see what they prefer? But seriously having no switch on this behaviour for pre 1.7 Java source versions is very unprofessional.
(In reply to comment #18) > Perhaps you should actually poll you user base to see what they prefer? But > seriously having no switch on this behaviour for pre 1.7 Java source versions > is very unprofessional. Given that its a javac bug, don't you think its a better to idea to knock on Oracle's door and press them to backport their fix to java 1.6 as well? That way you will no longer have complains against the "correct" Eclipse behaviour.
(In reply to comment #19) Quite frankly no. Is Eclipse a Compiler, and IDE or what? I can't say its being marketed as a compiler. When I point to a JDK version I expect it to use the javac from that, any other action is counter intuitive and wrong. As for bugs, Eclipse seems to allow trailing comas on annotation parameters i.e. @Suite(...,) javac throws this out. javac must be correct here. So what you are actually providing a Java developer with now is a superset of bugs/fixes for two different compilers. This is not a very good thing. No one will be using Eclipse for production or automated builds for starters. Stick to the flagging problems and warnings of the compiler that the user selects, not fudging in patches and add 'other' features that are not in the compiler theye select > (In reply to comment #18) > > Perhaps you should actually poll you user base to see what they prefer? But > > seriously having no switch on this behaviour for pre 1.7 Java source versions > > is very unprofessional. > Given that its a javac bug, don't you think its a better to idea to knock on > Oracle's door and press them to backport their fix to java 1.6 as well? That > way you will no longer have complains against the "correct" Eclipse behaviour.
(In reply to comment #20) This seems to be getting a little off topic. Yes Eclipse has its own compiler. IIRC, javac is not an incremental compiler, and you could not achieve the same level of integration without it. For more information, you'd have to look at the JDT design from pre 2003. > No one will be using Eclipse for production or automated builds for starters. This one baffles me. I know a lot of businesses that choose the Eclipse compiler over javac. In fact, Eclipse is built with the Eclipse Compiler.
(In reply to comment #20) [...] > When I point to a JDK version I expect it to use the javac from that, any other > action is counter intuitive and wrong. > As for bugs, Eclipse seems to allow trailing comas on annotation parameters > i.e. @Suite(...,) javac throws this out. javac must be correct here. Please open a separate bug for unrelated items and we will evaluate them independently. > Stick to the flagging problems and warnings of the compiler that the user > selects, not fudging in patches and add 'other' features that are not in the > compiler theye select The wording of this comment seems to imply that you harbor the notion that eclipse IDE uses javac from the JDK you point it to with some incremental patches/fixes. As a subsequent commenter pointed out, this is not so. Eclipse has its own compiler built from the ground up that has no shared code with javac compiler proper. And it is not our aim to bug compatible with javac.
(In reply to comment #22) So great its even worse then :-) Now I have 2 compilers with different bugs in them. Fantastic. Ok move onto Intellij I guess. In all respects, I want to select the compiler I use. If you want to offer me one please keep it obvious and selectable. All you are doing is adding massive pain, cost to many, many of your users. I doubt you have seen one post thanking you for 'fixing' this? > (In reply to comment #20) > [...] > > When I point to a JDK version I expect it to use the javac from that, any other > > action is counter intuitive and wrong. > > As for bugs, Eclipse seems to allow trailing comas on annotation parameters > > i.e. @Suite(...,) javac throws this out. javac must be correct here. > Please open a separate bug for unrelated items and we will evaluate them > independently. > > Stick to the flagging problems and warnings of the compiler that the user > > selects, not fudging in patches and add 'other' features that are not in the > > compiler theye select > The wording of this comment seems to imply that you harbor the notion that > eclipse IDE uses javac from the JDK you point it to with some incremental > patches/fixes. > As a subsequent commenter pointed out, this is not so. Eclipse has its own > compiler built from the ground up that has no shared code with javac compiler > proper. > And it is not our aim to bug compatible with javac.
(In reply to comment #23) > In all respects, I want to select the compiler I use. > If you want to offer me one please keep it obvious and selectable. As pointed out earlier, the IDE's rich feature set is built on top of and derives directly from having our own compiler. This compiler cannot be substituted/deselected, though ant scripts can use javac if needed.
(In reply to comment #24) In that case I think it is every ones best interest that you, Oracle, and who ever else is developing compilers work together to develop a java compiler compliance kit that ensures you are specification compliant. Clearly its been 15+ years of Java now and neither you or Oracle are yet compliant to the specification. In the meantime myself, team and recommendation to our firm will be to stick to Eclipse 3.5 and address this when we hit Java 7. I can understand why you have done what you did in purity stakes but I cant say it was the best of the 2 evils you had as options for the community. > (In reply to comment #23) > > In all respects, I want to select the compiler I use. > > If you want to offer me one please keep it obvious and selectable. > As pointed out earlier, the IDE's rich feature set is built on top of > and derives directly from having our own compiler. This compiler cannot > be substituted/deselected, though ant scripts can use javac if needed.
> > As pointed out earlier, the IDE's rich feature set is built on top of > > and derives directly from having our own compiler. This compiler cannot > > be substituted/deselected, though ant scripts can use javac if needed. +1 to Liam's comments. If Eclipse's compliance settings are set to 1.6, then the built-in compiler should match javac 1.6 as much as possible. I'm in a shop that uses Eclipse and ant/javac interchangeably. For now, we have to roll back to Eclipse 3.5 to work around this issue . . . that's not an ideal solution for us.
Can't agree more to Liam. I am surprised to hear something like 'to knock oracle's door'. This sounds so unprofessional and irresponsible. Being 'bug compatible' is actually the only choice until you own java and rule the world. If you have any respects to your customers, please think about how to make their works easier(yes you did a great job, thanks a ton) but not harder(like this one). At least we could have a work-around solution like making a flag on your own compiler but not fail else workable projects.
Thanks for everyone who weighed on this issue - we are looking into making this a warning in 1.6- modes. This is likely to be done for 3.7.1.
(In reply to comment #28) > Thanks for everyone who weighed on this issue - we are looking into > making this a warning in 1.6- modes. This is likely to be done for > 3.7.1. Srikanth, thank you so much for addressing this issue!
(In reply to comment #28) > Thanks for everyone who weighed on this issue - we are looking into > making this a warning in 1.6- modes. This is likely to be done for > 3.7.1. This is really a great deal. You guys are always superb.
(In reply to comment #28) > Thanks for everyone who weighed on this issue - we are looking into > making this a warning in 1.6- modes. This is likely to be done for > 3.7.1. Thanks a lot.
Thanks for taking account community feedback on this. That will indeed make our life easier in the classroom.
(In reply to comment #25) > Clearly its been 15+ years of Java now and neither you or Oracle are yet > compliant to the specification. This is not true. We are trying to match the specifications as much as possible. This case is completely different from being compliant with the specifications.
(In reply to comment #33) Surely if we had basic testing of compliance around the compiler we would all be in a far better position? I thought the JDK has some compliance kit? Isn't the compiler part of this? Currently there are simple bugs in javac to do with annotations and commas that Eclipse handles correctly and javac incorrectly. One very simple compliance test could of nipped this in the bud before Java 5. It remains on the Bug list at Oracle now for fix in JDK 7 ... how many years is that? This one simple discrepancy between compilers has caused much time wasted for my team. Multiply that by the teams in the community using both javac and Eclipse and you start to get a picture of the issue. It is not a case of 'were right and there wrong', it is about getting it better for all and anything Eclipse can do to influence this will help the community. > (In reply to comment #25) > > Clearly its been 15+ years of Java now and neither you or Oracle are yet > > compliant to the specification. > This is not true. We are trying to match the specifications as much as > possible. This case is completely different from being compliant with the > specifications.
Ayush, As I am away this week, could you please look at this please ? Ask Olivier for review once the patch is ready.
Well, this looks a bit twisted. The following case does not compile with javac6, even though return types are different package p; import java.util.Collection; import java.util.LinkedHashMap; import java.util.List; public class ErasureBug { public String output(List<String> integers) { return ""; } public void output(List doubles) { return ""; } }
(In reply to comment #36) > Well, this looks a bit twisted. The following case does not compile with > javac6, even though return types are different I guess this is another javac6 bug. I don't see much of a difference in case in comment 0 and in comment 36. In both cases, formal parameters are not equal but their erasures are equal making the methods erasure compatible. We were wrongly compiling this code (comment 36) in Eclipse 3.5 as well, so if we go back to the old behaviour, we still won't be completely compatible with javac6.
Again, running into more javac issues: This does not compile with jacac6: interface J { <T extends Number> T foo(final Number p); Float foo(final Number p); } However this does: class X { <N extends B> N a(A<Number> s) { return null; } <N> Object a(A<Number> n) { return null; } } class A<T> {} class B {} I dont see much difference- return types are different and method parameters are equal. Srikanth, what do you think we should do here?
Created attachment 200641 [details] proposed fix This is the fix i was working on btw. Haven't updated all tests yet
(In reply to comment #36) > Well, this looks a bit twisted. The following case does not compile with > javac6, even though return types are different Sigh. That is the fundamental problem in attempting to be bug compatible. (In reply to comment #38) > Srikanth, what do you think we should do here? What we want to do is match the JDK 1.7 behavior in all cases you cite, except that it should be only a warning in 1.6 compliance. So if that leaves us compiling some code which JDK 1.6 won't, but JDK 1.7 will, that is ok. OIOW, let us not be more restrictive in the scenario at hand than JDK 1.6 when compliance is set to 1.6
Created attachment 200761 [details] proposed fix v1.0 + updated tests Checked most of the tests with javac6 and 7. We do compile some cases where javac6 fails, but I guess thats the best we can do. In 1.7 and 1.5 compliance the patch preserves the old behaviour
Srikanth, please review. Thanks!
(In reply to comment #41) > Created attachment 200761 [details] > proposed fix v1.0 + updated tests > > Checked most of the tests with javac6 and 7. Just so we don't inadvertently introduce some unexpected behavior, could you verify the behavior with all the tests that had to change ? > We do compile some cases where > javac6 fails, Could you confirm that in all these cases, our new bahavior matches JDK 1.7 ?
(In reply to comment #43) > Just so we don't inadvertently introduce some unexpected behavior, > could you verify the behavior with all the tests that had to change ? Yes I meant I checked "all" tests. > > We do compile some cases where > > javac6 fails, > > Could you confirm that in all these cases, our new bahavior matches JDK 1.7 ? Why should the behaviour match JDK 1.7 in 1.6 compliance? The whole point of this bug is to check return types in 1.6 compliance. So the following case would compile with javac7 public interface J { <T extends Number> T foo(final Number p); Float foo(final Number p); } but should not compile in 1.6 compliance since return types differ. (However, it does compile with javac6 on some strange whim).
(In reply to comment #44) > Why should the behaviour match JDK 1.7 in 1.6 compliance? The whole point of > this bug is to check return types in 1.6 compliance. So the following case > would compile with javac7 > public interface J { > <T extends Number> T foo(final Number p); > Float foo(final Number p); > } > > but should not compile in 1.6 compliance since return types differ. (However, > it does compile with javac6 on some strange whim). Sorry there's a mistake in this comment. I wanted to point out the other case class X { <N extends B> N a(A<Number> s) { return null; } <N> Object a(A<Number> n) { return null; } } class A<T> {} class B {} which javac6 compiles but javac7 doesnt. If we align with javac7, we get more restrictive vis-a-vis javac6. Then again people will complain.
Perhaps I'm not too clear. Lets start back at comment 38. Given that both cases are similar in the fact that they have different return types, and same arguments, fixing this issue will mean ECJ with compliance 1.6 will *compile* BOTH cases, while javac6 and 7 will both *reject* the FIRST case. Is this ok? Or if it is not, what is the alternative?
(In reply to comment #44) > (In reply to comment #43) > Why should the behaviour match JDK 1.7 in 1.6 compliance? The whole point of > this bug is to check return types in 1.6 compliance. So the following case > would compile with javac7 What I was suggesting was that where we do differ from JDK 1.6, it would be better if our behavior was grounded in (some version of) reality by matching JDK 1.7 feature. But from the examples you cite, this does look like a utopian goal. So let us skip that point. (In reply to comment #46) [...] > Is this ok? Or if it is not, what is the alternative? I guess we will have to live with it. Can we compare the new behavior on the cases you cite with some version of eclipse before the fix for bug 289247 went in (3.6 M2). So does the new behavior matches eclipse 3.6 on these corner cases ? See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=258658.
(In reply to comment #47) > I guess we will have to live with it. Can we compare the new behavior on > the cases you cite with some version of eclipse before the fix for bug 289247 > went in (3.6 M2). While looking into this fix I believe we may have sidestepped the specs in JLS $8.4.2 which says two methods have same subsignatures if - either they have same signature, or - signature of either of them has same erasure as the other's signature. I don't see this being taken into account in our current implementation in SourceTypeBinding#methods(). We are just checking the "erasure" point, but not the "same signature" point, which entails looking into the type variables, substitutability, etc. So basically I dont understand the logic behind deleting that whole block of code in SourceTypeBinding in Kent's patch - https://bugs.eclipse.org/bugs/attachment.cgi?id=146981&action=diff. One example of this is org.eclipse.jdt.core.tests.compiler.regression.AmbiguousMethodTest.test010a(). Clearly in this the 2 methods have same erasure. Yet we are no longer complaining so. Srikanth, can you please validate my claim?
(In reply to comment #48) > One example of this is > org.eclipse.jdt.core.tests.compiler.regression.AmbiguousMethodTest.test010a(). > Clearly in this the 2 methods have same erasure. Yet we are no longer > complaining so. For the record, javac7 compiles this. So even now we're not compatible it seems :\
Created attachment 200840 [details] proposed fix v2.0 + updated tests This patch more or less reverts the fix for bug 289247 in compliance 1.6. It takes care of the comment 48. However, the test mentioned in comment 48 fails with "duplicate method" error. Javac7 compiles it, as mentioned in comment 49.
To maintain sanity, I suggest that we should address separate issues using different bugs. Let us keep the current one only for the case where we have started reporting name clash/duplicate method error even in 1.6 mode ignoring differences in the method return type. Anyways it is too late in the game for 3.7.1 for us to be looking into a comprehensive overhaul of this area. Having looked at both the patches, I am inclined to go with the first one. It looks simpler and all it is basically doing is to make the error a warning in 1.6 mode if the clashing method differ in return type. I think given how many duplicates have come about, we should verify that the patch addresses every single case of duplicate of this bug. After releasing the focused fix, we can have follow up defects that can be investigated for 3.8. I'll spend some more time with the first patch and share comments if any.
I reviewed the code changes in proposed fix v1.0 and it looks good to me. Here are a couple of comments: Source type binding: (1) The variable complyTo15 is better named complyTo15OrAbove. (2) The variable severity should be initialized inside the loop, inside of outside. I didn't review the changed tests per se, since per comment 41 and comment 44, these have been validated against versions of javac compiler. For the cases where we still differences, please raise follow up defects. Please verify against all the duplicates to make sure they are all fixed. If all of this looks good, it is ready for release.
(In reply to comment #52) > Please verify against all the duplicates to make sure > they are all fixed. If all of this looks good, it is ready for > release. I checked against all the duplicates and 9/11 work ok. https://bugs.eclipse.org/bugs/show_bug.cgi?id=317762 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=327571 needs to be looked into. The former is a variant of one of the exceptions you have cited already I believe. In the latter case, the name clash is gone, but we report the call as being ambiguous (even in 1.7 mode) - needs to be looked into see if this is reasonable. Now that the virulent strain of this bug is addressed by this patch, let us release it with new junits for the duplicates and reopen bug 317762 and bug 327571 targetting them for 3.8
(In reply to comment #53) > (In reply to comment #52) > > Please verify against all the duplicates to make sure > > they are all fixed. If all of this looks good, it is ready for > > release. > > I checked against all the duplicates and 9/11 work ok. > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=317762 and > https://bugs.eclipse.org/bugs/show_bug.cgi?id=327571 needs > to be looked into. https://bugs.eclipse.org/bugs/show_bug.cgi?id=327571 was not really a duplicate, but was mistagged (and has since been reopened.) So the patch fixes 9/10 duplicates and the original.
(In reply to comment #54) > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=317762 and Mea culpa. Even this is fixed by the current patch. So we are all set to go. Thanks Ayush. Sorry for the noise.
Created attachment 201125 [details] final patch patch taking care of the review comments and adding all dups as regression tests.
Created attachment 201129 [details] patch updated for HEAD
Released in HEAD for 3.8M2 and in R_3_7_maintenance for 3.7.1
.
IMHO, the test case given in comment 36 should be fixed. Filed bug 355838 to track this.
Verified for 3.7.1 RC2 using build M20110824-0800
Verified for 3.8M2 using build id: I20110912-0800
*** Bug 379794 has been marked as a duplicate of this bug. ***
Hello the problem happens again in Version: 4.3.1. public static double[] extractScore(List<Token> tkl) { double [] s=new double[tkl.size()]; for (int i=0;i<s.length;i++) { s[i]=tkl.get(i).getScore(); } return s; } public static double[][] extractScore(List<ArrayList<Token>> tkll) { double [][] s=new double[tkll.size()][]; for (int i=0;i<s.length;i++) { s[i]= new double[tkll.get(i).size()]; for (int j=0;j<s[i].length;j++) { s[i][j]=tkll.get(i).get(j).getScore(); } } return s; } it appears: Method extractScore(List<ArrayList<Token>>) has the same erasure extractScore(List<E>) as another method in type Token
