3 ms·

1. Java already has succinct lambda expressions. parameter -> expression (parameter1, parameter2) -> expression (parameter1, parame

• gavinray 3y ago
  > and function signatures like the below might be "clunky" from your point of view, but IMHO are more clear since they document explicit types. (and you can navigate to their javadoc) Blah doSomething(BiFunction<String, Integer, Foo> fn) What happens when you want to pass a function of arity 3, 4, 5 or 6? Also, it's nice to be able to give identifiers to the arguments: // In Kotlin (absurd example, just to prove a point) fun withHandler( handler: (name: String, age: Int, isAdult: Boolean, callback: (Int, Int, Int) -> Unit) -> Unit ) { handler("John", 25, true) { println(it, it, it) } } // In Java: interface Handler { void handle(String name, int age, boolean isAdult, Callback callback); } interface Callback { void call(int a, int b, int c); } class JavaClass { public static void withHandler(Handler handler) { handler.handle("John", 25, true, (a, b, c) -> { System.out.println("a: " + a + ", b: " + b + ", c: " + c); }); } }
  • lenkite 3y ago
    It is possible to create custom functional interfaces in Java. One is not restricted to what is provided in the stdlib. @FunctionalInterface public interface VargsFunction<T,R> { R apply(T... t); } @FunctionalInterface public interface QuadFunction<T, U, V, W, R> { public R apply(T t, U u, V v, W w); } Of-course Java is nowhere as flexible as C++ in this regard which has variadic templates, template parameter packs and template-template parameters. Well, you can do this with currying if one is feeling lazy, but obviously not recommended: Function<One, Function<Two, Function<Three, Function<Four, Function<Five, Six>>>>> func = a -> b -> c -> d -> e -> 'z'; The second point (named parameters) is one that several language designer greybeards (not just Java) have taken a deliberate design decision against for varying reasons. Use builders/records/structs is the usual advice given here anytime you ask them this question.
• soulbadguy 3y ago
  > 5. Java with virtual threads now has far better support for async programming than Kotlin or Scala. It is now competitive with Golang in async ease-of-use green thread/stackfull coroutine such as in go/java and stackfless coroutine as in kotlin are well know solutions for introducing async programming in a way that feel natural to dev. They both have strength and limitation, i don't think one offer "far better support for async programming", and even more importantly they are not mutually exclusive and can be used together depending on one needs (see https://www.youtube.com/watch?v=zluKcazgkV4 https://www.youtube.com/watch?v=zluKcazgkV4)
• kllrnohj 3y ago
  > Java with virtual threads now has far better support for async programming than Kotlin or Scala. It is now competitive with Golang in async ease-of-use. Only if your problem set matches one of using threads. There are other async problems that don't fit cleanly into a "force it to be a blocking thread instead" model. In particular those in front ends where being on a specific thread at specific times is important. Green threads work great for server-style async, which is where go is seeing success. Then again servers are probably the last major usage of OpenJDK, so copying Go's tradeoffs here probably makes sense for it. But it's not unambiguously "the best way to do async"
  • kaba0 3y ago
    AFAIK you can create a virtual thread executor backed by a single native thread.
• ahtihn 3y ago
  > BiFunction<String, Integer, Foo> fn That signature is awful. I never remember if the return type is first or the last in the list. Also the "generic" types don't document anything, by design. Yes it's an actual type but it's too generic to have any value over something like Kotlin or Scala declaration. It's impossible to tell from this signature what the input and output types are supposed to represent. Almost always it's better to define a new functional interface than using BiFunction or similar.