Essentially, I've tried to throw a task which, I thought, Claude won't handle. It did with minimal supervision. Some things had to be done in "adversarial" mode where Claude coded and Codex criticized/reviewed, but it is what it is. An LLM was able to implement generics and many other language features with very little supervision in less than a day o_O.
I've been thrilled to see it using GDB with inhuman speed and efficiency.
I am very impressed with the kind of things people pull out of Claude's жопа but can't see such opportunities in my own work. Is success mostly the result of it being able to test its output reliably, and of how easy it is to set up the environment for this testing?
Claude will also tend to go for the "test-passing" development style where it gets super fixated on making the tests pass with no regards to how the features will work with whatever is intended to be built later.
I had to throw away a couple days worth of work because the code it built to pass the tests wasn't able to do the actual thing it was designed for and the only workaround was to go back and build it correctly while, ironically, still keeping the same tests.
You kind of have to keep it on a short leash but it'll get there in the end... hopefully.
Btw, working on Java 7 support. At this moment I sorta have working Java 7 compiler targeting Java 6 bytecode (Java 7 has StackMapTable which is sort of annoying).
Also, I've tried to replace parser with a modern one. Claude succeeds in generating Java 8 parsers with various parser generators/parser combinators but fails to resolve extremely tight coupling.
looking at the "att" branches (excuse my unhealthy curiosity) I can only say - "jesus fucking christ".
from the old parser ast -> to json -> to new ast representation (that is basically again copy of the old one) -> to some new incomplete bytecode generation
im sure there is some good explanation, but....why?! :)
Ah, by the way. I've tried to do the same with Codex (gpt-5.1-codex-max) and Gemini (2.5 pro), both failed spectacularly. This job was done mostly by Sonnet 4.5. Java 6 did not require intensive supervision. Java 7 parts are done with Opus 4.5 and it constantly hits its limits, I have to regularly intervene.
I'm genuinely curious on how well this is working, is there an independent Java test suite that covers major Java 5/6 features that can verify that the JOPA compiler works per the spec? I.e. I see that Claude has wrote a few tests in it's commits, but it would be wonderful if there's a non-Clauded independent test suite (probably from other Java implementations?) that tracks progress.
I do feel that that is pretty much needed to claim that Claude is adding features to match the Java spec.
Related: I recently got javac working with OpenLDK, my JVM bytecode to Common Lisp transpiler. The `javacl` binary is a dumped sbcl image that behaves just like OpenJDK javac program, but with CL under the hood (eg. java objects/methods are all CLOS).
The Bootstrappable Builds community would likely be against using AI auto-generated code as part of any bootstrap process. If its auto-generated, it isn't considered "source" code.
I won't call this "auto-generated". It's source code which was written with a lot of assistance from the models but it's not like I did nothing - just try to repeat this.
23 comments
[ 3.0 ms ] story [ 49.4 ms ] threadI've been thrilled to see it using GDB with inhuman speed and efficiency.
I had to throw away a couple days worth of work because the code it built to pass the tests wasn't able to do the actual thing it was designed for and the only workaround was to go back and build it correctly while, ironically, still keeping the same tests.
You kind of have to keep it on a short leash but it'll get there in the end... hopefully.
How does one set up this kind of adversarial mode? What tools would you need to use? I generally use Cline or KiloCode - is this possible with those?
Also, I've tried to replace parser with a modern one. Claude succeeds in generating Java 8 parsers with various parser generators/parser combinators but fails to resolve extremely tight coupling.
from the old parser ast -> to json -> to new ast representation (that is basically again copy of the old one) -> to some new incomplete bytecode generation
im sure there is some good explanation, but....why?! :)
I do feel that that is pretty much needed to claim that Claude is adding features to match the Java spec.
"Modernizing" to Java 6 is amusing.