Reason: If your class files are arranged into packages, you have to invoke jc from the directory that is the root of the package tree (it is assumed that your class files reside in appropriately named subdirectories).
Resolution: See the sample in samples/PrjSys/package.
Reason: The current setting of JET’s memory usage limit is too small for compilation of your program.
Resolution: Increase the compiler heap size:
jc MyApp.jar -compilerheap=90000000
The default value of COMPILERHEAP may be inspected by running jc in the EQUATIONS submode:
jc =e
Reason: The current setting of JET memory usage limit is too large for your system.
Resolution: Close all applications that you do not need at the moment. If it does not help, reduce the size of compiler heap:
jc MyApp.jar -compilerheap=20000000
The default value of COMPILERHEAP may be inspected by running jc in the EQUATIONS submode:
jc =e
The obvious reason is that the class file does not exist. If the file exists, you must have specified wrong pathes in the redirection file or in the project file.
Example
Let’s assume that you want jc to find the file foo/bar/Foo.class (relative to the current directory).
Case A: If the class Foo belongs to the default package, add the line
*.class = foo/bar
to the local jc.red file, or the line
-lookup = *.class = foo/bar
to your project file.
Case B: If the class Foo belongs to the package bar, add the line
*.class = foo
to the local jc.red file or the line
-lookup=*.class = foo
to your project file.
Reason 1: If a certain class Foo is imported but never used during program execution, i.e. it is never instantiated, none of its static methods are called, and none of its static fields are accessed, the virtual machine does not load the class Foo and therefore the program would execute ok even if the file Foo.class is not present on the system.
Similarly, if the file Foo.class is present, but does not contain a particular method or field that is referenced in another class, execution on a virtual machine would fail only when and if control reaches the code referencing that field or method.
Unfortunately, not all vendors check their class libraries for consistensy, so third party archives (JARs and ZIPs) often contain references to absent classes, fields, or methods. We call such libraries fuzzy. For instance, Oracle’s JDBC driver, classes12.zip, is fuzzy.
JET by default requires all imported classes to be available during compilation, and does not permit references to absent fields and methods, so error messages are reported on an attempt to compile a fuzzy JAR or ZIP.
Resolution:
The compiler shall issue warnings and insert code raising the respective exception at locations where the absent classes or members are used.
Reason 2: An imported class is not available at compile time but becomes available at run time.
Resolution: set the equation CLASSABSENCE to “HANDLE”. This will enable the reflective shield facility.
-gui+
Properties may be set at compile time using the JETVMPROP equation or at launch time using the JETVMPROP environment variable. See System properties for details.
Resolution: Use resource binding. If that is not possible, add pathnames of .jar file(s) and directories containing resources to the CLASSPATH environment variable:
SET CLASSPATH=%CLASSPATH%;C:\Res\A.jar;C:\Res\audio
MyApp.exe
Reason: Application’s heap size is set to adaptive, and there is not enough available physical memory on the system, or the explicit setting is too low.
Resolution:
jc MyApp.jar -compilerheap=90000000
SET JETVMPROP=-Djet.gc.heaplimit:90000000 MyApp
SET JETVMPROP=-Djet.gc.defragment MyApp
More information on JET memory management may be found in Application memory usage tuning.
Reason: Your application runs too many threads.
Resolution: Reduce thread stack size:
jc MyApp.jar -stacklimit=100000
The default value of STACKLIMIT may be inspected by running jc in the EQUATIONS submode:
jc =e
Reason: Your application dynamically loads a class that is not explicitly imported and therefore was not recognized by the compiler.
Resolution:
Hint: If a particular library intensively uses dynamic loading, you may force compilation of all classes from the .jar file containing that library:
-lookup=*.jar=./Mylibs . . . !module MyLib.jar
Reason: Conversion classes for encodings with large conversion tables are not precompiled by JET. You have to add them to your project manually as described in Character encodings.
Reason: Run-time dynamic memory limit setting is too high.
Resolution:
jc MyApp.jar -compilerheap=90000000
SET JETVMPROP=-Djet.gc.heaplimit:90000000 MyApp
SET JETVMPROP=-Djet.gc.defragment MyApp
More information on JET memory management may be found in Application memory usage tuning.
Reason: Garbage collector is invoked too often due to low run-time dynamic memory limit settings.
Resolution: Let the run-time system to adjust the heap size dynamically:
jc MyApp.jar -compilerheap=0
More information on JET memory management may be found in Application memory usage tuning.
Use the standard Invocation API. See samples/Invocation.
JET fully supports Java Native Interface (JNI), which is the only standard way to call a native code function from Java. However, direct usage of JNI is very inconvenient and error prone. We recommend you to use xFunction — our Java library for calling native code functions from Java without using JNI and C programming at all. xFunction itself is implemented using JNI and reflection and therefore is 100% Java 2 Runtime compatible.
xFunction Home Page URL is:
http://www.excelsior-usa.com/xfunction.html
See Chapter Deployment Automation for information on JET deployment automation facilities.
Using JetPerfect, you may compile your application and it link together with the JDK classes it requires into a single EXE file.
See Chapter JetPerfect Global Optimizer for more information.
!module MyApp.ico