I don't mind Java so much as the types of code people tend to write with it. No one needs a FooReactorFactoryFactory when. There is only a single FooReactor which is always chosen. I've recently learned that it's possible to write such abominations in C++, which is equally bad.
And don't get me started on dependency injection systems like Guice. @Inject just means I have no way of knowing the type of an object or how it is initialized without sifting through the entire code base looking for an @Provides. And even then I can never be sure.
1) A lot of enterprise devs think all problems are best solved in Java, and refuse to acknowledge anything else (looking at the IBMers in the room)
2) Spring Boot takes what you don't like about Guice and cranks it up ten levels. It's so common in the industry that it might as well be adopted as a javax package now.
> @Inject just means I have no way of knowing the type of an object or how it is initialized without sifting through the entire code base looking for an @Provides.
If you're using interfaces correctly with strong contracts, the concrete implementation shouldn't matter.
This falls apart very quickly if your implementations don't match the contract.
Guice can be quite pleasant (though confusing at first) since it makes it easy to test your code and easily swap out implementations of classes, e.g. for dev vs prod.
Guice is honestly the worst DI container I’ve ever used. It has no life cycle support and you have to hack around all of its features. Id take any of the popular ones over it. Spring/Avaje/CDI. Most likely Avaje since it most easily supports compile time injection.
And don't get me started on dependency injection systems like Guice. @Inject just means I have no way of knowing the type of an object or how it is initialized without sifting through the entire code base looking for an @Provides. And even then I can never be sure.