Java 7 for Mac OSX

[Richard Bair]

Hi Johannes,

On Feb 21, 2012, at 3:18 PM, Johannes Schindelin <Johannes.Schindelin at gmx.de> wrote:

> Hi Richard,
> 
> On Tue, 21 Feb 2012, Richard Bair wrote:
> 
>> 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.
> 
> That is what I referred to when I said "pushing the burden".

I don't understand what you are referring to? I want to be clear -- the current model has, by it's nature, certain drawbacks related to compatibility and security which cannot be solved. Compatibility and security are fundamentally at odds with each other in shared JRE installations when used in web deployed scenarios.

There are several deployment scenarios which require different answers. For what I call "web deploy" I'm talking about applications which the user does not install, but rather they execute either by visiting a web site or clicking a link on a web site. That is, applet or web start deployment.

Then there is "app deploy", which is your standard desktop execution.

Web deploy currently requires multiple shared JRE installations. I'm not going to go into depth on web deploy right now because this thread is about app deployment. However web deploy is where security and compatibility are at odds with each other. If you have an app that relies on 6u10 because it was not tested against 7, then you are out of luck because 6u10 has known security vulnerabilities so you can only get the latest "security baseline" in the java 6 train. But some bug fixes between 6u10 and 6u30 might break your app. But we can't let you run against 6u10 because you might be a malicious app and therefore intent on exploiting security holes. This is what I mean when I say that in the web deploy scenario, compatibility and security are at odds with each other. And here security must win.

For app deploy, security is a non issue, because a desktop app has no security manager and therefore can do anything the system allows, and cannot do anything the system forbids. So for app deploy it is a red herring.

For app deploy the tradeoff is compatibility vs. download size. There is also the method of app deploy.

With an installed JRE you can use a double clickable jar. But that is odd to users who are not used to double clickable jars and it is also not reliable. Some unzip utilities register the ability to unzip jars such that double clicking a jar launches the unzip utility.

You could co-bundle the JRE with your app in a zip with custom shell scripts and batch files to run the app. Kind of insane but you could do it.

But both of these options are awful for end users. No, a user wants the app to be installed in the normal, native way. And with Java 8 this becomes feasible. We can generate exe, app, rpm, etc. automatically based on the modules you use. We could automatically remove JRE modules you don't require and bundle in third party libs as well. The user gets the best possible experience and you get the best possible stability and compatibility. For ease of updates we could have a "Sparkle4J" type project.

> I grant you that it would be easier on the JDK/JRE developers

To me that is not important (unless the cost were excessively high such that the larger project were in peril). This is about giving developers the most stable and compatible way to deploy apps and give end users the best possible experience with "native" apps.

Like I said, web deploy is a different situation with different parameters and would be handled differently (lest there is any confusion on that point!)

> 
>> In addition, every single time we fix a bug with a semantic side effect,
>> somebody out there is going to be broken.
> 
> You know, that is why some developers refrain from relying on undocumented
> behavior.

What I'm talking about has nothing to do with undocumented features. There are times when the specification and implementation disagree. Sometimes the spec is changed and sometimes the implementation is changed. Regardless of which changes, somebody will get burned. You don't see the bug reports or hear all the screaming :-).

> 
>> 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.
> 
> By that reasoning, we should all ship our software together with specific
> OS versions (not allowing for system updates, that might change the
> behavior and break the application). Just completing the logical argument,
> is all I did.

Well if you are going to go that far you may as well also ship your own hardware. Well, now you know why Steve Jobs did what he did :-)

But you are being quite unreasonable in this analogy. You don't require third party libs to be preinstalled, do you? No, likely you co-bundle those with your app. I don't see Java as an OS, I see it as a library. See it can go both ways :-)

> The way you are suggesting things to be done guarantees that some security
> flaw which was fixed in Java for decades will still come back to bite the
> users.  Or that improvements in the JIT do not reach them.

No not at all. What I advocate is that you, the app developer, are in the driver seat. You get to choose whether you want those vm improvements. You get to certify the configuration your app runs on. Your users get the best user experience. Your app doesn't mysteriously break because some other app updated java.

And no, the security thing you brought up is a red herring. (a) we cannot promise this today either and (b) native apps can do anything anyway because there is no security manager installed.

Literally, you get better user experience and better control. I don't see how this can be a bad thing.

> Just to be ultra-clear: is what you suggest -- to stop having a
> system-wide, well-maintained JRE in favor of JREs bundled with each and
> every Java application -- the official stance of Oracle, or is this just
> your personal opinion?

I am a strong advocate for having at most one system wide JRE only for web deploy (and this must always be the latest), and having apps co-bundle the JRE.

The JDK of course is another story, since developer needs are different from consumers. You can have multiple system wide JDK's installed, but only the latest system wide JRE will work for web deploy.

As client architect, I have a certain amount of sway :-). But there is no finalized plan to not have multiple system JREs on windows or Linux. There is also no finalized plan to *have* multiple system wide JREs on Mac.

Cheers
Richard

> 
> Ciao,
> Johannes