This topic documents the following known issues for this release:

Unexpected Stepping Behavior
New Requirements for Accessing Methods of a Class in Another Package
Using Package-Managed Classes with Existing Tools
Calling the ActiveXControl Class
XML Issues

Note   The build numbers of the Microsoft virtual machine (Microsoft VM) and jvc for this SDK release can be found in the file Build.txt, located in the Relnotes folder of the SDK.

Unexpected Stepping Behavior

Using the latest Microsoft VM with an older version of Microsoft® Visual J++® may result in unexpected stepping behavior because of optimizations done by the Just-In-Time (JIT) compiler.

New Requirements for Accessing Methods of a Class in Another Package

The following requirement is now strictly enforced: 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; 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.

Using Package-Managed Classes with Existing Tools

If you are using package-managed classes with existing tools, note the following updates:

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. The clspack tool is provided in the SDK\bin directory. You can use clspack by setting the path to the SDK\bin (set path=c:\%SDKDIR%\bin;%path%) or copying it into %windir% directory.

In addition, the value of the CLASSPATH environment variable 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; 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 as follows before running the compiler: set CLASSPATH=%WINDIR%\Java\Classes\Classes.zip. For easy use, consider placing this command in a batch file.

Calling the ActiveXControl Class

Any class calling the ActiveXControl class needs to be trusted. If an applet intends to host a Microsoft® 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 class path 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 will use the ActiveXControl class. Therefore, any code using the classes output by jactivex needs to be trusted.

XML Issues

Some Microsoft® XML Data Source Object (DSO) functionality requires Microsoft® Internet Explorer version 4.0 or later.

The following components of the XML specification have not yet been implemented:

• Conditional sections in the DTD (INCLUDE and IGNORE keywords).
  
  
• Some aspects of character encoding.

For more information and an updated version of the Microsoft® XML parser, see the XML website .