1. What is JCGO?

JCGO (pronounced as "j-c-go") is a software product which converts (translates) programs written in Java into platform-independent C code, which could, further, be compiled (by third-party tools) into highly-optimized native code for the target platform and deployed.

JCGO is a powerful solution that enables your desktop, server-side and embedded Java applications to take full advantage of the underlying hardware. In addition, JCGO effectively protects your intellectual property by making your programs when compiled to native code as hard to reverse engineer as if they were written in C/C++.

2. Does JCGO fully support all classes including AWT, Swing and JDBC packages?

Yes, AWT/Swing and SQL/JDBC are fully supported by JCGO through Sun JDK/J2SE v1.4.2 for Windows, Linux, Solaris x86 (i.e., for translation and compilation an AWT application you need JCGO-SUNAWT packages).

You can see several compiled AWT demos on Demos page.

But due to the JCGO trial limitations (only 400 classes could be translated at a time) - you can't use/evaluate JCGO for an AWT application.

As an alternative, we could offer you our translation service for determining suitability/fitness for your application (the service is paid only if JCGO really works your application).

3. Is JCGO JDK6-compatible?

No, at present JCGO does not support features introduced in the 3rd Java language specification (JLS 3). The Java generics, attributes (and migration from the GNU Classpath to JDK1.5/1.6) are in our far future plans. So, if your application really requires JDK1.5+ functionality then look for some 3rd-party competing product like Java to native code "through C" compilers or Direct Java to native code compilers.

4. Does JCGO support Linux?

Yes, the C code generated by JCGO could be compiled for Linux targets. More over, Windows, Linux and SunOS Solaris on i586 (x86) and x86_64 (amd64) are the most tested and supported target platform by our company.

5. Can I use JCGO to produce code for micro-controllers?

JCGO is not really a MCU-specific tool by design but it could be used for such purpose (typically with some additional porting efforts) as the compiled program image size for simple applications could start from 8 KiB and most immutable Java objects (like strings) go into read-only program sections. The produced native code does not have any special requirements for the underlying platform, does not contain any bytecode and does not require a Java VM. For the memory recycling (if needed), JCGO runtime uses either Boehm GC (BDWGC) or TinyGC.

6. What are the prices for JCGO and the translation service?

Our prices are shown at "Buy now" page.

We have recently begun licensing (selling) our product, so we currently setup only one product configuration (which includes an initial half-year technical support subscription).

For those who prefer to let the professionals do the work, we offer the translation (and compilation) service which is priced on per-hour basis (you pay for our work only if JCGO is really suitable for your application). The number of hours we spent to translate an application is highly-dependent on the application properties (and the first translation work also includes the time we spent to analyze the application requirements and its key JCGO-sensitive features).

7. Is performance good compared to a Java VM with JIT?

JCGO could be considered as a Java VM with ahead-of-time (AOT) compilation. AOT has "pros" and "cons" compared to JIT (see an article in "Some papers on Java" links section).

The performance is nearly as good as if an the application was written in C/C++ except for: - "try {} catch/finally {}" construction is translated to a setjmp() (unlike some other Java VM implementations where "try" is just a no-op if it completes normally); - unlike a normal C/C++ application, memory is freed by a garbage collector (so, for a real-time application, this might require significant efforts for tuning it to make GC delays acceptable).

8. Can I use JCGO for embedded targets?

Yes, JCGO works, at least, for embedded Linux and Windows Mobile/PocketPC (WinCE) on arm, mips, sh and x86.

