JDK-8177960 : Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u6,8,9,10,11,12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2016-11-04
  • Updated: 2019-08-08
  • Resolved: 2019-03-22
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.
JDK 13
13 b15Fixed
Related Reports
CSR :  
Sub Tasks
JDK-8218779 :  
This is a request to deprecate the Swing Motif Look and Feel, and document it as unsupported on macOS platform in jdk13.

The Motif L&F has long been part of the Swing implementation shipped with the JDK, although unlike L&Fs such as Metal and Nimbus it is not exposed in Java APIs and not part of the Java SE specification. Because it is an internal class, not exported from the java.desktop module, applications cannot instantiate it directly in JDK 9 and later, but is still accessible via command line option or passing the class name to the method "UIManager.setLookAndFeel(String className)".

This look and feel was implemented as the System look and feel for the Solaris platform at time when the CDE/Motif environment was used the principal supported desktop environment. Since then it has been largely superseded by the GTK L&F, both on Solaris, and on Linux versions.

But it was placed in shared code and provided and supported on all platforms including Windows and later MacOS. Applications can enumerate the installed L&Fs via standard API, and retrieve its class name and instantiate it. It has also been documented in tutorials, guides etc.

However its use as a cross-platform L&F is very limited applications are much more likely to use one of the true cross-platform look and feels which are exposed in Java API, ie

    Ocean - reworked version of Metal L&F in jdk5 https://docs.oracle.com/javase/1.5.0/docs/guide/swing/1.5/index.html#swingMajor
    Nimbus - was added as a Public API in jdk7 https://openjdk.java.net/projects/jdk7/features/#f244

Since it is superseded as a system L&F and has limited use and additionally as a L&F is very dated visually, we would like to discourage further use.

Additionally its availability on MacOS is the origin of some JCK issue, since AWT components on Mac are implemented using Swing.

As of jdk13 in the release notes we would like to document this L&F as unsupported on macOS, and deprecate it in the source code

In some future release we may deprecate it for removal and subsequently remove it completely, or we may remove it from the shared code to stop distributing it on Windows and macOS. These are mentioned here to give the most possible notice of such possible additional changes.
This is P1 TCK-RED issue for JDK 12 GA release. The fix is in progress.

I agree. I've read this bug and I think the submitter made a claim that they cannot possibly have verified. They wrote : > When we press the "Start" button,the frame that is shown has a scrollpane that > uses an "Always" scrollbar display policy,not the "AS_NEEDED" scrollbar display > policy with Motif LAF. That is a very unclear sentence. I believe it should read : > When we use the Motif L&F, and press the "Start" button, > the frame that is shown has a scrollpane that uses an "Always" > scrollbar display policy, not the "AS_NEEDED" scrollbar display policy. Now the Motif L&F has determined it needs a scroll bar because its content does not fit. It only needs to determine ONE pixel doesn't fit in order to make such a decision. That may look like "Always" to the submitter, but actually it is "as needed". So what I think we have here is "not a bug, user error".

Standalone minimized code sample ScrollPaneTest.java attached together with screenshots taken with default and with Motif L&F on MacOS.

" Like the Java (Metal) L&F, the Motif L&F will run on any platform." https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html

Test build:openjdk11 b22(64bit)/JCK11 b11 Test platform: Mac10.13 x64(Mac mini(Mid 2010)/Processor:2.4 GHz Intel Core 2 Duo/Memory: 4 GB 1067 MHz DDR3) Options:-Dswing.defaultlaf=com.sun.java.swing.plaf.motif.MotifLookAndFeel The case failed as the same issue. api/java_awt/interactive/SPaneTests.html#SPaneTests

This is a tricky bug. The test is for an AWT components and should not be affected by the look&feel from swing. But on macOS an AWT components are implemented via swing, this is why the bug is reproduced on mac only. I'll take a look to the root cause of the bug, but this is not a supported configuration(awt component + l&f).

Not possible to be sure without running through the test code + the Swing code, but it looks like if you took away the scroll bars the content would JUST fit. But it only has to be off in a calculation by one pixel somewhere .. either in the test code or the Swing code .. perhaps even less than one pixel if there is then rounding somewhere .. in terms of calculating the content size versus the available size to display those scroll bars. The Swing logic is surely the same on all platforms so something on the Mac may be throwing this off.

That's right Victor. If failure is not in the default setup, we should not consider the issue as TCK-Red.

isn't tck-red as failure is not on default LnF

Issue is re-producible.

// test SPaneTest0001: Verify the behavior of a scrollpane that // uses "as needed" scrollbar display policy public Status SPaneTest0001() { String[] instr = { "Pressing the \"Start\" button brings up a frame " + "that has a scrollpane that uses an 'AS_NEEDED'", "scrollbar display policy. The scrollpane contains " + "10 rows by 10 columns of buttons labeled 0-99.", "If support for window resizing is present, please " + "resize the display frame and verify that the", "scrollpane displays the vertical and/or horizontal " + "scrollbars only if its contents need to be scrolled", "to be viewable. If support for window resizing is not " + "present, please verify that it is not possible", "to resize the display frame.", }; for (int i = 0; i < instr.length; i++) { addInfo(instr[i]); } String qn = "Does the scrollpane behave as specified above?"; String passMsg = "Scrollpane behaves as expected."; String failMsg = "Scrollpane does NOT behave as expected."; // Add test panel to frame addTestPanel(new spTester("SCROLLBARS_AS_NEEDED", ScrollPane.SCROLLBARS_AS_NEEDED)); // Set question that is presented to user setQuestion(qn); // Set messages that get printed upon pass and fail setStatusMessages(passMsg, failMsg); // Set title of test frame setFrameTitle("Scrollpane Test - SPaneTest0001"); // Set size of test frame setFrameSize(590, 350); // Set test timeout setTimeout(180); return Status.passed(""); } class spTester extends Panel { spTester(String testName, int sbPolicy) { ....... // Create scrollpane ScrollPane scrollpane = new ScrollPane(sbPolicy); scrollpane.setBackground(new Color(255, 122, 235)); ...... } } It looks like constructor setting with java.awt.ScrollPane(ScrollPane.SCROLLBARS_AS_NEEDED), is not working as expected with MotifLookAndFeel. As we do have support of MotifLookAndFeel on MacOS + Panel resizing also available, it should show the scroll bar only when needed; which means only after resizing.