Engineering wise. This adds nothing. It’s an absolute waste of compute and energy to run this through LLMs
> FixrLeak delivers precise, reliable fixes while leaving more complex cases for advanced analysis at the caller level.
In other words, this will only fix trivial leaks, which are best seen as a language design issue and can be fixed by RAII, reference counting, etc.
It won't fix the more insidious leaks like `UNBOUNDED_QUEUE.add(item)` that are more likely to pass through code review in the first place.
Peak waste.
What’s next?
"Get rid of your GitHub dependabot alerts and replace it with my shitty ChatGPT wrapper”
Exactly.
It's very disappointing to see that Uber engineers would rather trust an LLM to that claims to spot these issues when a battle-tested scanner such as SonarQube would have caught this in the first place.
The LLM hype-train is almost just as bad as the JavaScript hype train in the 2010s where some of the worst technologies are used on everything.
This adds little to no technical advantage over existing solutions what so ever for this particular use case.
Hey Uber, I am from the EU, I usually can‘t even solve leetcode medium but I will write you scalable, spotless Java for a third of the salary.
Our industry and its economics are a joke.
I guess we don’t need QA and Dev/Staging environment
Uber is not proposing a static checker. They even use sonar qube in their architecture. They propose using an LLM to resolve the leak detected by sonar qube.
stevoski•1mo ago
This was true maybe back in 2005. Java has had try-with-resources for a loooong time. As I see it this has been the dominant idiom for ages, for handling resources that might leak.
okr•1mo ago