News for hackers. Stuff that matters.
Re:Fluent: Static Extension Methods for Java by MrBuddyCasino on Monday July 03, 2023 @03:35AM (#36569952)
When you start transforming the AST, that might be a sign you should switch languages. Kotlin is nice, why not use it.
Re:Fluent: Static Extension Methods for Java by rogerkeays on Monday July 03, 2023 @03:48AM (#36570037)
Kotlin is great, but it is a fairly heavy dependency if all you want is extension methods. Java has mostly caught up in many other aspects, so I'm experimenting with Java + one or two compiler hacks. Checked exceptions are my next target...
Re:Fluent: Static Extension Methods for Java by javanonymous on Monday July 03, 2023 @06:48AM (#36571161)
I'm curious about how you plan to work on checked exceptions.

If it's just about ignoring forced exception management, Lombok provides the @SneakyThrows annotation.

I would need something more before I add a new type of extension. Maybe if you could solve the null-check issue.

i.e. rewriting

    var x = a.getFoo()?.getBar()
to

    var x = a.getFoo() != null ? a.getFoo().getBar() : null
In that case I may consider it for my personal projects, and then potentially recommend it at work once it becomes more widespread and has IDE support.
Re:Fluent: Static Extension Methods for Java by rogerkeays on Monday July 03, 2023 @09:14AM (#36572433)
I don't know yet. I'm already using some of my own variations of sneakyThrows, but what I really want is just to disable the whole damn thing in the compiler (checked exceptions are a compiler feature, not a JVM feature). I won't be changing the Java syntax though, sorry!
Re:Fluent: Static Extension Methods for Java by zeedude on Monday July 03, 2023 @09:57AM (#36572934)
Re:Fluent: Static Extension Methods for Java by rogerkeays on Monday July 03, 2023 @10:27AM (#36573391)
sweet
Re:Fluent: Static Extension Methods for Java by kaba0 on Monday July 03, 2023 @06:23AM (#36571017)
I think Kotlin differs far too much from Java — I don’t want all those plus features that will inevitably branch too far from the JVM/Java corresponding code, becoming its new thing.

I might want a nearly-Java language that only adds trivial syntax sugar, but are otherwise the same. Groovy sort of had a good initial idea here (being a superset of Java, though again, it has grown apart a bit since).

For me Kotlin lives in this weird limbo between these two extremes. If I want a different language on the JVM I would rather do Scala or Clojure.

Re:Fluent: Static Extension Methods for Java by vips7L on Monday July 03, 2023 @09:53AM (#36572892)
For me, if Kotlin is on the table I might as just use C# where the entire ecosystem is built around these concepts.
Re:Fluent: Static Extension Methods for Java by kaba0 on Monday July 03, 2023 @10:11AM (#36573123)
I wouldn’t really leave behind the JVM ecosystem, which is much bigger and better quality than the .NET one from what I gathered (though it is still good and bigger than most other languages’). And other people’s code is the numero uno productivity boost, so it’s an important area.
Re:Fluent: Static Extension Methods for Java by vips7L on Monday July 03, 2023 @01:26PM (#36576174)
I think I would be fine with a smaller ecosystem. I've seen a lot of projects that have made bad choices in libraries because there are too many. Sometimes I feel like if there was just one blessed jdk way it would be a lot simpler. Honestly, the only thing that is keeping me from .NET right now is async/await. Pron really did Java a service by pushing for virtual threads.