If you’re seeing this popup when you launch Eclipse itself, or the Eclipse installer on your macOS, this post is for you. First, there’s a bit more details on the Eclipse and JDK bug trackers. To fix this, you will need to uninstall the problematic JDK version and install the latest one on your macOS machine:

1. Run the /usr/libexec/java_home -V command to list all installed JVM versions.
2. Identify the problematic version of the JVM – in my case it was “14, x86_64: "Java SE 14" /Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home“.
3. Delete that version – with something like “sudo rm -rf /Library/Java/JavaVirtualMachines/jdk-14.jdk/“
4. Install the latest matching JVM / JDK – at the time of this writing it is 14.0.1
5. Verify that it appears in the list of installed JVMs with /usr/libexec/java_home -V
6. If needed, point the Eclipse.app/Contents/Eclipse/eclipse.ini to the location of the newly installed JVM (-vm parameter)

It gives me great pleasure to announce the third major release of Radiance. Let’s get to what’s been fixed, and what’s been added. First, I’m going to use emojis to mark different parts of it like this:

Substance

• 😻 New skins – Nebula Amethyst, Night Shade and Graphite Sunset
• 🤷‍♀️ Fix for disappearing internal frame title pane buttons
• 🤷‍♀️ Fix for crash during initialization
• 🤷‍♀️ Fix for OutOfMemoryError on sliders with large model ranges
• 🤷‍♀️ Fix for slider tracks under dark skins
• 💔 Fix for incorrect tracking of state-based alpha values in color scheme bundles
• 🤷‍♀️ Fix for drop shadows under some skins
• 🤷‍♀️ Fix for contrast ratio of highlighted content under Sahara skin
• 🤷‍♀️ Fix for antialiased rendering of pasted text content

Flamingo

• 😻 Keyboard traversal of ribbon content
• 😻 Keyboard traversal of command button popups
• 🤷‍♀️ Command button popups can now be dismissed without activating any action

Trident

• 😻 DSL for Trident
• 🤷‍♀️ Fix for combining looping timelines with .fromCurrent()

Photon

• 😻 Extended transcoding support for <image>, <marker>, <pattern> and <text> elements

The first Radiance release focused on bringing all the different Swing open-source projects that I’ve been working on since 2005 under one roof. The second Radiance release was about making them work much better together. And this one (code-named Coral) is about covering major functionality gaps that were missing up until now.

There’s still a long road ahead to continue exploring the never-ending depths of what it takes to write elegant and high-performing desktop applications in Swing. If you’re in the business of writing just such apps, I’d love for you to take this third Radiance release for a spin. Click here to get the instructions on how to add Radiance to your Gradle / Maven / Ivy / Leiningen / Bazel builds. And don’t forget that all of the modules require Java 9 to build and run.

See the recent follow-up on the changes to the font family name on Catalina and changes needed at the JRE level to support proper kerning.

Starting from OS X El Capitan (10.11), there’s a new default system font in town – San Francisco. And it came with a very big underlying change, as detailed by Craig Hockenberry:

Apple has started abstracting the idea of a system font: it doesn’t have a publicly exposed name. They’ve also stated that any private names are subject to change. These private names all begin with a period: the Ultralight face for San Francisco is named “.SFNSDisplay-Ultralight”. To determine this name, you need to dig around in the font instances returned by NSFont or UIFont; it’s not easy by design.

The motivation for this abstraction is so the operating system can make better choices on which face to use at a given weight. Apple is also working on font features, such as selectable “6” and “9” glyphs or non-monospaced numbers. It’s my guess that they’d like to bring these features to the web, as well.

Even though the underlying .otf files are still in /System/Library/Fonts, San Francisco is no longer exposed via the regular APIs that web and desktop developers have grown used to. Specifically for Swing developers (of which there may not be many, so at some point it will kind of take care of itself), passing “San Francisco” to the Font constructor ends up using the previous default – Lucida Grande.

JavaFX is already doing the right thing, using San Francisco as the default UI font on El Capitan and Sierra. Swing’s legacy is to have each look-and-feel decide which font to use, and I was expecting the “System” look-and-feel which maps to Aqua to be using the right font family on the latest OS releases. That is not the case as I’m writing this entry, and Swing apps on both El Capitan and Sierra are still using Lucida Grande on both 8u112 and 9-ea.

Last week Phil Race pointed me to this issue that tracked syncing up the internal implementation details of glyph mapping between JavaFX and AWT. That issue has been fixed in early access builds of JDK 9, and is slated to be available in JDK 8 u152 scheduled for October 2017. At the present moment there is no public API to get either a name or a font instance itself that will be mapped to Lucida Grande on 10.10 and earlier, and to San Francisco on 10.11 and 10.12. The only available solution is quite brittle as it depends on the internal naming conventions exposed by the underlying OS:

• .Helvetica Neue DeskInterface on El Capitan (10.11)
• .SF NS Text on Sierra (10.12)

Note that you need a leading dot in both cases, and that this only works on early access builds of JDK 9 at the moment:

In this screenshot the second button is using new Font(“.SF NS Text”, Font.PLAIN, 24) while the rest are rendered with Lucida Grande. The most noticeable differences are in the curvy strokes of “e”, “g”, “5” and “9”, as well as the straight leg of “a”.

Ideally, there’d be an officially supported way to use the right font on OS X / macOS, either in a form on some kind of a static Font API or a synthetic font family that maps to the underlying system font on all supported platforms. Phil has filed a bug to track the progress on that front.

The latest weekly drop of JDK 7 (b57) has finally exposed the functionality of translucent and shaped windows as publicly supported APIs on the java.awt.Window class. Bug 6802853 has tracked the progress of exposing these APIs previously available in 6u10+ in the internal com.sun.awt.AWTUtilities class, and it’s time to update the examples to use the new public APIs.

To recap, here are the previous entries that used the AWTUtilities class:

• Translucent and shaped windows in core Java talked about the AWTUtilities class in 6u10 and support for modern top-level windows effects.
• Soft clipping and per-pixel translucency for Swing windows explored the translucent effects on top-level windows.
• More tricks with translucent Swing windows followed up with the different effects achievable with the new translucent window support.

All the source files referenced in these examples have been updated to use the new Window APIs, and here is a brief overview of the relevant API signatures:

• AWTUtilities.isTranslucencySupported(Translucency) is now GraphicsDevice.isWindowTranslucencySupported(WindowTranslucency).
• AWTUtilities.isTranslucencyCapable(GraphicsConfiguration) is now GraphicsConfiguration.isTranslucencyCapable().
• AWTUtilities.setWindowShape(Window, Shape) is now Window.setShape(Shape).
• AWTUtilities.setWindowOpacity(Window, float) is now Window.setOpacity(float).
• AWTUtilities.setWindowOpaque(boolean) is superceded by Window.setBackground(Color). Passing the new Color(0, 0, 0, 0) achieves the old effect of installing per-pixel translucency.

You can see the Javadocs of the new Window methods in the corresponding Mercurial diff, or in the source archive bundled with the b57 installer.

Note that the com.sun.awt.AWTUtilities class is still there, and calling its API methods still produces the correct visuals. A quick look at the implementation reveals that the AWTUtilities methods do not (yet) go directly to the new Window methods, perhaps converging deeper in the AWT internals.