References to Apple JDK internal classes from other projects

[Mike Swingler]

On Jan 19, 2012, at 9:12 AM, Artem Ananiev wrote:

> Hi, Mike et al.,
> 
> I'm often contacted from other teams and projects about JDK7 on Mac. At the current moment, at least two requests are about Apple classes that are missed in Oracle JDK:
> 
> Java3D: they reference apple.awt.CGraphicsDevice
> SWT: they use apple.awt.CEmbeddedFrame to embed Swing content

Java3D and SWT both are cases of embedding, which is by necessity a native operation to get correct when hosted in a cross-process context (like applets).

In both of these cases, they should really use the CoreAnimation Layer based JAWT API which was introduced in Java SE 6, and attach or host the appropriate CALayer. SWT will have to do a little more work to marshal events into/out-of the AWT event model (depending on which way the embedding is going), but they actually have it pretty easy when it comes to hosting or creating the CALayer with their content (since they can make their NSView's layer backed).

For the case of Java 3D, they should investigate how the JOGL and LWJGL projects have adopted CALayer-based JAWT already. The code is straightforward and works today in all modern browsers using Plugin2 on Java SE 6.

> I would expect many other Mac OS X applications written in Java to rely on classes like these. Quick search for "import apple.awt" in Google shows at least 2 projects in top 10 results.

They are about to suffer a rude awakening. Though, all bundled applications will have to undergo some form of repackaging to adopt Java 7, since they will embed the JRE in their bundle. Getting off of Apple-private API will just have to be one of those steps.

> There are several options, but none of them looks perfect:
> 
> 1. Force application developers to fork their code to run with JDK6 and JDK7+

In cases of embedding, they should use the CALayer-based JAWT API, since that works in both worlds. If they are using platform dependent classes to dig at some native data structure, they will have to re-write their code to use JNI and use the JavaNativeFoundation framework if they are doing extensive interfacing with Cocoa APIs.

Again, with bundled applications, there should be no need to support Java 6, since they will already have a (clearly superior) Java 7 already inside them.

> 2. Re-implement all the Apple classes in JDK7 (and place them to the same package?) It may be very hard, if possible at all, to preserve exactly the same behavior, though.

In some cases, it's completely impossible because the component model in Java 7 is not NSView-backed, but CALayer/OpenGL backed. Some of the classes in apple.awt.* are just bridges onto NSView peers (or closely associated objects), which simply don't exist in Java 7.

There may be limited cases where creating backwards compatible classes for a few things may be feasible, but I'd need to see specific examples to make a better recommendation.

> 3. Add more APIs to com.apple.eawt both in JDK6 and JDK7 to use instead of direct references to Apple classes. What about classes that are not related to AWT?

Ick. Maybe there is a reason to do this, but taken on a case-by-case basis, it might be more desirable to just populate the apple.awt.* package space, mark them all as deprecated, and encourage a Java 7-only solution as soon as possible (since they would have to write new code to adopt new eAWT API anyway). New eAWT API seems like the least desirable option because it means that everyone (Oracle, Apple, and devs) re-writes, and targets a non-optimal solution.

> 4. Ignore such requests as all the applications relying on apple.*, or sun.*, or whatever else packages can be declared "unsupported".

Let's take it on a case-by-case basis. :-)

> Your ideas?
> 
> Thanks,
> 
> Artem

Regards,
Mike Swingler
Apple Inc.