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

Global lazy #692

Open
re-thc opened this issue Oct 4, 2024 · 7 comments
Open

Global lazy #692

re-thc opened this issue Oct 4, 2024 · 7 comments

Comments

@re-thc
Copy link

re-thc commented Oct 4, 2024

Hi, are there configuration options for inject, e.g. to apply lazy globally? Spring had an option to globally mark everything as lazy.

Trying to port an application to use this, but seems tedious to maintain @Lazy everywhere. Thanks!

@SentryMan
Copy link
Collaborator

Not at the moment, though that's something we can try to add

@rbygrave
Copy link
Contributor

rbygrave commented Oct 9, 2024

to apply lazy globally?

What is the use case? Why are you looking to apply this globally like that is a good thing to do?

I'm coming from the perspective that ideally Lazy isn't used much (Eager is preferred). In the server-side K8s case, when we start a service and respond OK to readiness we really want the service to be "Fully honest" along the lines "Yes I have started, I have initialised everything I need and I am ready to receive production traffic". In the everything is lazy case, we are really susceptible to saying OK to readiness without having initialised much at all ... and failing when trying to handle production traffic - in my view this is not cool relative to the "fail fast" / "Don't say OK to readiness unless are all truely all ready to serve production traffic".

Lazy was initially added for the JavaFX UI case, to delay initialisation of things that were relatively expensive and could be reasonably deferred to initialise lazily. What is the use case you are looking at? Why do you think global lazy is a good idea for that use case?

@re-thc
Copy link
Author

re-thc commented Oct 9, 2024

Thanks for considering. The production case makes perfect sense.

The use case is more for dev / testing. In this case faster startup / restarts would be preferred.

Spring devtools for example does provide hot reload with custom classloader so not everything restarts. It does have its quirks though.

At the moment I'm using inject and just restarting, which can take a while with lots of services and connections.

Hoping to also create preview builds per PR and having everything lazy would speed things up.

@rbygrave
Copy link
Contributor

At the moment I'm using inject and just restarting

It sounds like the case of building a Web UI (probably with server side rendering) and hence restarting the server frequently.

to apply lazy globally?

We can't do this transparently without using a more advanced AOP approach [along the lines of a javaagent]. That is, on the side when a component is injected we are effectively look to inject a Provider<T> rather than a T ... to enable the lazy use of T. We can't do that without a more more advanced AOP approach.

@SentryMan
Copy link
Collaborator

SentryMan commented Oct 14, 2024

We can't do this transparently

why not just add an annotation that changes the default generation behavior to make all beans lazy?

@rbygrave
Copy link
Contributor

why not just add an annotation that changes the default generation behavior to make all beans lazy?

Because it can't be done transparently. All the use sites need to change to Provider<T> - this is not a transparent change to the use sites without changing the AOP approach.

@SentryMan
Copy link
Collaborator

SentryMan commented Oct 14, 2024

What I understood by the issue was that it can be a hassle to manually add the lazy annotation everywhere when you desire your entire application to be lazy. Would not enhancing the annotation to work on a package/module level resolve that inconvenience?

Edit: oh wait I see what you're talking about, I had forgotten that one needs to use providers for lazy

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

3 participants