Summary: | Enable @SuppressWarnings for optional errors | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Stephan Herrmann <stephan.herrmann> |
Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | Lars.Vogel, rolf.theunissen |
Version: | 4.16 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Stephan Herrmann
2020-03-31 14:43:27 EDT
Maybe you could add platform UI plugin to your runtime workspace to find these issues early during development? (In reply to Lars Vogel from comment #1) > Maybe you could add platform UI plugin to your runtime workspace to find > these issues early during development? Doing this for every fix in the compiler is quite out of proportion and would significantly slow down development. Running comprehensive tests is the job of jenkins. Feel free to configure an additional build job that I could trigger. If it runs in less then 10 min. we could perhaps add it to our gerrit verification. By contrast, flipping one setting from disabled to enabled is so many orders of magnitude simpler. (In reply to Lars Vogel from comment #1) > Maybe you could add platform UI plugin to your runtime workspace to find > these issues early during development? And: perhaps you noticed that I did not promise that no additional problems will ever be raised? Read: even if I tested compiling all code in the world, I might still decide to accept some false positives for the benefit of many more correct positives. Can't we flip this setting once needed? (In reply to Lars Vogel from comment #4) > Can't we flip this setting once needed? You must have very strong reasons for avoiding this change. Fair enough -- if you personally promise to make the change when needed. Just note that the quickfix to add @SuppressWarnings will not be offered without that change, and hence you will not be aware which problems can potentially be suppressed. (In reply to Stephan Herrmann from comment #5) > (In reply to Lars Vogel from comment #4) > > Can't we flip this setting once needed? > > You must have very strong reasons for avoiding this change. > > Fair enough -- if you personally promise to make the change when needed. > > Just note that the quickfix to add @SuppressWarnings will not be offered > without that change, and hence you will not be aware which problems can > potentially be suppressed. No I just don't understand why we should change something which is not needed yet. As you fell strong about it, please provide Gerrit and Andrey can review it. Afaics Andrey was affected by the compiler issue. (In reply to Lars Vogel from comment #6) > (In reply to Stephan Herrmann from comment #5) > > (In reply to Lars Vogel from comment #4) > > > Can't we flip this setting once needed? > > > > You must have very strong reasons for avoiding this change. > > > > Fair enough -- if you personally promise to make the change when needed. > > > > Just note that the quickfix to add @SuppressWarnings will not be offered > > without that change, and hence you will not be aware which problems can > > potentially be suppressed. > > No I just don't understand why we should change something which is not > needed yet. As you fell strong about it, please provide Gerrit and Andrey > can review it. Afaics Andrey was affected by the compiler issue. The build of Platform UI was broken for 2-3 days in Gerrit. But also in the workspace, for anybody that was running the latest I-Builds. So the whole platform was affected, not only Andrey. Depending on the I-Builds of the compiler has a risk. When the JDT project has a advice on how to reduce or manage this risk, I would seriously consider it. Note that the workaround for the issue as suggested by Andrey would be far more ugly: https://git.eclipse.org/r/#/c/160250/ (In reply to Rolf Theunissen from comment #7) > (In reply to Lars Vogel from comment #6) AFAIK we did not have lots of compiler bugs affecting platform UI over the years. Hence my impression that we could use Stephans suggestion once needed not up front. IMHO it is not normal that changes in JDT core breaks Platform UI or other repos. But if someone wants to provide a Gerrit for platform UI, text, resources, runtime, team that is fine for me. |