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.
90% of C should be pretty easy to translate, but of course, the devil (and a lot of functionality in existing libraries) is in the details.
There would be probably money in translating COBOL to Java, but maybe there are solutions already?
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.
There is, Proyect NACA (http://developers.slashdot.org/story/09/06/24/1915205/Automa...).
Have a look at the generated codeif you want a good laugh, it translated COBOL code to Java line by line.
(Because "just change" usually ends up creating other problems. Been there, done that, "code is wrong but works" and when you try to fix stuff breaks)
For OSS (or other projects) that just need running JVM byte code, checkout the GCC Bridge component of Renjin, which uses a combination of GCC to Soot to compile C and Fortran code to bytecode: https://github.com/bedatadriven/renjin/tree/master/tools/gcc...
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.
http://git.megacz.com/?p=nestedvm.git;a=summary
And is actually open source, not "free for open source".
Kudos to the developers though, I'm not trying to bash your skills or diminish the quality of your work... I'm sure many enterprises can/will benefit from this. Just wanted to let the free/open source community know that you don't have chomp on the "free for open source" carrot.
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.
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.
Please note that the software needs to be in some public repository (github, bitbucket, sourceforge, ...).
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.
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 :)
So in that case, the C++ to C compiler was there before the first real C++ compiler which appeared some time later.
Why do young students no longer learn C? Don't you want to be closer to the underlying OS?
Who said they don't? This project is about porting existing stuff, for interoperability, etc. Not as a way to "avoid learning C".
>Don't you want to be closer to the underlying OS?
No, why would I want to do that unless I have a specific need for that?
At least if you're using a Unix-like system, then understanding POSIX is essential for knowing how things work starting on an intermediate level.
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.
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.
do {
to.set((from = from.shift(1)).get(-1));
} while(--count > 0);
n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
Anyway, C is a horrible language. Between Fortran and Ada it's unclear to me why C should be chosen for anything, inertia and herdthink aside.
All the infrastructure you're using goes through C/POSIX in one way or another. When things go haywire, you can only get by fixing it on the higher levels or just blindly restarting for so long.
EDIT: Only true if you use the implicit-none flag when compiling Fortran.