Community
Participate
Working Groups
See also bug 348492 - For the following snippet in 1.5 mode eclipse compiler says - "Incorrect number of arguments for type ArrayList<E>; it cannot be parameterized with arguments <>" - On the other hand javac says - "diamond operator is not supported in -source 1.5. use -source 7 or higher to enable diamond operator" => JDT compiler should also do the same for the same reasons mentioned in bug 348492. ------------------------------------------------------------------- package org.eclipse; import java.util.ArrayList; import java.util.Iterator; import java.util.List; class Diamond { void foo() { List<String> a= new ArrayList<>(); } public static void main(String[] args) { new Diamond().foo(); } } -------------------------------------------------------------------
Not too inclined to touch this one :)
As a user of 1.7- java, it is better that a user gets the message that Eclipse is showing now, rather than telling that diamond is not supported! Hence resolving it as WONTFIX.
(In reply to comment #2) > As a user of 1.7- java, it is better that a user gets the message that Eclipse > is showing now, rather than telling that diamond is not supported! > Hence resolving it as WONTFIX. Actually, if I were a 1.7 programmer, I would expect the latter message as javac. Nevertheless, if someone has set the level as 1.5, then we have to assume he/she has done it on purpose. So, the current message is alright. Verified.
What's unfortunate about the current situation is that with compliance 1.5, the following line produces 2 errors that look exactly the same: List<> b= new ArrayList<>(); The first problem is a real problem, but the second one is easy to fix. We would like to show a quick fix for the second problem (switch to 1.7), but we can't currently do this, because we would need to analyze the AST to find out if the problem is quick-fixable. Creating ASTs there is a no-go.
(In reply to comment #4) > We would like to show a quick fix for the second problem (switch to 1.7), but > we can't currently do this, because we would need to analyze the AST to find > out if the problem is quick-fixable. Creating ASTs there is a no-go. Ayush, Let us take another look. Please mark me as reviewer. TIA.
Created attachment 199143 [details] proposed fix v1.0 + regression tests I've changed the IsDiamond bit setting to be done in source less than 1.7 as well, so that when in less than 1.7 mode, we come across a diamond usage we can reject it using a new warning "'<>' operator is not allowed for source level less than 1.7".
Srikanth, please review.
Created attachment 199163 [details] Simpler patch Is this simpler ? If <> is used in 1.6-, we report an error and continue to consider it as diamond.
(In reply to comment #8) > Created attachment 199163 [details] [diff] > Simpler patch > > Is this simpler ? If <> is used in 1.6-, we report an error > and continue to consider it as diamond. It is simpler, but prone to side effects. Keeping the diamond flag raised for the AST node in 1.6- and treating it at par with the 1.7+ modes may run into issues. I havent tested yet, but won't it also lead to the inference mechanism kicking in for 1.6- also? I can already see 1.7 warnings such as "'<>' cannot be used for anonymous types" finding their way into 1.6-. Why is this needed? I think we should preserve all existing behaviour, but just make sure that there's a new warning for 1.6- as done in the previous patch. There every diamond usage is guarded with a compliance check, so we're safe.
(In reply to comment #9) > (In reply to comment #8) > > Created attachment 199163 [details] [details] [diff] > > Simpler patch > > > > Is this simpler ? If <> is used in 1.6-, we report an error > > and continue to consider it as diamond. > > It is simpler, but prone to side effects. Keeping the diamond flag raised for > the AST node in 1.6- and treating it at par with the 1.7+ modes may run into > issues. Déjà vu all over again :) This is standard compiler error repair strategy and I can't think of any ill effect due to this. When compiling the following program in 1.4- modes: import java.util.ArrayList; public class X { ArrayList<Y> ay = null; } Having complained "Syntax error, parameterized types are only available if source level is 1.5 or greater", we don't throw the type arguments and don't start treating ArrayList as a raw type as evidenced by the fact that we complain about Y. >When compiling this > I havent tested yet, but won't it also lead to the inference mechanism > kicking in for 1.6- also? I can already see 1.7 warnings such as "'<>' cannot > be used for anonymous types" finding their way into 1.6-. Why is this needed? There are two factors here: A compiler should report as many errors as possible while taking to make sure earlier errors don't result in a cascade of secondary errors. In this case, the two errors are orthogonal, so why won't we report them ? Secondly, if we don't resort to these error repair strategies, the compiler code will be littered all over the place with source level/compliance level checks rendering it a nightmare to work with. (in your original patch, you are checking source level in 16 _new_ places, while the alternate patch checks for source level in 2 new places) As a further example see https://bugs.eclipse.org/bugs/show_bug.cgi?id=348402#c5 Why are we complaining about type parameter bounds check in 1.4- modes ? >I think we should preserve all existing behaviour, but just make sure that > there's a new warning for 1.6- as done in the previous patch. There every > diamond usage is guarded with a compliance check, so we're safe. Let me know if you think of some interesting cases that show a problem. As things stand, this patch is significantly simpler (8 modified files vs 15 in the original, apart from that is also structurally simpler in that error handling is centralized and more regular in that it is the same set of changes applying to multiple places) and so is worth considering. BTW, I didn't run all the tests. Only the generics tests were run.
Committed above patch to BETA_JAVA7 branch
(In reply to comment #11) > Committed above patch to BETA_JAVA7 branch Released patch was the one in comment 8