But the translation of a GUI application is a problem since you cannot use Sun JDK for embedded targets, so, there exists only two ways - either use GNU Classpath GTK peers (which is far from perfect compared to the Sun AWT implementation but might, nonetheless, fit a particular application (see J2dBenchmarkGUI-gtkpeer from the demos page) or Eclipse SWT (which is supported for a dozen of targets and runs fine at least for GTK and Win32 platforms (Mobile/PocketPC/WinCE is less well supported but the SWT project is under active development at present). Also, there is the 3rd way - to use some AWT-over-SWT implementation (like open-source "swingwt" or proprietary "IBM J9 WEME ppro10 UI") but they are far from perfect (and not under active development at this moment).

Anyway, typically, before compiling a Java application for an embedded platform, it is good to compile it for the desktop running on similar OS utilizing the same Java GUI toolkit. Then (if it works out-of-the-box on a PC) recompile C files for the target embedded platform.

9. How can I run the JCGO translator on Linux/FreeBSD/SunOS?

If you are on a Linux (or FreeBSD, or Solaris SunOS) x86 development host, we could offer you the corresponding translator executable for your convenience on request. Please contact us at <support@ivmaisoft.com>. Note, however, that the target platform does not depend anyhow on the platform where the JCGO translator is launched.

10. I tried to use JCGO under Linux HQ Wine but it crashed. Where can I get the JCGO translator for Linux?

The translator is not working under Wine because the license protection module. (But the code compiled with JCGO for a Win32 target should run on Wine fine unless it is a GUI one.) If you are on a Linux/x86 development host then send us a request for a Linux version of the JCGO translator.

11. I can't unpack some of the distributive .gz files with tar utility. Are they corrupted?

No, they are not corrupted. Try to use the recent tar utility version or use popular "7-Zip" archiver.

12. I'm searching for right reverse engineer protection solution for my company's application. Is there any possibility to get special demo version of JCGO because our application is having over 10000 classes?

Yes, if 400 classes isn't enough for us, we could provide you with the JCGO evaluation version with the relaxed classes limit.

13. Is it possible to use JCGO to speed-up Android applications (by compiling them directly to machine native code)?

No, at present this is impossible because JCGO does not support some of the Java syntax defined in the JLS v3 (generics, enums, annotations, auto-boxing, for-each loops).

14. Is the Tricore C compiler supported?

No, we haven't tried it yet. But it would probably work for you (with little or even none modification of the JCGO run-time files). We could help you through our translation service.

15. Should I use TinyGC or BoehmGC for my project?

It is recommend to use BoehmGC (BDWGC) unless the latter does not fit you (for any purpose).

16. Is JCGO certified to be compatible with Sun Java?

No, but JCGO is compatible (almost fully) with Sun J2RE v1.4. Use the official JCK test suite to manually verify the compatibility. On the other hand, it is possible to relax the strict compatibility with the Sun Java in favor of speed (e.g., turn off array index checking).

17. Could I use JCGO (the translator and the accompanying run-time libraries) with a commercial closed source application?

Sure, provided you have purchased the JCGO commercial license. Everything (with the only exception) accompanying the JCGO could be used in a commercial project. More over, most of the JCGO components are open-source (mostly released under GPL plus the Classpath exception). The only mentioned exception is: the Sun JDK 1.4 GUI/Sound/SQL back-ends (currently they are available under the Sun Research-only license).

18. Is is possible to use JCGO for real-time and critical fault-tolerant Java applications?

No, by initial design, JCGO is for non-realtime and non-fault-tolerant applications only.

19. Is JCGO reliable? Is it possible to formally prove its reliability?

We do our best to make JCGO as reliable as possible. But we can't formally prove you its reliability. You can use the official JCK tests suite for this purpose.

20. How can I use JCGO to compile a J2ME application for a WinMobile target?

J2ME is not officially supported at present. But you can use some library emulating J2ME functionality on the top of a J2RE platform. Also, note that AWT is not supported for WinCE targets (Windows CE, Windows Mobile, Pocket PC) but, again, you can use some library emulating AWT over SWT.

21. I've tried to convert my Java application but the translator reports "Cannot find class: java.lang.Object". What's wrong?

The problem is you haven't specified the source path for "java/lang/Object.java". To solve the problem, specify "@$~/stdpaths.in" string as the last command-line argument when launching the JCGO translator.

22. I've translated the sample "Hello" successfully but when I try to convert my application, JCGO reports me "File bad for class: MyAppMain (unnamed package)". What's wrong?

JCGO expects fully qualified class names to be specified. E.g.: if you want to translate "myproject/src/pkg1/pkg2/MyAppMain.java" file then type "jcgo -sourcepath myproject/src pkg1.pkg2.MyAppMain" or "jcgo -sourcepath myproject/src pkg1/pkg2/MyAppMain.java". (Note that "MyAppMain.java" should then reside in "myproject/src/pkg1/pkg2" rather than directly in "myproject/src" folder.) "Hello" sample has no package, so it is passed to JCGO translator as "Hello" or "Hello.java".

23. Is there a way to convert Java files without main()?

Well, the purpose of JCGO is to translate Java applications to C code. Every Java application starts with main() (even applets are started by some viewer class like sun.applet.AppletViewer). So, at least, you should specify the class name of your application containing main(). For the case when you convert a library which is e.g. invoked through JNI, you can pass "Empty1" class name (e.g., type "jcgo -sourcepath your_project_src;$~/examples Empty1 @$~/stdpaths.in YourClass1 YourClass2 ..."). Any additional classes (specified in the command line) are not required to contain main().

24. Is there a way to convert multiple Java files in a directory with a single command?

Yes, there is a way to instruct JCGO to explicitly include some classes into the translation set - just specify the class names (or the source file names, or, even, you can use file wildcards) in the command line on JCGO invocation. Alternatively, you can create some "your_response.in" file, put the class names to it (on a one-per-line basis), and invoke JCGO specifying "@your_project/your_response.in" at the command line's end. Note, however, that JCGO discovers cross-class dependencies (including dynamic) so, possibly, you won't need to explicitly specify many classes in the command line. (To see whether a particular class is included in the compilation set, you can search (among all .h files produced) for the qualified name of that class with dots ('.') replaced with underscores ('_'). Alternatively, Main.c file may contain the list (named as "jcgo_classTable" of all classes included in the compilation set but for the space considerations the list is omitted unless Class.forName() is used.)

25. Is TurboC v2.0 supported by JCGO?

No, it is not officially supported by JCGO. While it is theoretically possible to compile the generated code with TurboC compiler, it would be very hard in a real world to produce the correct binary executable mostly because of the limit imposed by that compiler for ID length (only the first 32 characters are significant instead of 128, at least, required by JCGO).

26. What are the 16-bit compilers supported?

The list is shown in "Samples" file (see "For DOS 16-bit" section). The most recommended ones are the recent versions of Digital Mars (DMC) and Open Watcom (WatcomC) compilers.

27. How does JCGO work?

JCGO translates the whole Java application (including all the used Java libraries) at once producing portable C code. That code (along with the code in "include" folder and, possibly, in "native" folder) is compiled (either all at once or on a file-by-file basis) to the target platform's object code (which is then linked with the required libraries and deployed).

28. Does the translator run natively on Windows?

Yes. It was written entirely in Java, translated by itself, compiled for Win32 and processed by a software protection system.

29. Is it possible to use JCGO legally for doing iPhone/iPad development?

Yes. JCGO produces C code compilable by Xcode GCC (although this was not thoroughly tested yet unlike for WinMobile/CE development). JCGO offers full J2RE v1.4 compatible support on iPhone/iPad except for AWT/Swing/JDBC/JSound.

30. What are the use cases of JCGO_NOGC macro?

JCGO_NOGC macro instructs the compiler to exclude the garbage collection support from your application. There are several cases where you may succeed without GC:

• the program terminates quickly (e.g. some utility just processes input data and exists);
• the program does not allocate objects (or does allocate only limited number of them - this is a so-called "object reuse" pattern);
• you define (and call there necessary) a JNI function that calls free() for a given object.

31. Where can I find a sample command for compiling the translated source for the C compiler I use?

Look in "Samples" file (contained in the JCGO installation folder). E.g., the section named as "solaris cc amd64" contains sample commands for compiling for Solaris SunOS/X86 using SunC compiler for 64-bit code (the first sample turns on the maximum J2SE compatibility but turns off most of the optimizations).

32. What are the use cases of "goclsp/clsp_asc" folder?

If your application does not need I18N (internationalization), and does not use new String(byte[]) and String.getBytes() (even indirectly) then it is possible to exclude the I18N support (thus slimming down the executable size) by passing "-sourcepath $~/goclsp/clsp_asc" argument (prior to "@$~/stdpaths.in" one) to the translator.

33. Why does "Hello world" example contain so many classes translated?

The C code translated for "Hello" sample class contains near 80 classes (and near 280 methods) even without the I18N support because it uses NIO buffers, system properties, thread stuff and lots of exceptions. If you are targeting very limited environments then it might worth for you to write your own println native method (instead of using System.out/err) which calls C puts().

34. Will the translated C code size grow much faster on the growth of the original Java code?

Yes and no (depending on your application).

E.g., if your Java main() just do "System.out.println(new Date())" then the translated C code would be quite large (~6 MiB) containing: Locales manager (locale bundles), default locales, various date and decimal formatters, timezone rules, full list of timezones, code obtaining current timezone (in a portable way), various collections and hash maps (along with equals/hashCode() methods of all used classes), a table of all constant strings for String.intern() code, a list of all class names (because the Calendar uses reflection API for its instantiation), properties parser (for locale files), zip file deflater (to get locale property file from a compressed zip), full system properties initializer code (gnu.classpath.VMSystemProperties), Java "long" type support, etc.).

Here is the list of some dependencies:

• if HashMap/Set is used then JCGO translates all hashCode/equals() methods of all translated classes and also puts them to class virtual table (the latter exists for every class);
• if String.intern() is used then JCGO creates a table (in Main.c) all constant strings in the translated application;
• if phantom/soft/weak leaks are used then JCGO includes weak link handling module;
• if Class.forName() and/or reflection API is used then JCGO includes the meta-information in C code (names of Classes, relevant method signatures, etc.);
• if your code uses Exception class (or its subclasses) then the Java core exceptions would be included too;
• if your native code uses JNI (pJniEnv parameter) then you need to include JNI support (same for threads, floating point and "long" type support).