Right, way back, back when C++ and Java were competing with each other,one of the main differences was that Sun was a big player in the open source ecosystem, whereas Microsoft was a big proponent of closed source development. As a company, Sun adopted, and even enabled open source ecosystems. On the other hand, Microsoft believed (and still believes) that they are the final arbiter of what tools developers should use. It prescribed a list of technologies that came with Visual Studio, and it was difficult to step out of it.
Both methods have their merits. Within a open-sourced ecosystem, you have a lot of choices for the same thing, and some time, one of these choices wins out over the other choices. This has an advantage that you are not stuck with the limitation of one library. If a library doesn't suit your need, you find another. However, the problem is that making the choice is the hardest thing about a project. Most developers don't realize this because someone has already chosen a tech stack for them, and their challenge is to learn and use the tech stack. However, being in a position of selecting a Java based tech stack is very challenging. They only way to know if a tech stack works is by using it. However, you need to decide before hand. If you are an architect, and someone asks you to recommend a tech stack, you know that you are making your best judgement , and your job depends on it. On the other hand, your job in a Microsoft ecosystem is easy: You use the tool that Microsoft gives you, and you know everything will work together. If the tool doesn't do what you want it to do (or makes it difficult), you shrug your shoulders and say something about technical limitations or such. You can squarely put the blame on Microsoft's shoulder and Microsoft is more than happy to take that blame. They get a good excuse to sell your company the next version of Visual Studio.
10 years down the line, this lead to fundamental differences in
philosophy. Java development had become more about people. Microsoft development had become about process. When, you have a Java based tech stack, you will ultimately need to switch your tech stack, sooner or later. You know you don't have the best tech stack now, and even if you do, a better one will come in 3-5 years. So, if you are planning for long term, you need to hire smart people who can learn the new tools by themselves easily. If you are in a Microsoft stack, you aren't competing with other companies like you on the strength of your developers or technology choices. You are competing on how well you can manage your projects. So, emphasize on the process. Streamline it to heck. As a result, Java shops eventually evolved into kind or organized chaos, where everyone is trying to pull the tech stack in differrent directions, and what you get is something that either the head honcho loves, or no one hates. Whereas, Microsoft shops became these efficient machines of beauty. In other words, Java shops are meritocratic democracies, whereas Microsoft shops are hierarchical dictatorships.
Of course, what do large companies prefer? Hierarchical Dictatorships?! It fits nice into how bean counters think companies should work. They don't like the mess that goes on in the dungeon of a Java shop. So, there was a need for "prescribed tech stacks", or in other words, Microsoft like tech stacks that tell you exactly what you need to use, and you don't have to go hunting for solutions. There are 2 such stacks that I know of (maybe there are more): Spring and Oracle ADF. Spring is free. Oracle is paid. Spring doesn't provide support (unless you consider hiring a Spring consultant as paying for support) and makes it's source available for you to look at. Oracle provides support.
So, coming back to
main challenges of a Java developer. It entirely depends on the company you work for. You are working in a company that tries out and adopts every open source solution out there, then you will be struggling with learning new technologies and figuring out how to make them work with each other. If you are working at a company that s using a prescribed stack, then you will be spending most of the times fitting square pegs into round holes.
) but I recall seeing some frameworks that were fine for generating the first cut outline of a project, but where it was often difficult to implement changes later. 
