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?
Besides, gotta start somewhere. It's probably a PoC, for a platform that will eventually handle all sorts of things.
I agree and I think we should give folks leeway to make progress but this seems to be the qualifier for nearly every GenAI demo I’ve seen
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
won't FileReader leak if the BufferedReader constructor throws?
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 !
In Java out of memory is signaled with an OutOfMemoryError which is a throwable (and can be caught) but is not technically an exception. Errors should generally never be caught and cannot be recovered from, which is how they differ from exceptions.
Now you can argue that this is not truly recovering from exception but it is a lot better than what you can do with most of the other Error subclasses. I said most because there are easy to recover from Error like the StackOverflowError where you just have to fail the operation or request that caused the error.
Let's say you get 1/100 requests that are randomly sent to your process. That 1 takes 100x the average memory usage of the others. You could spin it out to different services to better handle the weird one-off, but that doesn't always make sense. Sometimes you just need to be ok with working the 100x job and let the other 99 get progressive falloff retry. Different solutions are always possible.
leosanchez•4h ago
jillesvangurp•4h 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.
TYMorningCoffee•4h ago
nradov•2h ago
And once SonarQube flags a resource leak to a developer, a competent developer would learn from that and never make the same mistake again.
TYMorningCoffee•4h ago