Spring boot Constructor Injection using Lombok

[somber glade]

Hi all, fundamentally the following code I've got for handling Spring Boot constructor injection works:

@RequiredArgsConstructor
@Service
public class FooService {
    private final MyBean myBean;
    // ...
}

The above is an alternative to the documented way of performing Constructor Injection by outright defining the constructor and its arguments:

@Service
public class FooService {
    private final MyBean myBean;

    public FooService(MyBean myBean) {
        this.myBean = myBean;
    }
    // ...
}

From a compilation perspective, these evaluate to the exact same code (as far as I know).

Is there any reason that anybody can think of as to why I shouldn't use Lombok's RequiredArgsConstructor here?

[onyx laurel]

Detected code, here are some useful tools:

Formatted code

@RequiredArgsConstructor
@Service
public class FooService {
  private final MyBean myBean;
  // ...
}

<@&1004656351647117403> please have a look, thanks.

[olive steeple]

The problem with lombok is that it isn't java

meaning

editors need special support for it

it needs special plugins

you need to wait for lombok to update before you update java versions

(lombok can break randomly since it hooks into JVM internals that they change freely)

so you have to weigh those long term risks and downsides against the convenience you gain using "Lombok, the Java superset"

is the difference between this

@RequiredArgsConstructor
@Service
public class FooService {
    private final MyBean myBean;
    // ...
}

and this

@Service
public class FooService {
    private final MyBean myBean;

    public FooService(MyBean myBean) {
        this.myBean = myBean;
    }
    // ...
}

Worth breaking compatibility with tools designed for Java and not Lombok + Having update problems in the future

[somber glade]

Those are fair insights yeah, cheers Ethan! Luckily, I think I'm happy living with those potential problems for this project - I'm using IntelliJ which has great support for Lombok and Java update wise I'm more than happy to wait - will most likely have to for the myriad of other dependencies I use regardless 😁

[olive steeple]

then yes, those two snippets of code are identical

a point on the compatibility thing that might not be obvious

You might assume that it would break going from 23 -> 24 or something

but the risk is more like breaking on 23.01 -> 23.02

[somber glade]

Ooh, didn't consider that it'd be minor versions too. I'll definitely be sure to keep that in mind

[olive steeple]

but thats all at compile time - your generated code is fine

[atomic horizon]

huh?

[olive steeple]

even patch versions

[atomic horizon]

i mean, it's the compiler changes that impact lombok

[olive steeple]

lombok breaks whenever they change key parts of the compiler code. they are now willing to do that even on patch releases

[atomic horizon]

how commonly do they make breaking compiler changes on patch releases?

[olive steeple]

that might be fun to quantify

[atomic horizon]

i understand the possibility, but it also seems to be instilling fear that isn't really needed

its more "you get what you pay for with lombok, it impacts the compiler, so you have to keep up-to-date with compiler changes"

and lombok does a pretty good job at taking care of that

but i dont think it's like "its very common to need to update lombok when Java has a new patch"

the only thing the user has to worry about in production is "did lombok update?" or "does lombok support this version?"

the rest is handled by lombok

[somber glade]

That does make life easier. In brutal honesty I didn't even check if Lombok supported the minor JDK version I'm using.

Really stupid question but if you don't provide a version number for a dependency using Gradle does it determine the latest supported dependency for your provided JDK and other dependencies?

[olive steeple]

no, but it might default to one coming in from a BOM or similar

idk if they support just writing LATEST

[somber glade]

So it shouldn't supply a dependency that doesn't support a specific Java version (ignorant of provider)?

[olive steeple]

there is no metadata in dependencies to indicate what java versions they do and dont support

i mean, there might be in artifacts published with special gradle only metadata (they exist) but in general you have no clue

the rule of thumb is that if a library doesn't use java internals it probably will continue to work mostly forever

so long as it works with a version greater than 16

minus stuff thats gonna be removed like applets and unsafe

[somber glade]

That's really odd, I would have thought they'd have to specify supported Java versions. So outside of building a BOM and manually checking all the dependencies releases (which would take an age for some projects) there's no decent way of knowing whether your chosen JDK supports the dependencies you're using? It's just hope and TIAS?

[olive steeple]

correct

ditto for whether certain library versions work together

though that at least has specified minimum versions

which lets gradle pick out a version of each library it thinks will work

[somber glade]

Though they could take the same approach as the project I'm currently working on and not provide versions?

[olive steeple]

no they need to provide versions if they want dependencies to automatically be pulled in

they could technically leave a dependency off the list (it happens a bit) but they usually do