Java 7 for Mac OSX

[Richard Bair]

>> 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.
> 
> Is it now the official position that Java is not future-compatible
> anymore? That "compile once, run everywhere" is a joke?
> 
> I understand that you are not speaking for Oracle, because that would be
> sad.

I was interrupted halfway through the response so it was kind of short, so here's the more full description.

Java has never been future compatible, and will never be. I just want to make sure that is clear, because if you've been under the impression that it was 100% future compatible or that there was an implied contract I can assure you that is not the case. There are numerous times in each release where fixing a bug will break somebody. It is just the nature, or physics, of the situation.

Suppose we have a bug where, when you set padding on a component, the right padding didn't work (but used the left by mistake). Perhaps it was a copy paste bug. When we fix this bug, it will break somebodies layout. With the reach and distribution of Java, it will definitely break somebody.

In Java we always have to determine, for a given bug fix, what is the likelihood of breakage? If it is high, we sometimes simply will not fix the bug, because it is too late to do so. If the breakage is minimized in some way (for example, people couldn't have used the API correctly anyway), then it is something we might fix.

And of course we do have regressions. We fix something or add a new feature or improve performance and break you. It happens.

Of course we have tried to be careful and not do more harm than good by making changes. This has been limiting to the platform in many ways, but that is the price you pay for adoption.

It may be that you just haven't been bitten by any of these fixes, but you're just rolling the dice. The only sane way, really, is to bundle a JRE with your application. Now in the Applet case you cannot pick a specific version of Java (due to performance issues, among other things) and this is a major challenge for us to figure out how to resolve.

As an app developer (which I was prior to joining Sun and still consider myself, in my heart, to be), I would *never* ship a desktop application relying on some preinstalled version of Java. Personally I would do something like Sparkle for Java for managing updates. I think asking a user to go download a JRE so my app runs is a non-starter, and I don't want to be dependent on some random JRE version being on the system.

So let's not get alarmist here. Oracle isn't at all changing the policy, this is the way it was at Sun as well. We don't break people on purpose and binary compatibility is where we put all our effort (so old bytecodes run on new JVMs), but binary compatibility doesn't ensure that the code will do the same thing. The only way to guarantee that is to run against the same JRE from here till forever.

>> Including a JRE inside the app bundle is simply a new requirement, since
>> Apple does not provide one as part of the base OS, and Oracle is in
>> charge of shipping Java 7 and newer versions. It doesn't matter if you
>> bundle a proprietary binary built by Oracle, an OpenJDK binary you built
>> yourself, or an OpenJDK binary someone else built for you - it's your
>> choice.
> 
> However, the reality out here is that it does matter whether the binary
> was built by Oracle, by Apple or by yours truly.
> 
> You know, if you wanted to seed uncertainty and doubt about Java on
> MacOSX, things like "oh, and we break 32-bit compatibility without warning
> and we are unwilling to fix the breakage but instead argue that you have
> to cope with it yourself" and "oh, and Java, well, hide it in your App.
> Bring your own. Do not have a system-wide well-tested and well-maintained
> Java" are *exactly* what I suggest you should start with.
> 
> Basically, you are asking people to forget about everything they learnt to
> rely on in Java. Stability. Compatibility. Platform-independence.

I can understand the concern around 32-bit. However as I mentioned above, the only way to really know what you are running against is to co-bundle the JRE with your app. That doesn't hurt any of those things you state -- in fact it is (and has always been!) the only way to truly have Stability. Compatibility and Platform independence are still there as well as they've ever been.

Lets calm down a bit here. Apple hardware soon won't support 32-bit anyway. In the Apple world, life moves on and Java has to as well. That has always been true.

Richard