Link Details

Whoa incredistupid!!! Making the program dependent on a hard coded value to work and Company name of all things?? Just plain dumb on IBM's part. When you watch their commercials you believe them to be uber geniuses. I guess not so much.

Eclipse laucher need to pass to the Sun/Oracle virtual machine (in command line) a non standard parameter, not present in other virtual machines. The parameter is specific to the Sun/Oracle vm memory management.
The only way to do this is to parse a dll property (java hasn't start yet) that contains the name of the vendor.

public static final String JDK_COMPANY_NAME = "Sun Microsystems";

public static final String

@Topnotch

It's like everything I was taught NOT to do in school, these big ass corporations do as policy.

Agreed. In fact this is so outrageously bad that if I would've thought of it sooner I would have submitted this directly to thedailywtf, it's that bad.

Old news already

And already fixed by Oracle reverting the change

No the issue is that Oracle even had to do any kind of reversion at all. Why are you trying so hard to defend such poor code being present in Eclipse? The fact that you actually tried to justify the techniques being used in Eclipse speaks volumes about your competency or lack thereof.

I'm not trying to justify nothing.
I simply reported what I read from eclipse community in another blog.
But if you are so sure of your competency please give us your solution to that problem.
They need to know the VM they are launching before they launch it, possibly in an efficent way, how do you do it?

Ok, I figured I wouldn't need to explain this but here goes: the root cause of the problem is the maxpermgen setting and the default being too small. This isn't really related to the name of the company. This is why their approach is flawed. They need to check for artifacts like Xusage.txt in the jre install folder.On my install in the 'jre6\bin\client' directory there are only 3 files including Xusuage.txt this should be a lightning fast search from C. Of course on Linux this will be diffferent but still there will be data evidence related to the maxpermgen setting.This is only one artifact that I know of from a quick search. I'm sure there are even more quick ways to check for Sun JVM fingerprints without depending on the company name. The key though is looking at evidence of maxpermgen not the company string.

The permgen issue my be not directly related to the name of the company, but I don't see why is should be related to a file like Xusage.txt and why looking for is should be much more reliable.
Athought it contains information on some command line parameters, it says nothing about the -XX:MaxPermSize.

Let me make my point clear. I don't think the solution used by eclipse is a good one, but before calling them "incredistupid" I would look for a clearly better solution and no one showed one.

Nope I was still right they were incredistupid. The key is the setting not the company name.

@Topnotch
I'm still of my opinion. It's easy NOW to say it was a bad choise, but no one I know has swon a solution that is clearly better (and stable).
Your solution (Xusage.txt) isn't either cause it's based on a file that has nothing to do with the problem (perm size management).
Now you can say it'd be a better choice because it hasn't changed, but when they made the choice there were no CLEAR reason to second one over the other.

And insisting on insulting people doesn't add any strenght to your arguments. I think the contrary instead.

,It's important to point out that what I presented is a hint in the correct direction for a solution without depending on the company string. That is all. It was a hint not a full solution so stop insisting that I presented that as a solution, its a hint to look at data besides the company name but instead the setting which is the correct approach.

I don't insist that you presented a complete correct solution (nor intended to).
I insist that no one (that I know) did!

This make me think that calling them "incredistupid" is exagerated at best.