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."
Re:Sounds... wrong (Score:5, Informative)
Using a company field to extract key VM info? (Score:5, Informative)
IT'S ALREADY FIXED!! (Score:4, Informative)
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.
Yes and no... (Score:5, Informative)
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:
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.
Oracle Responded Well (Score:5, Informative)
Re:Why design the VM that way? (Score:5, Informative)
Re:Yes and no... (Score:5, Informative)
Yes. It is. You shouldn't detect whether you can use a feature based on the User Agent, you should detect based on the presence or absence of that feature. Anything other than that is absolutely the web developers' fault.
Re:Yes and no... (Score:5, Informative)
The FBR states that this is a file attribute only present under Windows, which seems like an odd choice by the Eclipse developers:
"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.
Posted Date : 2010-07-22 15:50:53.0"
Re:Yes and no... (Score:4, Informative)
While there certainly are cases where you have to identify whether a user is on IE, particularly IE6, your example is less than spectacular since the very link you provided is an explanation of how to handle margins without having to detect the User Agent.
Re:Then Eclipse Was Already Broken (Score:2, Informative)
Not exactly
The trouble is due to the way suns GC is designed it essentially needs to work with a limited size pool of memory. Make the pool too big and you end up with a machine that swaps instead of garbage collecting when memory gets tight under high load and/or a java app unnessacerally hogging memory other apps need. Make it too small and you get out of memory errors.
Bloatware like eclipse needs the pool set large than the default, so there is code that sets that if it sees a VM that it thinks needs it setting. The trouble is the change to the vendor string meant that the VM was no longer being identified as one that needed it.
That's my understanding of the issue anyway.
Re:Well that's it... (Score:5, Informative)
Didn't you hear, Java is the new COBOL
Re:Oracle Responded Well (Score:3, Informative)
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 test for anything. For those kinds of tests you use this reflective thingie they invented...
--dave
Re:Pay for support, or else... (Score:4, Informative)
Re:Yes and no... (Score:3, Informative)
Why is a virtual machine being run with a heap size limit by default anyway?
Because the developers are too lazy to read the documentation. I don't know how many Java developers I have had complain about slow performance. Show them how to launch a jvm not using default values, point out the information in the docs, and suddenly I am a genius. Had a whole project group ask for 16 J2EE servers because they used the default heap size; and the web apps were abysmally slow.
I'd publish a FAQ; but developers would never read it.
Re:Better approach? (Score:3, Informative)
Of course we don't live in a perfect world. C and C++ never promised "write once, run everywhere". Java did. That's why it's flawed.
Really? That's the big flaw? Java works quite well cross platform, thank you. Please try again and find some real flaws rather than the illusory ones people tried to pin on it 10 years ago.
They would have accomplished roughly the same thing, in a much more straightforward way. Instead they gave us C++ with a GC, a little different syntax, and then evolved it from there. I was, and continue to be, unimpressed.
Some of us actually think not having to manage resources like memory on an active basis to be an advantage. Fine if you don't, but snide remarks don't really impress me. Java most certainly has flaws, but you have to actually know the language and work with it to identify them, not just take a couple pot shots from comments you've heard from others.
Re:Using a company field to extract key VM info? (Score:3, Informative)
A somewhat complex and interesting problem (Score:5, Informative)
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.
Re:Sounds... wrong (Score:1, Informative)
Read the article! IT IS NOT A JAVA PROPERTY. It is a property of the Win32 EXE file. Eclipse' PLATFORM SPECIFIC LAUNCHER checked the setting of a PLATFORM SPECIFIC PROPERTY of a PLATFORM SPECIFIC EXECUTABLE FILE. I hate all caps. But you have to read the article.
Re:Sounds... wrong (Score:2, Informative)
I hate all caps.
Then use bold.
Re:Using a company field to extract key VM info? (Score:2, Informative)
Added to that - some of the plugins used by Eclipse are not always up to scratch. I've installed various plugins over the years that basically broke my Eclipse, with the only option to de-install the plugin (and sometimes re-install Eclipse).
Vanilla Eclipse has always been rock solid in my experience, ever since version 2 at least when I started using it. And I believe they have done a lot of work in the later releases to lessen the plugin-hell.
from tfa (Score:4, Informative)
So, it looks like
Re:Yes and no... (Score:3, Informative)
Not really. Compilers are probably better at deciding what should go in registers than programmers are. But programmers are probably better at releasing garbage promptly than garbage collectors. So manual memory management will generally need less memory than GCs.
This is why Obj-C now has optional garbage collection for Mac programming, but it's not allowed for iPhone programming.
Re:Yes and no... (Score:1, Informative)
>seems like an odd choice by the Eclipse developers
Maybe it's because they need to determine what startup parameters to pass to the VM, and you have to know those things BEFORE you start the VM. If you check vm values after you start up, it's a little late.
One line fix (Score:3, Informative)
Launch your copy of Eclipse like so:
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:
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.
Re:Yes and no... (Score:3, Informative)
According to docs, MaxPermSize is "Size of the Permanent Generation". So... Why does Eclipse care about this? In my experience needing any of the XX options to work, as opposed to Xmx (which sets the maximum memory the VM will allocate), is a sign of the program breaking Java Memory Model - in other words, a (stupid) bug.