Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: 20090619-0625 Eclipse seems to overload "unchecked" warning suppression to also suppress raw uses of parameterized classes. Javac doesn't issue a warning in this case so there's nothing to suppress. However this does pose an issue when working with other IDE's as they will complain about the use of a raw parameterized class. The following snippet illustrates the difference: public class Foo<T> { //This is unchecked assignment //and should be suppressed using "unchecked" //This will appear as a warning in javac Foo<T>[] a = new Foo[10]; //This is raw use of a paramterized type //Not suppressed in javac using "unchecked" //This will NOT appear as a warning in javac Foo[] b = new Foo[10]; } The workaround is to declare b with a wildcard, e.g.: Foo<?>[] b = new Foo[10]; Reproducible: Always
@SuppressWarnings("unchecked") is not documented to have any effect on raw type warnings. We should add @SuppressWarnings("raw") for raw types warnings.
Created attachment 147814 [details] Proposed fix + updated regression tests
Markus and Daniel, I believe we should split @SuppressWarnings("unchecked") into @SuppressWarnings("unchecked") and @SuppressWarnings("raw"). @SuppressWarnings("unchecked") would be reserved for unchecked warnings and @SuppressWarnings("raw") would be used only for raw type references.
Created attachment 147827 [details] Same patch that includes jdt.ui.tests patch
Adding @SuppressWarnings("unchecked") on a class will hide all real unchecked warnings issues as well as raw warnings issues. People using a 1.5 framework might want to get rid of raw warnings, but "fix" all unchecked warnings. If existing code has new warnings, then there is a quickfix for them or the warnings can be "fixed".
(In reply to comment #3) I would fully agree if this was the release in which we introduced "unchecked". The problem is that we supported "unchecked" for raw types for a long time, (bug 89529 comment 9) and changing it now means that users need to update their codebase. And if their team uses Eclipse 3.5 and 3.6, they can't even get a clean table any more. I wanted to suggest that we add "raw" now, but wait for 3.7 to stop accepting them with "unchecked". But then I found that JDK7 will probably use @SuppressWarnings("rawtypes") for that, see the link in bug 253663: http://blogs.sun.com/mcimadamore/entry/diagnosing_raw_types
*** Bug 253663 has been marked as a duplicate of this bug. ***
I don't have any problem by using "rawtypes" instead of "raw" for the @SuppressWarnings token. I understand that this might require users to add additional SuppressWarnings annotation, but changing it now will prevent them from doing it when the codebase is even bigger. The sooner, the better.
I agree with most that has been said so far i.e. we want to separate this but we also have to consider the migration path. Here's what Markus and I discussed would be a good path for 3.6: - we no longer suppress raw when "unchecked" is used - we introduce "rawtypes" for that - we encourage people to fix their code - for those that do not or cannot fix the additional warnings that they get we offer an environment variable that can be set on start up, e.g. -vmargs -DsuppressRawWhenUnchecked=true - we will document this in the migration guide Of course we will also have to adjust the UI code to this change.
(In reply to comment #9) > - we no longer suppress raw when "unchecked" is used > - we introduce "rawtypes" for that I'll update the patch for this. I used "raw" for now. > - for those that do not or cannot fix the additional warnings that they get we > offer an environment variable that can be set on start up, e.g. > -vmargs -DsuppressRawWhenUnchecked=true I don't see the point. Why would it be a problem to "fix" the additional warnings? The UI provides a quickfix and the quickfix to add the @SuppressWarnings("rawtypes") works without any changes in the UI. However I'll prepare a patch that contains this property. I just would like to understand what use case requires that property to be added. > - we will document this in the migration guide Good. > Of course we will also have to adjust the UI code to this change. The previous patch contained the changes for the UI tests. I'll update it as well to use "rawtypes" instead of "raw".
>I don't see the point. Why would it be a problem to "fix" the additional >warnings? Two reasons: 1. some teams working on the same code might not be able to use the latest eclipse version (in this case even no final version yet) and if the warning is fixed in HEAD then those working with an older version will get a warning for unknown @suppressWarning tag. 2. some teams might might not have time to fix the warnings
Created attachment 147902 [details] Proposed fix + updated regression tests Patch that addresses most of the points in comment 9. >- we no longer suppress raw when "unchecked" is used Done >- we introduce "rawtypes" for that Done >- we encourage people to fix their code Not done. I guess this is done in the migration guide. >- for those that do not or cannot fix the additional warnings that they get we > offer an environment variable that can be set on start up, e.g. > -vmargs -DsuppressRawWhenUnchecked=true Done. >- we will document this in the migration guide Not dome. The migration guide will be updated separately. Markus, could you please take care of releasing the jdt.ui.tests part of the patch? Thanks.
> Markus, could you please take care of releasing the jdt.ui.tests part of the > patch? Released, thanks for the patch.
Released for 3.6M3. Updated existing tests.
Thanks for the quick fix. I've filed bug 290361 to track the JDT UI work. >The migration guide will be updated separately. Do you have a log for that somewhere? If not, it makes your life harder near the end of the release or you might miss an entry. Also, people using 3.6 builds might run into this and would be happy to get some information in the migration guide. I've prepared the JDT migration guide for 3.6.
> >The migration guide will be updated separately. The entry should also tell that projects need to be manually cleaned and rebuilt after toggling the property.
Verified for 3.6M3 using build I20091025-2000.
Any chance to support @SuppressWarnings("rawtypes") in 3.5.2 to ease the adoption of the change and to make this less confusing when people are using 3.5 and 3.6 in parallel? If you write code in 3.6 now, developers using 3.5 get (imho) invalid warnings now: Unsupported @SuppressWarnings("rawtypes") Class is a raw type. References to generic type Class<T> should be parameterized
