211–220 of 259 posts
I'm a bit surprised to see those examples, because there's nothing really new here. These are typical beginner pitfalls and have been there for at least a decade or more. Or maybe it's because I learned java in the late 90s and later used it for J2ME, and then using things like StringBuilder (StringBuffer in the old days) were almost mandatory, and you would be very careful trying to avoid unnecessary object allocati…
I think that the `sychronized` keyword in Java was a mistake. I've seen classes that are meant to be used by multiple threads where literally every method has `synchronized` because "that was the only way they could get it to work". Of course, if literally every method is synchronized it literally can't actually be used by multiple threads, it just looks like it is. Generally speaking I work pretty hard to avoid any…
The point of view is usually also wrong, they focus on the method call flow while they should think about protecting access to shared data.
This is a Spring specific gripe and I know this blog post doesn't assume Spring, but I hate seeing `new ObjectMapper()`. Spring Boot auto configures an ObjectMapper for you and you probably want the customization it gives you, including `java.time` handling and classpath scanning. I've wrestled with so many bugs caused by not using the `ObjectMapper` bean.
The code will not look pretty but it will be very fast.
A subject close to my heart, I write a lot of heavily optimised code including a lot of hot data pipelines in Java. And aside from algorithms, it usually comes down to avoiding memory allocations. I have my go-to zero-alloc grpc and parquet and json and time libs etc and they make everything fast. It’s mostly how idiomatic Java uses objects for everything that makes it slow overall. But eventually after making a JVM…
> And aside from algorithms, it usually comes down to avoiding memory allocations. I’ve heard about HFT people using Java for workloads where micro optimization is needed. To be frank, I just never understood it. From what I’ve seen heard/you have to write the code in such a way that makes it look clumsy and incompatible with pretty much any third party dependencies out there. And at that point, why are you even usin…
Earlier quoted context omitted.
Hidden class optimizations just make JavaScript objects behave a little more like Java class instances, where the VM knows where to find each field, rather than having to look it up like a map. It doesn't make JS faster than Java, it makes it almost as fast in some cases.
I can only say what I observed in testing, and that's that having millions of instances of a class like Point3D{x, y, z} in JS uses significantly less memory than in Java (this was tested on Android, not sure if relevant). It was quite some time ago so I don't remember the details.
It's also many versions behind the Java API (depending on when it happened).
So your data point is basically completely irrelevant.
Earlier quoted context omitted.
You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.
GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.
First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.
i'd be curious about a head to head comparison of how much the c2 actually buys over a static aot compilation with something serious like llvm. if it is valuable, i'd be surprised you can't freeze/resume the state and use it for instantaneous workload optimized startup.
I mean, both of your points are a thing, see https://www.azul.com/products/components/falcon-jit-compiler... for LLVM as a JIT compiler
and https://openjdk.org/jeps/483 (and in general, project Leyden)
This is a Spring specific gripe and I know this blog post doesn't assume Spring, but I hate seeing `new ObjectMapper()`. Spring Boot auto configures an ObjectMapper for you and you probably want the customization it gives you, including `java.time` handling and classpath scanning. I've wrestled with so many bugs caused by not using the `ObjectMapper` bean.
Have always really liked Java, but yeah, Spring overall has been terrible for the language. Autowiring is against the principles of a typesafe programming language - Don't make me guess what what object is going to be attached to a reference. And if you do, at least figure out what linked object is at compile time, not at run time. Spring autowiring makes Java seem as a whole unnecessarily complex. Think it should be…
Constructor autowiring is the application of the inversion of control and dependency injection pattern. If there was no autowiring, you could autowire the components together just the same with normal code calling constructors in the correct order. Spring just finds the components and does the construction for you.
Earlier quoted context omitted.
> Because every single database vendor will try to lock down their users to their DBMS. I mean, that already happens. It's quite rare to see someone migrate from one database to another. Even if they stuck to pure SQL for everything, it's still a pretty daunting process as Postgres SQL and MSSQL won't be the same thing.
> It's quite rare to see someone migrate from one database to another. I'm not discounting the level of effort involved, but I think the reason you don't see this often is because it is rare that simply changing DBMS systems is beneficial in and of itself. And even if it was frictionless (ie: if we had discovered ORM Samarkanda), the real choices are so limited that even if you did it regularly, you would soon run ou…