Suppress warnings in generated classes

Question

Suppress warnings in generated classes

Opened this issue 8 years ago · 6 comments

It would be nice for those of us tha try to keep warnings at Zero, if the generated classes could suppress their unchecked cast warnings.

@SuppressWarnings("unchecked") on the whole class would probably be simplest.

Currently casting Serizlizables to parameterized ArrayList seems to be the biggest culprit for me. But it's probably any Serializable.

Answer 1 · 2016-12-30T06:42:35.000Z

@adam, you can configure your quality tools to ignore the generated classes. That's generally a good practice. We also happily accept PRs. 2016-12-30 1:12 GMT+01:00 Adam Brown <notifications@github.com>:

…

It would be nice for those of us tha try to keep warnings at Zero, if the generated classes could suppress their unchecked cast warnings. @SuppressWarnings <https://github.com/SuppressWarnings>("unchecked") on the whole class would probably be simplest. Currently casting Serizlizables to parameterized ArrayList seems to be the biggest culprit for me. But it's probably any Serializable. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#143>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABv33S5gQYQPNEaLMFxyVZX6lcjKxu72ks5rNExUgaJpZM4LX7SJ> .

Answer 2 · 2017-01-03T21:21:14.000Z

@stephanenicolas I could be wrong (it's happened once before) but I don't think Android Studio/IntelliJ has a way to ignore warnings by file or directory.

However, I have a PR for you! #145

Answer 3 · 2017-01-04T04:12:17.000Z

Thx @Wavesonics for the PR, but we need it to be green to make something out of it !

Also, I was talking about the quality tools you can automate as part of your builds like findbugs, pmd, checkstyle, not something you manually trigger in AS.

Answer 4 · 2017-01-04T04:25:47.000Z

@stephanenicolas btw, I sent a PR some time ago and it was red as well haha. But I have read the CI test report and the diff is just the order of generated methods in Henson class. (I mentioned it in the PR as well). This kind of failed really matters? Or could you allow us to improve the test cases as well?

Answer 5 · 2017-01-04T04:27:29.000Z

Yes it does matter, we only merge green PR. It is not only a good principle, it's also the only thing we can do via GH... 2017-01-04 5:25 GMT+01:00 LoLo <notifications@github.com>:

…

@stephanenicolas <https://github.com/stephanenicolas> btw, I sent a PR some time ago and it was red as well haha. But I have read the CI test report and the diff is just the order of generated methods in Henson class. (I mentioned it in the PR as well). This kind of failed really matters? Or could you allow us to improve the test cases as well? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#143 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABv33VSxqWmeTUjW_uRNjUwPDyxsefmJks5rOx9MgaJpZM4LX7SJ> .

Answer 6 · 2017-01-04T04:35:27.000Z

@stephanenicolas Ya I know the TDD principle, but what I am confused is that I need to add some codes not really elegant if I want to make the CI test green(in my case, I could simply sort the method to suit the test but it is kind of ugly :(
So is it a good practice to do so? I am new to open source group and not very familiar with the rules of PR. If the answer is yes, I will update my PR later :)