>> 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.
When an API is marked as deprecated, we expect it to go away in a
future _version_, but not in a future _update_. Does this mean we
can expect any deprecated API to disappear in Java 6 Update 5? We
would also expect some type of migration API while the old API is
deprecated and still available. The new API is com.apple.laf which
was not available until Update 4. How could we have migrated to it?
Don't. The Aqua Look and Feel classes have never been API. They should
never be called directly by any client code. Assume the packages and
names will pirouette about wildly from release to release. The classes
are merely public as an implementation detail of how Swing uses
reflection to instantiate UI delegates from unprivileged code.
>> In Update 4, we have removed the old implementations (that cannot
function beyond Leopard) in Java SE 6, and replaced them with stub
implementations.
This approach would have worked well for us and as expected, except
that you didn't provide _complete_ stub implementations. The
incompleteness is what caused the problem.
This was an oversight in our initial compatibility testing.
>> 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.
This was reported to us weeks ago by developers using the Developer
Preview, who told us they reported it to Apple ... maybe they really
didn't report it.
A bug ID would be helpful to track down what happened here.
We have found a workaround to the problem by using reflection to
know which API to use, so we are good for now.
thanks
-John
Mike Swingler wrote:
On Jun 15, 2009, at 6:57 PM, John LH wrote:
Hi,
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
