Community
Participate
Working Groups
There are a number of classes the have warnings involving ArrayList as a raw type. Updates classes so warning is removed.
(In reply to comment #0) > There are a number of classes the have warnings involving ArrayList as a raw > type. Updates classes so warning is removed. I will work on this for the initial code sprint.
Created attachment 148117 [details] Fix for ArrayList Warnings Changes remove ArrayList Warnings.
Applied the patch. It only fixed some of the ArrayList warnings. However, the type of warning also affects Enumerations, HashMap, HashSet, Iterator, List, Map, and Set... I will try and make a new patch to address all the raw type / generic reference warnings across the board.
The "fix" for this bug (aka declaring the generic types being used), may break backwards compatibility, no? They only introduced this in a semi-recent version of java. I have a 1.6 JDK and I see the warning, but Miles is on 1.5 (we think) and when he applied the patch it was showing up with errors..
Created attachment 156332 [details] Patch to address various warnings Adding a patch to address a number of warnings flagged in eclipse including.. - Declaring generic reference types (the noted ArrayList warnings as per this bug) - Cleaned up unused imports (eclipse also auto formatted some too) - Added some @suppresswarnings for a couple cases. We may need to address some of the suppressed warnings where we declare a specific reference type for an object, but the function calls unbound code so get a new, unchecked type warning. (Ideally, I think the calling code should declare the type and make them all compatible, but the code is from the eclipse framework which we have no control over...). Also added some suppressed warnings on apparently "unused" code, but it seems to be used (just not called locally from our code) so I think eclipse may be wrong in this case. Some warnings remain, I'm unsure what to do with the deprecated warnings... I'm guessing theres a good reason why we are still using the deprecated functions that remain.
Setting this as a blocker for Bug 300017.
Will apologies to Dwight, Cory, and Dennis, I'm closing this bug as INVALID. Frankly, the fixes suggested--while good--aren't really addressing the root problem. The root problem is that all of the classes we're patching are using internal code. I'd rather try to address the root problem.
A +1 from me to get to the root problem. So do we try to influence the JDT so we can subclass or roll out our own code?
(In reply to comment #8) > A +1 from me to get to the root problem. So do we try to influence the JDT so > we can subclass or roll out our own code? I need to look harder at what we're trying to do. I spent a few minutes looking at LiteLaunchShortcutsAction. It occurred to me that we probably should reconsider how we're presenting this to the user... Currently, it manifests as "Run as > Java Application" in the pop-up menu. Shouldn't this just be "Run"? While the submenu makes some sense in a generic Eclipse context, it seems a little cumbersome for our purposes. So it's not just a matter of redoing what the JDT does. At least in some cases, I think we want to do things differently. Frankly, I think we should be able to build a customized launcher using only public API. If we can't then we need to push on Platform/JDT to make it so we can. As I look at these issues, I'll open specific bugs. In the meantime, if we can--at least temporarily--live with the current fork of JDT code, I think we can live with the compiler warnings.
