Unable to compile @NotNull when applied to a field #116

Closed
lombokissues opened this Issue Jul 14, 2015 · 10 comments

Projects

None yet

2 participants

@lombokissues
Collaborator

Migrated from Google Code (issue 43)

@lombokissues
Collaborator

๐Ÿ‘ค voidstar ย  ๐Ÿ•— Sep 02, 2009 at 01:35 UTC

What steps will reproduce the problem?

  1. Put an @ NotNull on a field and watch javac choke.

Please provide any additional information below.
In my case I'm using an older version of hibernate validator with it's
@ org.hibernate.validator.NotNull annotation. The newest version uses @ javax.validation.NotNull
which from what I can tell will have the same issue.

See this thread:
http://groups.google.com/group/project-lombok/browse_thread/thread/572eb913e1a86eea

@lombokissues
Collaborator

๐Ÿ‘ค reinierz ย  ๐Ÿ•— Sep 02, 2009 at 02:04 UTC

Well, it'll only choke on that particular variant of @ NotNull (javax.validation.NotNull). But, show-stopper. We'll fix
this ASAP.

@lombokissues
Collaborator

๐Ÿ‘ค r.spilker ย  ๐Ÿ•— Sep 02, 2009 at 08:27 UTC

To solve it right, we need to implement the bindings so we can tell what exact
NotNull is being used and maybe even check where it can be applied.

For now, I'm considering to NOT copy the NotNull annotation to the parameter because,
for as far as I know, the only other NotNull annotation in the wild is the one from
IDEA, and currently we don't support IntelliJ anyway. And not having the annotation
copied won't break anything.

@lombokissues
Collaborator

๐Ÿ‘ค reinierz ย  ๐Ÿ•— Sep 02, 2009 at 08:31 UTC

Yup. For safety's and consistency's sake, we should probably stop copying the annotations everywhere (so, also
for the getter), and not just for the parameters of the setter and the constructor.

@lombokissues
Collaborator

๐Ÿ‘ค jacek99 ย  ๐Ÿ•— Sep 02, 2009 at 08:59 UTC

Wouldn't it be better to have some generic logic that would look at how an annotation
is defined and where it can be applied and use that in a common fashion to decide if
annotations should be copied around?

The same issue may pop up on other annotations that Lombok may have to deal with in
the future.

@lombokissues
Collaborator

๐Ÿ‘ค reinierz ย  ๐Ÿ•— Sep 02, 2009 at 09:18 UTC

jacek99: Well, what kind of 'generic' logic are you referring to? If you're referring to: Check the target
ElementType and copy only if its legal - well, lombok can't do that - no type info. That's what Roel meant in
comment ๏นŸ2 with "we need to implement the bindings so we can tell". It's planned - the suggested 'let's not
copy anything' is a short-term workaround.

@lombokissues
Collaborator

๐Ÿ‘ค reinierz ย  ๐Ÿ•— Sep 02, 2009 at 23:41 UTC

Fixed in c46bf85 which will be rolled out in v0.8.5.

The "fix" simply reduces the feature to scan only for annotations named 'nonnull'. All annotations named nonnull
work the way we want them to (e.g. legal on parameters). The only commonly used notnull that ISNT a variant of
javax.validation.NotNull is IDEA's, but lombok doesn't support IDEA.

This is a workaround - once lombok supports type introspection we'll fix this properly.

@lombokissues lombokissues removed the accepted label Jul 14, 2015
@lombokissues
Collaborator

๐Ÿ‘ค matt.deboer ย  ๐Ÿ•— Oct 17, 2011 at 19:48 UTC

This doesn't seem to be resolved (or has regressed?); using Lombok 0.10.1 with a maven 3.0.3 build, having a simple class with a single member which has @ javax.validation.constraints.NotNull applied causes compiler plugin to bomb with the aforementioned "annotation type not applicable to this kind of declaration".. this works correctly within Eclipse environment, but fails during Maven build.
(Compiler plugin is configured to use compilerVersion,source,target all = 1.6)

@lombokissues
Collaborator

๐Ÿ‘ค reinierz ย  ๐Ÿ•— Oct 25, 2011 at 13:04 UTC

It's a regression introduced in 0.10.1. See issue #360 for more up to date discussion.

@lombokissues
Collaborator

End of migration

@Tradunsky Tradunsky pushed a commit to Tradunsky/lombok that referenced this issue Aug 19, 2015
Michail Plushnikov Issue #116
added handling of @Builder annotation on the constructor/method and not on the class file
e66bdbe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment