It so happened that I worked a lot on C / C ++ and did not work on Java. And now, I see, for mobile platforms, Java is very much in demand. I, as a reasonable-lazy person, want to avoid a full study of Java. I would still like to write in C ++, but in order to translate C ++, the code is not in native code, but in code for a Java machine.

Question:

  1. Are there technologies now, where C ++ - the code is translated not into the native code for a specific platform, but into the code for a Java machine? So that later this code was executed as Java code on a Java machine on any platform.

UPD1:

In my opinion, Java code is now being translated into some intermediate code for an abstract Java machine. On different platforms there is a JIT-translator, which, when running this code, translates it into native code for this platform and launches it. Or am I wrong?

UPD2:

It seems to be something easier. Take the GCC translator, leave the parser and instead of the code generator for the x86 platform write a code generator for the Java machine. Has nobody made such a hybrid yet?

UPD3:

Then the second question related to the first:

Question:

  1. How are Java programs distributed? Are Java programs distributed in source code, or are Java programs distributed in code for a Java machine?
  • Mobile platforms in particular support C / C ++ applications. Well, you yourself imagine how this will work? how will C ++ be translated in java? there is essentially all different - Tsyklop
  • @Tsyklop [how C ++ will be translated to Java] I want a little bit wrong. Not C ++ is translated into Java, and C ++ is translated into code for Java-machine. - pepsicoca1
  • At least under the android there is an alternative: fat binaries - packing several binaries for the most common architectures (3-4?) Into one .apk. With this feature, why broadcast to baytkod? - HolyBlackCat
  • @HolyBlackCat [With such a feature, why broadcast to bytecode?] If there is such an opportunity, then it almost solves my problem. But still, dragging along a few native codes is not comme il faut. If only because the size of the binary increases by 3-4 times. And if there is a new platform? It will be necessary to build .apk again. Too bad. - pepsicoca1
  • @ pepsicoca1 Yes, this is a minus. But you can collect and individual. Apk. For example, Google Play, EMNIP, allows you to download different .apk for different architectures, and automatically slips the user to the desired. Or he can split the fat apk himself into several. - HolyBlackCat

4 answers 4

Are there technologies now, where C ++ - the code is translated not into the native code for a specific platform, but into the code for a Java machine? So that later this code was executed as Java code on a Java machine on any platform.

There is a couple, but not the fact that it works for mobile platforms and that it is really convenient to use it when developing:

nestedvm :

NestedVM provides binary translation for Java Bytecode. Compile to a MIPS binary. GCC can be run in 100% pure Java with no source changes.

GCC-Bridge :

GCC-Bridge is a C, C ++ and Fortran to Java bytecode compiler. GCC-Bridge uses the GCC to create a Java class file.

A set of libraries and tools for LLVM to compile C into JVM bytecode :

The C to JVM bytecode compilation provided by LLJVM includes several steps. Source code is first compiled to LLVM intermediate representation (IR) by a frontend such as llvm-gcc or clang. LLVM IR is then converted to JVM bytecode.

  • Thanks for the information. Judging by the fact that all of the freshest of these projects stalled 2 years ago, the topic is really not in demand. - pepsicoca1
  • @ pepsicoca1 in my opinion is easier to master java than to work with these tools. - Mikhail Baksheev
  • [easier to learn java] Here one is connected with the other. If the topic were in demand, then these tools would be brought to commercial use. And the people would work in C ++ and translate the code for the JVM. - pepsicoca1

Let's take it in order:

Are there technologies now, where C ++ - the code is translated not into the native code for a specific platform, but into the code for a Java machine?

There are such technologies, but only in the form of a certain research in the deepest beta, and there are no such technologies in production.

In my opinion, Java code is now being translated into some intermediate code for an abstract Java machine. On different platforms there is a JIT-translator, which, when running this code, translates it into native code for this platform and launches it. Or am I wrong?

As if it is true, but the whole problem is that this work is done on the side of the virtual machine, that is, the JVM receives the bytecode and sends it to the JIT, which translates it into platform-specific instructions.

It seems to be something easier. Take the GCC translator, leave the parser and instead of the code generator for the x86 platform write a code generator for the Java machine. Has nobody made such a hybrid yet?

No, it’s not simpler, in C / C ++, memory management is a programmer’s concern (language tools), but in Java this is a functional that is solved by JVM tools (outside the language itself) - until you eliminate this contradiction, you will not get full C / C + + in the sense of semantics.

