I say this as a Java developer who thinks Java is on the whole pretty decent: Java is way behind browser vendors when it comes to adding new ciphers and dropping broken ciphers.
Between the infrequent releases, the slavish devotion to maintaining backwards-compatibility, the sluggish release distribution, and the general conservative nature of some Java shops when it comes to upgrading, it's just not reasonable to expect the average non-java-using organisation to wait for Java before dropping broken crypto.
If you're running the latest LTS release of Ubuntu you'll get Firefox 37.0.2, released May 2015. But you'll still get Java 7, despite the fact Java 8 was released in March 2014. Giving you cutting-edge TLS1.0 and CBC ciphers [1]. And least Java 7 looks good compared to Java 6 [2] which has no SNI support, a stack of weak ciphers, and only supports the most obscure ciphers. And I know some people who are still running Java 6 in production systems.
If you wait for every last Java 6 holdout before deploying a secure configuration, you'll be waiting forever. Leave us behind, we'll only slow you down [3].
I'd say best practices for Java shops should be to move the SSL termination to a proxy in front of the app server. This doesn't work if you're doing mutual TLS to authenticate users in your Java stack of course, and I'm sure there's a bunch of other use cases where you can't, and it would of course be ideal if Java could keep up with security. But given the state of the Java world, just drop in an TLS termination proxy wherever possible (nginx works great) and forget about doing it in Java.
What people are really saying here is that the native APIs provided the standard Java packages are behind. Java, as a platform, has no inherent limitations like this. Feel free to check out the excellent work of the team a Bouncy Castle [1]. They offer full ECDHE support in a really well maintained library. Sure, Oracle should build this in natively (and I admit that it does look bad when you see it on SSL Labs), but there are other options.
Ubuntu uses IcedTea I think, which in its latest version supports 1024-bit and 2048-bit DHE on the server side (768-bit DHE is still default though) and up to 4096-bit DHE on the client side.
Between the infrequent releases, the slavish devotion to maintaining backwards-compatibility, the sluggish release distribution, and the general conservative nature of some Java shops when it comes to upgrading, it's just not reasonable to expect the average non-java-using organisation to wait for Java before dropping broken crypto.
If you're running the latest LTS release of Ubuntu you'll get Firefox 37.0.2, released May 2015. But you'll still get Java 7, despite the fact Java 8 was released in March 2014. Giving you cutting-edge TLS1.0 and CBC ciphers [1]. And least Java 7 looks good compared to Java 6 [2] which has no SNI support, a stack of weak ciphers, and only supports the most obscure ciphers. And I know some people who are still running Java 6 in production systems.
If you wait for every last Java 6 holdout before deploying a secure configuration, you'll be waiting forever. Leave us behind, we'll only slow you down [3].
[1] https://www.ssllabs.com/ssltest/viewClient.html?name=Java&ve... [2] https://www.ssllabs.com/ssltest/viewClient.html?name=Java&ve... [3] http://tvtropes.org/pmwiki/pmwiki.php/Main/IWillOnlySlowYouD...