The crisis is primarily that many J2EE projects are fundamentally cost center projects designed to be written once and maintained by a low-cost team and are thus focused more upon compliance to standards and consistency than creative problem solving. If a business domain is well understood and documented, it is very straightforward regardless of software platform to codify its rules and conventions - this is not what happens in most software developed today. The culture in the J2EE community (that does have value, not devaluing the approach) along with its participating community of typically old, established companies with cultures not favorable to certain personalities (regardless of skill) has caused a huge brain drain from making usability (and therefore consistency IMO) improvements that could have been possible. It'd be really interesting to see what would have happened if half of Silicon Valley's engineers contributed to the J2EE ecosystem, but we will never know given the trajectory of the industry.
From my years doing integration projects for a lot of the F500 I've confirmed your assertion that technology hardly matters for them, but this makes it very difficult to grow as a developer because you're not solving technical problems anymore as much as business level ones. The "learning" involved at technical levels tends to become more about trivial (API inconsistencies from implementation, names of properties) or specific, proprietary knowledge gained from basically reverse engineering other parties' code. This also does not require any skill or much training either. Combined with mostly straightforward coding requirements, this drives down the skill level necessary to be successful in a usual J2EE software shop and thus the labor pool drives toward commoditization.
From my years doing integration projects for a lot of the F500 I've confirmed your assertion that technology hardly matters for them, but this makes it very difficult to grow as a developer because you're not solving technical problems anymore as much as business level ones. The "learning" involved at technical levels tends to become more about trivial (API inconsistencies from implementation, names of properties) or specific, proprietary knowledge gained from basically reverse engineering other parties' code. This also does not require any skill or much training either. Combined with mostly straightforward coding requirements, this drives down the skill level necessary to be successful in a usual J2EE software shop and thus the labor pool drives toward commoditization.