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

Why design the VM that way?

[Chemisor]

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:Oracle Responded Well

[h4rr4r]

Oracle immediately reverted the change within 2 days

I don't think that is what immediately means.

Re:IT'S ALREADY FIXED!!

[Sir_Lewk]

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:Why check for vendor?

[Anonymous Coward]

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)

Re:Well that's it...

[Anonymous Coward]

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

Re:Sounds... wrong

[Anonymous Coward]

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.

Re:Yes and no...

[mysidia]

This does not work so well when the feature is present but buggy in various browsers, or for features whose presence or absence cannot easily be detected, the result would be inconsistent rendering if user agent was not checked to redirect the user to the proper page.

It is not a best practice to rely on attempts to "test for the presence" of a feature, to determine whether it should be used.

"Detection" is only possible if using javascript: not all browsers support, and some users might have it turned off.

User agent is commonly used for this purpose, and it is the best practice as defined by the standard [ietf.org] to use the user agent field for the purpose of tailoring responses to avoid particular user agent limitations

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

[Anonymous Coward]

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.

Re:Yes and no...

[mysidia]

Maybe they'll just clone them, creating identical com.oracle.* packages. Meanwhile the com.sun.* packages will ship with java, be deprecated and not receive any updates.

Not like anyone will notice their JRE installs growing from 700mb in size to 1000mb in size.

Stallman did this too

[IGnatius T Foobar]

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.