Charles Oliver Nutter
@headius.bsky.social
JRuby co-lead, Java champion, Ruby hero, JavaOne Rockstar, international traveler and speaker. Book me for your next event! I depend on your donations and sponsorships! https://github.com/sponsors/headius
I have never had someone approach my projects and be disappointed that I wanted to see more discussion about an issue before diving into an ill-advised fix. On the contrary, everyone I've ever talked to appreciates how interactive we are and it drives them to contribute more.
November 21, 2025 at 7:16 PM
I have never had someone approach my projects and be disappointed that I wanted to see more discussion about an issue before diving into an ill-advised fix. On the contrary, everyone I've ever talked to appreciates how interactive we are and it drives them to contribute more.
Taken to an extreme... I would never accept a PR without discussion (and I assume you wouldn't either), so why is it different if there's no PR yet? At some point you may need to show code changes to further the discussion, but denying discussion until someone pushes a PR is absurd.
November 21, 2025 at 7:13 PM
Taken to an extreme... I would never accept a PR without discussion (and I assume you wouldn't either), so why is it different if there's no PR yet? At some point you may need to show code changes to further the discussion, but denying discussion until someone pushes a PR is absurd.
I think it's absurd to expect everyone coming to your project to swim around hundreds of thousands of lines of code without any guidance before you will even talk to them about the issue. That is the approach that has consistently failed for me. People just walk away from the project completely.
November 21, 2025 at 7:09 PM
I think it's absurd to expect everyone coming to your project to swim around hundreds of thousands of lines of code without any guidance before you will even talk to them about the issue. That is the approach that has consistently failed for me. People just walk away from the project completely.
Of course I disagree. If someone comes to me with an issue and I would like them to try to fix it, I give them pointers on where to look and what the likely problem might be. I treat every issue as a gift, and I respond in kind by providing guidance. It's an opportunity to make a contributor.
November 21, 2025 at 7:08 PM
Of course I disagree. If someone comes to me with an issue and I would like them to try to fix it, I give them pointers on where to look and what the likely problem might be. I treat every issue as a gift, and I respond in kind by providing guidance. It's an opportunity to make a contributor.
Combined with compact objects in JDK 25+ this could be a huge breakthrough in scaling JRuby apps. What if your JRuby app's working set could be half as big on the heap, with improved throughput due to smaller objects and less allocator overhead?
A first shot at drastically reducing object size in JRuby, in this case by using more compact wrappers for small Integers: buff.ly/KxZEKBh
Other fixes will reduce the size of "immediate" types (numerics, etc) by up to 16 bytes and the size of ALL objects by 5-6 bytes. 🤯
Other fixes will reduce the size of "immediate" types (numerics, etc) by up to 16 bytes and the size of ALL objects by 5-6 bytes. 🤯
Specialize Fixnum by headius · Pull Request #9085 · jruby/jruby
This adds specialized RubyFixnum subtypes for byte, short, int, and long, making RubyFixnum abstract. All allocations of a Fixnum are boxed using the most compact size. This drastically reduces the...
buff.ly
November 21, 2025 at 9:57 AM
Combined with compact objects in JDK 25+ this could be a huge breakthrough in scaling JRuby apps. What if your JRuby app's working set could be half as big on the heap, with improved throughput due to smaller objects and less allocator overhead?
A first shot at drastically reducing object size in JRuby, in this case by using more compact wrappers for small Integers: buff.ly/KxZEKBh
Other fixes will reduce the size of "immediate" types (numerics, etc) by up to 16 bytes and the size of ALL objects by 5-6 bytes. 🤯
Other fixes will reduce the size of "immediate" types (numerics, etc) by up to 16 bytes and the size of ALL objects by 5-6 bytes. 🤯
Specialize Fixnum by headius · Pull Request #9085 · jruby/jruby
This adds specialized RubyFixnum subtypes for byte, short, int, and long, making RubyFixnum abstract. All allocations of a Fixnum are boxed using the most compact size. This drastically reduces the...
buff.ly
November 21, 2025 at 9:29 AM
A first shot at drastically reducing object size in JRuby, in this case by using more compact wrappers for small Integers: buff.ly/KxZEKBh
Other fixes will reduce the size of "immediate" types (numerics, etc) by up to 16 bytes and the size of ALL objects by 5-6 bytes. 🤯
Other fixes will reduce the size of "immediate" types (numerics, etc) by up to 16 bytes and the size of ALL objects by 5-6 bytes. 🤯
In this case, they are unfortunately projects I cannot avoid and do not own. I'd be happy to file a PR if I had any idea how to fix the issue, but without some discussion, I don't know where to start.
November 21, 2025 at 5:46 AM
In this case, they are unfortunately projects I cannot avoid and do not own. I'd be happy to file a PR if I had any idea how to fix the issue, but without some discussion, I don't know where to start.
We can live out the remainder of our days sending each other multi-thousand word essays.
November 21, 2025 at 5:44 AM
We can live out the remainder of our days sending each other multi-thousand word essays.
Am I "old" for wanting to discuss a bug and its potential fixes *before* opening a pull request? I'm frequently chided for talking about the issue first rather than just making a PR right away (i.e. "wasting our time"). Personally I tend to reject nontrivial PRs that had no discussion.
November 20, 2025 at 11:06 PM
Am I "old" for wanting to discuss a bug and its potential fixes *before* opening a pull request? I'm frequently chided for talking about the issue first rather than just making a PR right away (i.e. "wasting our time"). Personally I tend to reject nontrivial PRs that had no discussion.
Given the test suites I have available, none of this is unverifiable. It becomes a question of wasting my time iterating with an LLM that can't actually reason about the code and keeps feeding me broken logic. At some point the risk and effort is no longer worth the reward.
November 20, 2025 at 9:59 PM
Given the test suites I have available, none of this is unverifiable. It becomes a question of wasting my time iterating with an LLM that can't actually reason about the code and keeps feeding me broken logic. At some point the risk and effort is no longer worth the reward.
Asked ChatGPT to find the best way to choose the smallest Number box for a long value. Several options were discussed with JMH benchmarks. Code looked good, but unfortunately most options introduced tricky negative boundary bugs, despite my requirements. How can I ever trust it to write code?
November 20, 2025 at 8:27 PM
Asked ChatGPT to find the best way to choose the smallest Number box for a long value. Several options were discussed with JMH benchmarks. Code looked good, but unfortunately most options introduced tricky negative boundary bugs, despite my requirements. How can I ever trust it to write code?
TFW AI generates *completely wrong* code that almost looks correct. Pretty hard to have any confidence in LLMs for code generation when they creates nonsense like this.
buff.ly/kMsOHX0
buff.ly/kMsOHX0
November 20, 2025 at 12:56 AM
TFW AI generates *completely wrong* code that almost looks correct. Pretty hard to have any confidence in LLMs for code generation when they creates nonsense like this.
buff.ly/kMsOHX0
buff.ly/kMsOHX0
This new AI world continues to frustrate the hell out of me. I'm seeing pull requests that clearly don't solve the problem, conversations that are automated nonsense, and fake engagement across all social media. No wonder people have no excitement about OSS work lately. ☹️
November 19, 2025 at 6:51 PM
This new AI world continues to frustrate the hell out of me. I'm seeing pull requests that clearly don't solve the problem, conversations that are automated nonsense, and fake engagement across all social media. No wonder people have no excitement about OSS work lately. ☹️
I don't know, i haven't done it yet.
November 15, 2025 at 8:31 PM
I don't know, i haven't done it yet.
I mean fully compiling Ruby to JVM bytecode. I don't believe that performance would be bad enough to outweigh the benefits. JRuby already can do that now but Native Image can't handle invokedynamic.
November 14, 2025 at 7:59 PM
I mean fully compiling Ruby to JVM bytecode. I don't believe that performance would be bad enough to outweigh the benefits. JRuby already can do that now but Native Image can't handle invokedynamic.
I get asked about this a lot, so... Would anybody be interested enough in a native-compiled Ruby implementation to fund a fork of JRuby that can be compiled with GraalVM Native Image? It's totally doable, but the work involved is nontrivial and incompatible with the JVM version.
November 13, 2025 at 10:31 PM
I get asked about this a lot, so... Would anybody be interested enough in a native-compiled Ruby implementation to fund a fork of JRuby that can be compiled with GraalVM Native Image? It's totally doable, but the work involved is nontrivial and incompatible with the JVM version.
Good progress discussing a Ruby "deep_freeze" feature at this month's ruby-core dev meeting! matz is not opposed to adding the feature, but we need to formalize the protocol and decide how much control user-defined objects should have over the process. We'll make it happen!
November 13, 2025 at 4:05 PM
Good progress discussing a Ruby "deep_freeze" feature at this month's ruby-core dev meeting! matz is not opposed to adding the feature, but we need to formalize the protocol and decide how much control user-defined objects should have over the process. We'll make it happen!
Java could do a lot to eliminate its "bloated" reputation by providing space-efficient collections out of the box. HashMap is enormous compared to a direct-addressing implementation and there's no Set impl that doesn't just wrap a Map instance. So frustrating.
November 12, 2025 at 9:56 PM
Java could do a lot to eliminate its "bloated" reputation by providing space-efficient collections out of the box. HashMap is enormous compared to a direct-addressing implementation and there's no Set impl that doesn't just wrap a Map instance. So frustrating.
Aurora borealis over my home in Minnesota last night. Quite a light show!
November 12, 2025 at 2:06 PM
Aurora borealis over my home in Minnesota last night. Quite a light show!
Thankfully, we don't have to sacrifice any optimizations or VM features like CRuby does, since we punt all that to the JVM. The rest is just working around missing posix features and normalizing paths and newlines the same way as CRuby. It's still a big hassle to support, but I think it's worth it.
November 11, 2025 at 6:19 PM
Thankfully, we don't have to sacrifice any optimizations or VM features like CRuby does, since we punt all that to the JVM. The rest is just working around missing posix features and normalizing paths and newlines the same way as CRuby. It's still a big hassle to support, but I think it's worth it.
Yeah, WSL is clearly just a band-aid over the fact that Windows behaves so differently from Unix systems... just a much better Cygwin. At the end of the day either you you want to develop on a Unix or you don't, and WSL clearly isn't a solution for the latter case.
November 11, 2025 at 6:17 PM
Yeah, WSL is clearly just a band-aid over the fact that Windows behaves so differently from Unix systems... just a much better Cygwin. At the end of the day either you you want to develop on a Unix or you don't, and WSL clearly isn't a solution for the latter case.
That sounds like me when I first transitioned off of Windows in the early 2000s. I could probably cope with the lack of posix, since equivalent functionality is roughly available in win32 APIs (for most things), but backslashes and newlines are super frustrating to deal with and impossible to avoid.
November 11, 2025 at 6:13 PM
That sounds like me when I first transitioned off of Windows in the early 2000s. I could probably cope with the lack of posix, since equivalent functionality is roughly available in win32 APIs (for most things), but backslashes and newlines are super frustrating to deal with and impossible to avoid.
It makes some things easier, but we still have to deal with path separators and newlines and lack of a full posix implementation and so on. Couple that with the fact that it's the only operating system that does all these weird things and it gets back-burnered a lot.
November 11, 2025 at 1:37 AM
It makes some things easier, but we still have to deal with path separators and newlines and lack of a full posix implementation and so on. Couple that with the fact that it's the only operating system that does all these weird things and it gets back-burnered a lot.
I wish we could but there's still a huge percentage (majority?) of Windows-based developers that just don't do unix.
November 10, 2025 at 10:31 PM
I wish we could but there's still a huge percentage (majority?) of Windows-based developers that just don't do unix.
I sent an impassioned protest to the fosdem folks, but I'm pretty sure it's too late to make any changes this year. If there's a committer's workshop I will go anyway, but without that, it's tough to make a business case.
November 10, 2025 at 10:13 PM
I sent an impassioned protest to the fosdem folks, but I'm pretty sure it's too late to make any changes this year. If there's a committer's workshop I will go anyway, but without that, it's tough to make a business case.