This could be interesting, but all the example code is so poor, and the extent of the fix so limited that it feels like this is 'AI' for the sake of it.
Stringly-typed, catch-log-ignore, generates warnings in IDE anyway...
Fixed 90 of 125 errors that were found by a different technology... probably.could have been fixed by one developer in 1-2 days anyway - how long did this take?
> all the example code is so poor, and the extent of the fix so limited
I agree about the limitations, but look from another perspective, is it good use of time asking experienced engineers who get paid 300-500k/year to go and fix these issues? Probably no.
Would it bring them a joy finding simple leaks and fixing them? Probably no again.
Then this tool is a nice addition to the engineers
That BufferedReader constructors is not supposed to throw, unless the reader is null or you're out of memory. If your out of memory you should probably abort the program execution because the difficulty of correctly recovering from an OOM exception is between hard and impossible.
Edit:
Disregard the above, it was too naive.
It cannot leak because of a stronger warranty. In the JLS, it is specified that the try-with-resources track successfull initialisation of AutoClosable resources, not successful assignation. So one try with resources can desugar into the logical equivalent of multiple nested try-catch-finally !
There were static code analyzers like findbugs able to do stuff like this 20 years ago. These days, your IDE should tell you off as well. And hopefully teams configure their builds to catch stuff like this using any of the available plugins for this.
LLMs seems overkill for this. But of course letting it do general code reviews is not a bad idea. And static code analyzers aren't perfect. Doing this at scale might be a bit tricky though; you'd have to go file by file. I assume Uber might have many millions of lines of code to screen. And maybe their developers aren't that concerned with addressing warnings.
But going file by file might be simple enough. And you can probably screen for important stuff with some decent system prompt and instruct it to check for potential resource leaks and similar issues and produce detailed bug reports with some priority if it finds them and a diff that addresses the issue. Could be a nice use case for agentic AIs to screen code like this.
I think you'd be surprised, how many people do production code WITHOUT automated formatting / linting / static analysis.
Now these people and their managers are staring at the shiny new thing, the LLMs. They missing googling skills are fixed by LLMs ont heir everyday life, so they think a magic "code quality tool" (AI) would help them in they work.
To answer your question, obviously there are many linters/analyzers for Java (and for other languages too), both for static and dynamic code analysis, formatters, everything.
I'm not sure I fully understand the purpose of this tool. Modern IDEs are quite good at detecting these types of issues. And if they don't catch something, I often just copy and paste the method with some context-into an LLM and ask it to find the problem. It usually handles all the necessary changes for me.
This architecture is promising. Large legacy code bases can have static analysis violations in the 1000s which devs never have the time to address. I've seen sonar tube reports that require man years to resolve everything.
time4tea|9 months ago
Stringly-typed, catch-log-ignore, generates warnings in IDE anyway...
Fixed 90 of 125 errors that were found by a different technology... probably.could have been fixed by one developer in 1-2 days anyway - how long did this take?
tuyguntn|9 months ago
I agree about the limitations, but look from another perspective, is it good use of time asking experienced engineers who get paid 300-500k/year to go and fix these issues? Probably no.
Would it bring them a joy finding simple leaks and fixing them? Probably no again.
Then this tool is a nice addition to the engineers
daxfohl|9 months ago
Besides, gotta start somewhere. It's probably a PoC, for a platform that will eventually handle all sorts of things.
fjwufjfa|9 months ago
won't FileReader leak if the BufferedReader constructor throws?
nick__m|9 months ago
Edit: Disregard the above, it was too naive.
It cannot leak because of a stronger warranty. In the JLS, it is specified that the try-with-resources track successfull initialisation of AutoClosable resources, not successful assignation. So one try with resources can desugar into the logical equivalent of multiple nested try-catch-finally !
leosanchez|9 months ago
jillesvangurp|9 months ago
LLMs seems overkill for this. But of course letting it do general code reviews is not a bad idea. And static code analyzers aren't perfect. Doing this at scale might be a bit tricky though; you'd have to go file by file. I assume Uber might have many millions of lines of code to screen. And maybe their developers aren't that concerned with addressing warnings.
But going file by file might be simple enough. And you can probably screen for important stuff with some decent system prompt and instruct it to check for potential resource leaks and similar issues and produce detailed bug reports with some priority if it finds them and a diff that addresses the issue. Could be a nice use case for agentic AIs to screen code like this.
kmarc|9 months ago
I think you'd be surprised, how many people do production code WITHOUT automated formatting / linting / static analysis.
Now these people and their managers are staring at the shiny new thing, the LLMs. They missing googling skills are fixed by LLMs ont heir everyday life, so they think a magic "code quality tool" (AI) would help them in they work.
To answer your question, obviously there are many linters/analyzers for Java (and for other languages too), both for static and dynamic code analysis, formatters, everything.
TYMorningCoffee|9 months ago
kburman|9 months ago
nitinreddy88|9 months ago
TYMorningCoffee|9 months ago
microflash|9 months ago
https://docs.openrewrite.org