|
Known Issues for the
Microsoft VM for Java
This
release of the Microsoft VM strictly enforces the
following requirement: for a class to access methods of a
class in another package, the second class must be
declared public. Previous releases did not enforce this
requirement. Hence some applets that worked before may
display errors with the new virtual machine. It is
advisable to make the packages conform to this Java
requirement.
For
ActiveX-Beans integration, certain functionality
(such as persistence and OC96 windowless support)
is not yet present. The ActiveX control hosting
does not support all ambient properties. Code
download will be provided in future releases.
VM uninstall option is provided in this release. Be aware of the following issues:
If you want use the VM uninstall option, go to Control Panel, Add/Remove Software and uninstall the VM. If you uninstall the VM yet still plan to use Internet Explorer 4.0, this may cause potential problems with the downloading ability of the browser.
Internet Explorer 4.0 uninstall includes an option to remove the Microsoft VM for Java. If you uninstall Internet Explorer 4.0 yet plan to use the VM and the SDK, the VM may not function properly. You must reinstall the stand-alone VM, by using the "Download" or the "Install and Download" option offered by SDKsetup.exe (the SDK download wizard). You can obtain the stand alone VM (majavx86.exe) from the download directory you define or use the default directory C:\SDK-Java.20\Components. You can then double click on the msjavx86.exe to reinstall the VM at any time.
Using
package-managed classes with existing tools:A
tool called clspack creates all the ZIP
files that are usually included in
%WINDIR%\Java\Classes, and are now stored in
the package manager. It is provided in the
SDK\bin directory. You can use it by setting the
path to the SDK\bin (set
path=c:\sdk-java.20\bin;%path%) or copying it
into %windir% directory.
In addition, the
value of the CLASSPATH registry setting is
prepended with a reference to this generated
classes.zip file (if one is not currently there).
The compiler provided with the SDK (jvc.exe) checks
this location by default for classes, so there is
no need to set the CLASSPATH environment
variable.
For
other compilers that do not check this location
by default, set the CLASSPATH environment
variable with:
set
CLASSPATH=%WINDIR%\Java\Classes\Classes.zip
before
running the compiler. It's a good idea to
place this command in a batch file for easy use.
- Raw
Native Interface Enhancements:
The Raw Native
Interface (RNI) has been extended as a result
of feedback and performance enhancements. The
enhancements made to RNI are in four primary
areas:
- Additional
APIs to enable reflection from native code
- Changes
to support future garbage collection
performance enhancements
- RNIGetCompatibleVersion
requirement for RNI DLLs
- RNI
invocation APIs
For a
more detailed description of the new and updated
APIs, see the SDK documentation.
- Any
class calling the activeXControl class
needs to be trusted. If an applet intends to host
an ActiveX Control using the activeXControl
class, it needs to be signed with the "fully
trusted" permission. Any class calling the activeXControl
class needs to be on the CLASSPATH or have the
right permissions ascribed to it through package
management. If the JActiveX tool is used
to host an ActiveX Control, the classes output by
the tool end up using the activeXControl
class. So any code using the classes output by JActiveX
needs to be trusted.
- The
following components of the XML specification have not yet
been implemented:
- Conditional
sections in the DTD (INCLUDE & IGNORE
keywords)
- Some
aspects of character encoding.
|