I am a Software Design Engineer in the Enterprise Server Group. From April 1998 through June 1999, I was a Software Design Engineer on the MSJVM Team. During this time I was responsible for developing Java/COM samples, white papers, and testing the MSJVM Java/COM interface. If called to testify as a witness in this case, I could and would testify competently to the truth of the statements made in this declaration.

I am the author of an article entitled Using COM Objects from Java that was posted in the "Technical Articles" section of the Microsoft Technologies for Java web site at http://www.microsoft.com/java/resource/java_com2.htm . I am also the author of another article entitled Integrating Java and COM , posted at http://www.microsoft.com/java/resource/ java_com.htm . In these white papers, I made statements regarding the use of custom class attributes to add functionality as being an approved method under the Java specification, and the best way to extend Java functionality according to The Java Virtual Machine Specification

I understand that Sun has objected to the above statements. For the reasons set forth below, I believe that these statements are in fact true.

The compiler directive "@com" provides access to native Component Object Model (or COM) libraries. A Java application calling a method on a COM component is the same as a Java application calling a native method via the Java Native Interface. To use a native method via the Java Native Interface, a Java object is created that contains native methods and a native code wrapper is created that exports function names according to the Java native method prototype. The @com compiler directive is simply an optimization for calling native COM code. The MSJVM uses the @com attributes to dynamically create the native code wrappers required to make the native call, so that users do not have to write these wrappers themselves.

In stating that custom class attributes were an approved method of adding this kind of functionality to Java classes, I relied on 4.7.1 from the Java Virtual Machine Specification (entitled "Defining and Naming New Attributes" ) which states as follows:

Compilers for Java source code are permitted to define and emit class files containing new attributes in the attributes tables of class file structures. Java Virtual Machine implementations are permitted to recognize and use new attributes found in the attributes tables of class file structures. However, all attributes not defined as part of this Java Virtual Machine specification must not affect the semantics of class or interface types. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize.

For instance, defining a new attribute to support vendor-specific debugging is permitted. Because Java virtual machine implementations are required to ignore attributes they do not recognize, class files intended for that particular Java virtual machine implementation will be usable by other implementations even if those implementations cannot make use of the additional debugging information that the class files contain. Java virtual machine implementations are specifically prohibited from throwing an exception or otherwise refusing to use class files simply because of the presence of some new attribute. Of course, tools operating on class files may not run correctly if given class files that do not contain all the attributes they require. Two attributes that are intended to be distinct, but that happen to use the same attribute name and are of the same length, will conflict on implementations that recognize either attribute. Attributes defined other than by Sun must have names chosen according to the package naming convention defined by The JavaTM Language Specification. For instance, a new attribute defined by Netscape might have the name "com.Netscape.new-attribute. "

Java Callable Wrappers follow all of the rules required for new attributes. If a Java developer chooses to use the @com directive for accessing COM functionality, that functionality will be optimized on Virtual Machines that support the COM attributes, but the applications will still work on Virtual Machines that do not, because those Virtual Machines will ignore those attributes that it does not recognize, and will use the regular Java Native Interface calling implementation to invoke the native methods in the Java Callable Wrapper.

I believe that these methods are the best way to accomplish Java/COM integration. Java/COM integration is a valuable function for developers, allowing them to create truly useful Windows applications and preserve their investments in pre-existing COM objects while taking advantage of the Java programming language. The usefulness of Java/COM integration has been recognized by a number of different companies, each of which offer Java developers tools that support COM development in ways similar to Microsoft. In fact, Suns own subsidiary NetDynamics provides a method to integrate Java code with COM objects.

Microsofts use of the @COM directive in its developers tools is a method of making it easier for developers to achieve the COM integration described above that allows users to more easily make use of existing technology that uses COM objects. The sole purpose of the language extensions and compiler directives is to make it easier for Java developers to write better, faster Windows-specific applications. These tools increase the performance of the software and make it more attractive to developers.

The developer who is interested in using COM objects in Java is by definition a developer who is attempting to write a Windows-specific application, as Windows applications are the only applications that use COM objects.

There was no intent on my part to deceive anyone who read my papers into thinking that Sun had approved Microsofts technologies for Java/COM integration, or that these were not Microsoft-specific tools. I regularly participate in discussion groups and Internet forums for Java developers and have never had a Java developer indicate any confusion about this or about the statements in my papers. I was not aware that the Court had preliminarily ruled that Microsofts Java/COM integration technologies were inconsistent with the published Java specifications. My statements were based on my own interpretation of the specification and my experience as a java language programmer.

If I had been notified by Sun or anyone else that they were confused or misled by these statements I would have changed them to make it more explicit that these are my opinions and not intended to imply any approval by Sun or removed them. Now that Sun has apparently taken issue for the first time (although the my papers have been posted since January 1999), I intend to remove this language from my white paper.