Share via

J# Design-Time Breaking Changes

  • Article

 
Short Description HTTP errors will result in IOException
Affected APIs java.net.URL.getContent(); java.net.URL.openStream(); java.net.HttpURLConnection.connect(); java.net.HttpURLConnection.getContent(); java.net.HttpURLConnection.getInputStream(); Severity Low Compat Switch Available No

 
Description J# AddOnRTM and version 1.1 implementations for the above methods return a stream object which contains the error response returned by server. This semantic doesn't distinguish between the case where server returns the actual document as a response message and say, the case where it simply sends HTTP 404 (Not Found) response with error information. This means that user code may read the stream data assuming it's the data for say, an image object. But the data actually is plain error message. The new behavior (i.e. throwing IOException) is compliant with MSJVM (VJ++ 6.0) implementation. In AddOnRTM and version 1.1, we tried to match MSJVM behavior, but this issue didn't get caught in the earlier releases. If this issue is not fixed now, our model [and its semantics] will be broken forever.

 
User Scenario With the change, the above APIs will throw IOException for the cases where HTTP error is encountered while retrieving the resource from the server.

 
Work Around User code can catch IOException (which is expected exception as per JDK spec). The code can either ignore/swallow it or assume the resource is not available. Of course; this will require re-compilation. However; since IOException is expected exception for the above APIs; it's reasonable to expect that the code is already catching IOException. So; recompilation would not always be necessary.

 

 

 
Short Description Lightweight components should listen for mouse events in order to be hit tested.
Affected APIs No APIs impacted directly. Severity Low Compat Switch Available No

 
Description

 

If a lightweight component is not listening for mouse events, then the event is passed to the any overlapping sibling that is listening for mouse events and within whose boundaries the mouse lies. Otherwise it is passed to the nearest ancestor that has an attached mouse listener. If none of the ancestors listen for the mouse event, it is delivered on the nearest native ancestor. The exact change from previous implementation:

  1. If the lightweight component followed 1.0 eventing, the events would get passed in 1.0 eventing model.
  2. If it was following 1.1 eventing model, if the component did not have any mouse listeners, then the event was being passed up the parent hierarchy, but not passed to any overlapping siblings that were interested in mouse events.

The impact of 1. is not severe as in JDK. Lightweight components were first introduced in JDK 1.1, by which time 1.0 eventing model was deprecated. Swing implementation requires that if a component is not listening for the mouse, then any overlapping component that listens for the mouse event should get the mouse event.

 
User Scenario

 

  1. 1.0 style eventing removed.
  2. Cursor set on a lightweight component will not show up unless a mouse listener is added.

 
Work Around No workaround.

 

 

 
Short Description Lightweight components follow 1.1 eventing model only.
Affected APIs All 1.0 eventing APIs in vjslib. java.awt.Component:
public boolean postEvent (Event evt)
public boolean handleEvent (Event evt)
public boolean action (Event evt, Object arg)
public boolean gotFocus (Event evt, Object arg)
public boolean lostFocus (Event evt, Object arg)
public boolean keyDown (Event evt, int key)
public boolean keyUp (Event evt, int key)
public boolean mouseDown (Event evt, int x, int y)
public boolean mouseDrag (Event evt, int x, int y)
public boolean mouseEnter (Event evt, int x, int y)
public boolean mouseExit (Event evt, int x, int y)
public boolean mouseMove (Event evt, int x, int y)
public boolean mouseUp (Event evt, int x, int y) 		Severity Low Compat Switch Available No

 
Description

 

Lightweight components were supporting 1.0 eventing and 1.1 eventing model previously. With this change lightweights no longer support 1.0 eventing model and always follow 1.1 eventing model. This change is required for Swing implementation.

