Java 7 for Mac OSX

[Phil Race]

On 2/22/2012 10:20 AM, Richard Bair wrote:
> Agreed, I think the JDK team has been and continues to be very serious about it. I wonder what you mean by "server" apps though -- application servers and the like? Those typically require a full JDK anyway because they require a compiler, but in my descriptions about "app deploy" I'm really just talking about consumer applications deployed to desktops.

Application servers and more. Anything that listens on a network port 
and services a request
and consumes and parses bytes from the external request.
The floating point parsing bug and the beast ssl hack are examples of 
what can happen.
Yes, I knew (and said) you were talking about pure desktop apps. I just 
wanted to point out there
is another class of app that may bundle a JRE (or JDK) but still can 
have JDK security issues to contend with.

-phil.

> Richard
>
> On Feb 22, 2012, at 9:54 AM, Phil Race wrote:
>
>> On 2/21/2012 4:24 PM, Richard Bair wrote:
>>> 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.
>> True as far as it goes for pure client/desktop apps here where that security is a non-concern
>> means more that since the end-user already trusted the app to install and be granted
>> privileges akin to native code, so that upgrading to fix security bugs in the JRE against
>> untrusted code is pointless.
>>
>> But "server" apps which respond to untrusted requests are more like web deployed apps.
>> If they bundle a JRE then you need to update the whole bundle as new more secure
>> JREs become available, so that unscrupulous people can't compromise your server.
>>
>> I also want to make it clear that whilst increasing security and maintaining compatibility
>> are sometimes conflicting goals, that the Java SE org. has for many years made
>> compatibility a key theme. We do not just pay lip service to compatibility. We work
>> very hard at it. Yes, we may break apps, intentionally or unintentionally, but its not
>> for the want of trying. I think overall we've become good at it, and its really important
>> to customers. They do test when we ship a new release, and then they complain
>> loudly and/or often if we broke something. And if we can fix that, we will.
>> Enterprise customers expect this. They'll go somewhere else if we aren't serious about it.
>> I think you are more likely to have an app behave differently on a new platform/version
>> than you are purely due to a patch upgrade in the JRE on the same platform/version.
>>
>> -phil.