You don’t really need any of the apache commons libraries with modern java versions, if that’s what you were referring to. Also I think that most people who are considering doing jvm development would consider kotlin as an alternative language or maybe c# and dotnet as an alternative ecosystem. I believe rust, c or cpp are rarely going to be considerations for most people in that situation.
It seems like micronaut has been able to avoid runtime bytecode generation by doing everything at compile-time. I wonder if there’s things that you can’t do the micronaut way.
- There are how many computer architectures? A compile-once-run-anywhere binary looks closer to shipping a fancy interpreter with your code than shipping a compiled project. Runtime bytecode generation is one technique for making that fast.
- More generally, anything you don't know till runtime generates a huge amount of bloat if you handle it at compile-time. Imagine, e.g., a UI for dragging and dropping ML components to create an architecture. For as much compute as you're about to pour into training, even for very simple problems, it's worth something that looks like a compilation pass to appropriately fuse everything together. You could probably get away with literally shipping a compiler, but bytecode generation is a reasonable solution too.
- Some things are literally impossible at compile-time without boxing and other overhead. E.g., once upon a time I made a zero-cost-abstraction library allowing you to specify an ML computational graph using the type system (most useful for problems where you're not just doing giant matmuls all day). It was in a language where mutually recursive generics are lazily generated, so you're able to express arbitrary nth derivatives still in the type system, still with zero overhead. What you can't do though is create a runtime program capable of creating arbitrary derivatives; there must be an upper bound for any finite-sized binary (for sufficiently complex starting functions) -- you could cap it at 2nd derivatives or 10th or whatever, but there would have to be a cap. If you move that to runtime though then you can have your cake and eat it too, less the cost of compiling (i.e., bytecode generation) at runtime.
Etc. It's a tradeoff between binary size (which might have to be infinite in the compiled case) and runtime overhead (having to "compile" for each new kind of input you find).
I haven't used micronaut specifically, but I remember using Quarkus when it was rather new. It also does a lot at compile-time compared to, say, spring. The one big disadvantage I noticed that it's had to eject if you need to defer something to runtime for some reason. Don't know if it's still an issue, but that's really the only disadvantage I remember
It's up to the user agent. On one platform it's the spacebar, on another it's the return key. Of course, fake controls written in JS wouldn't be able to do this. Which is why it's the wrong thing to do.
In kotlin (maybe also java?) you can use the jetbrains @Language annotation to get syntax highlighting on string variables. A little more verbose but maybe it works for you.
jOOQ doesn't work with string variables (I mean it can, but that's not the point of that library). It compiles your database schema into objects and then you invoke a very SQL-like API over them. The code then reads very close to the actual SQL and since the schema is encoded in the Java objects you get the usual code completion for things like columns, tables, stored procedures, indices..
What you don't get is the more advanced, entire-query-level hints, because IDE's can't tell that Java / Kotlin / ... code is actually the SQL that will be emitted if you squint just a little bit :)
Modern Java has Coordinated Restore at Checkpoint (CRaC) as well as ways to compile it to native binaries that can start very fast (GraalVM & Substrate VM). The former has the benefit of a JIT as well!
Have you used any of these? I’m looking for ways to speed up start time of JVM, but almost options I’ve seen so far are “experimental” and not sure best route to take. For example was sad to see ahead of time compile being removed from JDK.
