Community
Participate
Working Groups
3.5 As a follow up of bug 239066, some UI work is indeed to surface the new compiler warning. fyi: Added a new compiler warning to signal absence of synchronized modifier when overriding a synchronized method. This diagnosis is controlled by option: JavaCore.COMPILER_PB_MISSING_SYNCHRONIZED_ON_INHERITED_METHOD and produces a problem marker which ID is IProblem.MissingSynchronizedModifierInInheritedMethod problem ID. Compiler option ID: Reporting Missing Synchronized Modifier On Inherited Method. When enabled, the compiler will issue an error or a warning if a method overrides a synchronized method without having a synchronized modifier. Option id: "org.eclipse.jdt.core.compiler.problem.missingSynchronizedOnInheritedMethod" Possible values: { "error", "warning", "ignore" } Default: "warning" This should appear in Potential Programming Problems section.
Will take this one if nobody disapproves.
Sure, thanks.
A quick fix would also be nice (and easy to add, see ModifierCorrectionSubProcessor#addNonFinalLocalProposal(..) for a template).
Yep, I already have a quick fix for that somewhere in my workspace ;-) I opened a seperate issue for that request. See bug 245250
Created attachment 110978 [details] patch Here is the patch to support the new compiler warning in the ui. One thing which bothered me are the missing tests for this kind of stuff. The only thing I can see is the PreferencesTest which seems to be completely broken. Does anybody really uses these tests? I could imagine to have a test which compares ProblemSeverityBlock#getKeys with the JavaCore constants to see if UI doesn't forget anything. But I think the two are just too different to have a generic test case for that scenario.
Thanks, released to HEAD (and fixed copyright headers). We currently don't have tests for this mapping, although it would maybe be interesting to see missing preferences.
> I could imagine to have a test which compares ProblemSeverityBlock#getKeys with > the JavaCore constants to see if UI doesn't forget anything. But I think the > two are just too different to have a generic test case for that scenario. I added such a test, see OptionsConfigurationBlockTest in HEAD.
