Slashdot Mirror
Oracle's Java Company Change Breaks Eclipse
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."
Oracle's pet linux is branded "Unbreakable"...
How is this Oracle's problem?
Should they?
You are not alone. This is not normal. None of this is normal.
Ladies and gentlemen, I call you attention to Exhibit A for the real world consequences of poor design decisions.
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).
jaymz
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.
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.
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.
Say it right: "Nuc-le-ah Powah".
Or just use opensource software, then you can fix it or pay someone to fix it.
How does that technique solve the problem where a feature exists but is implemented differently?
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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...
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.
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" :)
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
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.
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.
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.
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.
Patent litigation: A doctrine of Mutually Assured Destruction... in which everyone seems willing to push the button
Curious statement. I've never had Eclipse crash on me during start up and almost never at any other times either. I use it almost every day -- sometimes for hours on end.
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...
Remember to maintain your supply of
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.
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).
> Because Open Source software never breaks.
Citation needed.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
Unless closed-source schmucks start mucking with it. Helloooooo. QA? Testing? ANYONE?
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.
Don't thank God, thank a doctor!
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.
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.
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.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
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 :(