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.
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. :(
"Please describe the scientific nature of the 'whammy'" - Agent Scully
Ladies and gentlemen, I call you attention to Exhibit A for the real world consequences of poor design decisions.
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.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
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).
jaymz
Tangentially related, what does the following do:
doItRecursively(doWhatIWant()) { return doItRecursively(doItFaster(doWhatIWant()); }
I'm guessing it does it instantaneously...or never.
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 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.
He who has no
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.
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.
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.
Something along the lines of looking in %windir% rather than c:\windows. Not really that difficult.
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.
He who has no
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...
Write once, run nowhere?
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.
To Oracle's credit, when Eclipse dev's reported the issue (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236) Oracle immediately reverted the change within 2 days (http://hg.openjdk.java.net/hsx/hsx17/baseline/annotate/1771222afd14/make/hotspot_distro). 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.
Or just use opensource software, then you can fix it or pay someone to fix it.
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 ?
That's actually not a bad idea, and I'm surprised they didn't do this. Well, mostly, but it does depend on how, exactly the other company was involved in the merger/acquisition. I wouldn't be too surprised if in a few years, Oracle spins off Sun as a wholly-own Subsidiary. But don't expect much; it's worth more to Oracle to be able to put their company logo on machines sitting in your data center. Free advertising is a powerful thing.
On the other hand, it might not be such a bad idea for established IP like Java, and maybe not retaining some of the Sun branding is more damaging (dependencies notwithstanding).
He who has no
Yeah but #33063012
Say it right: "Nuc-le-ah Powah".
People actually trust automatic updates? I have to admit I find that rather humorous...
For justice, we must go to Don Corleone
The gp didn't say that this was a problem for Java or Eclipse. He/She just said it was a problem for "pay once, own forever."
GP might have been saying "it's a good thing in this case, otherwise everyone would have been screwed."
Look again, I most certainly am NOT fucking you!
Lemme guess, you're sweating bullets wondering if you're going to spend all night pissing on fires while the C guys laugh at you and drink beer?
I'm having trouble understanding why someone would code an application in a widely implemented language like Java, yet check for the vendor of the VM. It would make more sense to check availability of specific libraries or what have you, wouldn't it?
I don't program and even I know better than that. Sheesh.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
may windows apps are stuck in the 9x system with witting to there own folder and little to no per user stuff.
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...
Because Open Source software never breaks.
I like that approach. Then I can forget about who I was supposed to blame!
He who has no
No they're not. After the fiasco regarding blocking access to firmware updates for Sun servers on the new site we stopped considering using any more Sun/Oracle products for new deployments.
Of course old equipment is still badged with the Sun name. Whatever Oracle's doing is getting the opposite of advertising.
Running away from them as fast as possible.
Open source lets the community fix these breaking bugs only if there's still a community left for the project, and hiring a developer to fix is one way to say "paying for support"... basically, be nice to the developers and they'll be there for you. Let them move on and you've got no support left.
LOL, I used to have windows on my D: drive (in d:\winnt), and my C: drive was my CD-ROM.
i can't tell you how many times my CD tray would open followed shortly by some poorly written piece of crap crashing.
"hiring a developer to fix is one way to say "paying for support"..."
True, but incomplete.
In open source world, hiring a developer to fix is one way to say "paying for support", one that stands by the free market laws. On the other hand, in closed source world, you are tied to monopolistic service. I know what I'd choose, and you?
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.
Indeed. Lots of applications have gone the way of the dinosaurs when it probably would have been a few tweaks of some sourcecode to bring it back to life.
This is the kind of problem that has plagued legacy applications on the Windows platform. I'm not pointing fingers at MS or any vendor, just making the observation that as MS has changed and tightened the security model you see droves of applications that are made incompatible or become buggy in the context of these unexpected conditions.
For example, it was common practice that you would write your app to always request full read/write permissions to the registry even if you only needed to read the registry. No one thought in terms of privileged/unprivileged accounts and so no one put effort into thinking about granular requests for resources. A couple Windows versions later, that application is being under a user account without write permissions to that registry entry, and suddenly all those applications would crash in light of the new access denied exceptions that never occurred during testing/development years before.
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.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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's understandable that they might not want to run on just anybody's Java.
That's not the issue at all. Identifying the jvm vendor is simply a means to identify if the permgen size should be set, which is a vendor specific setting. Eclipse requires a large permgen space on the sun JVM. When this didn't get set it ran out of permgen memory, and thus the error.
I haven't looked into it, but it seems likely there's a standard API to check Java's version.
Given that Eclipse operates in this odd way, my guess is there's no standard API to check. I do agree it's a stupid workaround though.
AccountKiller
there are other possibilities...some one fixes the open source version and publishes the fix. been known to happen.
I wouldn't call it a bug as much as a poor design choice by a programmer that didn't understand how to code it properly. If you really need to know where the command interpreter is, use the %comspec% environment variable.
Another day, another update to a Google android app.
Let's see... you can download the JDK for free... which by definition is a 'development kit'. You can obtain a java editor at no cost. You can obtain a java IDE and debugger at no cost. Where do you get the impression that the development tools for Java require licensing, exactly?
File under 'M' for 'Manic ranting'
Don't forget the NEC PC-98 that put hard drives on A: and B:.
Yep, that was the proper solution... just the hard part was finding out who is allowed to touch that code. The original programmer should have realized Microsoft releases new OSes every 2-4 years so a complete list of today's supported OSes would be outdated quickly.
Yet another reason why intertwining the physical and logical arrangement of storage was a dumb idea. Microsoft really needs to ditch the whole "drive letter" concept and move to a single file system tree a la unix.
Monstar L
That's not the issue at all. Identifying the jvm vendor is simply a means to identify if the permgen size should be set, which is a vendor specific setting
Ahhh... so what Java really needs is something like #ifdef, so you can work around--Hey! Waaaaait a second. Wasn't it supposed to eliminate that?
Heheh. All this time, and I'm still glad I'm not a Java developer.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
A Vista-ready application? Couldn't you just delay marketing for a while and aim for Windows 7?
Every mans' island needs an ocean; choose your ocean carefully.
Ahhh... so what Java really needs is something like #ifdef, so you can work around-
Not really. It's a runtime configuration. It's something you can just set via command line and distribute the JVM packaged along with your product.
Heheh. All this time, and I'm still glad I'm not a Java developer.
We don't live in a perfect world. I'm sure I could point out several flaws of whatever language you personally choose. The permgen issue has existed for years, but it's relatively minor. If you're going to pick something to complain about in Java, at least pick something that's a real issue.
AccountKiller
640 letters otta be good enough for anyone
-Gill Bates
Table-ized A.I.
I don't know whether to call you sadist, masochist, psychotic, or just truly adventurous.
Every mans' island needs an ocean; choose your ocean carefully.
Yes, Microsoft should license Veritas technology and add another layer of abstraction into the whole operating system function.
Every mans' island needs an ocean; choose your ocean carefully.
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, I wouldn't have any problem with Java if they had simply done what would have made sense: Run C++ in a virtual machine. In other words, the MS approach minus the new C# language. 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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
You're moving the goalposts of your position. You had originally said that you have to license the development tools... which would imply that to do any Java development required licensing. Then you proceed to talk about not being able to distribute the JDK, which is something wholly different.
File under 'M' for 'Manic ranting'
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.
AccountKiller
It had been a while since I got into this kind of thing on /., or anywhere on the Internet.
I recognize it as the social equivalent of an anti-pattern,
and went for a short walk. I feel much better now.
Good-night.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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!
1. OpenJDK is GPL'd, so I don't know where you get that. And both Sun and openjdk are available via Ubuntu's package manager.
2. So what?
3. You clearly don't understand why Oracle cares about Java. It's not about the compiler any more than Microsoft Visual Studio is about the compiler. It's about all the other shit Oracle has that runs on Java -- here's an example. I don't particularly like these products (having been forced to work with Oracle ADF over the summer), but they all cost large amounts of money, and they all run on Java.
Given that, Oracle needs Java to work. And given that, open source or not, they need key Java people.
Don't thank God, thank a doctor!
Microsoft really needs to ditch the whole "drive letter" concept and move to a single file system tree a la unix.
Windows has had "proper" mount point technology since Windows 2000. DOS has "subst" (path as drive) and assign (drive as path.) NT4 has "subst" but not "assign".
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
Its not a proper mount point, its almost a proper mount point, a lot of bugs appear if you use it, atleast in XP and win2003.
Yes. not to mention some (many, a lot) developers assuming the OS is installed in English and all the directory names are in the same language. I've had my share of problems between "C:\Program Files" and "C:\Archivos de Programa"... to give an example.
Java isn't totally free. The runtime is free, but development tools require licensing...
Runtime used to be free, now it's also free software. "Development tools" is a bit of a nebulous term. The JDK (Java compiler and support tools) used to be free, now it's also free software. Various other third-party development tools used to have varying licences, but nowadays you can get full-blown IDEs (Eclipse and NetBeans) under open source licences - failing that, Emacs never went anywhere. Some rather integral third-party components of Java development, like Ant and JUnit, have always come from open source world.
Microsoft learned that one the hard way when they violated their agreement with Sun.
That agreement was about Java syntax. Microsoft decided that Java wasn't good enough for them and made an incompatible dialect of Java.
If you want to make a new programming language that compiles to JVM bytecode, that's perfectly okay and everyone is already doing that. Microsoft just decided to call their distinctly non-Java language "Java".
You could use similar facts to say .NET is free....
Except the .NET folks still haven't made the tiny little doubt about patent provisions to go away.
So, it looks like
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Paying the company for support doesn't mean they won't go out of business.
When my Sun VirtualBox application asked me to upgrade recently to version 3.2.6, I thought nothing of it; sure, always good to stay up to date, right? It proceeded without a hitch, although the only difference seemed to be that the branding had been changed from "Sun Microsystems Inc." to "Oracle" along with some corporate artwork. Was that all? Apparently not. Afterwards, several Linux distros refused to install as virtual machines: somewhere half-way, the process would report a generic failure. Strange, because I had installed the same distros many times before (at least the older VMs I had of them were still working). So, suspecting a bug, I downgraded back to v3.1.8 r61349 and the problem vanished. Pretty weird for what's ostensibly just a cosmetic change. At any rate, I feel this does not bode well for the future of VirtualBox and I've already been looking into the alternatives; perhaps something a little less dependent on some corporate overlord will be a safer choice.
Your OS might not. Mine does.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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 :(
Its not a proper mount point, its almost a proper mount point, a lot of bugs appear if you use it, atleast in XP and win2003.
Bugs in the OS, or bugs in incorrectly written applications?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Same thing happend to me, it was giving spacegen , outofmemory error all of a sudden and eclipse would crash.... I almost wasted 4hrs to find out the problem..
Yes.
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.
Tired of FB/Google censorship? Visit UNCENSORED!
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.
Try writing some high level code in C, then some equivalent code in Java.
Run the results.
Notice which one is faster, and which one was easier to write, is easier to read, and will be easier to maintain. Hint: it will be the same one in both cases.
This is typical of Oracle's acquisitions. Not only do they rewrite licensing agreements, they have to go an re-brand all the code. We are running lots of Tangosol Coherence instances. When Oracle bought Tangosol out, we had to change the way we deploy nodes to avoid blowing our costs up. Oracle loves node/cpu licensing.
Actually, it's a matter of choosing the right tool for the job. In systems programming, C (and to a lesser extent C++) rule supreme, and that's as it should be. Application programmers are free to choose Java if they so desire, or if they are forced to by existing frameworks. Personally, I'm a huge fan of C and C++, but I'm not afraid to touch Java code every now and then... if absolutely necessary, that is.
cpghost at Cordula's Web.
Ever tried OCFS2? Oracle deserves to be shot just for that.
The easiest (though certainly not the most elegant) way to get this to work is to have both drives formatted as NTFS then set 'D:' to mount to C:\Program Files (you can do this via Disk Management in the MMC)
Most human behaviour can be explained in terms of identity.
Very interesting. In that case, it's almost humorous, is it not? (Well, not for your needs, I realize, but the general notion that they're doing more to damage their reputation certainly is!)
He who has no