4 ms·
It must be said that this coding style may be the norm with Quarkus (and with Spring which it is trying to replace on graalvm/native-image), but isn't required
by tannhaeuser 4y ago
It must be said that this coding style may be the norm with Quarkus (and with Spring which it is trying to replace on graalvm/native-image), but isn't required by Java itself. As always, Spring-like Java buerocrats have chosen to chase and over-engineer trivialities because it's so much easier lol; well until using your framework becomes a study in psychology or software archeology.
Update: what I don't get with Quarkus though is why did they set out in Spring factory style only to have to immediately limit this for native-image's "closed world assumption"
- absove 4y agoI'm pretty sure Quarkus tries to stick as close as possible to Java EE APIs with some limitations to accommodate the lack of runtime reflection, being Red Hat's answer to application containerization for which JBoss isn't a good fit, if it looks like Spring it's mostly because it's a popular style in Java.