randombytes6869

Vert.X is a relatively light layer on top of Netty and it is quite nice to work with.

Spring WebFlux is also built on top of Netty, and missing some benchmarks, but I have no reason to think it would perform poorly. Its very easy to use for anyone with Spring experience.

The fastest frameworks are all nonblocking, like Express. They use streaming and reactive patterns, if it wasn't for Java's types everywhere some people wouldn't be able to tell the difference between Vert.X using RxJava and Express. The main design difference is that JS does non-blocking on a single core vs Java which does thread-per-core. Basically, in Java you can scale out non-blocking across all cores and still share memory when you want to.

If you don't want to deal with thread safety and non-blocking DropWizard performs quite well using traditional threads.

Just saying, performance and easy of use are not always exclusive. Maybe Vert.X didn't exist back when you were using Netty but these days it would be unthinkable to use Netty itself, the abstraction Vert.X provides is far easier to use and you don't really lose any performance.

Java's bad performance reputation is 90% due to old versions of Spring. Spring Boot has come a huge way, with performance maybe 100X better than Spring 4. Spring WebFlux takes this even farther with a Vert.X-like api, probably reaching near-Netty performance

This sucks so hard. Most Java libraries are planning to drop support for Java 8 when Java 17 hits LTS. This will completely divide the language into two, one for Android and the other for everything else.

Google could just run OpenJDK on phones and toss all the garbage they built, but they're too proud. The GC and performance of ART isn't anywhere near OpenJDK

This is exactly what newer versions of Java allow you to do. The problem is, nobody does it. I really like C# as a language, its better than Java in nearly every way. But this is a rare case where C# is implementing a feature Java has had for a very long time. And just like in Java, I don't think it will have the impact advertised.

> For example, the toString/hashCode/equals methods of record types (that are being added with Java 14). Are all generated at runtime via indy (Invoke Dynamic) instead of generating the bytecode for them at compile-time.

Didn't know that, interesting. I remember when invokeDynamic was added specifically to make VM conversion of dynamic languages easier, I guess JDK maintainers are somewhat guilty of the same laziness as the rest of us.

An aside, from reading about JVM targets of Haxe I learned that MethodHandles have truly terrible performance especially on Android.

I don't think the potential performance advantages of build time generation are overblown, just that everyone, even language designers, don't want to deal with the added complexity.

I could be wrong of course, but because of this I think the C# idea of generators will end up underutilized as well

Unfortunately I have doubts. This is one of the few features copied from Java instead of the other way around. You can pre-process code in Java and generate classes at build time instead of reflecting, but I know of just a handful of libraries that leverage this.

C# and Java are both guilty of this. I don't think generators will help nearly as much as hoped, because Java has the same problem even though it supports build time code generation through Annotation Processors for like over a decade, since Java 7 I think.

Reflection is just easier. Unless you go out of your way to use libraries that use code generation, Java is just as bad as C# in this regard.

There's a few bright spots, like MapStruct for object->object mappings and Dagger2 for dependency injection that are built entirely on code generation. But these are exceptions to the norm

reflection. Same problem Java has. Too many libraries fiddling with the code at runtime.

JS is also exposed to this. Some libraries can be shaken but I've always ran into random things breaking when trying it.

I remember reading about this in Java world a while back. To maintain safety you need to validate all the bytecode on load, so you can't really pre-cache it. Newer versions of Java use "class data sharing", but this only caches code after the local JVM has already validated it. Doesn't help with code files you've never seen before.

You could abandon validation and pre-compile but then running applications is no safer than c. You could modify the IR to do bad things like leak memory and crash VM.

JS has the same problem. Parsing and validating JS is a large part of page load times these days.

I'm not sure source generators will be the solution you hope for. Java has supported build time code generation for ages but everybody still reaches for reflection. A few popular libraries like MapStruct use build time generation instead of reflection, but again there's like 20 other popular libraries that do the same thing with reflection.

Java has attempted to fix the reflection hole with modules. You're supposed to pre-declare the classes you're reflecting in your assembly. But at current adoption rates its going to be another 20 years before you can count on all your dependencies using the module system correctly.

Trimming unused code is easy without reflection. Its been standard practice on Android for a long time. But every time I've tried to use it on servers I run into random crashes cause by runtime reflection and classloading.

Pretty unfortunate shortcomings to Java and C#. I don't think they'll ever be truly fixed unless somebody uses to nuclear option of disabling reflection completely