FAQ.txt

JCGO: Frequently Asked Questions
--------------------------------

Bellow are the most common questions about the JCGO software. The newcomers
should have a look into the "README" file first.


1. What is JCGO?
----------------

JCGO (pronounced as "j-c-go") is a software application 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 and Linux x86 (i.e., for translation and compilation an AWT
application you need JCGO-SUNAWT packages).


3. Is JCGO JDK6-compatible?
---------------------------

No, at present JCGO does not support features introduced in the 3rd Java
language specification (JLS 3). 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 platforms at present.

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

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 the block
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).


7. Can I use JCGO for embedded targets?
---------------------------------------

Yes, JCGO works, at least, for embedded Linux, Darwin 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 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.


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

The JCGO translator executable binary is distributed as "jcgo.jar" file
suitable to be launched on any Java VM (e.g. Sun JRE v1.4 or higher).

Also note that the target platform does not depend anyhow on the platform
where the JCGO translator is launched.


9. I can't unpack some of the distributive .gz files with tar utility
----------------------------------------------------------------------

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


10. Is it possible to use JCGO to speed-up Android applications
---------------------------------------------------------------

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


11. 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 modifications of the JCGO run-time files).


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


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


14. Could I use JCGO with a commercial closed-source application?
-----------------------------------------------------------------

Sure. 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
exception is: the Sun JDK 1.4 GUI/Sound/SQL back-ends (currently they are
available under the Sun Research-only license).


15. Is is possible to use JCGO for critical fault-tolerant Java applications?
-----------------------------------------------------------------------------

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


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

We did 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.


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

J2ME is not officially supported. 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 3rd-party library emulating AWT over SWT.


18. The translator says "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.


19. The translator says "File bad for class". 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
in "myproject/src" folder directly.) "Hello" sample has no package, so it is
passed to JCGO translator as "Hello" or "Hello.java".


20. 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/simple
Empty1 @$~/stdpaths.in YourClass1 YourClass2 ..."). Any additional classes
(specified in the command line) are not required to contain main().


21. How 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.)


22. 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
the real world to produce the correct binary executable mostly because of the
limit imposed by that compiler for identifiers length (only the first 32
characters are significant instead of 128, at least, required by JCGO).


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


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


25. Could the translator itself run natively on Windows or Linux?
-----------------------------------------------------------------

Yes. It was written entirely in Java and could be translated by itself, and,
then, compiled for Win32 or Linux.


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

Yes. JCGO produces C code compilable by Xcode GCC. JCGO offers full J2RE v1.4
compatible support on iPhone/iPad except for AWT/Swing/JDBC/JSound.


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


28. Is there a sample command for using a particular C compiler with JCGO?
--------------------------------------------------------------------------

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


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


30. 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().


31. Will the translated code size grow faster than that of the original 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).

--- [ End of File ] ---