How to prepare for Java 7 Update 51?
The exception site list [link] newly introduced with Java 7 Update 51 is a well needed work-around for those LiveConnect users out there that get blocked on every update, however am I correct in assuming it does nothing to help the issues we will encounter with the roll-out of Java 7 Update 51 in January?
If so, it still puts administrators in reactive mode for this next update. Thousands of applets around the world will stop functioning the day they are marked outdated (usually the day the new version is released), and the only work-arounds are inadequate for non-specific deployments (the spirit of cloud services and spirit that the web was formed on). i.e. Default settings will block the applet and there isn't an easy way for users stop it.
Arguments I've seen to alleviate this stress on the users (and therefor on the projects and companies that are flooded with complaints when this occurs) often mention 1. Deployment Rule Sets for the PCs and 2. Lowering the security slider for the PC.
1. Deployment Rule Sets:
From my experience, DeploymentRuleset.jar has needs that are too specific for most global software roll-outs (as the specification specifically warns against anyways) so offering DeploymentRuleset.jar as a long-term solution to fix compatibility is impractical as well as ill-advised. It's a bad solution unless you have a very controlled closed network of computers.
2. Lowering the "bar"
Lowering the security slider bar is the exact OPPOSITE of what outdated installs should be doing (they are outdated after all), but this is the only *other* solution I've found to get LiveConnect to work on Java 7 that's below security baseline.
From what I've read, the reasoning behind blocking LiveConnect (and therefore blocking all JavaScript calls to the applet) is Oracle's position that JavaScript code is "unsigned" and therefore "untrusted" with old versions of Java, but I've yet to see a proposed way by Oracle to sign and trust JavaScript code.
The end result is legitimate applets that have been working for months suddenly fail to load with no obvious warnings to the user. This causes revenue loss for companies (for profit and not for profit) as well as a burden on the individual. In most cases, the individuals using the applet lack sufficient access and/or knowledge to update, which hurts all parties involved.
Is there something I'm missing? How do the "big guys" do it?
-Tres
If so, it still puts administrators in reactive mode for this next update. Thousands of applets around the world will stop functioning the day they are marked outdated (usually the day the new version is released), and the only work-arounds are inadequate for non-specific deployments (the spirit of cloud services and spirit that the web was formed on). i.e. Default settings will block the applet and there isn't an easy way for users stop it.
Arguments I've seen to alleviate this stress on the users (and therefor on the projects and companies that are flooded with complaints when this occurs) often mention 1. Deployment Rule Sets for the PCs and 2. Lowering the security slider for the PC.
1. Deployment Rule Sets:
From my experience, DeploymentRuleset.jar has needs that are too specific for most global software roll-outs (as the specification specifically warns against anyways) so offering DeploymentRuleset.jar as a long-term solution to fix compatibility is impractical as well as ill-advised. It's a bad solution unless you have a very controlled closed network of computers.
2. Lowering the "bar"
Lowering the security slider bar is the exact OPPOSITE of what outdated installs should be doing (they are outdated after all), but this is the only *other* solution I've found to get LiveConnect to work on Java 7 that's below security baseline.
From what I've read, the reasoning behind blocking LiveConnect (and therefore blocking all JavaScript calls to the applet) is Oracle's position that JavaScript code is "unsigned" and therefore "untrusted" with old versions of Java, but I've yet to see a proposed way by Oracle to sign and trust JavaScript code.
The end result is legitimate applets that have been working for months suddenly fail to load with no obvious warnings to the user. This causes revenue loss for companies (for profit and not for profit) as well as a burden on the individual. In most cases, the individuals using the applet lack sufficient access and/or knowledge to update, which hurts all parties involved.
Is there something I'm missing? How do the "big guys" do it?
-Tres
Comments