Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
I have analyzed the classes and have run across seven areas that should be of great concern to developers if they want to develop solutions with Microsoft's SDK for Java that will work in other Java 1.1 certified environments. These areas of concern are:
Baratz used the word "deceptively" in Sun's announcement of the lawsuit because the (javadoc) documentation for the Java classes that comes with the SDK makes no mention of these changes. To find these differences, it is necessary to use either the ClassVue tool that comes with the SDK or manually examine the source code. Your best bet is to rely on ClassVue, as the source files provided with the SDK are not always the ones used for the generated classes. For those unfamiliar with ClassVue, the equivalent tool that comes with the JDK from Sun is javap, a class file internals examiner.
As much as I'd like to claim that what follows is an exhaustive list of changes to the SDK, it is possible that something was missed. With several items, there is a pattern -- so if you avoid similarly named things you should be okay. All of the problems identified here are in the java.lang, java.io, java.awt, java.util, and java.security packages/sub-packages.
So, what changed in each package?
The first set of changes in Microsoft's SDK for Java is new classes, methods, and variables that were added to the system packages. A system package, or core Java API, is anything that begins with java.* in its fully qualified class name. So, as far as new classes go, 16 new ones were added into java.awt. These are:
| Microsoft's new Java classes for AWT peers |
|---|
| WButtonPeer | WCheckboxMenuItemPeer | WCheckboxPeer | WChoicePeer |
| WLabelPeer | WListPeer | WMenuBarPeer | WMenuItemPeer |
| WMenuPeer | WPopupMenuPeer | WScrollbarPeer | WScrollPanePeer |
| WTextAreaPeer | WTextComponentPeer | WTextFieldPeer | WUIPeer |
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. Stay away from that too. Additional package-private
(also called friendly, for when no access specifier keyword is specified) classes were added, like __AwtUIBand and __UIMenuRoot. Because these are inaccessible outside of java.awt, you cannot directly use them.
The most commonly added method is called getBaseName(). Thankfully, it too is package-private, although it should be just plain private. Other changes, like making ClassLoader's loadClassInternal() method private, instead of package private, are due to implementation differences and should have no effect on developers.
I don't mean to downplay the package-private changes that Microsoft made, but unless developers are extending the key Java class libraries themselves, they cannot access these changes. Since developers seeking cross-platform solutions know better than to inject their own changes into the key Java class libraries, this isn't an issue. (See Rule 3 of SunTest's "100% Pure Java Cookbook," referenced in the Resources section.)
The real problems appear with the public methods that Microsoft introduced:
| Public methods added into key Java libraries |
|---|
| Class | New Method(s) |
|---|
| java.awt.EventQueue | _postEvent (AWTEvent) |
| java.awt.Font | getNativeData() |
| java.awt.image.ColorModel | finalize() [was protected] |
| java.awt.image.DirectColorModel | getToolkitData() |
| java.awt.image.IndexColorModel | getOpaque() getToolkitData() |
| java.awt.SystemColor | getWin32Index() |
| java.lang.Class | getInterface(String) getMethods(int[]) getMethodFromSignature(String,String) getDeclaredMethodFromSignature(String,String) |
| java.lang.Runtime | getNativeServices() |
| java.lang.SecurityManager | checkFileDialog() checkMultimedia() checkRegistry(int,String) checkSystemStreams(int) |
| java.lang.VerifyError | getAuditDetails() getAuditIdentifier() getClassName() getMethodName() getPC() getViolationCode() getViolationDescription() |
| java.lang.reflect.Method | getDescriptor() getParameterCount() |
| java.util.Locale | Locale(String, String, String, int, int) getCodePage() getDefaultLocaleList() getLCID() [was private] getLocaleFromLCID(int) |
| java.util.ResourceBundle | getMenu (String) getMenuBar(String) |
You will need to avoid all of the above methods, unless you want your Java programs to run only with Microsoft's environment. In addition to these new methods, you have access to three new instance variables and lots of new Locales for internationalization:
| Instance variables incorporated into Java API |
|---|
| Class | New Variable | ||
|---|---|---|---|
| java.awt.Font | pData | ||
| java.awt.SystemColor | appWorkspace | ||
| java.lang.reflect.Member | PUBLIC_DECLARED | ||
| java.util.Locale |
|
PUBLIC_DECLARED is brand new to Member, and appWorkspace is brand new to SystemColor, while pData was private and is now public. As with everything else, avoid them. As far as the Locale objects go, Microsoft's environment
seems to understand a few additional languages, that JavaSoft doesn't. While the intention is good, instead of using the new
constants, you should create a Locale object yourself, with the necessary parameters, although not using the new Locales may require some extra work when formatting
messages.
For each Locale added, there are two public classes added into the java.text.resource package. Because Sun's documentation specifically states that you should not directly call any API in text.resource, I do not view these additions as a problem.
An interface defines a partial template that a class must follow. Microsoft seems to have modified the templates of some of the security interfaces:
| Additional methods in Java security interfaces |
|---|
| Interface | New Methods |
|---|---|
| java.security.interfaces.DSAPrivateKey | getAlgorithm() getEncoded() getFormat() getParams() |
| java.security.interfaces.DSAPublicKey | getAlgorithm() getEncoded() getFormat() getParams() |
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.
com.ms is a grouping of classes delivered with Microsoft's proposed Java implementation. All the classes within com.ms.* packages
normally are inaccessible to people using Netscape Navigator/Communicator and Java 1.1 environments. If you choose to use
something from a class in a com.ms.* package, more than likely you are moving outside the realm of portability. One example
in which this may prove tricky for the uninformed is getting FontMetrics from the Toolkit class (via getFontMetrics()). While the method signature is the same "public FontMetrics getFontMetrics()," what you get back is an instance of com.ms.awt.FontMetricsX. If you treat it as a FontMetricsX object, your program will work only with the Microsoft virtual machine for Java; if you stick with FontMetrics, then you're portable.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq