Community
Participate
Working Groups
Most of the platform components have moved or are in the process to move to Java 1.5 or Java 1.6. I suggest to move org.eclipse.ui.ide also to Java 1.6 (or at least to Java 1.5).
Advantages are the typical ones: 1.) Use annotations 2.) Use enhancement for loop 3.) ....
https://git.eclipse.org/r/#/c/19243/
If we move, I suggest to move to the same level as the other UI bundles, which is currently 1.5, I think. Also, I'd expect that we don't get any warnings in the official build.
(In reply to Dani Megert from comment #3) > If we move, I suggest to move to the same level as the other UI bundles, > which is currently 1.5, I think. > > Also, I'd expect that we don't get any warnings in the official build. Agree to 1.5, I update to the Gerrit review. With regards to warnings, there are already warnings in the official build if I see it correctly. For example "Missing Javadoc" in GotoActionGroup or "Deprecated" warnings.
(In reply to Lars Vogel from comment #4) > With regards to warnings, there > are already warnings in the official build if I see it correctly. No, there are only warnings in the *.e4.* bundles (which should get fixed too ;-). See e.g. http://download.eclipse.org/eclipse/downloads/drops4/N20131202-2000/testResults.php
> No, there are only warnings in the *.e4.* bundles (which should get fixed > too ;-). See e.g. > http://download.eclipse.org/eclipse/downloads/drops4/N20131202-2000/ > testResults.php This would be the equivalent of the "Problems" view, right? I also don't see any warnings here (also after the change to Java 1.5). But the Package Explorer shows warnings, examples see https://bugs.eclipse.org/bugs/show_bug.cgi?id=423025#c4
(In reply to Lars Vogel from comment #6) > > No, there are only warnings in the *.e4.* bundles (which should get fixed > > too ;-). See e.g. > > http://download.eclipse.org/eclipse/downloads/drops4/N20131202-2000/ > > testResults.php > > This would be the equivalent of the "Problems" view, right? No. By default the official build applies its own global rules, so that all projects are measured with same rules. Projects can override them for the IDE/workbench via project specific settings, usually to see more warnings than in the build. A project can also change the settings for the official build via pom, but that should be the exception. > I also don't see > any warnings here (also after the change to Java 1.5). But the Package > Explorer shows warnings, examples see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=423025#c4 Then you probably have some filter enabled in your 'Problems' view.
Created attachment 238002 [details] ProblemsView > Then you probably have some filter enabled in your 'Problems' view. I think I have set the filters correctly, see attachement. This should show all warnings in the currently selected project, I think.
(In reply to Lars Vogel from comment #8) > Created attachment 238002 [details] > ProblemsView > > > Then you probably have some filter enabled in your 'Problems' view. > > I think I have set the filters correctly, see attachement. This should show > all warnings in the currently selected project, I think. I see 1373 warnings on ui.ide in my 'Problems' view with the settings shown in your picture. No idea, why they don't show up in your workspace.
Several platform plug-in have updated to Java 1.6 to surpress the type warnings in their build. I really like this approach, this way we can upgrade the classes gradually.
It looks like this was now done, but now causes 11 warnings in our official build: http://download.eclipse.org/eclipse/downloads/drops4/N20140408-0015/compilelogs/plugins/org.eclipse.ui.ide_3.10.0.N20140408-0015/@dot.html Lars, please fix them ASAP or revert the change. Thanks.
(In reply to Dani Megert from comment #11) > It looks like this was now done, but now causes 11 warnings in our official > build: And the right fix is not to cast something, but to remove the "new String[] {...}" and perform a varargs invocation. For the methods passing "null", you have to check if it's OK to just remove the "null" and perform a varargs invocation with zero additional args.
(In reply to Dani Megert from comment #11) > It looks like this was now done, but now causes 11 warnings in our official > build: > http://download.eclipse.org/eclipse/downloads/drops4/N20140408-0015/ > compilelogs/plugins/org.eclipse.ui.ide_3.10.0.N20140408-0015/@dot.html > > Lars, please fix them ASAP or revert the change. Thanks. I see 17 warnings, but I think the discourage access was there before. I have a look tonight and try to fix them. Thanks Markus for the pointer.
(In reply to Markus Keller from comment #12) > And the right fix is not to cast something, but to remove the > "new String[] {...}" and perform a varargs invocation. For the methods > passing "null", you have to check if it's OK to just remove the "null" and > perform a varargs invocation with zero additional args. I was able to follow your advice for the EditorAssociationOverrideDescriptor and IDEResourceInfoUtils but for ExtendedMarkersView I had to add an explicit cast. I tested this cast and it should be fine IMHO. But as you explicit said I should not do this, I did not want to commit it, without your feedback.Can you have a look and tell me if there is a better way of getting rid of this warning? https://git.eclipse.org/r/#/c/24658/
(In reply to Lars Vogel from comment #14) > for ExtendedMarkersView I had to add an explicit cast. The cast is not needed: MarkerMessages.errorsAndWarningsSummaryBreakdown, counts[0], counts[1], counts[2] + counts[3]);
(In reply to Dani Megert from comment #15) > (In reply to Lars Vogel from comment #14) > > for ExtendedMarkersView I had to add an explicit cast. > > The cast is not needed: > MarkerMessages.errorsAndWarningsSummaryBreakdown, counts[0], counts[1], > counts[2] + counts[3]); I can do that, but that replicates the logic; assume it changes later you have to remember to change it twice. Why is the cast bad?
(In reply to Lars Vogel from comment #16) > I can do that, but that replicates the logic; assume it changes later you > have to remember to change it twice. Why is the cast bad? Gerrit review adjusted as requested. Thanks for the feedback.
(In reply to Lars Vogel from comment #17) > (In reply to Lars Vogel from comment #16) > > I can do that, but that replicates the logic; assume it changes later you > > have to remember to change it twice. Why is the cast bad? > > Gerrit review adjusted as requested. Thanks for the feedback. Dani applied the review with https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=37981c487563d3945d0a168c46af66b0f58e0700
I overlooked that the code that reassigns 'counts' has not been removed. Without that, the new code will run into AIOOBE. I also fixed the code duplication. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f57ff125d5c0d604482906cb90f9dd0712e9cfa5 > Why is the cast bad? Casts should always be avoided if possible.
Verified in Git
