Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Bug Oracle Java Sun Microsystems Upgrades

Oracle's Java Company Change Breaks Eclipse 397

crabel writes "In Java 1.6.0_21, the company field was changed from 'Sun Microsystems, Inc' to 'Oracle.' Apparently not the best idea, because some applications depend on that field to identify the virtual machine. All Eclipse versions since 3.3 (released 2007) until and including the recent Helios release (2010) have been reported to crash with an OutOfMemoryError due to this change. This is particularly funny since the update is deployed through automatic update and suddenly applications cease to work."
This discussion has been archived. No new comments can be posted.

Oracle's Java Company Change Breaks Eclipse

Comments Filter:
  • Ironically... (Score:5, Insightful)

    by fuzzyfuzzyfungus ( 1223518 ) on Wednesday July 28, 2010 @06:26PM (#33062854) Journal
    Oracle's pet linux is branded "Unbreakable"...
  • So? (Score:5, Insightful)

    by Anonymous Coward on Wednesday July 28, 2010 @06:27PM (#33062872)

    How is this Oracle's problem?

    • by Anonymous Coward on Wednesday July 28, 2010 @06:32PM (#33062978)

      I don't know why they're blaming Oracle. This is clearly a fuck-up made by the Eclipse developers.

      If any other piece of software checked the platform it was running on and didn't handle unexpected cases properly, it wouldn't be the platform developer's fault. The blame would rest solely with the application developer.

      • Yes and no... (Score:5, Informative)

        by Zancarius ( 414244 ) on Wednesday July 28, 2010 @06:40PM (#33063064) Homepage Journal

        Yes and no. While it's not the best practice to rely on some field assuming it'll forever remain static, if you read the bug report in TFA (surprise, surprise), you'll find this:

        This causes a severe regression for programs that need to identify the Sun/Oracle HostSpot VM such that they know whether the "-XX:MaxPermSize" argument needs to be used or not.

        So, the reason they examine it in the first place is to know whether or not they need to set specific values that are supported by the Sun/Oracle JVM. It's not optimal, but I can't exactly fault them for that.

        • Re:Yes and no... (Score:5, Insightful)

          by beanluc ( 780880 ) <beanluc up to> on Wednesday July 28, 2010 @06:48PM (#33063156) Journal

          Is "company name" *really* part of any intended-to-be-reliable way to identify the VM?

          Is "company name" *really* necessary for identifying the VM?

          If either answer is "yes", then, I agree, and I add, shame on the VM designers. Shame.

          Otherwise, shame on any team who developed apps depending on that.

          One way or the other, this is *not* a benign, forgivable occurrence.

  • Sounds... wrong (Score:5, Insightful)

    by squiggleslash ( 241428 ) on Wednesday July 28, 2010 @06:27PM (#33062882) Homepage Journal

    Apparently not the best idea, because some applications depend on that field to identify the virtual machine

    Should they?

    • Re:Sounds... wrong (Score:5, Informative)

      by LostCluster ( 625375 ) * on Wednesday July 28, 2010 @06:29PM (#33062924)
      If you're using Sun/Oracle-specific commands, you don't want to find your app running in an unofficial or unsupported Java such as Microsoft's that was eventually recalled.
      • Re: (Score:3, Insightful)

        by jisatsusha ( 755173 )
        Isn't this exactly the sort of thing that reflection is designed for? As an analogy, it's like looking specifically for "Microsoft Internet Explorer" when writing web pages, instead of checking if document.addEventListener is available. It's flakey and easy to break when the platform gets updated.
        • Re:Sounds... wrong (Score:4, Insightful)

          by Vellmont ( 569020 ) on Wednesday July 28, 2010 @07:59PM (#33063908) Homepage

          Isn't this exactly the sort of thing that reflection is designed for?

          I'm not sure if there's anything in reflection that'll tell you specifics about the virtual machine options or not, but that's not really what reflection was designed for. Reflection is primarily used to find out information about, and allows manipulation of Classes.

        • Re: (Score:3, Insightful)

          by oreaq ( 817314 )
          The information is needed to start the VM. Reflection is designed to be used when the VM is already running.
    • Should they?

      I seem to remember some applications not fully working with Blackdown and possibly others facing some breakage with other JVMs. So while it's stupid to rely on the vendor field in general, I can sort of understand why they'd examine it for purposes of compatibility. It goes both ways.

      Let's just blame everyone and get it over with.

    • Kind of my first thought when I read that; maybe not the best move.
    • Should they?
      Sometimes different implementations of a "standard" behave differently, sometimes that is because of a bug, sometimes it's because of an ambiguous specification in the standard. Sometimes it's because of something beyond the scope of the standard (e.g. suns VM needs to be told how much memory it's allowed to use upfront or memory hungry applications will fail).

      When this happens you have to identify what you are running on so you can tailor your apps behaviour to that of the implementation it is

  • by mandelbr0t ( 1015855 ) on Wednesday July 28, 2010 @06:28PM (#33062902) Journal
    I am beating myself over the head until I forget all programming languages. There is not a single programming culture left that I can identify with. :(
  • Design Decisions (Score:4, Insightful)

    by Subliminalbits ( 998434 ) on Wednesday July 28, 2010 @06:28PM (#33062906)
    Ladies and gentlemen, I call you attention to Exhibit A for the real world consequences of poor design decisions.
  • by kaladorn ( 514293 ) on Wednesday July 28, 2010 @06:30PM (#33062930) Homepage Journal
    Poor planning. Eclipse should not use a 'company' field to be pulling key VM info from. And there should be another more particular way to acquire VM information applications require. That was a poorly thought out situation from the get-go, but Oracle was mightily short sighted for making this change without much testing of compatible apps. Mind you, it isn't their fault as such, but pissing off all of those using Eclipse is mightily retarded. While we're on the subject of retarded, automatic updates? You deserve what you get if you trust those. You should be damn sure an update is solid, stable, and won't give you a BOHICA experience before you apply it. No sympathy for auto-update users.... that's just bad planning as well. So: Oracle: Minor thumbs down. Eclipse devs: Thumbs up overall (except for bloating), but thumbs down for this one. Auto-update Users: Not bothering with a thumb, too busy ROFLMAO.
    • by 0123456 ( 636235 ) on Wednesday July 28, 2010 @06:33PM (#33062998)

      Mind you, it isn't their fault as such, but pissing off all of those using Eclipse is mightily retarded.

      I can't help but feel that most Eclipse users won't notice one more source of random crashes on startup.

      • Re: (Score:3, Informative)

        Use NetBeans. I use both NetBeans (by choice) and Eclipse (by necessity, for work) and find Eclipse to be powerful but it is unstable and has a truly awful interface (that only IBM could love!) from a usability point-of-view. NetBeans is much simpler and straightforward to get things done.
    • Poor planning, perhaps. But I wonder what the deal is with Oracle being so over-eager to plaster their company name all over the place. Wherever you go,,, javadocs, the "ORACLE" Logo is everywhere and this happened only a week or two after the takeover.

      • Don't forget the new splash screen on, including the reversion to the really old icons.

      • Re: (Score:3, Insightful)

        by GumphMaster ( 772693 )

        But I wonder what the deal is with Oracle being so over-eager to plaster their company name all over the place.

        It means that the marketing/branding people in the company carry more clout than anyone with actual product knowledge. This is certainly not unique to Oracle, with most large publicly-traded companies worrying more about their "brand" than the product.

    • Re: (Score:3, Insightful)

      by bws111 ( 1216812 )

      It was poor planning on the specification of the JVM that there is not a standard way to specify the requested heap size. So Eclipse tries to figure out the JVM the best it can so it can pass in the correct parameters to the JVM. In this case, they could not determine the JVM, so I guess they just used the default heap size. I am not sure there is anything Eclipse could do differently (except maybe issue an 'unknown JVM' message, which doesn't help the users any more than possibly running out of memory).

  • The real title should be "Enterprise Software Breaks when Oracle Changes Name."

    Thick-client software that relies on a branding for string comparisons or regular expressions (I don't know which it is)? Hum.

    (I say "thick-client" because "thin-client" ... or, hosted ... is a lot easier to push updates for :) )

  • I can remember trying to install programs to D:\ rather than C:\ - That caused no end of problems due to developers hard coding in and just assuming that windows and themselves would be installed on the conventional C: That anyone would ever use any other drive letter didn't seem to occur to them. If I remember correctly this happened to me with a version of matlab (or something in that family).
    • I remember seeing "how to" articles for various languages there to determine the drive the app is on, and the drive and directory where Windows is. Programmers who didn't learn from these things were ignorant.
  • Clearly... (Score:3, Funny)

    by by (1706743) ( 1706744 ) on Wednesday July 28, 2010 @06:32PM (#33062972)
    Eclipse wasn't built leveraging the doWhatIWant() [] function (not to mention doItFaster(doWhatIWant())).

    Tangentially related, what does the following do:

    doItRecursively(doWhatIWant()) { return doItRecursively(doItFaster(doWhatIWant()); }

    I'm guessing it does it instantaneously...or never.

  • IT'S ALREADY FIXED!! (Score:4, Informative)

    by Anonymous Coward on Wednesday July 28, 2010 @06:33PM (#33062988)

    They already released a fix, with the original "Sun Microsystems" embedded in the exe on Monday. WTF, was this posted by kdawson? The FUD is strong in this one.

    • by Sir_Lewk ( 967686 ) < minus herbivore> on Wednesday July 28, 2010 @07:03PM (#33063326)

      Their fix was lying and claiming that the company is still Sun Microsystems, and you think this isn't still news? As far as I can tell, that is an incredibly shitty work-around and the real problem still exists.

      Of course, the "real problem" isn't that Oracle changed the company field, it's that "Java programmers still continue to use poor programming practices despite layers and layers of 'best practice' crud". Seriously, isn't the great appeal of Java supposed to be that you can avoid shit like this?

      • Re: (Score:3, Funny)

        by Tim C ( 15259 )

        You mean it's possible to make poor design decisions and write shit code whatever your language/platform of choice? Say it ain't so...

  • by dugn ( 890551 ) on Wednesday July 28, 2010 @06:34PM (#33063008)
    From the guy who proposed the fix in the triage meeting, "It's only a one-line change."
  • that they'd test, it'd be Eclipse.

    • Re: (Score:3, Funny)

      by mmkkbb ( 816035 )

      Why? They can just tell everyone to use NetBeans or JDeveloper!

    • by DragonWriter ( 970822 ) on Wednesday July 28, 2010 @06:44PM (#33063120)

      You'd figure that if there were one Java app that they'd test, it'd be Eclipse.

      I wouldn't even think that that would be the Java IDE they'd be most likely to test -- I would pick NetBeans for that.

      I mean, saying that if they were going to test one app on a new Java update it would be NetBeans is like saying if Microsoft was going to test one app on a Windows update it would be iTunes.

  • by Chemisor ( 97276 ) on Wednesday July 28, 2010 @06:40PM (#33063076)

    I don't get it. Why would you design the VM to have a fixed size address space in the first place? Anybody here remember the reason? And how come there is no standard option to change that size so Eclipse has to resort to platform-specific hacks to do it? 128M ought to be enough for everybody, I guess...

    • by loubs001 ( 1126973 ) on Wednesday July 28, 2010 @06:52PM (#33063198)
      One reason... security. Prevents a unstable application from growing out of control, causing the whole system to start paging which with a GC becomes a diaster, dragging the whole system to a hault makign it unresponsive. So you set a heap size to "more than you'll ever need" so that it aborts if something goes wrong. There are technical advantages too. But still... I agree. The fixed heap limits are more of a pain than a benifit, especially when the default setting for the client JVM was 64MB until recently because it handnt been changed since around 1997.
      • Re: (Score:3, Insightful)

        by Anonymous Coward

        I don't think that's the reason. In fact, it's not a fixed size. You can specify min and max sizes for the VM. I believe the requirement is that the address space is contiguous.

    • by Chemisor ( 97276 )

      Ok, here's some research. First, there are actually two memory areas in the VM, the heap and the Permanent Generation []. It is a PermGen overflow that's causing Eclipse's problems, not heap overflow. As I understand from the linked article, PermGen is a place where VM data is stored; stuff like the class structure, method bytecodes (is that just a copy of the executable?), heap content information, etc. PermGen info used to be stored in the heap, but was moved out as a performance optimization, which incident

  • by sjames ( 1099 ) on Wednesday July 28, 2010 @06:43PM (#33063112) Homepage Journal

    Write once, run nowhere?

  • by loubs001 ( 1126973 ) on Wednesday July 28, 2010 @06:47PM (#33063148)
    To Oracle's credit, when Eclipse dev's reported the issue ( Oracle immediately reverted the change within 2 days ( They could have argued that it was Eclipse's fault for depending on the value in the first place and that rebranding their VM is something they should be allowed to do. But they put the best interest of other applications first. Still, it raises an issue that no one has really bothered with before. There are many Hostpot "vendor specific" options that are very commonly used. Almost every large application would configure heap sizes. There should be a standardized mechanism to define these options and thus avoid these very problems.
    • Re: (Score:3, Interesting)

      by h4rr4r ( 612664 )

      Oracle immediately reverted the change within 2 days

      I don't think that is what immediately means.

      • Oracle immediately reverted the change within 2 days

        I don't think that is what immediately means.

        Immediate enough that by the time it hit Slashdot it had already been fixed for several days. Official updates had been available since Monday. This is last weeks news.

        Add to that the fact that the workaround had been passed around the Eclipse within 24 hours and I'd say that Oracle did fine.

        Even the Eclipse community agrees and blames the silly hack on the Eclipse launcher not Oracle.

        • by h4rr4r ( 612664 )

          I do not disagree with any of what you said, but 2 days != immediately.

          You must be new around here though, because Slashdot is always a week or more behind.

    • Re: (Score:3, Informative)

      by davecb ( 6526 ) *

      Indeed: Oracle now employs my former Sun boss, David J. Brown, who pointed out on the order of ten (10!) years ago that one needed to distinguish between stable and unstable interfaces. He then labeled all the interfaces with the number of their standard document, and all the unstable ones SUNWprivate.

      And yes, you can ask the JVM if any of the Java interfaces are supported, so switching on the name of the company that produced them is unnecessary. The company name is neither a necessary nor a sufficient t

  • Ignoring the 'one line change', does it seem appropriate that changing a company string should cause an "Out of memory" error? I realize the OOM error happened about 8 stack frames later but I mean, seriously ?
    • Ignoring the 'one line change', does it seem appropriate that changing a company string should cause an "Out of memory" error? I realize the OOM error happened about 8 stack frames later but I mean, seriously ?

      Apparently, the VM sniffing was done to determine whether to use a particular mechanism to adjust memory settings. So, while it probably should have thrown up a "this is an unknown VM and things might not work" type of error at least the first time it encountered the unknown VM, its not entirely surpr

    • Ignoring the 'one line change', does it seem appropriate that changing a company string should cause an "Out of memory" error? I realize the OOM error happened about 8 stack frames later but I mean, seriously ?

      It was a "clever hack" is that turned out to be a bug waiting to happen. This is generally acknowledged within Eclipse. Shame on Eclipse, kudos to Oracle for bending over backwards to help a competitor.

    • by Anonymous Coward

      Read the bug. It's not the heap or the stack that is running out of memory (something that is completely within the developer's control), it's the space the VM uses internally for storing class definitions. All big apps( ie those with a lot of classes) that use Sun's VM have to configure the permanent generation space size or they hit this issue. As this configuration is vendor specific and eclipse is designed to support multiple VM vendors, the only way to tell if the custom Sun -XX option should be set is

  • Not Oracle's fault (Score:5, Insightful)

    by gig ( 78408 ) on Wednesday July 28, 2010 @07:37PM (#33063710)

    Actually, it was a great idea to change the company field since it maintained accuracy.

    The problem is the apps that were poorly coded and assumed that Java would be owned by Sun for the next thousand years. They deserved to break.

    • Re: (Score:3, Insightful)

      by C_Kode ( 102755 )

      Wrong, it should have the App and version. (Java: version#) and thats it.

      It's companies needing to attach their name to everything (marketing) that causes the problem.

      Redhat suffers from the same problem. It's why CentOS has /etc/redhat-release file. It should just be /etc/release for ALL OSes. (meaning Unix too)

      If they did that, any app would know exactly what OS they were running on without multiple checks. Easy breezy.

  • How about uname? (Score:4, Insightful)

    by KonoWatakushi ( 910213 ) on Wednesday July 28, 2010 @07:44PM (#33063786)

    Shh! Don't tell Oracle that the uname command returns SunOS, or all hell will break loose.

    The obsession with removing the Sun name from everything is petty in the extreme, to say nothing of tacking Oracle on where inappropriate, ie. Oracle Solaris. It as if Larry were a kid who felt the need to stamp his name on all of his possessions.

    • Re: (Score:3, Insightful)

      by toby ( 759 ) *

      Quite so. It's also a potential marketing error. Sun's hardware and software engineering, pre-Oracle, had one of the best reputations in the industry (even if their sales organization wasn't so highly regarded).

      McDonald's owns Chipotle, but that doesn't mean you can only buy McBurritos there, because that would likely send exactly the wrong message. Just like McDonald's, Oracle's brand has various negative connotations. Another example: Microsoft is very careful about this - for example, Xbox marketing mate

  • by suresk ( 816773 ) * <spencer.uresk@net> on Thursday July 29, 2010 @02:17AM (#33065630) Homepage

    Someone in our company ran into this several weeks ago, and I had kind of a fun time tracking down the problem. The summary and most of the comments are missing a lot of details and nuance, which actually make this problem kind of interesting.

    1) It wasn't even running out of memory

    Sun/Oracle's VM implementation (HotSpot) has a concept of a permanent generation, which is separate from the rest of the heap and has its own maximum size. This generation holds stuff like the code cache and interned strings. Whether or not this is a good concept is debatable, and as far as I know, they are planning to do away with it in the future as JRockit and HotSpot merge. At any rate, this is the space that was filling up. This probably didn't happen very quickly on a normal Eclipse distribution, but with a lot of plugins installed (and thus a lot of classes being loaded) it crashed pretty quickly.

    2) This is only because of somewhat subtle differences between the various VMs

    HotSpot is the only major JVM I know of that has a PermGen space - J9 (IBM) and JRockit (Oracle, via BEA) don't have this concept. Thus the requirement to be able to behave differently based on which VM you are using. Being able to behave properly on multiple VMs is especially important for Eclipse because not only do they have a lot of people using it on HotSpot, but because it is the basis for IBM's RAD, they have a ton of people using it on J9 as well.

    3) This problem is in the launcher, not Eclipse itself

    So, the crux of the problem is that Eclipse needs to start a VM, and has to know the proper flags to pass to it *before* it starts up. A few people have suggested trying reflection or other runtime methods as a better way to solve this, but this ignores a) Once the VM has started up, you can't change the heap or PermGen sizes, and b) As far as I know, there is no way to query the VM at runtime to figure out what its underlying heap structure looks like - that is an implementation detail.

    So, while it does kind of suck that Eclipse was relying on a vendor name, it is trickier to solve than it appears at first glance. The only really graceful ways I can think of to solve this problem rely on some changes to the VM spec.

  • from tfa (Score:4, Informative)

    by smash ( 1351 ) on Thursday July 29, 2010 @04:32AM (#33066158) Homepage Journal

    ... i know its cool to post first before reading and all but...

    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.

    So, it looks like

    • it is windows only
    • programmers should not be relying on that field
    • the change is being backed out until Java 7
  • by IGnatius T Foobar ( 4328 ) on Thursday July 29, 2010 @11:35AM (#33069778) Homepage Journal
    Quite a lot of software development tools and build scripts also broke when Richard Stallman changed the gcc target "i386-pc-linux" to "i386-pc-linux-gnu". GCC development had long since been taken over by other people but RMS just had to commit his little political agenda to the build, and broke a lot of builds in the process. Same thing here.
  • One line fix (Score:3, Informative)

    by flink ( 18449 ) on Thursday July 29, 2010 @11:51AM (#33070038)

    Launch your copy of Eclipse like so:

    "D:\Program Files\eclipse\eclipse.exe" -data %APPDATA%\"Eclipse\workspace" -vm "D:\j2sdk-1.7.0\bin\javaw.exe" -vmargs -Xms256m -Xmx1024m -XX:MaxPermSize=128m

    This will override the eclipse launcher's default set of JVM arguments with a custom set. The MaxPermSize is the issue. If the eclipse launcher can't identify the JVM, then it doesn't know to specify a larger permanent generation size for the Sun/Oracle JVM.

    To those people saying that this was a lousy design decision by the Eclipse devs:

    D:\>java -X
        -Xmixed mixed mode execution (default)
        -Xint interpreted mode execution only
        -Xshare:on require using shared class data, otherwise fail.
    The -X options are non-standard and subject to change without notice.

    Since a nonstandard switch is required at launch by the JVM, the only way to know what set of switches to pass is to query the JVM vendor string. It's not a clean solution, but it's a solution dictated by the platform.

God helps them that themselves. -- Benjamin Franklin, "Poor Richard's Almanac"