Show HN: I wrote a Java decompiler in pure C language

I'm curious, how did you notice this?

Do you have a scanner that checks these sorts of things or is it something that you are passionate about?

In multi-threaded mode, each thread will create a separate memory pool. If in single-threaded mode, a global memory pool is used. You can refer to https://github.com/neocanable/garlic/blob/72357ddbcffdb75641.... The x_alloc and x_alloc_in in it indicate where the memory is allocated. When each task ends, the memory allocated in the memory pool is released, and the cycle repeats.

Many command line tools do not need memory management at all, at least to first approximation. Free nothing and let the os cleanup on process exit. Most libraries can either use an arena internally and copy any values that get returned to the user to the heap at boundaries or require the user to externally create and destroy the arena. This can be made ergonomic with one macro that injects an arena argument into function defs and another that replaces malloc by bumping the local arena data pointer that the prior macro injected.

Interesting. Someone should come up with a language that prevents these sorts of mistakes!

In the same file:

  static bool is_java_identifier_start(char c)
  {
    return (isalpha(c) || c == '_' || c == '$');
  }

I think some <ctype.h> implementations are hardened against this issue, but not all.

> I am always curious how different C programs decide how to manage memory.

At a basic level, you can create memory on the stack or on the heap. Obviously I will focus on the heap as that is dynamically allocating memory of a certain size.

The C programming language does not force you how to handle memory. You are pretty much on your own. For some C programmers (and likely more inexperienced ones) they will malloc individual variables like they are creating a 'new' instance in a typical OOP language like Java. This can be a telltale sign of a programmer working with C that comes from an OOP background. As they learn and improve on their C skills they realise they should create a chunk of memory of a certain type, but could still be malloc(ing) and free(ing) all over the code, making it difficult to understand what is being used and where -- especially if you are looking at code you did not write.

You can also have programs that do not bother free(ing) memory. For example, a simple shell program that just does simple input->process->output and terminates. For these types of programs, just let the OS deal with freeing the memory.

Good C code (in my opinion) uses malloc and free in only a handful of functions. There are higher level functions for proper Allocators. One example is an Arena Allocator. Then if you want a function which may require dynamic memory, you can tell it which allocator to use. It gives you control, generally speaking. You can create a simple string library or builder with an allocator.

Of course an Allocator does not have to use memory on the heap. It can still use on the stack as well.

There are various other patterns to use in the world of memory, especially in C.

Strings! The bane of C programming, and a big reason I prefer C++. :D

https://github.com/Vineflower/vineflower

The "jikes" compiler from IBM <https://github.com/daveshields/jikespg> was written in C++ and was for the longest time screaming fast. It also had its own parser generator lpg which was fun to play with, if you're into those things <https://github.com/daveshields/jikespg>

It seems someone liked it and made a "v2" along with LSP support https://github.com/A-LPG/LPG2#lpg2

I am writing the part of decompiling dex and apk. The current speed is about 10 times faster than that of Java, and it takes up less resources than Java. And the compiled binary is smaller, only about 300k. Thank you for your attention.

The readme shows support for dumping dex files. Edit: missed that it has a comment that stays "unsupport for now" but at least it looks like something planned

It is processes inner classes recursively. First read all entry from jar, and analyze the relationships between classes. Then do some decompile job.

Things may have changed, but my impression as of several years ago was that JD-GUI was far, far behind the state of the art (Fernflower, aka the built-in IntelliJ decompiler) in terms of correctness, re-sugaring, support for modern Java features, and so on. Fernflower is open source as part of IntelliJ: https://github.com/fesh0r/fernflower

90% by hand, 10% AI. I do this for fun and to learn about jvm.

Irrelevant to me. People would never ask whether someone has created something looking at SO or not. If the thing works as advertised, good for them!

A great question to ask. We're in the middle of learning where AI can and can't be effective. Knowing where and how it's being used is quite useful.

Of course it can be done! It wouldn't be as general purpose as the Java decompiler in C because the C decompiler would have to know about the CPU architecture of the executable code (just as the Java decompiler has to know about JVM opcodes).

https://github.com/NationalSecurityAgency/ghidra/blob/Ghidra... (Apache 2)

[flagged]

I moved from C++ to C and I am more productive. I also think this "no seat belts" meme is exaggerated, as there are plenty of tools and strategies to make C fairly safe to use. (it is true though that many people do not put the seat belts on).

In my experience, although many of the other programming languages do improve some things compared with C, they also make many things worse and avoid some of the benefits of C programming.

This is the best question for me. Writing these codes in C language is the best way to learn the file structure of jvm/dalvik/pe. This process makes me like C language more. For me, I think it is simple and pure, which is enough.

Yes, yes I'm sure. I like using C sometimes.

Or riding a motorcycle.

But stupid real-world analogies are stupid.

When debugging complex projects, the C language is more flexible and convenient to view data in memory.

i only write in C. if id build a car it wouldnt have seatbelts. boring, put in ejector seats! not safe? no problem for C :).

We need people who can (and do) write in C, assembly, and all these low-level languages. Otherwise, software will just get slower and slower.