Some aspects of the problem, exagerated for effect: boolean isDead = (new I("0.9")).divide(new I("55")).multiply(new I("0.1")).lessThan(new I("1"))

Because you can't make your own types that work better.

So you can but you need to rewrite everything instead of just changing a type, and the code will look completely impossible to read.

And now all your simple scalar values need to exist on the heap as class object instances - and will incur plenty of runtime allocation costs for every arithmetic operation - or try to risk it with non-immutable heap-allocated objects, but that’s a recipe for disaster: no-one should ever think mutable shared state is a good first-design.

A lot of Java/JVM’s design decisions made sense in the mid-1990s, such as not supporting user-defined stack-allocated value-types and only supporting GC-managed objects - as main-memory was fast-enough compared to CPU registers - and many/most Java targets didn’t have any kind of CPU data cache - the idea of using the heap for basically everything wasn’t a bad design… back then. But now it is: high-perf code for the CLR means eliminating unnecessary GC allocation wherever possible - but in the JVM that isn’t possible.