Yeah, I mean duh, of course? Why infer when you have the proper names? I don't understand what you're trying to point out here...

Is it really an obvious use case of LLMs? Traditional byte code to source decompilers are faster, use less memory, and are deterministic. Using a LLM to decompile code makes as much sense as using a LLM to compile code.

That said there are probably ways a LLM could improve a decompiler in a way that does not impact its correctness. Like deriving class and variables names based on context, when symbols are missing or obfuscated.

... until you realize that the LLM-generated code doesn't even compile, or you need a PhD to write all the prompts needed to have a prototype instead of the real thing.

>Generic erasure is a giant pain in the rear

Personally, I don't get the sentiment. Yeah, decompiling might not produce the original source code, which is fair. It's possible to generate code using invokeDynamic and what not - still being valid code if a compiler opts to do so.

When decomiling bytecode there has to be a reason for, and a good one. There has to be a goal.

If the code is somewhat humanly understandable that's ok. if it's more readable than just bytecode, that's already an improvement.

Reading bytecode alone is not hard when it comes to reverse engineering. Java already comes with methods and fields available by design. Having local variable names and line numbers preserved is very common, due to exception stack traces being an excellent debugging tool. Hence debugging info gets to be preserved.

try/finally shares the same issues, albeit less pronounced.

C# doesn't erase all generics; but there's also some type erasure happening: nullable reference types, tuple element names, and the object/dynamic distinction are all not present in .NET bytecode; these are only stored in attributes for public signatures, but are erased for local variable types.

C# also has huge amounts of syntactic sugar: `yield return` and `await` compile into huge state machines; `fixed` statements come with similar problems as "finally" in java (including the possibility of exponential code growth during decompilation).

You're awesome! I had really good experiences with CFR in the mid 2010s.

I used it for game modding and documentation (and caught/reported a few game bugs + vulnerabilities along the way). I'd pull game files from Steam depots with steamkit, decompile with CFR, and run the resulting java through doxygen.

Do you have a write up of what exactly happened, how trivial the vulnerability was?

Didn't Oracle drop support for Java 8 like six years ago? I'm sure there are plenty of companies still running it, but even Apple (a relatively conservative company in this regard) updated to Java 11 when I was there in ~2019.

this isn't really the case. a lot of legacy code may still be running the version it was developed against, but java 17+ has a sizable share of the ecosystem now that all of the popular libraries require it. spring for example bumped their baseline to jdk 17 in 2022.

It used to but Oracle‘s licensing and probably more important security guidelines from the very top linking CVE scores to mandatory updates got things moving on the last years.

What about Android? Hmm....

Nope, we are on Java 25