<Swing Dev> customizing L&Fs in JDK9

[Alan Snyder]

Bundled apps run without a Security Manager, at least they do for me. Users have higher expectations for bundled apps.

The customizations are delivered via a JAR file (and perhaps a JNI library). No need to build a custom JRE.

These are some of the APIs that I know have been used by L&F customizations:

      -> sun.font.CFontManager                              JDK internal API (rt.jar)
      -> sun.font.FontManager                               JDK internal API (rt.jar)
      -> sun.font.FontManagerFactory                        JDK internal API (rt.jar)
      -> com.apple.laf.AquaHighlighter                      JDK internal API (rt.jar)
      -> com.apple.laf.AquaHighlighter$AquaHighlightPainter JDK internal API (rt.jar)
      -> sun.awt.AppContext                                 JDK internal API (rt.jar)
      -> sun.swing.UIAction                                 JDK internal API (rt.jar)
      -> sun.awt.SunToolkit                                 JDK internal API (rt.jar)
      -> com.apple.laf.AquaTableHeaderUI                    JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants                           JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants$Orientation               JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants$State                     JDK internal API (rt.jar)
      -> apple.laf.JRSUIConstants$Size                      JDK internal API (rt.jar)
      -> com.apple.laf.AquaSliderUI                         JDK internal API (rt.jar)
      -> com.apple.laf.AquaTreeUI                           JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonUI                         JDK internal API (rt.jar)
      -> com.apple.laf.AquaComboBoxUI                       JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonBorder                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonBorder$Dynamic             JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize                  JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize$SizeDescriptor   JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize$SizeVariant      JDK internal API (rt.jar)
      -> com.apple.laf.AquaBorder                           JDK internal API (rt.jar)
      -> com.apple.laf.AquaListUI                           JDK internal API (rt.jar)
      -> com.apple.laf.AquaPanelUI                          JDK internal API (rt.jar)
      -> com.apple.laf.AquaSplitPaneDividerUI               JDK internal API (rt.jar)
      -> com.apple.laf.AquaSplitPaneUI                      JDK internal API (rt.jar)
      -> com.apple.laf.AquaTabbedPaneUI                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaFocusHandler                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaTableUI                          JDK internal API (rt.jar)
      -> com.apple.laf.AquaFocusHandler                     JDK internal API (rt.jar)
      -> com.apple.laf.AquaButtonToggleUI                   JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize                  JDK internal API (rt.jar)
      -> com.apple.laf.AquaUtilControlSize$PropertySizeListener JDK internal API (rt.jar)
      -> com.sun.java.swing.Painter                         JDK internal API (rt.jar)

Probably more would be except that they are package private.

A list of all the things that need fixing in the Aqua L&F would be very long, and not worth creating if there is no support for such a large effort.

As just one example, consider that Yosemite has been out for quite a while now and Java is still using Mavericks rendering on Yosemite.

  Alan


> On May 15, 2015, at 12:49 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> My understanding is that the Aqua L&F classes are already inaccessible
> if there's a SecurityManager so its not a completely new thing.
> Whilst there may be ways around the JDK9 restrictions, what internal Aqua APIs do you need
> to customise ? And how do you deliver those customisations ?
> 
> We are already looking at finding ways to expose some com.apple APIs in a supported way as Java APIs.
> Perhaps something in Aqua can be fixed, or perhaps exposed - perhaps being a key word.
> 
> Note that bundling a JRE is not the same thing as building your own & bundling.
> I expect most applications will want to work with a pre-built Oracle JDK which will hide internal APIs.
> 
> Perhaps
> 
> 
> 
> On 5/15/2015 12:09 PM, Alan Snyder wrote:
>> If my understanding is correct, the classes for several JDK specific L&Fs (Aqua, GTK, and Windows) will become inaccessible to applications in JDK9. Is this true?
>> 
>> I am concerned about the impact of this change for the Aqua look and feel, which historically has lagged behind the platform UI and continues to do so (although progress has been made) and for which both small and large customizations have been written. Blocking access to the Aqua look and feel classes will make such customizations much more difficult, possibly even impossible if native code is involved.
>> 
>> While I understand the desire to protect applications from depending upon JDK specific code, the benefit of this restriction seems small. After all, how many JDK implementations are there for desktop applications on OS X? The current OS X application architecture bundles a JRE in each application, so JDK changes will not break installed applications.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150515/48198b01/attachment.html>