I've been thrilled to see it using GDB with inhuman speed and efficiency.
I won't say so. From my experience the key to success is the ability to split big tasks into smaller ones and help the model with solutions when it's stuck.
Reproducible environments (Nix) help a lot, yes, same for sound testing strategies. But the ability to plan is the key.
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?
Or you can just switch the models in a regular conversation and tell one to review everything up until now, optionally telling it to get a git diff of all the unstaged changes.
> is this possible with those?
You can always write to stdin/read from stdout even if there is no SDK available I guess. Or create your own agent on top of an LLM provider.
I do feel that that is pretty much needed to claim that Claude is adding features to match the Java spec.
So, I can't tell how good it actually is but it definitely handles reasonably complex source files with generics (something the original compiler was unable to do).
The actual goal of the project is to be able to build at least ANT to simplify clean bootstrap of OpenJDK.
"AI DID EVERYTHING IN A DAY"
"How do you know it works?"
"... it just looks like it does"
Like when I ask AIs to port sed to java, and it writes test cases ... running sed on a CLI and doesn't implement the full lang spec no matter how much prompting I give it.
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.
setting copyright issues aside, javac is a pretty clean textual-input-output program, and It can probably be reduced to a single thread variant
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?! :)
In the end I've just reanimated the original parser generator and progressed to full Java 7 syntactically (-att5 branch), but there are some major obstacles with bytecode.
"Modernizing" to Java 6 is amusing.
Even Java 6 support should make ground zero bootstrap of modern JDKs much easier.