Download New Classes in J++

Java vs. J++
(or why J++ failed)
Elisa Chong
CS 151
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.
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.
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
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.
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)
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
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.
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.
No JNI or RMI Support


JNI is the native code interface used to access platformspecific 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.
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.
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.
New Methods
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.
New Instance Variables
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.
New Interfaces
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 nonMicrosoft environments, it is necessary to always
implement the additional behavior, whenever you
implement either interface in a class.
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.
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-pitfallsupdate.html - ok
http://www.javaworld.com/javaworld/jw-11-1997/jw-11-pitfalls_p.html
In Conclusion


Microsoft Attempted to fragment the standardized
application programming environment established
by the Java technology, to break the crossplatform 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