Sorry for any confusion, but there are no split packages. A new L&F is created with subclasses/uses class from the Aqua L&F.
Alan > On May 15, 2015, at 2:22 PM, Phil Race <[email protected]> wrote: > > Hi, > > The sun.* classes are definitely considered to be out of bounds on all > platforms. > For the apple "laf" ones that is a very long list that is being customised. > It seems a lot of work to do that outside the JDK and I echo Sergey's comments > that if these are changes which would benefit other users they are best > delivered back into OpenJDK > And the technique for delivering the changes in a jar on the class path will > not > work with the modular JDK even if we made all of these classes public and > exported .. jigsaw does not allow such split packages. > > -phil. > > On 5/15/2015 1:10 PM, Alan Snyder wrote: >> 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] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[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.
