javac Xlint removal warning in generated code

[jnehlmeier]

I updated to latest ebean and now I have a pair of warnings for every query bean:

• Warning: [removal] filterMany(String,Object...) in TQAssocMany....
• Warning: [removal] _filterMany(String,Object...) in TQAssocBean....

I don't call these methods at all in my application code and it is pretty annoying now as it "hides" other, more important warnings.

I can see that public filterMany calls protected _filterMany and both are marked for removal. Maybe all warnings go away if _filterMany would not be marked for removal? My impression is that I should only see a warning if I actually call a deprecated forRemoval method.

[rbygrave]

as it "hides" other, more important warnings.

"hides" isn't accurate right, in that its more that it produces "noise" and that noise distracts us away from other compiler warnings - isn't that the case?

My impression is that I should only see a warning if I actually call a deprecated forRemoval method.

I believe what you are suggesting is that if we remove the @Deprecated(forRemoval = true) from TQAssocBean._filterMany() [which is an "internal" method only callable via the generated query beans, so it seems reasonable that we could remove that @Deprecated there] then these warnings that we are seeing on the generated query bean code will go away ... and that would be good because they are producing a lot of noise in the compiler output.

[jnehlmeier]

as it "hides" other, more important warnings.

"hides" isn't accurate right, in that its more that it produces "noise" and that noise distracts us away from other compiler warnings - isn't that the case?

Yes, it was in the sense that noise makes it harder to see other real warnings.

My impression is that I should only see a warning if I actually call a deprecated forRemoval method.

I believe what you are suggesting is that if we remove the @Deprecated(forRemoval = true) from TQAssocBean._filterMany() [which is an "internal" method only callable via the generated query beans, so it seems reasonable that we could remove that @Deprecated there] then these warnings that we are seeing on the generated query bean code will go away ... and that would be good because they are producing a lot of noise in the compiler output.

Yes, in my case I am hoping that all warnings go away as soon as TQAssocBean._filterMany is changed because my code never calls TQAssocMany.filterMany.

Once changed, if javac will still complain about TQAssocMany.filterMany just because I have to compile the generated code then I am not sure what I will do. Probably disabling the check during compilation.

[rbygrave]

Note that this method does not exist on version 15.x, this is a 14.x specific issue.

[jnehlmeier]

I just updated the library and sadly I still have warnings for TQAssocMany.filterMany() and all its implementations in query beans even though the method is not called at all.

After some testing it seems like javac will produce the warning if you simply have a method deprecated for removal in an interface and implementations exist, even if you never call these methods.

[rbygrave]

So the options are: 1. Remove the for removal from the @deprecated 2. See lots of compiler warnings 3. ??? ... is there a third option?

…

On Tue, 11 Feb 2025, 12:30 am Jens Nehlmeier, ***@***.***> wrote: I just updated the library and sadly I still have warnings for TQAssocMany.filterMany() and all its implementations in query beans even though the method is not called at all. After some testing it seems like javac will produce the warning if you simply have a method deprecated for removal in an interface and implementations exist, even if you never call these methods. — Reply to this email directly, view it on GitHub <#3546 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABTATKN5BPZ2FGIVD57HC32PCEU7AVCNFSM6AAAAABV6JU3HOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBXG4YTIMRTGM> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[jnehlmeier]

3. Speed up time so a 14.x-javax release without these methods is available

4. Disable the removal check of javac linter for the time being. It is a Gradle multi-module project so I do not have to disable the check for all modules but only the ebean one. I would need to check if the module contains more than just entities + querybeans. If it does then I would first try to figure out if the generated sources can be written to a dedicated ebean-generated-querybeans module which then has the removal check disabled.

[rbygrave]

3. Speed up time so a 14.x-javax release without these methods is available

That is probably not a bad option in this case. Deprecated since around August 2023 and has a good migration option to filterManyRaw(). So I'll look to prepare a PR for this.

[rbygrave]

Refer #3558