No Promises in Java.

Sadly - the language is really not quite as 'async' as we would like it to be.

Java scales much better than Javascript though, and I mean that in the architectural sense.

Past 50K lines of code - the lack of typing in JS can start to be hell, unless you really know what you are dong.

Of course, you move much more quickly early on in JS and that's actually important: you need to be able to 'iterate and adapt' in todays world. So it's kind of a paradox.

If you're building a bank, you do it deliberately with Java or something like that.

If you're building a nimble startup, you can start with Node and if there are systems that reach a certain degree of maturity and the uses/cases and data model start to settle you can fold over systems to Java or something like that.

A great team can use anything in the end though - that said, it's really hard to find super talented and responsible people across the board.

Java has an implementation of Futures, but it's not very good. In the JVM, however, we have Scala Futures, which IMO are far better than Javascript promises. And on top, you have a lot more flexibility deciding how to run those futures, as far as threading goes, because they run on top of Java's very sturdy ExecutorService. There are a variety of executor services for pretty much anything you want.

JVM concurrency is best in class. It's just the Java language itself that moves at a snail's pace.

Java has Futures, which are close, and allow similar patterns of code. But they're not woven into the language as pervasively as Promises are into JavaScript. You need to deal with asynchronous-ness explicitly.

There's also, in true Java tradition, a number of competing implementations of Promise based frameworks. The one I've used, Ratpack, defines and uses promises almost identically to JavaScript/Node.js.

Look into Scala and Futures, very similar.

In either SE or EE, no. Most people use Google's Guava library, which contains Futures that have that functionality.