Their use of Scala was the only reason I gave the play framework a second look. Just because you're not interested in Scala doesn't mean nobody else is. Scala is the most popular plugin for intellij by a very wide margin, that's a lot of 'nobody' downloads. Having used both java and Scala extensively I honestly can't understand why anyone would still pick java by choice other than if it's the only jvm language they know.
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.
I prefer my Spring applications to look like this:
@SpringBootApplication
public class Application { ... }
The biggest is DI. Having witnessed what a tangled mess large Guice codebases can become where you really have no idea what is providing what I have to say that Spring here gets a bad rap from the all-XML days and (IMHO) it is actually the cleanest and easiest to work with.
The author mischaracterizes Spring too:
> It has a either code-based wiring or XML configuration-based wiring.
Actually Spring can use a mix of XML code configuration and auto-wiring.
A modern Spring application will have precisely an application context XML file with one line per "bean" eg:
and that's it. Note: there's no classpath scanning. Auto-wiring takes care of the rest. This has two big advantages (over Guice in particular):1. Everything is in one place. If it's not instantiated here it doesn't exist. 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); and
2. 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.
I'm glad to see this post recommend Maven. It's fun to bash Maven but most detractors ignore the huge benefit that applies to any shop with lots of devs: Maven is opinionated. That's a plus not a minus. Seen one Maven Web application and you've seen them all. There's no really weird directory layout because someone decided they just had to be different.
Lastly Play. I really tried to like Play. I really did. But as of Play 2.0+ it became a Scala not a Java framework. It may still work with Java but some things just require you to know something about Scala. That's a huge negative IMHO. I'm not interested in Scala. Nobody is.
Plus the auto-compile feature of Play tended to randomly break with indecipherable error messages for no readily apparent reasons such that you couldn't tell if it was a bug or not. I get enough of that with C++ template programming thank you.
I also agree that the two books the author recommends are probably the two most important Java books in existence.