Reference platforms which we test against - MSJVM for AWT and Websphre for Swing also do not support this.

 
User Scenario Using 1.0 eventing is not supported with lightweight components. Users should use 1.1 eventing model.

 
Work Around No workaround.

 

 

 
Short Description For malformed file names ("C::\TEMP.TXT" - note the two colons), the constructor of java.io.FileWriter throws a different exception, than it was throwing previously.
Affected APIs .ctor java.io.FileWriter(String fileName) Severity Low Compat Switch Available No

 
Description In version 2.0, we had changed the implementation of java.io. classes from native to .net (becasue of security reasons). We have this bug because of this very specific reason. However, note that according to JDK specs, we should have thrown java.io.IOException in the first place—so this is actually a bug that got fixed. Also note that, this is a negative scenario, where the user is creating a java.io.FileWriter stream on a malformed file name.

 
User Scenario If the user catches 'java.lang.InternalError' exception being thrown by the .ctor java.io.FileWriter(String fileName) for unexistent files, he will be broken, as we are now throwing java.io.IOException.

 
Work Around Catching java.lang.Exception(the mother of all JDK exceptions) solves the problem.

 

 

 
Short Description FileInputStream doesn't accept uninitialized FileDescriptor class.
Affected APIs public java.io.FileInputStream(FileDescriptor fd); // Constructor Severity Low Compat Switch Available No

 
Description There is a constructor in java.io.FileInputStream() class which takes a FileDescriptor as a parameter. In earlier implementations, there was no validation performed on FileDescriptor object. Thus FileInputStream, constructed in this manner, remained in an invalid state. And subsequent calls on FileInputStream which in turn call into FileDescriptor were throwing exceptions. The new behavior detects this error condition beforehand and throws IOException at the construction time itself.

 
User Scenario This change may cause applications that try to initialize J# FileInputStream class using uninitialized java.io.FileDescriptor class.

 
Work Around None

 

 

 
Short Description We will not be supporting the System properties that are specific to Java Language
Affected APIs java.lang.System.getProperties. We want to remove the following properties: java.vendor.url=https://www.microsoft.com/
java.version=1.1.4
java.class.path=C:\TEMP;C:\WINDOWS\Microsoft.NET\Fram...
java.home=C:\WINDOWS\Java
java.class.version=45.3
java.resource.path=C:\TEMP;C:\WINDOWS\Microsoft.NET\Fram...
awt.appletWarning=Warning: Applet Window
java.vendor=Microsoft Corp.
We want to change these properties:
user.home=C:\WINDOWS\Java 		Severity Low Compat Switch Available No

 
Description As we are not a Java vendor, we will not be supporting the properties that are related to the Java language. We will be returning null for such properties.

 
User Scenario The users will not be able to get the Properties related to the java language. The backward compatibility will be broken.

 
Work Around The user needs to set the properties using the setProperties() API to add the Java language-specific properties to the System.java.util.Properties prop = java.lang.System.getProperties();
prop.put("java.vendor","Microsoft Corp");
java.lang.System.setProperties(prop);

 

 

 
Short Description Some public static fields that were non-final in v1.0/v1.1 have been made final(readonly) in version 2.0.
Affected APIs public class java.awt.datatransfer.DataFlavor
Field: public static DataFlavor plainTextFlavor is now readonly in version 2.0
Field: public static DataFlavor stringFlavor is now readonly in version 2.0
 Severity Low Compat Switch Available No

 
Description The above fields changed from being non-readonly to readonly in version 2.0. This was done because of changes in the Java language specs 1.2 (we usually follow JDK 1.1.4). Also this was pointed out by FxCop and we fixed it to be FxCop clean.

 
User Scenario The user will not be able to change "DataFlavour.plainTextFlavour" field in their source code.

 
Work Around No workaround

 

 

 
Short Description Locale.getDisplayCountry(Localt tgtLocale), Locale.getDisplayLanguage(Localt tgtLocale), would from now onwards return strings in the language of the source locale only.
Affected APIs Locale.getDisplayCountry(Localt tgtLocale) Locale.getDisplayLanguage(Localt tgtLocale) Severity Low Compat Switch Available No

 
Description

 

JDK specs for Locale.getDisplayCountry(Locale tgtLocale) "The method retrieves a human-readable version of this Locale object's country code. The human-readable name is localized for the language specified in 'tgtLocale'. If the country name cannot cannot be translated into the language specified by 'tgtLocale', the country name is translated into the language specified in this Locale object.

Till version 1.1 we used to do the translation for only French and German languages other than English. How we implemented this was that we had a lookuptable whose rows were (EngName, FrenchName, GermanName) - the EngName being the key for lookup (EngName was got by quering the BCL).

