Bug ID: JDK-4782458 Wrong exception is thrown while trying to set a Null or invalid Display mode

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
5.0 tigerFixed

Java -version

java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b06)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b06, mixed mode)


Try to set a display mode which is not available in the system it should throw IllegalArguementException(according to API doc).Instead,it throws an AWT Error which is as follows 

Exception in thread "main" java.lang.InternalError: Could not set display mode 
 at sun.awt.Win32GraphicsDevice.configDisplayMode(Native Method)  
 at sun.awt.Win32GraphicsDevice.setDisplayMode(Win32GraphicsDevice.java:300)  
 at Test1.main(Test1.java:20)  

Please try running the attached program "Test1.java".

Similarly ,if we Try to set a "null"display mode,it should throw     IllegalArguementException.Instead,it throws Null Pointer Exception which is as follows:

java.lang.NullPointerException 
	at sun.awt.Win32GraphicsDevice.isDisplayModeAvailable(Win32GraphicsDevice.java:345) 
	at sun.awt.Win32GraphicsDevice.setDisplayMode(Win32GraphicsDevice.java:296)  
	at Test.main(Test.java:20)  

Please try running the attached program "Test.java".

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b15 VERIFIED IN: tiger-beta

14-06-2004

EVALUATION setDisplayMode APIs are owned by 2D now. Reassigning to 2D after talking to ###@###.###. ###@###.### 2002-11-22 We should be throwing an IllegalArgumentException instead of a NullPointerException. This problem has existed since fullscreen was introduced in JDK1.4. ###@###.### 2002-11-25 There is also a hang in Test1.java. The parameters passed to DisplayMode are bogus. It might be that when we set up a DDrawDisplayMode() in awt_Win32GraphicsDevice.cpp, the DDrawDisplayMode is not valid. ###@###.### 2002-11-26 There are 2 distinct problems here: 1) This condition test in Win32GraphicsDevice.setDisplayMode() is wrong: if (dm == null && !isDisplayModeAvailable(dm)) An illegal display mode is either a null dm OR one that is not available. Substitute the && for an || and this is fixed. 2) Once that is fixed, we realize that isDisplayModeAvailable() does not do the right thing in native code. The display mode check is based on a call into DirectDraw and the callback(s) that it makes into our code with each applicable display mode. In the case of the Test1 app, we are passing in a completely bogus display mode, which should not result in a call to our callback bunction, but ddraw calls our function with every mode available. The source of this problem is an incorrect setup of the DDSURFACEDESC structure in Dx7Object::EnumDisplayModes(). We correctly set the w/h/d/refresh fields in the structure, but we fail to tell the structure that those fields are active. DDraw interprets this as equivalent to a NULL surface; any w/h/d/refresh values are valid, thus it enumerates all modes on the system. The fix to this is to specify a value for the dwFlags field that reflects the fields that are valid. This value will be DDSD_WIDTH | DDSD_HEIGHT, or'd with one or both of DDSD_REFRESHRATE and DDSD_PIXELFORMAT, depending on whether the user passed in don't-care values for those (DisplayMode.BIT_DEPTH_MULTI for depth and DisplayMode.REFRESH_RATE_UNKNOWN for the refresh rate). Also, we should make the pixelformat structure a bit more standardized by setting the dwFlags (DDPF_RGB) and dwSize (sizeof(DDPIXELFORMAT)) appropriately. ###@###.### 2003-07-21

21-07-2003