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."
Ironically... (Score:5, Insightful)
So? (Score:5, Insightful)
How is this Oracle's problem?
Comment removed (Score:5, Insightful)
Design Decisions (Score:4, Insightful)
Reminds me of some windows progs back in the day (Score:5, Insightful)
Eclipse fucked up here. (Score:4, Insightful)
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.
Re:Sounds... wrong (Score:3, Insightful)
You'd figure that if there were one Java app... (Score:2, Insightful)
that they'd test, it'd be Eclipse.
I wouldn't figure that... (Score:4, Insightful)
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.
Re:Yes and no... (Score:5, Insightful)
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.
Re:Pay for support, or else... (Score:3, Insightful)
Or just use opensource software, then you can fix it or pay someone to fix it.
Re:Yes and no... (Score:5, Insightful)
How does that technique solve the problem where a feature exists but is implemented differently?
Re:OOM? Yes Really. (Score:2, Insightful)
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 the company name. I agree with the previous commentator, this is a flaw in Java:
"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."
And I mean from within the VM too.
BTW: java -X which is suppose to give you a listing of non-standard options doesn't include all of the Sun / Oracles options so you can't even uses that...
Re:Oracle Responded Well (Score:1, Insightful)
There should be a better way indeed. Under UNIX programs like 'autoconf' are commonly used to 'probe' for capabilities of things like the OS, the compiler, the linker, the file-system, et. al. Often these probes are just automatically generating a 'test' script that *tries* to do something in a specific (vendor / API / OS / filesystem / compiler / whatever) way and runs the script in a sub-process. If it fails to build / run correctly, the conclusion is made that "oops, I guess that option isn't going to work" and it generates a run-time / build-time configuration flag "Ouch, don't do that!" for the particular option and moves on. It does that like x1000 to handle all the various permutations of possible conditions.
Considering all the methodological engineering available for doing things like "design by contract", interface definition languages, schemas, formal grammar definitions, SQL, XML, et. al. I often wonder why we're STILL resorting to such poorly specified and engineered "interface definitions" and "documentation" for things like program command line options, configuration file formats, data file formats, APIs, documentation, et. al. You don't have to look very deeply into almost any OS or major piece of software to find that at least some of these things are poorly / arbitrarily / not well specified and are just relying on ad hoc kludges for generating / parsing / using the code vs. the external dependencies of the file or configuration or documentation or whatever.
Seems like it wouldn't take much OOP / UML / SQL / IDL / whatever design to at least formally specify what inputs / outputs / interfaces your particular application provides and consumes and then be able to automatically validate those as compatible versus whatever dependency resources it has to interface with.
There's "JavaDoc" for the JAVA platform APIs themselves, but something like this implies that the actual command line or VM capabilities themselves aren't necessarily formally defined which is bizzarre.
JAVA's system.getProperties attributes can be inquired to tell you a lot about a particular runtime platform's capabilities, but obviously having to rely on ... is not sufficiently rich since then you have to hard-code things like what derivative capabilities and command interface and such depends on a given version of a given runtime environment.
java.vendor Java Runtime Environment vendor
java.vendor.url Java vendor URL
java.home Java installation directory
java.vm.specification.version Java Virtual Machine specification version
java.vm.specification.vendor Java Virtual Machine specification vendor
java.vm.specification.name Java Virtual Machine specification name
java.vm.version Java Virtual Machine implementation version
java.vm.vendor Java Virtual Machine implementation vendor
java.vm.name Java Virtual Machine implementation name
java.specification.version Java Runtime Environment specification version
java.specification.vendor Java Runtime Environment specification vendor
java.specification.name Java Runtime Environment specification name
There ought to just be a standard IDL database of what the actually available APIs or capabilities are available and then have the thing take advantage of those automatically or at least automatically check for interface / operational compatibility in a way better than "run me and see if I crash". Not very design-by-contractish.
Re:Using a company field to extract key VM info? (Score:3, Insightful)
It feels like a rock solid piece of software. Yet judging from this discussion, it has a reputation for being flaky...?
I'm pretty sure it's a case of RealPlayer syndrome.
For years and years RealPlayer earned a special corner of hatred for many sysadmins. It was a pioneer in broken crapware and users who installed it deserved to be shunned if not verbally abused. Now, years later, it doesn't matter if RealPlayer has utterly mended its ways and is the best software out there -- for many experienced administrators it remains the spawn of an infested pool of the lowest scum and has no business being installed anywhere.
Eclipse is in much the same boat. I tried using it years ago and had nothing but problems with crashing, memory usage, deleting files, etc. For those reasons and more besides I avoided it outright and advised everyone who asked to do the same. However, about a year ago, I had to use it for a huge collaborative Java project and I found, much to my surprise and delight, that it has since become a very solid and well-designed IDE. It even has some simple yet useful features I wish Visual Studio (my normal world) would copy.
So the short answer is "yes" :)
Re:Why design the VM that way? (Score:3, Insightful)
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.
Not Oracle's fault (Score:5, Insightful)
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.
How about uname? (Score:4, Insightful)
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:Using a company field to extract key VM info? (Score:3, Insightful)
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:Using a company field to extract key VM info? (Score:2, Insightful)
Re:Sounds... wrong (Score:4, Insightful)
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:Yes and no... (Score:3, Insightful)
There are still far smarter ways to code something like this. Create a function with a return type YOU can rely on and have it determine the platform specifics. Then if crap like this happens you only have to change one function and suddenly everything works again. MUCH smarter than constantly checking some browser string...
Re:Pay for support, or else... (Score:4, Insightful)
At work... I once ran into code that said
If NT or 2000, look for the DOS prompt program here...
If 95 or 98, look for the DOS prompt program here...
If XP, look for the DOS prompt program here...
Only problem is that Vista was out at the time, and it's OS string failed on all three ifs, so that led to a fail. Worse yet, this was outside of the domain that I'd be allowed to fix, and the search for who was the maintainer-of-record for this program kept coming up empty. I had to call marketing and tell them to hold off on declaring the whole system Vista-ready because we had a small programming bug and a big organizational malfunction.
Re:Using a company field to extract key VM info? (Score:3, Insightful)
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).
Re:This is why I use Open Source (Score:2, Insightful)
> Because Open Source software never breaks.
Citation needed.
Re:This is why I use Open Source (Score:3, Insightful)
Unless closed-source schmucks start mucking with it. Helloooooo. QA? Testing? ANYONE?
Re:Ironically... (Score:3, Insightful)
Oracle always claims that. They once claimed that their database was unbreakable. It broke:
http://www.schneier.com/crypto-gram-0202.html#6 [schneier.com]
Re:Not Oracle's fault (Score:3, Insightful)
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.
Re:How about uname? (Score:3, Insightful)
Yes, Oracle owns it; they bought it. You may justify it however you want, but it doesn't make it right. What Oracle is doing is dishonest; it is akin to replacing the manufacturer's label with your own.
I don't stamp my name on someone else's product even after I purchase it, and nor do most other companies after acquisitions where they continue to sell products which are clearly not of their own creation. If the company brand has recognition, it is usually kept, and if not, the changeover typically takes place with new product lines. This is clearly not appropriate for an established OS with decades of development.
Oracle is fooling no one, just making themselves look like asses.
Everyone's fault... (Score:5, Insightful)
It's true, you shouldn't detect browsers based on user-agent.
But then, the other ways aren't terribly reliable. I remember, once upon a time, trying to find "The Right Way" to deliver XHTML with an XML mime type for browsers capable of it, and as HTML for everyone else.
There isn't a right way.
The closest I got was the Accept header. The problem here is that every single browser out there sends a */*, because every browser can accept downloads. At the time, I remember one browser (can't remember which, maybe Safari) sent a */* and nothing else -- while others sent a string explicitly mentioning a few and assigning priorities to them.
The problem was, there wasn't any way for me to specify my preference on the server side, and there certainly wasn't a good way for a browser to say what it natively supports, what it can open in external programs, and what it can only download and bother the user about. All I could do is follow the browser's own preferences, and feed it whatever it ranked highest -- and even then, I'd have to prefer text/html (even though I really prefer application/xhtml+xml) for those browsers which don't specify preferring html to */*, but really don't support xhtml...
At the end of the day, my options were pretty much to either stop caring about the standards, or interpret them in a very non-standard way, or use User-Agent detection, or just give up and serve it as text/html.
And that's just getting the thing to render. It only gets messier from there...
So yes, it's my fault, as a web developer, that I might fall back on user-agent detection -- and, in particular, I'm likely to detect IE so I can work around some of its many deficiencies. It's also the fault of the standards for not defining clearer ways to negotiate capabilities. It's also the fault of browsers for not following what standards do exist.
I certainly try to avoid browser detection and focus on feature detection, as you suggest. But your blanket statement, like many blanket statements, is just wrong.
Re:What? (Score:3, Insightful)
Do you trust apt/yum/portage/whatever on your Linux/BSD distro of choice? Same thing... you trust that the developer's code-signing and key management policies are solid, and they won't dick you by releasing something really bad.
If you're not turning on automatic updates on Windows boxes (and even MacOS and Linux boxes), you might be part of the problem. Yes, you should have centralized patch review and deployment in place for all the machines you manage... but make sure it is all of them. All my company's servers and workstations have managed deployments, but I've configured Mom's laptop to get all updates ASAP straight from the vendor so I don't have to fuck with it and she remains malware-free. She hasn't had major breakage from an automatic update from any vendor in more than a decade (unless you count Adobe, whose best code is still horribly broken). There are probably 20-30 machines I "manage" informally at any given time, and I don't want to tackle patching them interactively, or deal with setting up my own WSUS or apt repository for them.
Re:How about uname? (Score:2, Insightful)
Umm.. Rebranding is pretty common in business acquisitions. There are some cases where the business case not to rebrand exists, but otherwise its very standard practice. The tech industry is full of countless examples.
It's hardly dishonest - companies are merely legal entities, the people have a stake in the company come and go. CEOs change, employees change, investors change, and so forth. The company that existed 10 years ago may still exist today but could, because of management shakeups, layoffs, employee turnovers, and 10 years worth of buying and selling on the market, be essentially a different company in many regards. Is an acquisition fundamentally different? An acquired company just goes through some legal procedures in which the management tasks, ownership, and financials are folded into the acquiring company.
Re:Yes and no... (Score:2, Insightful)
As other posters have pointed out, there are times when you need to act based on the user agent string. Similarly I can believe there is a need to read the company string of the Java VM. These things are not ideal, but they are part of the realities of programming.
No, the fault lies with having an app that crashes when there is something unexpected in those string fields. Rather, an unexpected string should cause the app to operate in a compatibility mode which will work across any browser/vm/whatever. At the very minimum it should fail with an error message indicating that it failed because it didn't recognise the particular string in question.
Re:Sounds... wrong (Score:3, Insightful)
Re:Yes and no... (Score:3, Insightful)
How does that technique solve the problem where a feature exists but is implemented differently?
From the bug reports I gather that in this specific case, the problematic checks were a workaround for other JVMs that did not implement a specific option ("-XX:MaxPermSize=256m") and did not start at all when it was used. Looks like a poor workaround to me, when we've been using installation time checks as a de facto standard for such things (i.e. GNU Autoconf) for more than a decade to avoid such issues. Eclipse could simply have tried to start the JVM with said option at installation time and if that failed, disabled the option.
Re:Pay for support, or else... (Score:3, Insightful)
You should know the number of the webbrowser "bugs" I've debugged that basically came down to:
And people are wondering we the websites dynamic menus are not working in Konqueror (or Opera for that matter). Well, see...
PS. This extremely stupid user-agent function-switching is also how most Google webapps are made (including gmail), and why many of them fail to work in konqueror unless you change useragent string :(
Re:How about uname? (Score:3, Insightful)
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 materials often carry no Microsoft branding.
Ownership certainly does not mean you must piss all over everything to mark it as yours.