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 <[email protected]> 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.
>>
>
