Just listening to #329 and I think undue attention is paid to OSX "secret APIs" in the context of a hypothetical community port of a Mac JDK.
Gosling's blog http://nighthacks.com/roller/jag/entry/steve_jobs_comments_on_apple complains about secret APIs in graphics rendering, but then goes on to say (as Tor points out in this episode) that Java on the Mac uses the default Java graphics pipeline, meaning that any platform-specific graphics rendering abilities, secret or not, are off the table anyways. This is what Gosling is complaining about in the third graf: Oracle's insistence that Apple abandon its anti-aliased rendering pipeline, and stay pixel-for-pixel compatible with aliased Windows XP. Secondly, in the context of #329's discussion, it's not clear why secret APIs are even relevant. The things that an AWT/Swing port needs to provide are a known problem, and it is known that these things can all be done with public APIs. After all, SWT does them all, and is far more entangled with native widgets than Swing/AWT. And since SWT is open source, it should be straightforward to go see how they did it. So, I don't buy that secret APIs are necessary for a SwingAWT port. Frankly, I don't think there's a hidden empire of wonderful secret APIs in Mac OS X. If there are, then I'd like to know why iTunes is still such a goddamn train-wreck. As most people acknowledge, many secret APIs are hacks and kludges that haven't had adequate review and aren't fit for third-party use. Also for those secret APIs that are found through various means (method swizzing, memory inspection, etc.), there's no technical reason on OS X that you can't call them -- look at the Ars article that Gosling cites and you'll see that the problem isn't that Mozilla can't see the secret function that WebKit uses (they know it's called WKDisableCGDeferredUpdates), but that the licensing implications of calling it are unclear. Big difference, though still a blocker for Mozilla. One unrelated thing I thought of while mentally composing this note. The Mac has two viable graphics APIs: Quartz (aka, Core Graphics), and OpenGL. Quartz is implemented in OpenGL, which provides hardware- acceleration for all system graphics (yay). So a port of Java2D would presumably want to use Quartz. But then I wondered: has anyone implemented Java2D in OpenGL? I thought there was a project doing this years ago, but I couldn't remember. If so, then it might be worth investigating if it would be practical for a hypothetical port to use that for its Java2D implementation, using NSOpenGLViews all over the place and then drawing Java2D->OpenGL into them. --Chris -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
