FULL PRODUCT VERSION :
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

EXTRA RELEVANT SYSTEM CONFIGURATION :
HiDPI displays

A DESCRIPTION OF THE PROBLEM :
HiDPI support on OS X and Windows is not implemented in the same way, violating Write Once, Run Anywhere.

While on OS X the developer can take advantage of the points vs pixels abstraction (virtual pixels vs physical pixels, also see https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html), on Windows a pixel is always equal to a point, leading to all kinds of problems.

For example, the standard row height of a JTable is 16 pixels (also see https://bugs.openjdk.java.net/browse/JDK-8029087) . On OS X, because 16 pixels is interpreted as 16 points (to be rendered as either 16 or 32 pixels, depending on resolution), the row is appropriately sized no matter what the display resolution is.
On Windows on the other hand, it is always 16 pixels, regardless what the display resolution is - leading to tiny rows on HiDPI displays.
At the same time, on Windows, standard fonts are bigger for higher resolution displays. On OS X, fonts have the same point size, but are rendered in greater detail. This is a fundamental difference in behavior and makes it unnecessarily hard to write portable applications.

Another issue are images... again, the Windows implementation offers nothing (as far as I currently know), on OS X, there is proper HiDPI support using abstractions like the @2x image name notation.

To ensure portability between Windows HiRes, Windows LoRes, OS X HiRes and OS X LoRes (or any other OSes for that matter), a common solutions needs to be found.


Otherwise applications simply aren't portable.


It seems to me that the OS X approach is more mature than the (currently) inconsistent Windows approach. It features a higher level of abstraction and removes some of the burden of developing for hi AND lo res displays.

The only thing that's currently missing from the OS X approach, is an easy way to find out the scale factor for a Graphics context or a display via a public API.

REGRESSION.  Last worked in version 8u5

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Write a hi res app for os x featuring a rich UI and run it on windows, both with hi and lo res displays.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
On windows the app should look just as good as on osx, regardless of the display resolution.
ACTUAL -
On windows with a hi resolution display things look terrible, because of a fundamentally different hi res approach taken in the Java implementation.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
You can attempt to write lots of platform dependent workarounds... :-(