Community
Participate
Working Groups
Out of the box, Eclipse generates many compiler warnings that are not found when using javac.exe. For example, complaining about the usage of raw types. Just because List is now generic, doesn't mean that all references to it should be parameterized. In fact, it is often the case that collections contain Objects. "Correcting" my code so that it reads: List<Object> list; is about as useful as: String message = (String)"hello"; I think it's fine if Eclipse wants to support its own types of warnings, but the default settings should produce the same warnings as javac, such that code which compile clean outside of eclipse, compiles clean when imported into a new workspace.
This warning got enabled after a poll was conducted on jdt-core-dev and newsgroup. Also it was referenced as bug 159456. This very warning is to help migrating to generics, as opposed to only helping addressing the type safety issues. Unchecked warnings are only showing the secondary bad effects of using raw types. The raw type warning is more useful for detecting the origin of the problem. Also the spec clearly discourages from using raw types, and even mentioned these could be banned in the future. Also note that List<Object> is not equivalent to the raw List. Re: defaults matching javac. I disagree. Javac picks the warnings it finds relevant, and we do the same. Now, you can always turn off some annoying warnings if you need.
No further action planned.
I just thought I would take a shot at suggesting "warning parity" with javac. I can only assume that "error parity" with javac is a rule. In other words, JDT must not generate errors if javac does not generate errors. As far as my example, List and List<Object> is like Integer vs. String. If I need a List<Object>, I should know that and I'll use it when necessary. Otherwise, I'll just use "List", because that's all I need, and it's easier to read. Anyway, I understand the argument of being better/different than javac. However, my feeling on polls is that you generally get more input from the people who want things to change, and less from people who are happy the way things are (or don't even understand the question ;-). thanks.
I agree that polls are somewhat biased, but I just wanted to say that it got discussed a while ago in the open, before we enabled this warning by default. Re: parity with javac We usually try to match the language spec than javac. In case of discrepancies, this is more tricky (need to find out which is right/wrong). The spec describes error situations, and mandates only very few warnings (unchecked mostly).
Verified for 3.4M2 using build I20070917-0010
