1. Java vs. J++ (or why J++ failed) Elisa Chong CS 151

2. History Microsoft’s “Java-compliant” J++ violated Java's philosophy of "Write once, run anywhere". Dangerous to Microsoft is the possibility that if enough portable Java applications are written, the need for Windows evaporates.

3. Background June 20th of 1996 - Microsoft Corporation announced support for Sun Microsystems' Java in Internet Explorer version 3.0. October 7, 1997 - Announced today that it is suing Microsoft for failing to stick to the letter of its Java licensing agreement.

4. Sun’s Reasons Prevent MS from misleading Java developers and prevent them from delivering anything but fully compatible Java technology implementations Prevent Microsoft from improperly using the Java Compatible logo Get MS back into compliance (By not shipping the complete JDK in the final version of IE 4.0, MS breached its contractual obligation

5. Microsoft’s Strategy The first was to implement standard Java libraries poorly or not at all, and then provide a Windows-only alternate library that runs well on Windows operating systems and not at all on non-Microsoft operating systems. Add functionality to the standard Java libraries by providing libraries to fill voids. (i.e. The Java AWT does not provide access to all the Windows GUI functionality. Microsoft extended the AWT to provide access to these functions. A side effect was that Java programs using these Microsoft library extensions were not able to be ported to non-Windows machines.

6. Summary of Violations Microsoft's J/Direct @dll COM imports violate standard Java coding conventions by being embedded inside Javadoc-style comment blocks. Microsoft's Internet Explorer 4.0 and SDK (software development kit) version 2.0 do not support the JNI Specification and do not natively support RMI (Remote Method Invocation)

7. Summary of violations (cont.) MS added the following: 16 new classes were added into java.awt 1 was added into java.lang 32 new public methods 3 new instance variables Lots of new Locales for internationalization 8 additional security methods

8. Summary of violations (cont.) MS's implementation is missing a required method – the toString() method of the ByteArrayOutputStream that accepts a character encoding name as a parameter MS’s Visual J++ includes the WFC (Windows Foundation Classes), which support a language construct called delegates or bound method references. This construct, and the new keywords, "delegate" and "multicast", introduced to support it, are not a part of the Java programming language.

9. Compiler Directives Non-descriptive attributes are placed in class files that only Microsoft's Java VM understands. These refer to @ddl commands in javadoc-style comments: /** @dll.structmap([type=FIXEDARRAY, size=2]) */ /** @dll.struct(pack=1, auto) */ /** @dll.import("GDI32",auto,setLastError) */ /**@dll.import("KERNEL32",auto,entrypoint="GetLargestConsoleWindow Size") */ When the MS compiler finds this directive in the source, it adds an attribute to the class file to load the specified dynamic library. However, the standard Java way to load a library is with the System.loadLibrary() method. Because non-Microsoft Java VMs will not recognize the attribute added by the @dll.import directive, the necessary library will not load and the program will not work correctly.

10. No JNI or RMI Support JNI is the native code interface used to access platform- specific capabilities, like a serial port or a microphone, for things that aren't available yet through the Core API. The goal of JNI is to allow developers to provide a single set of native libraries for every Java implementation on a specific platform. The lack of JNI support in MS products requires native-library vendors to maintain multiple libraries for integration into different Java virtual machines on the same platform. MS provided the RMI classes separately from all its products, it doesn’t provide the rmic compiler. The lack of the rmic compiler makes both the SDK and J++ environments incomplete and incompatible. When it comes to RMI, the remote method invocation library for executing Java code directly within other Java virtual machines.

11. New Classes 16 new classes where added to java.awt All classes are peer classes for AWT components, where a peer is the platform-specific representation of a graphical component.

12. New Classes (cont.) With the exception of the last one, all the classes are peer classes for AWT components, where a peer is the platform- specific representation of a graphical component like a button or menu. Normally, these classes would go into a different package like sun.awt.windows or sun.awt.motif. Since you aren't supposed to use them anyway, they should be easy to avoid. The WUIPeer class also is a peer, but it supports a Microsoft-specific behavior.

13. New Methods

14. New Methods (cont.) Key problem appears in public methods that microsoft introduced. All the methods on the previous slide are platform dependant and will only run with MicroSoft’s environment. You will need to avoid all of the above methods, unless you want your Java programs to run only with Microsoft's environment.

15. New Instance Variables

16. New Instance Variables & Locale PUBLIC_DECLARED is brand new to Member, and appWorkspace is brand new to SystemColor, while pData was private and is now public. Microsoft's environment seems to understand a few additional languages, that JavaSoft doesn't.

17. New Interfaces

18. Interfaces (cont.) An interface defines a partial template that a class must follow. MS modified the templates of some of the security interfaces. The way interfaces work, when you create a class that implements an interface, you define a method for each method declared in the interface. By increasing the number of methods in the interfaces, Microsoft is breaking every class that implements each original interface. If you need to create programs to work in both Microsoft and non- Microsoft environments, it is necessary to always implement the additional behavior, whenever you implement either interface in a class.

19. Missing Method The toString() method of ByteArrayOutputStream that accepts a character encoding name as a parameter isn't present. A character encoding permits localized display of text messages. The workaround for this omission is to ask for the byte array of the stream ( toByteArray() ) and then use the String constructor that accepts an encoding name. By always taking these two steps, even with the JDK, you'll be sure your programs will work when used with Microsoft's runtime environment.

20. Bibliography http://java.sun.com/docs/white/delegates.html - sun article discussing items on J++ http://www.nikos.com/javatoys/articles/tsv1298.html - bunch of why j++ is not compliant examples. http://developer.netscape.com/docs/wpapers/javax/javax.html#war - very good http://www.javaworld.com/javaworld/jw-08-1998/jw-08-pitfalls- update.html - ok http://www.javaworld.com/javaworld/jw-11-1997/jw-11-pitfalls_p.html

21. In Conclusion Microsoft Attempted to fragment the standardized application programming environment established by the Java technology, to break the cross- platform compatibility of the Java programming environment, and to implement the Java technology in a manner calculated to cause software developers to create programs that will operate only on platforms that use defendant Microsoft's Win32-based operating systems and no other systems platform or browser This in turn caused developers to be wary of the J++ SDK and for the sake of writing Java code that would be