Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • August 11, 2014

Keeping users on Internet Explorer up-to-date and secure

Donald Smith
Sr. Director of Product Management
Oracle actively works with many vendors on Java security and an
important goal is finding ways to remove old and unsecure Java
versions from circulation.   Oracle recommends that Java users keep
their JRE installations up to date with the latest security baseline
through the Java Auto Update feature. Microsoft Windows users
have long been able to  improve the security of their computer by
checking for old versions of Java and removing them using the Java
Uninstall Tool

On August 6th, Fred Pullen and Jasika Bawa from Microsoft announced, on the Internet Explorer Team Blog, that Internet Explorer will
soon block out-of-date ActiveX controls.  On August 10th, Microsoft
updated their their blog
 with more technical information,
timelines and pointers to more resources for developers and

This Internet Explorer feature will provide Internet Explorer
users with notifications when web pages try to load out-of-date
Active X controls, like Java ActiveX controls provided by a JRE
below the security baseline [1].  Additional documentation and
information and how to configure and manage this new Internet
Explorer feature are provided by Microsoft.

At Oracle, maintaining the security-worthiness of Java is our
.  As in this case with Microsoft, we continue to work
together with our partners to keep Java users up-to-date and
secure across different browsers and operating systems. 
Enterprises that need to keep an older JRE around for legacy
applications should still use a current JRE installed along the
older JRE and leverage the Deployment Rule Set Functionality to
limit access to the older JRE to well-known applications

 - Don 

Join the discussion

Comments ( 5 )
  • guest Monday, August 11, 2014

    You publish an update one day, that addresses every internet user. Than you find out that company user have a problem the other. Than you release an update the third closing comments on the blog post, but refer to the one that you describe by name of the authors and link to it. This is kinda destrubctive, while you talk of "partners".

  • guest Monday, August 18, 2014

    Can anyone help with this??

    c:\dev\GEAC\Extensity\Rel8_3>java URLContent

    java.net.SocketException: Permission denied: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.AbstractPlainSocketImpl.connect(Unknown Source) at java.net.PlainSocketImpl.connect(Unknown Source) at java.net.SocksSocketImpl.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at java.net.Socket.connect(Unknown Source) at sun.net.NetworkClient.doConnect(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.openServer(Unknown Source) at sun.net.www.http.HttpClient.<init>(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.http.HttpClient.New(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown


    at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Sou


    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Sour


    at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown S


    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown So


    at URLContent.main(URLContent.java:18)

    If the program is compiled and ran using Java 7, there’ll be no error.

  • guest Monday, August 18, 2014

    We are using Deployment Rule Sets to limit access to the older JRE to well-known applications like you stated - but are running into a problem.

    One business critical applications has the following properties (*s to protect info):

    title: Enterprise Services Repository

    location: null

    jar location: http://app.*.com:52400/rep/repository/*.jar

    jar version: null

    isArtifact: true

    The application downloads a .jnlp file, and uses java web start to execute.

    Since the location is null, this application cannot be targeted by a location rule. And the certificate hash method only works when the application is cached (being ran more than once). If cache storing is off, which is the case in some situations, how can this application be targeted? Or at least told to run with an older JRE on start?


  • costlow Wednesday, August 20, 2014

    Let's head over to a discussion site like https://community.oracle.com/community/java or http://serverfault.com/ to look at the deployment rule sets. I think more people will benefit from those vs. this comments section. (post a link once the question is up there)

  • guest Wednesday, August 20, 2014
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.