I have to admit, I'm a little confused by the idea of having dependencies injected at compile time. It's like... inverted IoC!
I definitely see how that would be faster than resolving the whole world at startup, and that has to be one of the reasons Grails takes so long to get rolling.
Plus ça change... It's time for the pendulum to swing the other way again.
Quick note: if you already use sdkman to manage versions of tools you use (grails, jdk, etc), you can install micronaut trivially with
Dependency injection at compile time is definitely a different concept if you are used to the way Spring Framework (and others) handle it at run-time. I don't know that I would say it is "inverted IoC". The framework is still in control, but the framework now extends to compile time and does the hard work of weaving your code together up front. That way it doesn't have to be done at startup.
When Spring (and other frameworks) started, they touted Dependency Injection and Inversion of Control as this new amazing thing (which it was, at the time). If you now resolve dependencies at compile time, it feels like it's the opposite of that, and what IoC was trying to get around at the time.
It looks like it uses a different approach to hook up dependencies at compile time, so that it's not a massive mess to change one implementation of a service for another, but it's still a bit amusing to see how paradigms shift over the years.
I'm keeping an eye out for integration between Mironaut and Grails, which I hear may happen with a Micronaut profile for Grails. crossing fingers
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have to admit, I'm a little confused by the idea of having dependencies injected at compile time. It's like... inverted IoC!
I definitely see how that would be faster than resolving the whole world at startup, and that has to be one of the reasons Grails takes so long to get rolling.
Plus ça change... It's time for the pendulum to swing the other way again.
Quick note: if you already use sdkman to manage versions of tools you use (grails, jdk, etc), you can install micronaut trivially with
Thank you for the introduction!
Dependency injection at compile time is definitely a different concept if you are used to the way Spring Framework (and others) handle it at run-time. I don't know that I would say it is "inverted IoC". The framework is still in control, but the framework now extends to compile time and does the hard work of weaving your code together up front. That way it doesn't have to be done at startup.
Thanks for the comments!
When Spring (and other frameworks) started, they touted Dependency Injection and Inversion of Control as this new amazing thing (which it was, at the time). If you now resolve dependencies at compile time, it feels like it's the opposite of that, and what IoC was trying to get around at the time.
It looks like it uses a different approach to hook up dependencies at compile time, so that it's not a massive mess to change one implementation of a service for another, but it's still a bit amusing to see how paradigms shift over the years.
I'm keeping an eye out for integration between Mironaut and Grails, which I hear may happen with a Micronaut profile for Grails. crossing fingers