Primitive variables in Java, such as `int`, `boolean`, and `double`, store their actual values directly in memory. When they are local variables inside a method, this memory is typically allocated on the thread's stack. These primitives do not have the structure or overhead of an object, including the object header used by the Garbage Collector (GC) to manage heap-allocated objects.
If a primitive value must be treated as an object (e.g., when stored in a Java Collection like ArrayList or when passed to a method that requires an object), Java uses a process called `boxing` to wrap the primitive value into an instance of its corresponding Wrapper class (e.g., Integer, Boolean, Double). These Wrapper objects are allocated on the heap and do possess the necessary object header, making them subject to the GC's management.
No, but yes. There is nothing in the standard library, that implements the Collection-interface and works with primitives. However you can write your own and there are several implementations of collections for primitives. The problem is that you have to implement them seperately for each type of primitive (e.g. an IntList, DoubleList, BooleanList...).
My bad, I think they are called Generics in Java. I always thought of these as the same thing, just with different names in different languages, is that wrong?
Templates and generics are very different. Afaik Templates generate specialised code for each invocation of that template with a different type.
Java uses Type Erasure for Generics, which means that generic type variables are checked at compile time, but that type information is not available at runtime. At compile time you may have List<Foo> and List <Bar> but at runtime its all just List<Object> (Object being the base type everything inherits from). Basically List stores a bunch of pointers to objects and since pointers can point to anything a List can basically "store" anything.
Then you have a divide between primitives and Objects in Java, where primitives are double, int, boolean etc.. Primitives are types in the C-sense, e.g. int is nothing more than a 32-bit number, not a class in the Java-sense. But since ints are not classes and as such do not inherit from Object, they cannot be placed inside of List<Object>. Therefore there cannot be a List<int>. But there is Integer, which is an Object-wrapper around an int, meaning you can have a List<Integer>. This is called boxing and like all indirection carries a performance penalty.
Java hopes to heal this rift between primitives and Objects through something called Project Valhalla which has been 10 years in the making and is expected to land in the next two years or so.
Yeah that's very much an explicit design philosophy of Java, dating way back. Let other languages experiment, and adapt what proves useful.
It hasn't worked out in terms of delivering perfect language design, but it has worked out in the sense that Java has an almost absurd degree of backward compatibility. There are libraries that have had more breaking changes this year than the Java programming language has had in the last 17 releases.
They are a good idea. They solve the problem that you don't know where an exception is coming from (the "invisible control flow" complaint), and let the compiler help you to avoid mistakes when refactoring. There is zero valid reason to hate on checked exceptions.
The only problem with them is that they don’t work well with lambdas (and related features like Stream). If you need to call a method that throws a checked exception inside of a Stream, there’s no good way to pass it up other than re-throwing it as unchecked or some other hack (like collecting all the thrown exceptions in a separate loop).
A different implementation of lambdas that allow for generic exceptions would probably solve it, but then that introduces other issues with the type system.
My other complaint is that the standard library didn’t have enough pre-made exceptions to cover common usecases.
When you use lambdas you lose control over when and how often your code gets executed. Since checked exceptions are very often thrown by code that has side effects, I'd consider the friction to be a feature.
> collecting all the thrown exceptions in a separate loop
It's really not comfortable to do so in Java since there is no standard `Either` type, but this is also doable with a custom collector.
> Since checked exceptions are very often thrown by code that has side effects, I'd consider the friction to be a feature.
This is true, but I think that it’s partly true because checked exceptions are cumbersome here. In my ideal world, the majority of functions would throw exceptions, testing cases that today are either missed or thrown as unchecked exceptions.
Some inspiration came from C++, Modula-3, CLU etc. (note, inspiration, not validation of the idea)
They exist since v1, which had very different philosophy than Java of 2010s-2020s. 1990s were an interesting time in language design and software engineering. People started reflecting on the previous experiences of building software and trying to figure out how to build better, faster, with higher quality. At that time checked exceptions were untested idea: it felt wrong not to have them based on previous experience with exceptions in C++ codebases, but there were no serious arguments against them.
I assume it was the other way around, a slight twist to exceptions, only enforced by the compiler (the JVM doesn't care about checked/unchecked) probably seemed a cheap and reasonable way to implement explicit error handling. Given that Java ergonomics of the time didn't offer any convenient and performant way to return multiple values instead.
I always thought of it as a reaction to the “your program can throw anywhere for any reason due to an exception” nature of C++.
So they added checked exceptions. That way you can see that a function will only ever throw these two types of exceptions. Or maybe it never throws at all.
Of course a lot of people went really overboard early on creating a ton of different kinds of exceptions making everything a mess. Other people just got into the habit of using RuntimeExceptions for everything since they’re not checked, or the classic “throws Exception“ being added to the end of every method.
I tend to think it’s a good idea and useful. And I think a lot of people got a bad taste in their mouth early on. But if you’re going to have exceptions and you’re not going to give some better way of handling errors I think we’re probably better off than if there were no checked exceptions at all.
As a co-founder of Ginkgo Health[1], this is a refreshing discussion to see.
The "Is this aging?" article perfectly articulates the philosophy that drove us to start the company. We saw a huge disconnect between the longevity industry's focus on hype and moonshots, and what the science actually shows is effective for improving healthspan. The article's point about focusing on frailty and sarcopenia is spot-on ; functional health is one of the most powerful and evidence-based levers we have to improve quality of life as we age.
That's precisely why we built Ginkgo Active. We wanted to create a genuine "geroprotector" that was accessible to everyone, not just a theoretical treatment for the wealthy.
When we responded[2] to the recent CMS RFI[3] on the Health Technology Ecosystem, we outlined this exact approach. Our goal is to provide a practical solution to functional decline and chronic disease, which are massive burdens on the healthcare system.
Here’s how our thinking aligns with the article's main points:
Focus on Function, Not Just Biomarkers: Instead of chasing clocks, we focus on delivering personalized exercise prescriptions designed to improve strength, balance, and cardiovascular health. Our AI platform uses over 170,000 rules from authoritative sources like the American College of Sports Medicine to create these plans.
Prevention and Healthspan: Our platform is built to help people before they get sick, preventing or delaying the onset of 18 different chronic condition risk factors. This is about adding healthy years to life, which is the core of a real aging intervention.
Accessibility and Equity: We believe this kind of preventative care should be a right, not a privilege. We intentionally designed our platform so that it doesn't require expensive wearables or equipment. Our goal is to provide the same expert-level care to everyone, regardless of their income or where they live.
We believe the first real, scalable product of the longevity industry will be one that improves healthspan for the many. That's the problem we're dedicated to solving.
