Re: Gatekeeper on MacOS 10.7 Michael Hall Tue Apr 03 20:00:42 2012
On Apr 3, 2012, at 9:28 PM, Josh Marinacci wrote: > The short version is: there will be a Java 7 for Mac. It will come from > Oracle/Sun, not Apple, and it will update itself. Thus it will be just like > the JRE on Windows and Linux. > > However, they still recommend bundling a JRE with your app instead of the > system install. Also, if you want to put a Java app in the Mac App Store, > then you must bundle a JRE. > > JRE = end user copy of Java. Fairly small (Windows version has usually been > in the 7 to 10mb range) > JDK = developer copy of Java, including compiler, tools, etc. Huge. > 50MB. > > Regarding the app bundling tools, I have this Ant task which will make a .app > bundle for a Java app on today's Mac OSX (Lion), but it will not embed a JRE. > This tool also will export an EXE or JNLP or double clickable jar. > > http://joshondesign.com/2012/02/26/AppBundler_new_project > > I'm going to donate my code to a larger project on Java.net that will be > similar and also support JRE embedding on Java 7+. > > I hope this clears things up. Well, we seem to have the discussion going here. Fine as well I guess. Yes, this helps. At least it's reassuring that the extreme sized application bundles won't be forced. Is your Lion tool for the Oracle/Sun or Apple? As far as current goes on the extreme size, is there any way to create an application bundle that either embeds just the smaller jre or uses a standard location jre? For my launcher. A little more detail on why I did one would be that as far as I know current plans are not to support the prior OS X java application features of $JAVAROOT and $APP_PACKAGE macros in the plist. My understanding is that the intent is to change current working directory to the bundle root and then in-bundle references can then be made using relative file references in the jvm arguments. So two changes from prior application support in dropping macro support in the plist and changing application working directory at startup from what it used to be (For Apple jvm applications this was application parent). Mine would leave support for these as-is and still maintain what I currently understand to be the new java application file layout. I like the current provision for classpath. My launcher includes no handling for plist classpath specification as the new setup appears to make it unnecessary. I additionally think there has to be some provision for java resources in the application bundle other than classes. My application includes a JavaApp directory for this purpose. Continuing to maintain the plist $JAVAROOT and $APP_PACKAGE macros makes doing this easier than otherwise. I guess I just think in general the macros enhance the functionality of the plist more than trying to cram everything into command line arguments.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Java-dev mailing list ([EMAIL PROTECTED]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/java-dev/alexiscircle%40gmail.com This email sent to [EMAIL PROTECTED]
- Gatekeeper on MacOS 10.7 - Michael Hall Brian Davies 2012/04/03
- Re: Gatekeeper on MacOS 10.7 Michael Hall 2012/04/03
- Re: Gatekeeper on MacOS 10.7 Joshua Smith 2012/04/03