marco2357

marco2357

11 lat temudiscuss

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

marco2357

11 lat temudiscuss

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

marco2357

11 lat temudiscuss

Hahaha, cool!

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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

Thanks!

marco2357

11 lat temudiscuss

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

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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, ...).

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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

marco2357

11 lat temudiscuss

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 :)

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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.

marco2357

11 lat temudiscuss

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

marco2357

11 lat temudiscuss

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.™

Submissions

C to Java Translation. Automatic, Complete, Correct. Free for Open-Source.

comments