Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@Slf4j doesn't work if class has an org field #1400

Closed
stickfigure opened this issue May 23, 2017 · 4 comments
Closed

@Slf4j doesn't work if class has an org field #1400

stickfigure opened this issue May 23, 2017 · 4 comments

Comments

@stickfigure
Copy link

@Slf4j
class Foo {
    private Org org;
}

This produces a compiler error "non-static variable org cannot be referenced from a static context". It makes sense; the = org.slf4j.LoggerFactory.getLogger(... is ambiguous. Is there any way to make @Slf4j work?

@victorwss
Copy link
Contributor

BTW, you are likely to run into this same problem if you import both org.example.foo.Bar and com.example.moo.Bar and needs to reference somewhere in your code the org.example.foo.Bar class - You'd have no way to do that! This is a handicap in the java language that uses the same notation for two completely different concepts. Don't know what could be done in lombok to solve this issue without creating some other issue somewhere else.

@porub
Copy link

porub commented Oct 5, 2020

I didn't find any.

so, had to replace @Slf4j with direct private static final Logger log: stackoverflow

@randakar
Copy link

randakar commented Oct 5, 2020

Actually you might maybe get away with just adding the missing import to make this compile.

@rspilker
Copy link
Collaborator

rspilker commented Oct 8, 2020

There is a problem in the java language where using fully qualified names and the presence of a field with a name that is the same as the first part of the fully qualified names gives a compiler error.

Also, in our generated we use fully qualified names for several important reasons:

  • To prevent collisions with local types
  • To prevent collisions with imported types
  • We can suppress warning on generated fields and methonds, not on imports
  • It is easier to code and maintain. We don't have to add code in two different locations, or check for the existence of the import or a wildcard variant of it

@rspilker rspilker closed this as completed Oct 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants