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]>> 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.
