The new Java 6 Update 4 seems to have changed the implementation of
apple.laf.AquaImageFactory and apple.laf.ScreenMenuBar.
The class apple.laf.AquaImageFactory implementation was converted to
an empty implementation that extends com.apple.laf.AquaImageFactory,
but the new com.apple.laf.AquaImageFactory doesn't have the
method .drawFrameTitleBackground().
The class apple.laf.ScreenMenuBar was made empty, but it doesn't
extend the new com.apple.laf.ScreenMenuBar, so the class doesn't do
anything.
These changes were all intentional to wean external developers off of
using internal and unsustainable implementation details of the Aqua
Look and Feel. All the classes were marked @deprecated in Leopard in
both J2SE 5.0 and Java SE 6. We have called out that usage of the Aqua
Look and Feel classes is unsupported and will break in future updates
in the release notes for prior updates. In Update 4, we have removed
the old implementations (that cannot function beyond Leopard) in Java
SE 6, and replaced them with stub implementations.
It is not appropriate for a 3rd party to rely on internal and
undocumented implementation details of the Aqua Look and Feel. JIDE
needs to either use documented colors, borders, and UI delegates
installed in the UIManager, or guard their hacks with reflection and
fallback to their own custom drawing if/when they break.
This new Java Update could essentially break many Java applications
on the Mac, as it has done for ours. Any Java application that uses
apple.laf.AquaImageFactory.drawFrameTitleBackground() or the class
apple.laf.ScreenMenuBar will potentially fail to launch. Many of
our users have already started reporting this problem, including
Apple employees.
I'm sorry to hear that this has broken your app. Ideally, we'd like to
catch these issues early with our developer previews, and find a way
to at least let the app launch, even if it won't draw some elements.
I am not sure what is the best course of action at this time. I've
reported the bug ... Bug ID# 6975000
Thanks for the bug - we may put a do-nothing stub implementation in
place in a future update to prevent launching problems for old
applications that can't/won't update.
I apologize for the difficulty, but the old routines will break at
some point. By taking intentional steps in the non-default version of
Java, we are hoping to provide a path forward for most developers who
might not even realize they are indirectly relying on unstable code.
Mike Swingler
Java Runtime Engineer
Apple Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
