Microsoft Visual J++ Compiler

The following notes apply to the Microsoft® Visual J++™ Compiler. Issues identified here are subject to change without notice.

Note This version of the compiler supports @com tags for Java/COM integration. It also supports @dll tags for Microsoft® J/Direct™. For more information on these technologies, see the documentation for J/Direct and @com Directives, provided in the Microsoft SDK for Java.

Using new Java Language Features in Visual J++ 1.1

This release of the Java Language Compiler supports the new language features specified in the JDK 1.1 from Sun Microsystems, Inc., including

• Inner classes
• Anonymous classes
• Instance initializers
• Anonymous array expressions
• Class literals
• Blank finals and final locals
• The @deprecated tag

It is possible to use these new language features with Microsoft® Visual J++™ 1.1. You may do so 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 the Sun JDK 1.1. The following section briefly describes differences between jvc (the Java Language Compiler from Microsoft) and javac (the Sun Java Compiler).

The following items are in the Inner Classes specification and are implemented by the Sun 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 the Sun 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. The Sun 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 in the Sun 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 the Sun 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). However, warnings 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; the Sun javac does not (it never writes zero in either of these fields). Sun's javac may fault when reading the InnerClasses attributes that are 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 accessor method with default (package) access should be inserted to allow the inner class access to the private field or method."

The Sun 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; the Sun 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.

The following 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'