JDK-8024281 : [macos] stop relying on Apple's JavaVM Frameworks
  • Type: Bug
  • Component: client-libs
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • Submitted: 2013-09-04
  • Updated: 2021-07-13
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.
Sub Tasks
JDK-7131356 :  
JDK-8042959 :  
JDK-8218686 :  
While working on JDK-7131356 it came to my attention that we use JavaRuntimeSupport.framework (JRS), which is a special framework provided to us (and only us) by Apple, which wraps certain SPI into API, used by Apple in their JDK implementation.

The problem is that we now own the JDK, and got forced to rely on JRS, which does not seem like a good long term solution.

We should understand where we use JRS and deprecate its usage internally and start re-implementing those with our implementation.

This should be an umbrella bug as there are probably several components that use JSR (ie. Glass, Plugin, AWT, Swing ?)

Apple have reaffirmed their commitment to support the JRS framework indefinitely. So reducing reliance is a good thing, but we should not have to solve the tricky problem above regarding native rendering.

The Swing on macOS uses Aqua L&F which is implemented on top of the JavaRuntimeSupport. It uses this framework to draw the native components to some raster, these functionality is not provided by the public API. Probably it can be a reimplemented somehow but this will be a huge task.

I'm starting to create subtasks for the non-desktop items.

Removal of JavaNativeFoundation code could be done as a single task, since most of it involves writing boilerplate JNI code. Removing JavaRuntimeSupport, however, will be a larger task and should be broken up into smaller tasks that focus on specific parts of JRS.

As alluded to in JDK-8022282, there is a second framework under the JavaVM framework besides JavaRuntimeSupport, it's JavaNativeFoundation. If we also need to move away from JNF, that's another big chunk of code to go through - looks like the majority of jdk/src/macosx/native/ pulls in JavaNativeFoundation.h.

An issue has already been filed for deployment. There is a non-trivial amount code in JDK that relies on JRS at the moment so such a change won't be easy, but I don't think it will be impossible.