@Getter(lazy=true) causes unchecked cast warning

[sgrimm-sg]

The Lombok-generated code from @getter(lazy=true) contains a cast from Object to the field's type, which causes an unchecked cast warning when compiling with -Xlint:all.

[rspilker]

There's not a lot we can do here.

We do put two annotations on the method to let the compiler know it shouldn't emit warnings:

• @java.lang.SuppressWarnings("all")
• @javax.annotation.Generated("lombok")

The code is fine. Yes, the cast might be unsafe, but the code makes sure it isn't.

[LunNova]

Is SuppressWarnings definitely being added correctly?

I'm not setting any special lint options using -Xlint:all -Xlint:-processing and warning: [unchecked] unchecked cast is showing up for any use of @Getter(lazy=true).

[sgrimm-sg]

For what it's worth, here's the workaround we settled on, which gets rid of the warnings.

@Getter(lazy = true, onMethod = @__({@SuppressWarnings("unchecked")}))

[Maaartinus]

@rspilker According to the duplicate thread, adding the "unchecked" token to "all" helps, and it should be rather easy for Lombok to do this. Should I give it a try? Or would you?

There's a minor complication: For primitives, the "unchecked" token produces a warning in eclipse.

[mjustin]

@rspilker One wrinkle that makes this a bit more problematic: the onMethod workaround suggested in this thread currently causes an exception in Checkstyle when using the SuppressWarningsFilter, per checkstyle/checkstyle#7522.

[rzwitserloot]

Just to get it on the record: Whomever designed how @SuppressWarnings works should be flogged. What an omnibomb of a disaster. There are no specs, everybody does their own thing, and "all" means so many things... except "all". There is in fact no actual "all" at all. Aaaargh 🤢 💥

Adding "unchecked" helps, yeah. We'll get on that; good point by @Maaartinus that we do need to check if the type is primitive in which case, don't (we already do this, I think; we have to use a different AtomicX if the field is primitive already, and whilst we can't do resolution, primitives are hardcoded concepts we can trivially check for – not complicated in either case).

[rzwitserloot]

There's a minor complication: For primitives, the "unchecked" token produces a warning in eclipse.

Can't reproduce. We actually cast e.g. (java.lang.Long), letting auto-unboxing do the final step, so hopefully you meant this comment as a more general observation and not specifically for what @Getter(lazy=true) does.

[rzwitserloot]

Live in 1.18.12.