Main JAR Packager Native JFC Technical Support What's New dbDE

a. What is covered in this addendum
b. Resource binding
c. Differences with bytecode
d. Restrictions
e. Library lookup
f. Debugging Native Java Runtime
g. Changes to the Native Java Runtime
h. Changes to the Native Java Compiler


a. What is covered in this addendum
-----------------------------------------------------------------
This addendum discusses items that couldn't be covered in other documentation due to time constraints.

The primary topics discussed are the resource binding feature and limitations present in the current implementation of Symantec Native Java.


b. Resource binding
-----------------------------------------------------------------
You can bind your resources (e.g. gif files) directly to your DLL or EXE or you can leave them on disk. For an example of how to
bind resources refer to the sample 'resource'.


c. Differences from bytecode
-----------------------------------------------------------------
1. Applets

Native Applets are not supported. Support for running native applets would have to be provided by the browser vendor.

2. ClassLoaders and dynamic class definition

The default native classloader will load its classes from the executable or DLLs directly. Custom classloaders are not supported in native Java. Specifically the method ClassLoader.defineClass(..) will throw an exception if used. The reason for this is the defineClass(..) method allows the user to load a class from an array of bytecode. The native implementation understands x86 code only; it does not understand bytecode.

3. (Custom) Security Managers

Security managers are meant to provide security control for access to several class attributes (properties and methods). Currently this is not supported in native Java, as it comes with a large runtime overhead. Also this feature is mainly needed for bytecode, so browsers can control what level of access downloaded Java bytecode will get to the local system. Native Java is meant for applications only, and will provide you with the fastest possible executables instead.


d. Current Restrictions
-----------------------------------------------------------------
1. JNI

The native Java implementation provides complete support for the Java Native Interface (JNI). Please refer to the samples for any additional information. Currently, JNI Global references don't register themselves with the garbage collector. The reference functions simply return the jobject value that was passed in.

2. Byte code to x86 code conversion.

We currently don't support the conversion of byte code (.class files), to x86 code (native code). This means that in order to use 3rd party classes you will need to have the source for them, or you will need a DLL and import library from the vendor of the classes. An enhancement may be made in the future to support this functionality.

3. GEO components.

The GEO package included in the symbeans components library was not included in the symbeans.dll; consequently, the user cannot use the GEO components in building native applications.


e. Automatic library lookup
-----------------------------------------------------------------
When using a native DLL, under most conditions you will need to link with the corresponding import library of that specific DLL. The import library name will have to be explicitly specified in the command line or if one is using the Visual Cafe IDE, it has to be added to the library listing under the project options.

As an added feature, the native compiler will add information to class files that were compiled and linked to DLLs. So, when these class files are used as class definition lookups during a native compilation of another Java source code, there is no need to explicitly specify the import library name during that compilation. The import library will be found automatically as long as it is located in the directory where the LIB environment variable specifies (e.g. C:\VisualCafe(WDE|PDE|dbDE)\Lib).

This feature does not invalidate the class files as legal bytecode class files specific to your installation.


f. Debugging Native Java Runtime
-----------------------------------------------------------------
The default installation of Visual Cafe creates shortcuts in the start menu for switching between debug and release version of the Native Java runtime DLLs. In order to step into the runtime source while debugging, you must first switch to the debug versions of these DLLs. These DLLs reside in your windows\system (system32 for Windows NT). These Debug DLL files and redistributable DLL files can also be found on the Visual Cafe installation CD under VCafe.


g. Changes to Native Java Runtime
-----------------------------------------------------------------
* snjres tool now exits with error code of 0 if there are no problems. The exit code was random before.

* snjreg tool crash problem fixed.

* System.getProperty( "java.version" ) now returns "1.1.4" instead of "Unknown Version". The following symbeans components are affected by this:
symantec.itools.awt.TreeView
symantec.itools.awt.MultiList

* JNI bug fixed - passing arguments to methods from C/C++ code.

* Added internationalization support dlls.

Groupings are based upon locale_str.h.

snjint - additional internationalization support classes.

snj_ext - Extra encoding classes that don't have an associated locale in java\text\resources and that are not platform specific. ( EBCDIC, tiawanese )

snj_mac - Encodings for the Macintosh platform.

snj_la - Catalan, German ( Germany, Austria, Switzerland ), English ( Canada, GB, Ireland ), Spanish, Italian, Dutch

snj_ibm - Misc IBM encodings

snj_fr - French for all supported locales. ( France, Belgium, Canada, Switzerland )

snj_is - Icelandic

snj_sv - Swedish, Norwegian ( Nynorsk ), Danish, and Finnish

snj_pt - Portuguese

snj_ar - Arabic

snj_ru - Belorussian, Bulgarian, Macedonian, Russian, Serbian, Ukranian

snj_pl - Czech, Hungarian, Polish, Romanian, Serbo-Croatian, Slovak, Slovenian, Albanian

snj_el - Greek

snj_et - Estonian, Lithuanian, Latvian, Lettish

snj_iw - Hebrew

snj_ja - Japanese

snj_ko - Korean

snj_tr - Turkish

snj_zh - Chinese

snj_tw - Taiwanese

The import libraries for each group name ends with .lib and the DLLs are in the form of snj*11.dll

* Added native JDBC-ODBC bridge and other sun support classes.

* Garbage collection bug fixed - different problems with garbage collecting static objects.

* Linked/bounded resource bug fixed - problem with the call Toolkit.getImage(URL) when resource is linked/bounded into the application.

* MediaTracker bug fixed - problem with loading more than 10 resources using MediaTracker.

* Fixed initialize problem that broke output streams on Japanese ( as well some other ) systems.

* Several changes to reduce the number of 'C' runtime file handles consumed.

* AWT bug fixed - problem with using AWT components in NT4.0 with Service Pack 3 installed and when display is set to 24 bit colors.

* Key input events in AWT bug fixed - problem with inputting certain key combinations like the 'umlaut' character in AWT.

* Thread.stop() now works in most cases. When Thread.stop() is called, a ThreadDeath exception gets noticed when the thread calls sleep() or yield(), or if the thread passes into 'C' code
and tries to come back.


h. Changes to the Native Java Compiler
-----------------------------------------------------------------
* Garbage collection bugs were fixed. In certain rare cases, compiler-generated objects (members of statically allocated objects) would be incorrectly garbage collected, yielding runtime null-pointer exceptions. As a result of these changes, compilers of version 210.184 and later require the use of runtime dlls version 113.044 or higher.

* Two native floating point code generation bugs were fixed. One regarded extreme values and integer conversion, and another regarded expressions involving sign changes and common subexpressions.

* All reproducible cases of compiler-reported internal errors have been addressed.

* Memory usage of the compiler is now more efficient. It will now use less memory when compiling large projects.

* Fixed bug in producing proper names for overloaded native methods.