Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4268204

Windows Look&Feel doesn't look and feel like Windows



    • Subcomponent:
    • Resolved In Build:
    • CPU:
      generic, x86
    • OS:
      generic, windows_nt


      crollBarUI", packageName + "BSWindowsScrollBarUI"

        protected void initSystemColorDefaults(UIDefaults table) {

        protected void initComponentDefaults(UIDefaults table) {
          if (getClass().getClassLoader() != null) {
            Object[] defaults = {
              "ClassLoader", getClass().getClassLoader()
          if (true) {
            Color cNoSh = table.getColor("controlShadow");
            Color cDkSh = table.getColor("controlDkShadow");
            Color cNoHi = table.getColor("controlHighlight");
            Color cLtHi = table.getColor("controlLtHighlight");
            Border loweredBevelBorder = new BasicBorders.FieldBorder(cNoSh, cDkSh,cNoHi, cLtHi);
            Border raisedBevelBorder = new BasicBorders.FieldBorder(cNoHi, cLtHi,cNoSh, cDkSh);
            Border raisedCellBevelBorder = new BasicBorders.FieldBorder(cLtHi, cNoHi,cNoSh, cDkSh);
            Border pumBorder = new BorderUIResource.CompoundBorderUIResource(raisedBevelBorder, new EmptyBorder(1,1, 1, 1));
            Border buttonBorder = new BorderUIResource.CompoundBorderUIResource(table.getBorder("ToggleButton.border"), new EmptyBorder(1, 1, 1, 1));
            Object[] defaults = {
              "ScrollPane.border" , loweredBevelBorder,
              "Table.scrollPaneBorder", loweredBevelBorder,
              "TableHeader.cellBorder", raisedCellBevelBorder,
              "PopupMenu.border" , pumBorder,
              "Button.border" , buttonBorder

      package bs.swing.plaf.windows;

      import java.awt.Graphics;
      import java.awt.Rectangle;

      import javax.swing.JComponent;

      import javax.swing.plaf.ComponentUI;

      import javax.swing.plaf.basic.BasicScrollBarUI;

       * BSWindowsScrollBarUI.
       * <p>
       * @version 1.0
       * @author <withheld>
       * </p>
      public class BSWindowsScrollBarUI extends BasicScrollBarUI {

        public static ComponentUI createUI(JComponent c) {
          return new BSWindowsScrollBarUI();

        public BSWindowsScrollBarUI() {

        protected void paintTrack(Graphics g, JComponent c, Rectangle trackBounds) {
          g.fillRect(trackBounds.x, trackBounds.y, trackBounds.width,trackBounds.height);

          if (trackBounds.width > trackBounds.height) {
            for (int ix = trackBounds.x - trackBounds.height; ix < trackBounds.x +trackBounds.width; ix+=2) {
              g.drawLine(ix, trackBounds.y, ix + trackBounds.height, trackBounds.y +trackBounds.height);
          } else {
            for (int iy = trackBounds.y - trackBounds.width; iy < trackBounds.y +trackBounds.height; iy+=2) {
              g.drawLine(trackBounds.x, iy, trackBounds.x + trackBounds.width, iy +trackBounds.width);

          if(trackHighlight == DECREASE_HIGHLIGHT) {
          else if(trackHighlight == INCREASE_HIGHLIGHT) {

      (Review ID: 99529)

      ck.prasad@eng 2001-04-05Selected items:

      Problem description from Customer
      This is from JDK 1.4 beta 54 on Windows NT 4.0.
      java version "1.4.0-beta"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b54)
      Java HotSpot(TM) Client VM (build B54, mixed mode)

      From the above description Item 20 says :

      20. Selected items in lists and trees have a yellow focus outline
          in the Windows Look And Feel while Windows paints them with
          a grey/dark grey dashed/dotted outline.

      It complains that the focus indicator for JList and JTree in
      the Windows L&F is a yellow outline, rather than a dashed outline
      as it is for real Windows apps. The same is also true for JTable.

      Name: krC82822 Date: 05/31/2001

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

      The swing dialogs in JDK1.4 BETA still don't use the default
      windows font when Windows LNF is used. Since one of the goals
      JDK 1.4 is to be indistinguishable from native windows
      applications when using windows LNF, this should be fixed.
      (Review ID: 125074)

      Name: rlT66838 Date: 09/02/99

      At the moment, Microsoft Windows is the platform that most end users
      use to run desktop GUI applications. As I understand it, the concept
      behind Java is to make applications platform-independent; in order to
      be able to nevertheless create programs that have the (native) "look
      and feel" that most (Windows) users expect, Sun has created the
      "Windows Look And Feel".

      However, I have found (and others probably have as well) that there
      are still many problems in the current implementation of the Windows
      LAF that make it difficult to actually write applications that
      look and feel like real, native Windows ones (and I'm not even
      talking about speed/performance here). In order to help you
      improve the situation, I've taken the time to examine and
      describe some of the issues. A lot of them may appear to
      be minor ones but a) the sheer number turns them into one big
      problem and b) even little things that are somehow "wrong"
      can quickly make the user think that he or she is dealing
      with an "unprofessional" application. As there is no way to
      attach images to bug reports, I have not included screenshots
      that demonstrate the issues. However, in case you really need
      any, I am willing to create and send them by e-mail.

      Here are some of the problems that I have noticed
      (the list does not claim to be complete); they have
      intentionally been submitted as one bug report rather
      than many individual ones:


      01. By far the most obvious difference between the Swing Windows
          Look And Feel and the "real" Windows appearance is the font
          that is used almost everywhere where there is text to paint.
          This includes components such as labels, text fields, menu
          items, tabs, check boxes, radio buttons etc. I'm sure that
          you're aware of this difference and the fact that this hasn't
          been fixed yet suggests that there might be a technical
          problem. However, since Java2 seems to be able to use all
          installed fonts, why isn't the Windows system font being
          used? According to the display/appearance settings panel,
          it is "MS Sans Serif (Western)" size 8. Since this can be
          changed by the user, the Windows LAF should probably find
          a way to determine the current system font, at least once,
          at startup. In any case, Swing's current choice which
          seems to be FontUIResource("Dialog", Font.PLAIN, 12),
          makes it obvious to any user that they're not dealing
          with a real Windows application.


      02. By default, Swing seems to use white as the background colour
          for the interior of controls such as check boxes, radio buttons
          and combo boxes. However, in Windows, these are painted using
          the (configurable) "window" colour. If a user changes the
          "window" system colour from the default white to something
          else, Swing check boxes/radio buttons/combo boxes start looking
          different from their Windows counterparts.
      03. For scrollbar "channels", Windows uses a pattern of
          alternating grey and white pixels. Swing, however, uses
          a solid grey colour. For users who have changed the "window"
          system colour to grey, this can become a problem because in
          case the scroll pane contains a component that uses "window"
          as the background colour too (such as JTree), there will be
          no visual separation between the contained component and
          the scrollbar channel. This is both ugly and irritating.

      Resizable windows:
      04. In Swing, Resizable windows such as the JFileChooser or
          (resizable) JInternalFrames do not have the "draggable"
          texture in the lower right corners that the original
          Windows ones have.

      05. The default button size in Windows is 75x23 pixels.
          Swing ignores this; for example, the "OK" button in a
          JOptionPane is 39x27 pixels big, and in the JFileChooser
          dialogue, both the "OK" and the "Cancel" button are
          73x27 pixels big.
      06. Toolbar buttons (icon buttons) should not have
          a painted focus outline.

      Text components:
      07. In Windows, text components that are not editable have
          a blinking caret just as editable ones (although you
          cannot type anything). In Swing, there is no caret.
          This makes navigation and text selection very difficult.
      08. In a text field, there should be a margin of one pixel
          between the border and the caret if it's at the first
          position, just like in Windows. Otherwise, it's hard
          to separate the caret from the border.
      09. The marked selection in a text field should not cover the
          complete text field interior around the selected text as
          it does in Swing. Instead, there should be a margin of
          Insets(1, 1, 2, 1) as in Windows.

      Check boxes:
      10. The disabled look of check boxes is different
          from Windows (grey/white outline vs. black/white outline).

      11. Swing menu bars are two pixels higher than Windows menu bars.
      12. The colour of JMenu components does not change to grey when
          the window they're in is deactivated.
      13. JMenus don't have the Windows 98 rollover effect.
      14. Swing paints the white and grey outline of popup menus using
          a width of two pixels. Windows only uses one pixel.
      15. The width of the space to the left/right of the widest menu
          item in the menu is not the same as in Windows. Moreover,
          Swing menu items are four pixels higher than the real ones.
          There are also differences concerning the space between
          a) border/[checkbox|bullet]/name and b) name/mnemonic/border.
      16. The bullet (o) and arrow (>) icons/drawings aren't the same
          as in Windows either although the average user probably
          won't notice.
      17. Popup menus should disappear/be closed when the window
          they're in is deactivated.

      Tabbed panes:
      18. Swing tabs in tabbed panes are two pixels higher than Windows tabs.
          Moreover, the active tab exceeds the "base line" at the bottom
          by one pixel.

      Split panes:
      19. The arrows on a "one touch expandable" divider are too big.

      Selected items:
      20. Selected items in lists and trees have a yellow focus outline
          in the Windows Look And Feel while Windows paints them with
          a grey/dark grey dashed/dotted outline.

      21. Swing Table headers are four pixels higher than Windows
          table headers. There is also an inaccuracy concerning
          the outline colours (grey vs. black).

      22. The disabled look of the JSlider knob is different
          from Windows (grey vs. white/grey).

      Scroll bars:
      23. The placement of the arrows on Swing scroll bars is
          one pixel different from the way it's done in Windows.
          This might seem like a rather minor issue but it is
          quite noticeable.

      Internal frames:
      24. The title text of internal frames is placed two pixels
          lower than the original Windows title. Also, there is
          no colour transition in the title bar like the one
          Windows 98 offers... :)
      25. The "minimize" icon is not exactly the same as in Windows.

      Folder icons:
      26. The folder icons used in JTree and JFileChooser look
          different from the ones Windows (98) uses (in Explorer,
          for example).

      File chooser:
      27. The Swing file chooser is too big. Its size is 508x327 pixels
          which is considerably bigger than the original Windows size
          which is just 428x266 pixels.
      28. The size of the Swing toolbar buttons (25x25) is different
          from the original size (23x22).
      29. All files have the same icon. I assume that this is a design
          decision rather than a bug because access to the icons that
          are registered with each file type is a system-dependent
          feature. If it's intentional that only the default icon
          (the piece of paper with a Windows logo) is used, it should
          at least have the right colour: white - not transparent.
          I assume that it is another design decision to make the
          icon transparent to simplify painting of the "selected" status.
          However, if the "window" system colour is not white, the
          file icon is not white anymore either (which it should be).
      30. Selected file items should only have the outline painted
          around the file name (which is what Windows does), not the
          file name AND the icon. There still needs to be some kind
          of visual transformation of the icon, though (using the
          "selected" colour).
      31. In Windows, the "Open" and "Cancel" buttons do not have
          tooltips associated with them.
      32. There are still a lot of other issues that make the
          JFileChooser look and feel different from the original
          AWT FileDialog. Some are related to OS specific features
          (such as the -missing- help button), some are related to
          changes to the Windows GUI (three new toolbar icons were
          introduced with the Internet Explorer 5 upgrade) and
          others are related to general JFileChooser incapabilities.
          These include: a "list view" button that's always disabled,
          a missing "table view" (Name, Size, Type, Modified, Attributes)
          and missing multi-file selection.

      Colour chooser:
      33. This component doesn't even attempt to adapt to the
          Windows colour chooser look/feel. Whether there is
          a real need to, is debatable, of course.

      34. Swing tooltips are six pixels higher than Windows tooltips.

      New widgets:
      35. ...and finally, there are some new widgets (or new
          variations of existing ones) that Microsoft has introduced
          during the last few years. A look at Office 2000, for
          example, reveals that there are some that Swing doesn't
          offer (which makes it a Swing problem rather than a
          specific Windows LAF issue; and the productivity gain
          of some of MS's new GUI stuff is questionable anyway).

      I realize that it's hard to emulate a native look and feel
      100% accurately, especially if some of it keeps changing
      (Win95->Win98) and if many things rely on system features
      that a pure Java package doesn't have access to. Always
      using the Java Look And Feel instead might be a better
      solution - but as Sun has decided to provide "native"
      look and feels too, the Windows LAF has become part
      of the Windows release of Java2; and since it's there,
      it deserves to be done "right".

      Best regards,
      (Review ID: 94575)

      Name: krT82822 Date: 10/07/99

      If I set the font for NT, my application's JMenuBar still shows
      a san-serif type font, even if I restart it. This goes for text in dialogs etc. The font color isn't used either, seems like
      all of this is hardcoded?


      (see also 4129288)
      (Review ID: 94073)

      Name: krT82822 Date: 12/19/99

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

        To see the bugs you have to first change the default colors using
      your Windows "Display Properties" dialog. Choose the scheme 'Lilac'.

      The first bug is in menus. First go to any native Windows application
      and click on a menu. When the menu drops down, observe the colors
      of the edge of the menu and also the thickness of the edge. The
      edge is very thin (1 pixel?) and the color is light blue. Now start
      SwingSet and click on the File menu. The edge of the menu pane is
      too think (3 pixels?) and is white in color, not light blue. (In fact
      in many places, for example Group Box, the 3D highlight color is white
      when it should be light blue.)

      Another bug is the colors used for disabled labels. Go to SwingSet
      and click on the File menu. The colors of the grayed out menu items
      are all wrong.

      These bugs make Java based applications the "odd man out" on Windows.
      (Review ID: 99200)

      Name: krT82822 Date: 01/24/2000

      java version "1.2.2"
      Classic VM (build JDK-1.2.2-001, native threads, symcjit)

      None needed create any bevel border an set the look and feel to windows.
      Swing always makes the highlight White. If you set your windows colors
      to dark gray then the highlight should be light gray. The buttons work
      fine. But, Menu drop downs/Popups/JscrollPane/BevelBorders stay white.

      I bet if check what the button's do verse these other objects you will
      find an overlook in color setting.

      (Review ID: 100302)

      Name: krT82822 Date: 01/24/2000

      java version "1.3.0"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-I)
      Java HotSpot(TM) Client VM (build 1.3-I, mixed mode)

      Windows look and feel has unacceptable look defects
      notably the borders of various JComponent subclasses
      and the background pattern of JScrollBar.

      Below I provide the source code of my custom Windows LAF
      (based on Sun's Windows LAF) fixing the most important
      look defects. The fixes can be easily migrated into Sun's
      Windows LAF and have been tested thorougly.

      (I do not provide a single bug report for each look defect
      as there are too many).

      package bs.swing.plaf.windows;

      import java.awt.Color;

      import javax.swing.LookAndFeel;
      import javax.swing.UIDefaults;

      import javax.swing.border.Border;
      import javax.swing.border.EmptyBorder;

      import javax.swing.plaf.BorderUIResource;

      import javax.swing.plaf.basic.BasicBorders;
      import javax.swing.plaf.basic.BasicLookAndFeel;

       * Implements the Windows 95 Look and Feel.
       * Is build on top of Sun's implementation of the Windows 95 Look And Feel
       * (com.sun.java.swing.plaf.windows.WindowsLookAndFeel).
       * <p>
       * Fixes cosmetic defects (ScrollBarUI and Borders).
       * <p>
       * Inheritance is achieved by peering instead of by subclassing.
       * (UI classes not implemented specifically for My Windows fixes will
       * default to those implemented in Sun's Windows).
       * <p>
       * @version 1.0
       * @author Bruno Stuessi
       * </p>
      public class BSWindowsLookAndFeel extends BasicLookAndFeel {

        private LookAndFeel windowsLAF;

        public BSWindowsLookAndFeel() {
          try {
            String s = "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
            windowsLAF = (LookAndFeel) Class.forName(s).newInstance();
          } catch (Exception e) {
            throw new RuntimeException(e.toString());

        public String getName() {
          return "Windows";

        public String getDescription() {
          return "The Microsoft Windows Look and Feel";

        public String getID() {
          return "Windows";

        public boolean isNativeLookAndFeel() {
          return windowsLAF.isNativeLookAndFeel();

        public boolean isSupportedLookAndFeel() {
          return windowsLAF.isSupportedLookAndFeel();

        public UIDefaults getDefaults() {
          UIDefaults table = windowsLAF.getDefaults();
          return table;

        protected void initClassDefaults(UIDefaults table) {
          if (true) {
            String packageName = "bs.swing.plaf.windows.";
            Object[] uiDefaults = {


          Issue Links



              mdavidsosunw Mark Davidson (Inactive)
              rlewis Roger Lewis (Inactive)
              0 Vote for this issue
              0 Start watching this issue