Oracle rebrands Java, breaks Eclipse

Oracle rebrands Java, breaks Eclipse

Summary: Earlier this month, Oracle released a new version of Java, 1.6.0_21 (6u21). Unfortunately as Eclipse users quickly discovered, it was incompatible with Eclipse and Eclipse Rich Client Platform (RCP) programs.


Earlier this month, Oracle released a new version of Java, 1.6.0_21 (also called 6u21). Unfortunately as Eclipse users quickly discovered, it was incompatible with Eclipse and Eclipse Rich Client Platform (RCP) programs.

Bug 319514 in the Eclipse bug database has all the gory details, but in a nutshell, Oracle changed the company name property on java.exe from "Sun Microsystems, Inc" to "Oracle". The change was not announced or documented in the release notes. Ironically, Eclipse has been using this value since 2007 to work around another Java problem where Sun's default for the "MaxPermSize" option was too small for Eclipse to run. When it changed, the workaround no longer worked, and many people encountered "PermGen" errors when they started Eclipse.

Oracle responded by respinning 6u21 on Monday to restore the value, but warned that it will be changed for good in JDK 7. A company developer wrote:

As part of Oracle's rebranding of Sun's products, the Company Name property of the java.exe file, the executable file containing Oracle's JRE for Windows, was updated from "Sun Microsystems" to "Oracle" in Java SE 6u21.

After the updated JRE was posted on, it was reported that the change affected Eclipse users on Windows by causing it to hang when starting Eclipse after updating to the rebranded JRE. A workaround was quickly identified and posted on Eclipse's website, but a wide distribution of the rebranded JRE executable could negatively impact many Eclipse users. In consideration to Eclipse and other potentially affected users, Oracle has restored the Windows Company Name property value to "Sun Microsystems". This value will be changed to "Oracle" in JDK 7.

The change affected only the Windows version of the JRE, not the versions for Solaris and Linux. To accommodate this update the Windows build version will increase from 6u21-b06 to 6u21-b07. Solaris and Linux distributions will continue to ship build 6u21-b06.

An engineering side note: The "Java" property values for java.vendor and java.vm.vendor were never changed in the jdk6 releases and will remain "Sun Microsystems, Inc.". It was understood that changing the vendor property values could impact applications and we purposely did not disturb these vendor properties. The Windows specific exe/dll file "COMPANY" value is what is at issue here, not the Java properties. It came as a surprise to us that anyone would be inspecting or depending on the value of this very platform specific field. Regardless, we will restore the COMPANY field in the jdk6 releases. Note that the jdk7 releases will eventually be changing to Oracle, including the java.vendor and java.vm.vendor properties.

This morning I verified that the official Oracle download site has been updated with the correct version and that it works with Eclipse. Here's what it prints when I run java -version:

C:\> java -version java version "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b07) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)

If you downloaded Java for Windows 32-bit or 64-bit recently, be sure you have the 1.6.0_21-b07 version and not b06.

