AppleCommander/NATIVE-COMPILE

*********************
**     LINUX       **
*********************

See build/build-applecommander-linux-gtk for the script which builds
an executable of AppleCommander.  The build/build-swt-linux-gtk script
builds the SWT swt.so file.


**********************
**     WINDOWS      **
**********************

Building AppleCommander for Windows using MinGW (2.0.3 with GCJ update to 3.3).
See build/build-applecommander-mingw for the current script.

1.  Using MinGW, date related support classes are not compiled in.  This is a known
    issue and there is a suggested work-around posted here:
        http://gcc.gnu.org/ml/java/2002-04/msg00180.html
    Basically, force a reference to the classes which cause the error - the problem
    lies in classes loaded by reflection, so this forces these classes to be
    compiled in.  The suggested prelude is:
        // static references to these classes ensure that the linker will include them
        private static Class c1 = gnu.java.locale.Calendar.class;
        private static Class c2 = java.util.GregorianCalendar.class;
        private static Class c3 = gnu.gcj.convert.Input_ASCII.class;
        private static Class c4 = gnu.gcj.convert.Input_UTF8.class;
        private static Class c5 = gnu.gcj.convert.Input_8859_1.class;
        private static Class c6 = gnu.java.locale.LocaleInformation.class;
        private static Class c7 = gnu.gcj.convert.Output_ASCII.class;
    Presumably, this is just needed in one class - probably the class which contains
    the main method.  I am currently pasting this into AppleCommander.java itself.
    A better solution would be to do this automatically...

*************************
** MISCELLANEOUS NOTES **
*************************

Update #1:
    GraphicsFilter was reengineered to accomodate GCJ.  GCJ is not quite JDK 1.4 compliant
    and is obviously not a SUN JDK.  The image creation and saving responsibility was moved
    into subclasses of AppleImage.  AppleImage itself functions as a factory and tries to
    instantiate possible AppleImage classes via Reflection - this allows code to be compiled
    without patching the code.  When building with GCJ, the AppleImage classes that do not
    apply are simply not compiled nor linked into the executable. 

Update #2:
    Resources can be compiled/atteched to a specific Java class.  AppleCommander has
    a number of resources that should be built into the exe class.  This simplifies
    the distribution to be the AppleCommander executable and the SWT support DLL.
    See the AppleCommander build script for details.

Update #3:
    UPX is a very good compression tool for executables.  It should be standard practice 
    (and part of the automated build process) to run the final EXE and DLL files through 
    UPX to ensure a small filesize.  This has been incorporated into the AppleCommander
    build script but you may want to review how it is built in as detection can be funky.

Update #4:
    There are speed issues with the compiled version of AppleCommander which appear to
    be releated to GCJ 3.2 but do not show up in GCJ 3.3.  The speed issues do not
    appear to be present when run as a normal Java/SWT application.  I am unclear what
    the issue was, but the current assumption is that a bug or optimization to GCJ 3.3
    was introduced.  Additional note - this version of GCJ 3.3 also is packaged with 
    SWT 2052 which is a few point releases higher than other versions of SWT, so it also
    may be SWT releated.