Since we are layered on top of BCL, any time something (say the country name in English) changes in the BCL we need to do corrosponding changes to our lookup tables (update French and German names). So from now onwards we have decided not to do any translation at all.

We have decided not to do any translation at all and return strings in the language of the source locale itself(the JDK specs anyway say that if translation fails you could return strings in the language of the source locale). Similarly for Locale.getDisplayLanguage(Locale tgtLocale).

 
User Scenario

 

Before the change Locale.getDisplayCountry(Locale.FRENCH) would have returned the current locale's country name in French, now it will return the country name in the language of the source locale(the instance locale).

Before the change Locale.getDisplayCountry(Locale.GERMAN) would have returned the current locale's country name in German, now it will return the country name in the language of the source local(the instance locale). Similarly for Locale.getDisplayLanguage(Locale tgtLocale)

 
Work Around No workaround

 

 

 
Short Description "Instantiating enums" / "enums as identifiers" will result in compile time error from now onwards
Affected APIs This is a compile time scenario. Severity Low Compat Switch Available No

 
Description

 

  1. In J# you could use an enum(say enum "Color" defined in C#) as Color c = new Color();
    Color c1 = c.red; //you can access static members through an instance as per Java semantics     During version 1.1 the Java language didn't have an "enum"—so neither did J#, but J# could always consume a .net "enum" as shown above. During the version 2.0 timeframe, Java language has come up with its own "enum", which J# is supporting now. Now instantiating "enums" as per Java language, is a compile-time error. So even .net enums which previously in version 1.1 could be instantiated, would from now onwards result in a compile-time error if instantiated.
  2. Any user code using "enum" as a variable name(or identifier) will NOT compile from now onwards; as "enum" is now a keyword in J# - The workaround is to change "int enum" to "int @enum" for things to work.

 
User Scenario  

 
Work Around

 

Developers should not be doing "new Color()" to use the .net enum in the first place; he could always use "Color.red" directly. And that is the workaround. The below lines:

Color c = new Color();
Color c1 = c.red;

 should be changed to:Color c1 = Color.red;

 

 

 
Short Descriptionn Values of final static fields have changed for classes shipped in vjssupuilib.dll(swing functionality).
Affected APIss Many Severity Very Low Compat Switch Available No

 
Description

 

The changes made below are to conform to the JDK 1.4 specs. vjssupuilib.dll is shipping for the first time with VS 2005(it has never shipped with VS before) - it had earlier shipped as "Swing GDR" in mid 2003 - the changes mentioned are wrt to the Swing GDR release.

The values of these final static fields have changed:

BasicOptionPaneUI
   public static final int MinimumWidth = 262; from 250
   public static final int MinimumHeight = 90; from 100

JFileChooser
   public static final String DIRECTORY_CHANGED_PROPERTY = "directoryChanged"; from "DirectoryChanged";
   public static final String FILE_SELECTION_MODE_CHANGED_PROPERTY = "fileSelectionChanged"; from "FileSelectionChanged"
   public static final String FILE_VIEW_CHANGED_PROPERTY = "fileViewChanged"; from "FileViewChanged"
   public static final String FILE_FILTER_CHANGED_PROPERTY = "fileFilterChanged"; from "FileFilterChanged"

JSplitPane
   public static final String BOTTOM = "bottom"; from Bottom
   public static final String CONTINUOUS_LAYOUT_PROPERTY ="continuousLayout"; from continuousLayout
   public static final String DIVIDER_SIZE_PROPERTY = "dividerSize"; from DividerSize
   public static final String LAST_DIVIDER_LOCATION_PROPERTY = "dividerLocation"; from DividerLocation
   public static final String ONE_TOUCH_EXPANDABLE_PROPERTY = from OneTouchExpandable
         "oneTouchExpandable";
   public static final String ORIENTATION_PROPERTY = "orientation"; from Orientation
   public static final String LEFT = "left"; from Left
   public static final String RIGHT = "right"; from Right
   public static final String DIVIDER = "divider"; from Divider
   public static final String TOP = "top";

 
User Scenario Applications directly using the values of these above-mentioned fields will be broken.

 
Work Around None