• Type: Task
• Component: javafx
• Sub-Component: other

• Priority: P4
• Status: Resolved
• Resolution: Delivered

• Submitted: 2022-06-28
• Updated: 2024-04-01
• Resolved: 2022-08-03

Other
jfx20Resolved

Reopening to closed as "Delivered" since there isn't a commit associated with this task. 03-08-2022 Please refer to the screenshots for the resulting configuration in Preferences -> Java -> Compiler -> Errors/Warnings. 03-08-2022 all subtask have been resolved. 03-08-2022 > Most of the above list would be pretty far down on my list of things I'd want to spend time on I think that these fixes are simple enough that 1 reviewer is enough, and I can review it in batches. 07-07-2022 Other than the unused imports, I am unconvinced that they should be done at all. 07-07-2022 Most of the above list would be pretty far down on my list of things I'd want to spend time on (review cycles more than the development of the fix). > * unused imports: 1,369 errors This seems reasonable. Removing unused imports is at least pretty easy to do and to review, so maybe during an otherwise slow time (e.g., after RDP2 of JavaFX 19). > * unused method arguments: 681 errors I suppose there might possibly be something actionable here (unlikely), but I don't like the idea of cluttering the code with annotations, which we would need to do to shut up the warnings, so probably not. > * accessing a static member through an instance (== indirect access to static member): 480 errors I don't see the point of cleaning up accesses to static methods through an instance. > * non-static access to static member: 312 errors How is this different from the previous? > * methods can be static: 744 errors I wouldn't support refactoring to change instance methods to static. 06-07-2022 [~mhanl]: created JDK-8289845 06-07-2022 Fixing unused imports might be a good idea as well. I think in the jdk project that is normally done on a module basis, e.g. fix unused imports for fxml module, to avoid very big PRs. 06-07-2022 [~nlisker]: I would, on the contrary, suggest to leave these be. There are too many places, fixing them all would require touching thousands of files. On top of that, these are not really bugs, only 'unused method arguments' can be categorized as wasting resources. * unused imports: 1,369 errors * unused method arguments: 681 errors * accessing a static member through an instance (== indirect access to static member): 480 errors also: * non-static access to static member: 312 errors * methods can be static: 744 errors 05-07-2022 Eclipse allows you to configure the severity of its problems, so different Eclipse users will get different errors and warnings. It is a good idea to fix Eclipse's specific warnings (that are not reported by javac) because they hint at real problems. I avoided creating PRs for this because it would take a lot of review time, but if you submit the PRs for these then I can be the reviewer. I would also add issues for fixing warnings for * unused imports * unused method arguments * accessing a static member through an instance Some fixes will require adding an Eclipse-specific "ignore warning" annotation. I don't think we can submit those into the repo, so it might not be possible to resolve all warnings. Note that fixing warnings by type might be difficult because the fix will touch files all over the repo, some of which could conflict with current work. We might need to divide by modules or projects, depending on the files affected. 03-07-2022