If the application is going to be around longer than 5 years, roll your own MVC or ROA pattern in Java. Write your own DAO and database calls (stay away from ORMs). Keep 3rd party library use down to a minimum, limiting your vulnerability exposure and rewrites due to upgrades.
As a developer who has worked on code bases that were home rolled, and built with popular frameworks (spring, rails). The worst code bases I've ever worked on were home rolled. Obviously that's only my experience, but I have a hard time agreeing with this advice.
Home-grown means every other developer that ever has to touch it is going to have huge additional overhead getting started with the codebase (because your documentation is going to be nonexistent), and you're going to spend a ton of time unnecessarily reinventing the basics.
These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.
While it is true that there is additional overhead, they did say "if the application is going to be around for more than 5 years".
After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working.
Basically, it could be the difference between throwing away your app and rewriting it.
> than try and get what ever stack was common at that time working
Doesn't seem like a problem for languages with sane package management solutions, of which there are plenty. A Java app on Maven is going to work just fine in 5 years, and on the latest version of java to boot.
Maven is a build tool and can help manage dependencies. It doesn't ensure your code base is compatible with the latest version of the dependency or ensure the dependency is still supported.
I'm working on code bases that are 10 years old today, built on asp.net webforms and mvc. If you don't choose a FOTM you'll be ok, all the answers are still on SO.
