×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Oracle's Java Company Change Breaks Eclipse

timothy posted more than 3 years ago | from the oopsie dept.

Bug 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

397 comments

Ironically... (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 3 years ago | (#33062854)

Oracle's pet linux is branded "Unbreakable"...

Re:Ironically... (4, Funny)

mysidia (191772) | more than 3 years ago | (#33063228)

It's true, but the first two characters are just padding.

it's const char *osname = "UnBreakable Linux" + 2;

This is why I use Open Source (1, Funny)

Anonymous Coward | more than 3 years ago | (#33063472)

Because Open Source software never breaks.

So? (5, Insightful)

Anonymous Coward | more than 3 years ago | (#33062872)

How is this Oracle's problem?

Eclipse fucked up here. (4, Insightful)

Anonymous Coward | more than 3 years ago | (#33062978)

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.

Yes and no... (5, Informative)

Zancarius (414244) | more than 3 years ago | (#33063064)

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:

This causes a severe regression for programs that need to identify the Sun/Oracle HostSpot VM such that they know whether the "-XX:MaxPermSize" argument needs to be used or not.

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.

Re:Yes and no... (5, Insightful)

beanluc (780880) | more than 3 years ago | (#33063156)

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:Yes and no... (1, Flamebait)

mysidia (191772) | more than 3 years ago | (#33063276)

So if Microsoft gets bought out by Oracle and the User-Agent string of IE6, IE7, and IE8 are immediately updated to be OIE6 7 or 8, respectively, with a surprise critical update..

You are saying it's the web developers' fault, and not Oracle's, when this poorly conceived change breaks the web and compatibility for IE users?

Re:Yes and no... (5, Informative)

XanC (644172) | more than 3 years ago | (#33063346)

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... (4, Insightful)

Chuck Chunder (21021) | more than 3 years ago | (#33063442)

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.

How does that technique solve the problem where a feature exists but is implemented differently?

Re:Yes and no... (1)

XanC (644172) | more than 3 years ago | (#33063488)

Like what?

Re:Yes and no... (1)

AaronLS (1804210) | more than 3 years ago | (#33063530)

Sometimes the lack of any other god indicator leaves you having to really on that. Imagine if you had to right some javascript that was compatible with IE and another version for Firefox and you used the agent string to determine which code to run. Easy enough. Now imagine a hypothetical world where the agent string doesn't exist and you instead have to use some other identifier like the company name. As a developer you would probably know it was bad to depend on the company name field, but it might be the best you've got.

Pay for support, or else... (0, Offtopic)

LostCluster (625375) | more than 3 years ago | (#33062878)

This is a critical flaw in the "pay once, own forever" software model. If the company that supplied your app uses this field, assumes it'll never change, and then goes out of business or move on to different products, you're in big trouble right now. You've got to pay for support, or your vendor might not be there when you need them in a situation like this.

Re:Pay for support, or else... (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33063090)

Java and Eclipse are free, open source, software you fucking retard.

Re:Pay for support, or else... (1)

timepilot (116247) | more than 3 years ago | (#33063244)

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."

Re:Pay for support, or else... (2, Insightful)

h4rr4r (612664) | more than 3 years ago | (#33063170)

Or just use opensource software, then you can fix it or pay someone to fix it.

Re:Pay for support, or else... (1)

LostCluster (625375) | more than 3 years ago | (#33063600)

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.

Re:Pay for support, or else... (0)

Anonymous Coward | more than 3 years ago | (#33063216)

And then... you'd have to use an old version of the platform? Horrors! I'm astonished by this completely new and unexpected development: that legacy apps need legacy platforms.

may windwos apps are stuck in the 9x system with (1)

Joe The Dragon (967727) | more than 3 years ago | (#33063290)

may windows apps are stuck in the 9x system with witting to there own folder and little to no per user stuff.

Sounds... wrong (4, Insightful)

squiggleslash (241428) | more than 3 years ago | (#33062882)

Apparently not the best idea, because some applications depend on that field to identify the virtual machine

Should they?

Re:Sounds... wrong (4, Informative)

LostCluster (625375) | more than 3 years ago | (#33062924)

If you're using Sun/Oracle-specific commands, you don't want to find your app running in an unofficial or unsupported Java such as Microsoft's that was eventually recalled.

Re:Sounds... wrong (3, Insightful)

jisatsusha (755173) | more than 3 years ago | (#33063012)

Isn't this exactly the sort of thing that reflection is designed for? As an analogy, it's like looking specifically for "Microsoft Internet Explorer" when writing web pages, instead of checking if document.addEventListener is available. It's flakey and easy to break when the platform gets updated.

Re:Sounds... wrong (1)

WarJolt (990309) | more than 3 years ago | (#33062976)

Bad assumptions cause almost all programing errors. Unless documented not to change you must assume that value always can.

Maybe. (1)

Zancarius (414244) | more than 3 years ago | (#33062980)

Should they?

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.

Re:Sounds... wrong (2)

petermgreen (876956) | more than 3 years ago | (#33063564)

Should they?
Sometimes different implementations of a "standard" behave differently, sometimes that is because of a bug, sometimes it's because of an ambiguous specification in the standard. Sometimes it's because of something beyond the scope of the standard (e.g. suns VM needs to be told how much memory it's allowed to use upfront or memory hungry applications will fail).

When this happens you have to identify what you are running on so you can tailor your apps behaviour to that of the implementation it is running on.

Would another field have been better? possibly but when the documenation doesn't provide any info on what fields should and shouldn't be used for such purposed

Re:Sounds... wrong (1, Interesting)

Anonymous Coward | more than 3 years ago | (#33063578)

Even Microsoft learned this lesson [windowsteamblog.com] ;

That brings us to Windows Vista, which is 6.0. So we see Windows 7 as our next logical significant release and 7th in the family of Windows releases.

We learned a lot about using 5.1 for XP and how that helped developers with version checking for API compatibility. We also had the lesson reinforced when we applied the version number in the Windows Vista code as Windows 6.0-- that changing basic version numbers can cause application compatibility issues.

That was back in 2008.

Problem? (0)

Anonymous Coward | more than 3 years ago | (#33062894)

Sounds normal to me.

Well that's it... (3, Funny)

mandelbr0t (1015855) | more than 3 years ago | (#33062902)

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. :(

Re:Well that's it... (4, Funny)

copponex (13876) | more than 3 years ago | (#33063164)

I am beating myself over the head... There is not a single programming culture left that I can identify with. :(

If you're into a self-harm, you should check out Java.

Re:Well that's it... (1)

Eudial (590661) | more than 3 years ago | (#33063376)

I thought that was what COBOL was for.

Re:Well that's it... (0)

Anonymous Coward | more than 3 years ago | (#33063620)

May I introduce you to INTERCAL?

Re:Well that's it... (0)

Anonymous Coward | more than 3 years ago | (#33063622)

The end of the sentence is not where the preposition goes at.

Re:Well that's it... (1, Interesting)

Anonymous Coward | more than 3 years ago | (#33063522)

No, JAVA is definitely for harming your customers. In a company like ours with 90,000 desktops/notebooks, every Sun/Oracle Java update breaks applications. Most of the time it is something stupid the developers of the app did. Sometimes it is something stupid Sun/Oracle did (for example 1.6_11 worked fine with pass-thru authenticated proxy servers using auto-proxy detect, but versions after that (up until it was fixed in 1.6_21) were borked. Unfortunately all of those interim versions were critical security updates. So we had some vendor apps that needed say 1.6_16 or better, but we couldn't load that because it didn't WORK. We also had to leave the security holes because otherwise we had a business incident where apps didn't work.

Again, most of the time it is the developers of the apps who screw it up - they only work with one or two versions and when a security update to Java comes out their app won't work with it for months. Don't code in Java for the desktop unless you hate your customers (and want them to find a different vendor that doesn't use Java).

Design Decisions (4, Insightful)

Subliminalbits (998434) | more than 3 years ago | (#33062906)

Ladies and gentlemen, I call you attention to Exhibit A for the real world consequences of poor design decisions.

Re:Design Decisions (0)

Anonymous Coward | more than 3 years ago | (#33063062)

Ladies and gentlemen, I call you attention to Exhibit A for the real world consequences of poor design decisions.

You forgot the link to Exhibit A [slashdot.org]

(hey, I say that with great affection etc. but still...)

Re:Design Decisions (0)

Anonymous Coward | more than 3 years ago | (#33063126)

By the Eclipse Foundation or by Sun?

It's an assumption in a workaround for a bug that causes an out of memory crash.

Re:Design Decisions (0)

Anonymous Coward | more than 3 years ago | (#33063132)

Ladies and gentlemen, I call you attention to Exhibit A for the real world consequences of poor design decisions.

I agree and in any case, "Exhibit A" is a much more suitable name than "Java". Write once, crash anywhere.

Using a company field to extract key VM info? (5, Informative)

kaladorn (514293) | more than 3 years ago | (#33062930)

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.

Re:Using a company field to extract key VM info? (5, Funny)

0123456 (636235) | more than 3 years ago | (#33062998)

Mind you, it isn't their fault as such, but pissing off all of those using Eclipse is mightily retarded.

I can't help but feel that most Eclipse users won't notice one more source of random crashes on startup.

Re:Using a company field to extract key VM info? (1)

indre1 (1422435) | more than 3 years ago | (#33063102)

And I thought my computer was going crazy with Eclipse crashing every 30 minutes.

Re:Using a company field to extract key VM info? (0)

Andy Smith (55346) | more than 3 years ago | (#33063300)

Hmm. I'm using Eclipse on Windows, for Android development, and have been using it solidly for the past three months. It hasn't crashed once. It feels like a rock solid piece of software. Yet judging from this discussion, it has a reputation for being flaky...?

Re:Using a company field to extract key VM info? (1)

0123456 (636235) | more than 3 years ago | (#33063402)

Yet judging from this discussion, it has a reputation for being flaky...?

For me it usually crashes at least every couple of days or becomes so screwy that I have to exit and restart. And it's often refused to start up at all until I just deleted the old workspace and recreated it.

Certainly one of the most buggy programs I use on a regular basis.

Re:Using a company field to extract key VM info? (0)

Anonymous Coward | more than 3 years ago | (#33063584)

YMMV. This seems like you are A) leaving Eclipse running for very long periods of time B) don't say anything about the plugins you use.

Myself, I shut down my computer at work every day, when I leave. My co-worker leaves his computer running constantly. I have no particular problems with Eclipse, except for some issues directly related to some plugins I use. E.g. Hibernate tools were unusable as a dev tool, because of a large time out when running queries. Spring IDE for quite some time cause major delays etc. But these are all specific plugin's faults, which are not part of Eclipse itself.

It's like saying Linux is very flaky and constantly crashes, because my graphics driver causes regular lockups (which btw. was true for a very long time on my work machine until they finally fixed it).

Re:Using a company field to extract key VM info? (1)

Chyeld (713439) | more than 3 years ago | (#33063420)

Santa Claus! I've found Santa Claus!

Everyone! Look! It's Santa Claus!

I told them you existed, I really really did. Can I have a pony?

Re:Using a company field to extract key VM info? (2, Insightful)

nmb3000 (741169) | more than 3 years ago | (#33063560)

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:Using a company field to extract key VM info? (1)

allcoolnameswheretak (1102727) | more than 3 years ago | (#33063286)

Poor planning, perhaps. But I wonder what the deal is with Oracle being so over-eager to plaster their company name all over the place. Wherever you go, java.com, java.sun.com, javadocs, the "ORACLE" Logo is everywhere and this happened only a week or two after the takeover.

Re:Using a company field to extract key VM info? (1)

Nephilium (684559) | more than 3 years ago | (#33063494)

Don't forget the new splash screen on OpenOffice.org, including the reversion to the really old icons.

Nephilium

Wrong title. (1)

CannonballHead (842625) | more than 3 years ago | (#33062940)

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 :) )

Reminds me of some windows progs back in the day (4, Insightful)

jaymz2k4 (790806) | more than 3 years ago | (#33062956)

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).

Re:Reminds me of some windows progs back in the da (1)

LostCluster (625375) | more than 3 years ago | (#33062996)

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.

Re:Reminds me of some windows progs back in the da (1)

jonbryce (703250) | more than 3 years ago | (#33063060)

Something along the lines of looking in %windir% rather than c:\windows. Not really that difficult.

Clearly... (3, Funny)

by (1706743) (1706744) | more than 3 years ago | (#33062972)

Eclipse wasn't built leveraging the doWhatIWant() [slashdot.org] function (not to mention doItFaster(doWhatIWant())).

Tangentially related, what does the following do:

doItRecursively(doWhatIWant()) { return doItRecursively(doItFaster(doWhatIWant()); }

I'm guessing it does it instantaneously...or never.

IT'S ALREADY FIXED!! (4, Informative)

Anonymous Coward | more than 3 years ago | (#33062988)

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.

Re:IT'S ALREADY FIXED!! (0)

Anonymous Coward | more than 3 years ago | (#33063146)

No, this one was posted by the hapless Timmeh...

Re:IT'S ALREADY FIXED!! (4, Interesting)

Sir_Lewk (967686) | more than 3 years ago | (#33063326)

Their fix was lying and claiming that the company is still Sun Microsystems, and you think this isn't still news? As far as I can tell, that is an incredibly shitty work-around and the real problem still exists.

Of course, the "real problem" isn't that Oracle changed the company field, it's that "Java programmers still continue to use poor programming practices despite layers and layers of 'best practice' crud". Seriously, isn't the great appeal of Java supposed to be that you can avoid shit like this?

Re:IT'S ALREADY FIXED!! (0)

Anonymous Coward | more than 3 years ago | (#33063454)

No, no, no -- it's not about that, the thread is a demonstration of how little /. posters know about Java, and how much they want to share it.

Developers Developers Developers (4, Funny)

dugn (890551) | more than 3 years ago | (#33063008)

From the guy who proposed the fix in the triage meeting, "It's only a one-line change."

You'd figure that if there were one Java app... (1, Insightful)

dominator (61418) | more than 3 years ago | (#33063028)

that they'd test, it'd be Eclipse.

Re:You'd figure that if there were one Java app... (2, Funny)

mmkkbb (816035) | more than 3 years ago | (#33063092)

Why? They can just tell everyone to use NetBeans or JDeveloper!

I wouldn't figure that... (3, Insightful)

DragonWriter (970822) | more than 3 years ago | (#33063120)

You'd figure that if there were one Java app 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.

Ouch (0)

Anonymous Coward | more than 3 years ago | (#33063032)

Oracle, why didn't you just operate Sun as a subsidiary and brand instead of trying to merge it all in?

Re:Ouch (1)

Zancarius (414244) | more than 3 years ago | (#33063192)

Oracle, why didn't you just operate Sun as a subsidiary and brand instead of trying to merge it all in?

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 [wikipedia.org] . 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).

Re:Ouch (1)

mysidia (191772) | more than 3 years ago | (#33063520)

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.

Then Eclipse Was Already Broken (0)

Anonymous Coward | more than 3 years ago | (#33063066)

If this "broke" Eclipse, than it was already broken. Running out of memory because a string is not as expected?

Why design the VM that way? (3, Interesting)

Chemisor (97276) | more than 3 years ago | (#33063076)

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...

Re:Why design the VM that way? (5, Informative)

loubs001 (1126973) | more than 3 years ago | (#33063198)

One reason... security. Prevents a unstable application from growing out of control, causing the whole system to start paging which with a GC becomes a diaster, dragging the whole system to a hault makign it unresponsive. So you set a heap size to "more than you'll ever need" so that it aborts if something goes wrong. There are technical advantages too. But still... I agree. The fixed heap limits are more of a pain than a benifit, especially when the default setting for the client JVM was 64MB until recently because it handnt been changed since around 1997.

Re:Why design the VM that way? (1)

Chemisor (97276) | more than 3 years ago | (#33063582)

Ok, here's some research. First, there are actually two memory areas in the VM, the heap and the Permanent Generation [sun.com] . It is a PermGen overflow that's causing Eclipse's problems, not heap overflow. As I understand from the linked article, PermGen is a place where VM data is stored; stuff like the class structure, method bytecodes (is that just a copy of the executable?), heap content information, etc. PermGen info used to be stored in the heap, but was moved out as a performance optimization, which incidentally is no longer relevant. I'm still not quite clear why PermGen has a fixed size. Evidently there are quite a few applications out there that routinely overrun PermGen and have to increase it. The cause seems to be people writing custom classloaders [javalobby.org] that bypass the "class already loaded" optimization, which I suppose makes sense for Eclipse where you keep modifying the class all the time and want to keep reloading it into the VM for testing. Apparently it is possible to write them in such a way that the resultant class metadata "leaks", resulting in overflow. Now, I think I'll just take a small break laughing my ass off at how those poor Java kids need 256M just to store their class definitions. I say, collect your garbage off my lawn and learn C++ already! It seems your fancy Java doesn't absolve you from the need to learn memory management after all :)

If Slashdot was changed to DotSlash (0)

Anonymous Coward | more than 3 years ago | (#33063104)

A lot of nerds would be broken too.

Also Goatse is now kown as the Oracle of the Open Anus.

Write once huh? (4, Funny)

sjames (1099) | more than 3 years ago | (#33063112)

Write once, run nowhere?

Fucking Retard (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#33063134)

Wow dude! You are fucking hilarious. Got any good BSOD jokes dipshit?

Re:Fucking Retard (3, Funny)

sjames (1099) | more than 3 years ago | (#33063248)

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?

Oracle Responded Well (5, Informative)

loubs001 (1126973) | more than 3 years ago | (#33063148)

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.

Re:Oracle Responded Well (2, Interesting)

h4rr4r (612664) | more than 3 years ago | (#33063202)

Oracle immediately reverted the change within 2 days

I don't think that is what immediately means.

Re:Oracle Responded Well (1)

H0p313ss (811249) | more than 3 years ago | (#33063392)

Oracle immediately reverted the change within 2 days

I don't think that is what immediately means.

Immediate enough that by the time it hit Slashdot it had already been fixed for several days. Official updates had been available since Monday. This is last weeks news.

Add to that the fact that the workaround had been passed around the Eclipse within 24 hours and I'd say that Oracle did fine.

Even the Eclipse community agrees and blames the silly hack on the Eclipse launcher not Oracle.

Re:Oracle Responded Well (1)

h4rr4r (612664) | more than 3 years ago | (#33063452)

I do not disagree with any of what you said, but 2 days != immediately.

You must be new around here though, because Slashdot is always a week or more behind.

Re:Oracle Responded Well (0)

Anonymous Coward | more than 3 years ago | (#33063592)

I do not disagree with any of what you said, but 2 days != immediately.

You must be new around here though, because Slashdot is always a week or more behind.

Sounds like you are saying something that would conveniently fit into a damned if you do (QA), damned if you don't (QA) statement. 2 days is a pretty fast turn around, for a company as large as Oracle, or pretty much any shop for that matter.

Oracle +1 (0, Offtopic)

nurb432 (527695) | more than 3 years ago | (#33063296)

Oracle doing the right thing for the right reason, AND getting credit for it.. Who would have imagined?

Was that a pig i just saw fly by my window?

Re:Oracle Responded Well (1)

kcitren (72383) | more than 3 years ago | (#33063406)

Oracle immediately reverted the change within 2 days

Immediately? or 2 days?

Re:Oracle Responded Well (1, Insightful)

Anonymous Coward | more than 3 years ago | (#33063526)

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
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 ... 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.
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:Oracle Responded Well (1)

ShakaUVM (157947) | more than 3 years ago | (#33063616)

There should be a better way, indeed. I used to work doing Java development.

Java was built with the braindead/naive idea that it would run equally on all platforms. So when we found that the implementation on some obscure platform had a bug, we couldn't just #define a way around it like you can in C. Therefore you have to use more hackish tricks like these.

If you really want to horrify Java coders, think about what would happen if all the com.sun libraries got renamed to com.oracle. =) =)

OOM? (1)

nblender (741424) | more than 3 years ago | (#33063182)

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 ?

Re:OOM? (1)

DragonWriter (970822) | more than 3 years ago | (#33063380)

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 ?

Apparently, the VM sniffing was done to determine whether to use a particular mechanism to adjust memory settings. So, while it probably should have thrown up a "this is an unknown VM and things might not work" type of error at least the first time it encountered the unknown VM, its not entirely surprising that on an VM that it didn't know how to handle it ended up getting a memory-related error.

Re:OOM? (1)

H0p313ss (811249) | more than 3 years ago | (#33063426)

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 ?

It was a "clever hack" is that turned out to be a bug waiting to happen. This is generally acknowledged within Eclipse. Shame on Eclipse, kudos to Oracle for bending over backwards to help a competitor.

Re:OOM? Yes Really. (2, Insightful)

Anonymous Coward | more than 3 years ago | (#33063450)

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...

Why check for vendor? (1)

ilsaloving (1534307) | more than 3 years ago | (#33063266)

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?

Re:Why check for vendor? (1, Interesting)

Anonymous Coward | more than 3 years ago | (#33063424)

Because the Sun VM has a bug in it that eclipse works around if it can detect that it's indeed the Sun VM. Nothing to do with library support (and the existence of "sun.*" classes wouldn't help since most everyone else implements those too)

Better approach? (0)

istartedi (132515) | more than 3 years ago | (#33063476)

It's understandable that they might not want to run on just anybody's Java. For that matter, they might have only tested on a particular version. I haven't looked into it, but it seems likely there's a standard API to check Java's version. It seems like the proper way to address this is to pop up something that says, "This is Java vX.Y from company Foo, we haven't tested with it so it may not work. Conntinue? (button) Do not show this dialog again (checkbox)".

Plainly, whatever they did that caused an "out of memory" error was quite a goof.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...