couple of comments below:

Well for sure the main reason behind Java is not being used at least in core banking  is that most customers are already satisfied with what core is supposed to do. They just need to provide new channels and capabilities on top of this core.

reply: totally acceptable and that is why business owners are reluctant to accept new framework unless it is beneficial to their revenue. this on the other side might seems to be frustrating for the service providers where they want to compete in the challenging industry (maybe I should say people within).

But, to answer your question, I have to say _yes_ there are obviously some well-known deficiencies in current standard JVM that prevents Java being used in mission critical and dependable systems. To be fair, this is the nature of a general purpose language like Java that fails to provide some (rarely used) enterprise level capabilities in favor of less complexity and ease of use, but these rare features are sometimes the main players in mission-critical and high dependable systems.

reply: you are talking about enterprise capabilities within a core functionality, this is only a question though, what enterprise capability do you need in core of banking system?

So, theoretically there are issues preventing Java be used in every kind of systems. I will try to mention some of them based my limited experience but perhaps there may exist other issues whom I haven't came across yet.

- The first and the most important one is that Java has failed to provide a dependable incremental garbage collection mechanism upon now. There have been some major improvements quite recently (thank to BEA) in providing parallel incremental GC but we are not where we are supposed to be yet. This looks a minimal issue at the first glance but becomes a real pain when system has to answer thousand of request per second and still remain compliant to its SLA.

reply: this might be right for Java, but there are plenty of other languages that are used for critical purpose that doesn't even have GC but on top of those practices are applied to make them deliver the functionality

- According to me, the second major issue is the lack of tail-recursion detection in JVM. As you know, mission-critical system are not proved by mere unit testing; they are proved by mathematics. This is where lambda-calculus and functional programming paradigms apply. Again Java's deficiencies in providing functional infrastructure makes in unreliable for most critical systems.

- No build-in support for actor model concurrency, hence unable to get the most of today's highly concurrent multi-core world. Thanks to community works such as Scala and Kilim, at least we have a something similar to actor-model but JVM has to support this itself.

reply: Isn't this more a comment on how you design and implement the actual code? I mean using techniques to bypass possible deficiencies that specific design style might introduce? I guess this is the root cause of all best practices discussions.

Moreover there issues such as; lack of hot-swap, weak light/green- threads (aka fiber), generics erasers (to be fixed in Java 7), and weak DBC support.
SS: concurrency techniques have always been a problem even on languages or platforms that fully support them. because apart from the language, it makes porting to be major show stopper, specially among POSIX based platforms. usually designers look for alternate ways to avoid complications of porting as well as concurrency possible design flaws itself


Please note that no language can be strong in every fields. A friend of everybody is a friend of nobody. I myself use and praise Java, but this does not prevent me from seeing the rest of the world and close my eyes to weaknesses.

reply: correct, at some point, companies have policies over technical directions they take. introducing new technologies  into existing development has never been easy (for approvers of course)

Our team did a survey for one of the banks regarding development platform, and eventually we concluded that Java is used more and more each day in banking field  like many others domains. In recent ten years Java has been the first choice in banking field and even it is used in core banking. I know for example that BoA had a great success in evaluating Java is a cluster running more than 2000 machines and in fact Java did it quite successfully. And we all know VOCA which (is not a bank but) does finance using Java across Europe.
SS: that applies to nearly every industry, however this goes back to the first point you made that when the system is up and running there is no way business owner or even service provider wants to move to new stuff. as long as it satisfies the business, but when it comes to provision of new interfaces the discussion of integration starts which that is totally separate discussion.

there are mixed interest into this within service providers though. at some level they want to keep customer happy, but on the other side, they need to compete within the industry and enforce customer to accept their new technologies, this opens door to whole new interesting / boring conversations.to recap, business need and technical capabilities are key aspects to such decisions, but some of the points you made could possibly be resolved by alternate solution, maybe from core technical side of the story