Microsoft Visual J++ Compiler, v 1.02.4337

The following notes apply to the Microsoft Visual J++ Compiler, version 1.02.4337. Information and issues listed here are subject to change in the next major release of the product.

Note This version of the compiler supports @dll tags for Microsoft J/Direct. It also supports @com tags for Java/COM integration. For more information see the Microsoft SDK for Java.

Using new Java Language Features in Visual J++ 1.1

This release of the Java compiler supports the new language features specified in Sun's JDK 1.1, including: inner classes, anonymous classes, instance initializers, anonymous array expressions, class literals, blank finals and final locals, and the @deprecated tag.

It is possible to use these new language features with Visual J++ 1.1. You may do this by replacing the compiler file in Visual J++ with three files from the Microsoft SDK for Java. First, save a copy of the compiler (jvc.exe) from your existing Visual J++ installation. Next, copy jvc.exe, jps.dll and msjvc.dll into your Visual J++ directory. Projects will then build using the new compiler.

JDK 1.1 Compatibility

This release of JVC is compatible with the language enhancements specified in Sun's JDK 1.1. The following section briefly describes differences between JVC (Microsoft's Java Compiler) and javac (Sun's Java Compiler).

The following items are in the Inner Classes specification and are implemented by Sun's javac, but not by JVC:

There are no known items in this category.

The following items are in the Inner Classes specification, but are not implemented by Sun's javac or by JVC:

Inherited members in inner classes

The specification states: "Any inherited member m of a subclass C is in scope within the body of C.... If C itself is an inner class, there may be definitions of the same kind (variable, method, or type) for m in enclosing scopes. In all such cases, the inherited member m hides the other definitions of m. Additionally, unless the hidden definition is a package member, the simple name m is illegal; the programmer must write C.this.m".

JVC does not implement the last sentence: the simple name m is accepted in these cases. Sun's javac does not implement this either.

Member access protection in inner classes

The specification states: "Access protection never prevents a class from using any member of another class, as long as one encloses the other, or they are enclosed by a third class."

In JVC and Sun's javac, an inner class can access private members of an enclosing class. However, an outer class cannot access private members of an enclosed class, nor can two "sibling" classes enclosed by a common class access private members of each other. These rules seem much more logical and useful than those in the specification.

Exceptions thrown from anonymous class instance initializers

The specification states: "An instance initializer in an anonymous class can throw any exception."

JVC does not allow an instance initializer in an anonymous class to throw any checked exceptions. Neither does Sun's javac.

The following items are implemented differently by JVC and by Sun's javac:

Deprecation Warnings

Deprecation warnings in JVC are automatic (no -deprecation switch), but do require that source code with deprecated members be recompiled. Deprecation warnings are emitted at warning level 2.

Inner class index attributes

In the section on the "InnerClasses" attribute, the specification states: "If an inner class is not a member, its outer_class_index_index is zero. If a class is anonymous, its inner_name_index is zero."

JVC reads and writes the InnerClasses attributes according to these rules; Sun's javac does not (it never writes zero in either of these fields). Sun's javac may fault when reading the InnerClasses attributes produced by JVC.

Inner class access to private members of enclosing class

The specification states: "When an inner class accesses a private field or method of an enclosing class, the an accessor method with default (package) access should be inserted to allow the inner class access to the private field or method.

Sun's javac generates code that accesses the private member directly, which may cause verification or illegal access errors on some virtual machines. JVC does not create accessor methods, but uses a mechanism that is compatible with all virtual machines.

When an inner class accesses a private field or method of an enclosing class, JVC changes the access flags of the field or method to indicate that the member has default (package) protection. An additional attribute is written and read by the compiler that indicates the actual access flags of the member. This attribute can and should be ignored by the virtual machine: it is for the compiler only.

Interface declarations in inner classes

The specification states: "Inner classes may not declare ... member interfaces."

JVC enforces this rule, Sun's javac does not.

Compatibility with code written for previous releases of Visual J++

Due to more strict error and security checking in this release of the compiler, some illegal code that compiled without errors using Visual J++ 1.x may now (correctly) fail to compile. One common cause is more careful checking of class member access across package boundaries. Section 3.6.7 of the Java Language Specification contains an example of this scenario.

Here is an example of a typical error message for this type of code:

error J0204:

Cannot access protected member 'x' in class 'Point' via a qualifier of type 'Point3d'