Re:Better Java – Resources for Writing Modern Java
by lmm on Sunday September 20, 2015 @03:47AM
(#10246868)
> 1. Everything is in one place. If it's not instantiated here it doesn't exist.
But that one place is XML. Better to have it be code, where I can use all my normal tooling ("find references" in my IDE (yes some IDEs have spring support), grepping through .java files, automated refactoring...) to work with it.
> Guice can be many levels deep and tends to descend into ModuleBuilders and conditional logic in modules (which the docs recommend against but tends to be used extensively anyway)
Have you seen the kind of horrors that are possible in Spring XML with conditionals, proxying, interceptors...? Compare like with like.
And in the worst case, if you must put conditional logic in your config, at least if it's in code then you can unit-test it the normal way.
> Testing. Testing is incredibly easy. I'm talking functional testing here, even integration testing. You simply include another XML file that overrides any definitions from the first. Everything else remains the same. Testing with Guice can be horrendous and once you start making extensive use of Modules.override() you should abandon all hope.
Shrug. Not my experience; you get more-or-less equivalent tooling capability with both (that is, you can group your definitions into smaller modules, and you can override specific instances when testing), so if you use them the same way it'll be just as easy or hard.
But that one place is XML. Better to have it be code, where I can use all my normal tooling ("find references" in my IDE (yes some IDEs have spring support), grepping through .java files, automated refactoring...) to work with it.
> Guice can be many levels deep and tends to descend into ModuleBuilders and conditional logic in modules (which the docs recommend against but tends to be used extensively anyway)
Have you seen the kind of horrors that are possible in Spring XML with conditionals, proxying, interceptors...? Compare like with like.
And in the worst case, if you must put conditional logic in your config, at least if it's in code then you can unit-test it the normal way.
> Testing. Testing is incredibly easy. I'm talking functional testing here, even integration testing. You simply include another XML file that overrides any definitions from the first. Everything else remains the same. Testing with Guice can be horrendous and once you start making extensive use of Modules.override() you should abandon all hope.
Shrug. Not my experience; you get more-or-less equivalent tooling capability with both (that is, you can group your definitions into smaller modules, and you can override specific instances when testing), so if you use them the same way it'll be just as easy or hard.