Java 7 for Mac OSX

[Richard Bair]

Hi Gregg,

It could be the difference in perspective from this side. Since java is so widely used, even breaking .1% of the user base elicits screams :-). So while the risk of breakage may be low (so low some % of devs never experience it), from my perspective it happens regularly. So based on that experience I'd always recommend co-bundling.

But the other half of the reason is I think it leads to a much nicer user experience. As a user of your app I don't really know or care that it is a java app. On my mac I just want a .App -- it is really a hard requirement (anything else just says "junk" to me). I have heard Linux guys are similarly passionate about their packaging system of choice.

Windows is less picky but still expects an installer / uninstaller.

Cheers
Richard



On Feb 21, 2012, at 4:37 PM, Gregg Wonderly <gregg at wonderly.org> wrote:

> On 2/21/2012 4:08 PM, Richard Bair wrote:
>>>> Having the appropriate JRE installed for users to run my Java software, is also a big deal for me.   If we really do need to ship the "appropriate" JRE with every application, then it seems like we need to turn the whole compilation process upside down, and remove the JIT, and just have a complete native application built, instead of a jar.   All of the dynamic binding properties of Java, allow me, as a developer, to let you guys, the providers of Java, fix your issues, independent of me.
>>> That is an extreme oversimplification of the facts of real software development.
>>> 
>>> When it comes time for you to test your app, you only test against the version of Java you have, not future ones that don't exist yet. For your app's behavior to remain stable, the platforms it rests upon must be stable as well. Bundling your own JRE is the _only_ way to ensure that stability, and enable your app to be deployed as simply and as widely as possible on the Mac. This is also true on other platforms, but since deployment other platform is not as simple as dropping a single bundle onto the filesystem, this fact is shrouded by installers, scripts, registries, and other voodoo end users don't understand.
>> I completely agree with Mike on this. A *huge* (I would say, central) reason why Java deployment is chronically struggling is related to installed JREs and incompatibilities from one release to the next. In addition, every single time we fix a bug with a semantic side effect, somebody out there is going to be broken. As an application developer, I would never, ever, release software without tying it to exactly a specific version of the JRE. I would never rely on Java being preinstalled, in any circumstance. It is guaranteed to break at some unspecified time in the future.
> I guess I've always written Java with a different goal in mind.  For me, I've never had any issues with portability between Java SE releases.  For years, I've used the same Jar files with the same apps in them across multiple Java releases and never had any problems.   I've done Jini based applications that work just fine.  I've done extensive Swing based applications that work just fine.  I use the same javax.comm distribution for windows from Java 1.2 days and it still continues to function just fine on windows.
> 
> I've only recently (3 years or so) been developing on the Mac, but still, the same Java Jar files sitting on my desktop can be double clicked, and they just work.  Granted, when I came to the Mac, I needed to set the system property to get the menubar to work correctly on the Mac (what's up with that anyway?)
> 
> Over the years, the ONLY java portability issues I've had, are bugs revealed by hardware changes related to concurrency.  Everything else, has just worked!   Okay, when I had to switch from the old AWT event model to the new one, things were not portable and coding and testing was required.  But, that is absolutely the last time I had to "maintain" a Java application across releases.
> 
> Sun learned a hard lesson in Java 1.2.  But after that, they paid attention and made the write once, run anywhere work.
> 
> Gregg Wonderly