On Nov 9, 2010, at 7:44 AM, phil swenson wrote: > who cares if there are secret APIs or not? Just implement swing on > the existing documented APIs. It's good enough for all the nice, > beautiful native cocoa apps out there, why not good enough for Swing? > So maybe we miss on some weird edge cases, big deal. Let's be honest, > almost all of us use Java swing almost exclusively for developer apps > like IntelliJ IDEA/Netbeans/DB Visualizer/Ruby Mine, etc. They use > normal, standard type widgets - nothing too fancy. > > The real problem is: who is going to take the project? Oracle should > tell us what there plans are - if any. If they pass, then someone > else will pick up the slack.
I'm working on the Aqua Swing LAF for OpenJDK, and I'm calling it (of course) "Jaqua" for now. So far I have not had to use any secret APIs that I know about. Unless I really have and have just not been telling myself. There are many people willing to help. This guy: http://www.jkoala.org/ can even take the lead role in developing the ATW hooks into Mac OS. But it seems that all though there is much talk, there is little walking of the walk. If only 1000 people who rely on a good JVM to be available on Mac OS pitched in just 50EUR we'd have a full time resource on this project. But I suppose everyone wants their *free* JDK Mac OS X port, and despite all the complaining aren't even willing to pony up 50 bucks. There's lots of islands of activity at the moment, another group recently formed to discuss this is: http://groups.yahoo.com/group/java4mac Dalibor Topic and Landon Fuller have requested we all discuss this on the open-bsd mailing list, but I have seen almost zero traffic on that particular list so I don't know if there are secret discussions going on, or if really nothing is going on. At any rate, I'm working on Jaqua, the Mac OS look&feel for Swing, to be used on the new Mac OS JVM port whenever that appears. When I have a decent prototype working (I'm starting with the ButtonUI), I'll put it up on some SCM site. Rob > > On Mon, Nov 8, 2010 at 12:02 PM, Joe Nuxoll (Java Posse) > <[email protected]> wrote: >> Yes, Chris - I think I was trying to make this point. I think the >> "secret" APIs argument is a red herring of speculation by JG. >> >> - Joe >> >> On Nov 8, 10:36 am, Chris Adamson <[email protected]> wrote: >>> 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 >>> bloghttp://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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
