Further info: it appears that the issue is not really the O/S after all, but rather that JavaAppLauncher requires the Java 7 plugin. You can't install Java 7 on 10.6 and earlier, so the Java plugin on those platforms is supplied by Apple. It lacks the libjli library that is needed by JavaApplauncher.
Seems like providing two separate packages might be the better solution after all. :| I guess I could ship TurboVNC-Lion.dmg and TurboVNC-Leopard.dmg, the latter of which would be built with the old (1.2.x) method and the former of which would be built with the new appbundler method. 10 bucks says there's something in Mavericks that throws a further wrench into the works. On 11/7/13 11:49 PM, DRC wrote: > Ugh. I've spent way too much time on this. The long and the short of > it is that there's a single binary application (JavaAppLauncher) at the > heart of appbundler. The rest of appbundler is basically just doing > what we already do-- creating the .app structure, populating the > Info.plist file, etc., so we could duplicate the functionality of > appbundler in our build system fairly easily if we built JavaAppLauncher > from source (it's GPL, so no licensing issues.) It's a little clunky to > invoke the C compiler only for the purposes of building a piece of > packaging glueware, but at least it would eliminate any dependence on ant. > > JavaAppLauncher is problematic, though. It simply doesn't work on 10.6 > and earlier, and I've even tried rebuilding it from source using the > 10.6 and 10.5 SDKs. No luck. I'm not sure what to do at this point. I > would be willing to give up Leopard support, but not Snow Leopard. > Creating two separate apps seems rather nasty. > > > On 9/23/13 1:22 AM, James Wettenhall wrote: >> Hi DRC, >> >> On 23/09/2013, at 3:53 PM, DRC wrote: >>> >>> It won't work with the plugin. I know that already, because my system >>> has the Java 7 plugin but is still using the Java 6 JDK/JRE for running >>> actual apps. >> >> OK, maybe I accidentally installed the plugin, and missed the full-blown >> JRE. >> >>> However, I'm not sure what you mean by "waited for Oracle >>> to announce that they would provide Java 7 for Mac OS X." Java 7 is >>> available for Mac OS X and has been for some time. >> >> Yes, Java 7 for Mac OS X is available from Oracle now. But at the time >> when Apple decided to describe their build of Java as "deprecated" in >> 2010, there was a delay of a few weeks while Mac Java developers were >> scratching their heads wondering whether they would be forced to use >> something like SoyLatte, because no large organization was promising a >> JRE build for Mac OS X. >> >> It looks like the "Apple's Java deprecated on Mac OS X" announcement >> came on October 20th, 2010: >> >> http://appleinsider.com/articles/10/10/21/apple_deprecates_its_release_of_java_for_mac_os_x >> >> http://www.theregister.co.uk/2010/10/21/apple_threatens_to_kill_java_on_the_mac/ >> >> http://www.theregister.co.uk/2010/10/22/jobs_on_java_for_mac/ >> >> and the announcement from Oracle that they would provide Java 7 builds >> for Mac OS X came a few weeks later on November 12th, 2010: >> >> http://www.apple.com/pr/library/2010/11/12Oracle-and-Apple-Announce-OpenJDK-Project-for-Mac-OS-X.html >> >> >> >> However, I don't think that announcement put all Mac OS X Java >> developers' minds at ease. When the February 2013 end-of-public-updates >> milestone for Java 6 (as provided by Apple's JRE) approached, many >> developers on the Apple Java mailing list were posting to threads with >> titles like "Do we have to fear February?" >> http://lists.apple.com/archives/java-dev/2012/Oct/msg00115.html because >> they didn't feel that the Oracle build of the JRE was ready to deploy >> their apps on - even 2 years after the Oracle/Apple announcement, many >> developers felt that there were still critical Mac OS X bugs in Oracle's >> JRE build. >> >>> At the moment, however, directing them to Oracle's >>> version seems fine as well. I mean, even if we bundle a JRE, they're >>> going to need to install a separate JRE in order to get JWS >>> functionality, so bundling isn't a panacea. >> >> OK, it sounds like the last time I investigated deploying a Java >> application on a modern Mac OS X system, I jumped to the conclusion that >> the reason why my JarBundler-bundled Java application couldn't find the >> Oracle Java Runtime Environment was that the JarBundler / >> JavaApplicationStub method was only designed to allow an app to find the >> Apple JRE. But it sounds like the reason was actually that I had only >> installed the Oracle Java 7 browser plugin, not the full Java Runtime >> Environment. >> >>> That's pretty frickin' huge. :| When you start looking at doing this >>> for multiple platforms and multiple binaries for each platform, then >>> hundreds of megs per release will introduce a lot of problems for me as >>> project maintainer. >> >> Yes, 50 MB is a lot when you are doing builds for multiple platforms and >> architectures. >> >> If I am wrong about JarBundler / JavaApplicationStub applications having >> trouble interacting with an Oracle-built JRE (which I hope I am), then >> there is no reason for me to describe the lack of bundled-JRE in the Mac >> TurboVNC Viewer app as a "concern". If JarBundler / >> JavaApplicationStub applications can interact nicely with Oracle's JRE >> on Mac OS X, then that's great news for us too - we have dabbled in Java >> GUIs in the recent past, but we got put off by a few apparent obstacles. >> >> Thanks for explaining your take on GPL licensing. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