Topics: Software Development, Open Source, Oracle

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • write once run anywhere continues it's epic fail... sigh...

    how sad...
    Johnny Vegas
    • RE: Oracle rebrands Java, breaks Eclipse

      Somebody please pass this memo on to Adobe. KThxBye
      • RE: Oracle rebrands Java, breaks Eclipse

        @josegaldamez I will forward this article to him. Pretty sure he will have a good read. Thanks for sharing!
        <a href="">Theses</a> <a href="">Coursework</a> <a href="">Assignment</a>
      • RE: Oracle rebrands Java, breaks Eclipse

        @josegaldamez I am looking forward for your next post, I will try to get the hang of it!
        <a href="">Dissertation Writing</a> <a href="">Assignment Writing</a>
    • RE: Oracle rebrands Java, breaks Eclipse

      @Johnny Vegas Dude, you're totally clueless. This "bug" is about a company using metadata (that NEVER constituted an INTERFACE) in an *EXECUTABLE* to control runtime behavior. This has nothing to do with the Java language or VM. It's Eclipse's fault for relying on such an unstable value.
  • Great bug fix

    Who fixes a bug by making something dependent on the dll/exe company name? Stupid...How are those outsourced indians working for you now Oracle and Sun!!!!
    • RE: Oracle rebrands Java, breaks Eclipse


      Uh...think the article said it was IBM that coded the dependency on company name in Eclipse....not Oracle or Sun.
    • RE: Oracle rebrands Java, breaks Eclipse

    • RE: Oracle rebrands Java, breaks Eclipse

      @FireThorn -

      Open Source developers.. who else?
  • RE: Oracle rebrands Java, breaks Eclipse

    a very easy target ? grow up !!!!
  • RE: Oracle rebrands Java, breaks Eclipse

    I think the title of this should be 'Oracle rebrands Java, uncovers Eclipse bug.'
    Oracle should be complimented on changing it back so quickly...
  • RE: Oracle rebrands Java, breaks Eclipse

    has anyone experienced issues with IBM Lotus Sametime connect client and this java issue
  • RE: Oracle rebrands Java, breaks Eclipse

    Not really a branding. More a labeling change, not properly documented.<br><br>Which pisses me off. I used to be in charge of those release notes, and I like to think I'd never let something like this slip through.
  • RE: Oracle rebrands Java, breaks Eclipse

    That's one of the most horrible sensationalistic article titles I've ever read. Shame on ZDNet! If Eclipse writes code that depends on an unstable, unpublished non-interface then shame on them.
  • Java, a solution in search of a problem

    It's slow, it's buggy and it seems to get updated every week to fix some new thing.

    It's write once, run anywhere spin sounds good, until you realise you need to download and install the JRE before anything will work. It doesn't exist on Windows, except for the nerds and the curious who download it.

    It really can't compare to ,Net for ease of use and power, but Ecipse was an attempt to give it a real visual IDE (failed unfortunately) and drag it into the 21C. Rather stupid of the Eclipse developers to use a name property, but I'm sure it seemed a good idea at the time - probably because there was no other solution available.

    Java will be soon moving to the elephant's graveyard of programming languages. ;-)
    • RE: Oracle rebrands Java, breaks Eclipse

      @tonymcs@... Yeah Java sucks.It is slow and .net is slow too,those guys should learn from the Python guys.
  • RE: Oracle rebrands Java, breaks Eclipse

    Software maintenance will never end...
  • RE: Oracle rebrands Java, breaks Eclipse

    It's very easy to blame Eclipse for depending on this variable, but let's think for a minute about why it was done.

    1) The Sun JVM as shipped does not allow enough PermGen memory for a large application such as Eclipse to run. Incidentally many server applications also need to expand the PermGen available.

    2) There is no standard option to expand the PermGen. The option on the Sun JVM is -XX:MaxPermSize but the "XX" part indicates this is an option specific only to the Sun JVM and is not available on other JVMs such as JRockit, IBM J9 etc. In fact using it with those JVMs can cause them to simply emit an error and exit.

    3) Therefore Eclipse needs to detect whether it is on the Sun JVM specifically before it adds the -XX:MaxPermSize option. This cannot be done in Java because by the time the JVM has started it is too late, so it has to be done in the native launcher executable, i.e. eclipse.exe, which is coded in C. At this point the standard Java system properties are not available yet, but the properties in the exe/dll file IS available.

    So before blaming Eclipse... what would you have done?
  • RE: Oracle rebrands Java, breaks Eclipse

    Sounds like a cunning Oracle plan to have everyone move over to NetBeans :) (Which is, frankly, a better IDE in many ways anyway.)
  • RE: Oracle rebrands Java, breaks Eclipse

    Eclipse laucher need to pass to the Sun/Oracle virtual machine (in command line) a non standard parameter, not present in other virtual machines. The parameter is specific to the Sun/Oracle vm memory management.
    The only way to do this is to parse a dll property (java hasn't start yet) that contains the name of the vendor.
    <a href="">Free softwares</a>