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.
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".
How does that technique solve the problem where a feature exists but is implemented differently?
Boffoonery - downloadable Comedy Benefit for Bletchley Park
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.
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.
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!