How are Java programs distributed? Are Java programs distributed in source code, or are Java programs distributed in code for a Java machine?

Java programs are distributed as object codes .class collected in archives .jar/ear/war/zip

For Android, they are usually packaged in APK archives that contain bytecode instructions translated into an Android virtual machine (it does not match the JVM bikod codes)

Update

By VM in Android. Dalvik and its more recent incarnation of ART - differ from the Sun JVM in that the Android machine has a register-oriented architecture, unlike Sanovskoy, which has a glass-oriented architecture, which entails saving operational memory relevant for phones / smartphones.

Dalvik since version 2.2 has JIT, which is compiled into native codes at the moment of the first launch, ART uses its analogue called AOT (Ahead-Of-Time), which compiles into native codes at the moment of installation.

  • [until you eliminate this contradiction] This is just a problem when translating C ++ into bytecode. In the simplest case, all the pointers must be passed to the garbage collector when delete; - pepsicoca1
  • [it does not match the JVM bikods] I’ve heard that now Android has thrown out its self-written Dalvic and is using the standard JVM from SUN-Oracle. But this is not accurate and it does not matter. That is, Java programs are distributed in binaries for a Java machine. So we need to translate the C ++ code into the code for the Java machine. Then millions of C ++ programmers will be able to work for Android without retraining. - pepsicoca1
  • [but only as some kind of research in the deepest beta] Why? Is it really not in demand in the market? - pepsicoca1
  • [but the problem is that this work is done on the side of the virtual machine] Honestly, I don’t see a problem here. - pepsicoca1
  • one
    Bytecode is generally interpreted. Hot spots as statistics accumulate are compiled by an optimizing JIT compiler. - Nofate ♦

As a pure theoretician ... :)

  1. I have not heard. Theoretically, of course, it is possible, but there are a lot of nuances - just garbage collection is worth it - which will lead to a rather perverted Java code.

UPD1. Not really. The byte code is executed in the interpretation mode, it is analyzed in the course of execution, and the "hot" code is compiled into the machine code - such a combination of both options.

UPD2. Again - not heard. Probably, it is possible, but they don’t write everything that is possible, but what is claimed :) By the way, there’s a very specific specification of bytecode, very specific, so this isn’t such an easy task: a bytecode is far from an assembler .. .

  1. In fact, it was for this purpose that the byte-code and the JVM specification were developed, so that the binaries would work everywhere at once, and it was possible to distribute them, and not source and compile for each iron separately.

"In my opinion, so" (c) Pooh "

  • [The byte code is executed in the interpretation mode] Immediately the speed drops 100 times. ["hot" code is compiled into machine] If it is possible to compile bytecode into machine code, then why not do it for the whole code once at the beginning, in order not to lose speed at all? - pepsicoca1
  • [and not to compile the source code for each iron separately.] That bytecode compile to native code, that source code to compile to native code is no difference. Just for bytecode easier to write a specification. And JAVA constantly at least slightly changes the syntax and loses backward compatibility. - pepsicoca1
  • So that I did not rewrite here directly from the books ... The first is Bloch, "Effective Java programming," the second is Evans, and Java Optimization. I relied on the material of these books ... PS In Russian, so far the first is only the old edition, but both are announced in Dialectics as soon as they come out. So while I can advise only the English edition. - Harry
  • I also read various books and also saw statements there that the byte code is sometimes interpreted and sometimes compiled into native code. Not that I question your words. And it’s just strange that if there is an opportunity to immediately convert bytecode into native code, they don’t use this opportunity and (supposedly) interpret part of the code. Somehow it is not logical. Anyway. This is so, just my grumbling into space. There is a lot of IT in IT that makes people dark as it is done inside. Then they are afraid of plagiarism, they are afraid that they will be laughed at if they see how it is actually done. - pepsicoca1
  • one
    Clang? It is based on llvm, which does not have a built-in garbage collector. Java is not focused on performance but on stability. Yes, they use a bunch of hacks to optimize both when compiling into bytecode and when the application is running continuously. But naturally it will be slower than the CPR. Dude, why are you perverted? After CPS, Java will seem simple to you as a boot, and using CCP language on jvm will not save you from having to learn Java libraries. In short, do not strain on a hedgehog, write either on the CPR or in jvm-languages. - Riĥard Brugekĥaim

If you want to go to mobile phones and even on C with crosses, your path should go to Qt for mobile. I really didn’t try it myself, but Qt has proven itself, and I think everything is fine there. Of the benefits - you are not limited to Android.