marco2357

Yes indeed. We handled goto into do-while statements wrong. Fixed now. Thanks!

That would be a bug in the translation. We'll investigate. Thanks!

Hahaha, cool!

I saw that ;-) The translation is:

  do {

    to.set((from = from.shift(1)).get(-1));

  } while(--count > 0);

which looks correct to me. Hence my question what orodley thinks is wrong.

Didn't think too much about it since there are many C specific analyzers and tools that do the same. Well, they do it way better. E.g. Valgrind.

Thank you!

But of course a lot of development and money went into our translation framework. So the main aim has to be to make money with it. But as long as we have capacity, we're happy to translate open-source software and improving our translation while doing so.

Can you elaborate on that? What's the C code, the translated Java code and your expected Java code?

Thanks!

Yes, but it's way too limited for replicating what you can do with C pointers. Therefore we wrote our own classes.

Thanks!

malloc() we only optimized for char* so far (there are endless possible optimizations when translating C the way we do).

"(double* )malloc(sizeof(double) * 100)" should be translated as "new DoubleContainer(100, true)". We'll add that add some point.

Yep, supporting 90% of C took 10% of the time. Or even much less time.

Native C libraries (libc, libmath, ...) are just directly used from Java, not translated.

Yes, there is a lot of money in Cobol/Fortran to Java. Many tried, none successful (I know many stories). We'll look into those two languages in the future. But creating real translators takes years.

Send us an email. We're currently getting overrun with requests but will handle it as fast as possible.

Please note that the software needs to be in some public repository (github, bitbucket, sourceforge, ...).

Performance is of course lower. But it's impossible to put a number on it. Certainly native calls (printf, scanf, fopen, fread) add a lot of overhead. Also whenever the C memory layout has to be used, performance suffers (e.g. complex pointer arithmetic).

But the approach is to get the correct translation first, and then - if needed - bottlenecks can be removed manually. This should lead to a better migration/upgrading experience.

Yes. As long as it's non-commercial software.

True. But also adds a lot of complexity on top of an already very complex translation. But it's certainly something we'll look at in the future (together with supporting Cobol and Fortran).

But I heard there are C++ to C translators. I don't know how good they are and how the resulting code looks like. But if they're decent, you could do C++ -> C -> Java :)

It's easy to do a minimal prototype when doing research. But writing real translators means to get all the details right. In research we usually don't have the time for that.

Translating Java - in my experience - is very hard because of the extensive runtime system (reflection, base classes, synchronization, ...). E.g. if your application does System.out.println("Hello"); you already need the System and PrintWriter classes. They in return depend (among many other things) AWT which needs the security classes. And so on. A HelloWorld pulls in 1208 classes of the base library. They in return depend on java.dll which you have to re-implement from scratch. Or you rewrite all base library classes which is even harder.

I hope this gives you a basic idea of the problem.

Only in the form of translating and running dozens of C applications (programs and libraries) and running their testsuites. E.g. libcurl comes with a great extensive testsuite (a perl script running against the binary).

Translated applications still need to be thoroughly tested and usually some bugs are still found.

So we didn't formalize and verify our translation. Interestingly enough, we run into bugs in javac and ecj (Eclipse Java Compiler) surprisingly often. So verifying our translation would still lead to translations with bugs ;-)

Another fun fact: Since our translation knows the limits of allocated memory (and many other things), we found many illegal memory accesses in C programs that were unknown before (libgmp, micro httpd, vim, ...) since they didn't (or only very seldomly) lead to segfaults.

I've seen many research papers on Java -> C translation during my PhD. Some of them came with a prototype tool. But as with previous work on C -> Java translation, none of the tools actually really worked completely.

I actually wrote a Java -> Eiffel translator:

http://se.inf.ethz.ch/research/j2eif

Based on that experience I can say it would be quite a big effort to write a Java -> C translator. But not impossible.

We translated dozens of open-source projects and decided to list only the interesting ones on the website and upload only the most interesting ones; The ones that are very well known and have a nice GUI.

Feel free to send us an email and we'll be happy to send you the other programs you're interested in.

You can also ask for translations of open-source software we didn't translate yet if you want to see the translation of a specific project.

Main author here. Let me know if you have any questions. I’d be happy to answer.

There's a Java version of Vim here: https://www.mtsystems.ch/#section2

It's an automatic translation of the C version.

Like tomp said 4 hours ago: Like vim, just slower.™

Why not? There's not that much of a difference between translating C to assembler or a high level language like Java/C#/Go. The main challenge is to make the code readable. But basically someone just has to sit down and do it right.

Main author of the tool here. If you have questions feel free to contact me: marco.trudel@mtsystems.ch