JDK-4895864 : REG:any graphics app will get NPE on win98
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_98
  • CPU: generic,x86
  • Submitted: 2003-07-24
  • Updated: 2003-09-15
  • Resolved: 2003-08-19
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
Related Reports
Duplicate :  
JDK-4899750 - REGRESSION: It's impossible to create JFileChooser on Winows 98
Duplicate :  
JDK-4894924 - JLabel throw NullPointerException for Windows 98 SE
Relates :  
JDK-4922476 - JFileChooser behaves incorrectly with "My Documents" on Windows 98
Description
os: win98
jdk: 1.5 b11 above but works fine with b10;
There was no effect on setting either Disable d3d flag(-Dsun.java2d.d3d=false) or Disable ddraw flag (-Dsun.java2d.noddraw=true);

run the following sample code:
import java.awt.*;
public class A {
	public static void main(String[] args) {
		Frame f = new Frame("Testing");
		f.setSize(400, 400);
		f.setVisible(true);
	}


you will get Exception in thread "main" java.lang.NullPointerException
	at java.awt.Window.init(Window.java:247)
	at java.awt.Window.<init>(Window.java:275)
	at java.awt.Frame.<init>(Frame.java:401)
	at A.main(A.java:8)


See attached platform infos for two win98 (one with multimon)
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16
14-06-2004
EVALUATION Sounds like an AWT bug. ###@###.### 2003-07-24 Name: rpR10076 Date: 08/05/2003 First of all, this bug cannot be reproduced with built sandbox, only with a JRE image (or promoted build), see below for the reasons why this is so. However, it is possible to substitute classes from the promoted build (placing them into -Xbootclasspath/p) with classes built with debug printouts. Also, it is possible to replace awt.dll in promoted build with awt.dll from the sandbox (to run the test, one would also need to get sun.awt.windows.WObjectPeer from the sandbox and place it into bootclasspath). Having done these things, I got my debug printouts into the promoted build, and learnt the following. The exception happens in Window.java in init(GraphicsConfiguration): ... /* offset the initial location with the original of the screen */ /* and any insets */ Rectangle screenBounds = graphicsConfig.getBounds(); Insets screenInsets = getToolkit().getScreenInsets(graphicsConfig); this line ==> int x = getX() + screenBounds.x + screenInsets.left; int y = getY() + screenBounds.y + screenInsets.top; setLocation(x, y); ... It appears so that in the mentioned line both screenBounds and screenInsets objects are null. Actual computation of screen bounds happens in _getMonitorInfo in awt_MMStub.cpp, actual computation of screen insets happens in Java_sun_awt_windows_WToolkit_getScreenInsets in awt_Toolkit.cpp. Both these functions fail because the call to ::SystemParametersInfo(SPI_GETWORKAREA,0,(void *) &rRW,0) returns false. Such call is present in both these functions. GetLastError() tells us error #120 (unsupported function). MSDN says ::SystemParametersInfo(SPI_GETWORKAREA, ....) is not supported on Windows 95/98/ME (I really don't know how it worked previously). However, unicows.dll included with build11 contains SystemParametersInfoW, which, it seems, works fine. So here is the explanation why this only happens with promoted build, but not with the sandbox: in the sandbox unicows.dll and java.exe are located in the same directory (bin/), while in promoted build they live in different directories (jre/bin/ and bin/ respectively). So in the sandbox SystemParametersInfo is taken from unicows.dll, while in the promoted build it is taken from the system (dll in the same directory as executable takes precedence over dlls in the path). To get rid of the issue in promoted build, one can copy unicows.dll from jre/bin/ to bin/ (where executables are). It looks like this problem was introduced by the unicode support work done by awt_im team. Reassigning to classes_awt_im for further investigation. ###@###.### Aug 05 2003 ====================================================================== Currently, UNICOWS.DLL is loaded by the call "LoadLibraryA("unicows.dll")" in UnicowsLoader.cpp, which just looks for the dll in the Windows' path. As Roman described above, this works OKay when the launcher and the dll is in the same directory, but does not work otherwise. UnicowsLoader.cpp needs to be modified to search the dll in the directories that are specified in the "sun.boot.library.path" system property. ###@###.### 2003-08-05 The problem only happens with j2sdk, not with j2re. Even with the j2sdk, it only happens with the bin/java.exe, not with jre/bin/java.exe. Furthermore, the user can work around this problem by copying jre/bin/unicows.dll to bin directory. I am committing this bug to Tiger, and at the same time, considering these situations especially the existence of the workaround, downgrading this to P2. ###@###.### 2003-08-05
05-08-2003