The ecosystem has (at long last) standardized on JSpecify (https://jspecify.dev) for nullability annotations. JSpecify allows you to annotate a package or module with `@NullMarked` and your IDE and build (via ErrorProne+NullAway, typically) will check for null safety.

If you develop a library in Java and use it from Kotlin, the built-in Kotlin null-safety will recognize the JSpecify annotations on the library.

Null-restricted types are on the roadmap. See: https://openjdk.org/jeps/8303099

Java threads including Virtual Threads (JDK 21+) are preemptive.

They are not - and do not claim to be preemptive. They claim they are "not cooperative", but even that doesn't mean what anyone else thinks it means.

This paragraph is the only one containing the word "preempt" in JEP 444:

"The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads."

https://openjdk.org/jeps/444

How did we get to that?

We were talking about n:m threading, especially with threads being blocking IO-aware, being able to automagically turning such a call to non-blocking. Java more than fits that description.

The original message you replied to said (mistakenly):

> adopt true goroutines

Goroutines are preemptive. The distinction between cooperative and non-cooperative concurrency is very significant - it is the difference between never having to think about the scheduler and always having to thinking about it when doing CPU intensive tasks.

But this seems like a reasonable approach for reverse-engineering, and it seems the bug they found is real.

I don't think comparing new Pis to used micro pcs is fair. Compare a _used_ Pi with a used micro pc. If you have any geek friends, it's probably not hard to find a used Pi for free.

POJO is one of my favorite acronyms. Along with POTS and COTS.

POTS = Plain Old Telephony System COTS = Commercial Off-The-Shelf

> POTS = Plain Old Telephony System I worked for NY Telephone for years in the '80s, and it was referred to there as "Plain Old Telephone Service" not System. Not that it's a big deal at this point!

I started my career as a telecom tech in the mid Atlantic (late 90's) and can confirm it was that for me too

My understanding is that the Service was provided by the System.

I was in the ballpark!

And I think he's also acknowledging that not everybody has an application that needs these performance optimizations.

What are the most recent and/or highest performance of these?

Update: And mainline support and lack of proprietary boot blobs are two separate criteria. I've heard that NXP offers the former but not the latter.

Well, a 5-year-old chip may not count as "recent" but the RK-3588 boot chain is "almost fully open-source" [1]. And it seems like it took a major amount of effort (from Collabora, others) to get it this far. I don't know of any equivalent or newer chips that are "more" open, but would love to hear if there are.

[1] https://www.collabora.com/news-and-blog/blog/2024/02/21/almo...

Yeah, Collabora has done good job on rk chips, but even then there are still missing bits and pieces. At least for rk3588 they are documented nicely: https://gitlab.collabora.com/hardware-enablement/rockchip-35...

And the NPU part is also in the mainline kernel https://blog.tomeuvizoso.net/2025/07/rockchip-npu-update-6-w...

The "seated" option adds the feet and helps make it more recognizable.

Although that date should really only apply to the `m6502.asm` file. I think for a historical archive accuracy should be important. For example when was it licensed under the MIT license, I assume fairly recently. The file date should reflect that.