One important thing to keep in mind when comparing Java lambdas and JS functions is how both fields of vision span.
In Java, lambdas can only efficiently use final variables and display only those that are explicitly needed. In JS, functions can access all variables in all parent closures and thus capture everything.
The result of this is the possibility of a memory leak if you do not know what you are doing. As an example:
IntSupplier getSupplier(MyMemoryHeavyClass heavy) { int x = heavy.hashCode(); return () -> x; }
This method will return a lambda that actually contains only int. There is no problem. However, the naive translation into JavaScript ...
function getSupplier(heavy) { var x = heavy.hashCode(); return function() { return x; }; }
This may not be obvious at first glance, but it has a serious problem. A function expression will capture ALL within the scope, including the heavy parameter (even if it is not referenced inside the returned function). As a result, it prevents heavy collection (which in this example requires a large amount of memory) from garbage collection and thus remains in memory as long as the return function exists.
EDIT
As stated in the comments, this information may be a bit outdated, as modern engines look more reasonable. The V8, for example, will apparently only capture what it considers necessary. However, it can still be fooled, since all functions created in the same scope have the same closure.
For example, adding a string (function y() { return heavy; }); , which otherwise would mean nothing, will force heavy to close the same as return x; creating a leak.
Although itβs far-fetched in this particular example, itβs far from unbelievable that similar problems can occur with the naive translation of Java methods containing multiple lambdas.