You still use the vendour name to create the input arguments for your 2nd invocation. How is that any better than
It's better because you're at least asking the runtime to describe itself instead of asking Windows to describe a DLL file. A DLL that you may not be able to trust is the correct DLL. If the runtime is lying to you, then you have much bigger issues to worry about and this whole point is moot.
In the previous post, you also said...
When your supported VMs are upgraded by the vendor - you've got a tiny little Java app to update and the rest of the behemoth is never touched.
So even if the Eclipse devs followed your advice, it still would have been broken, because you have to update at least something.
Actually, no it wouldn't, and here's why: from the first link in the summary:
An engineering side note: The "Java" property values for java.vendor and java.vm.vendor were never changed in the jdk6 releases and will remain "Sun Microsystems, Inc.".
and
The Windows specific exe/dll file "COMPANY" value is what is at issue here, not the Java properties. It came as a surprise to us that anyone would be inspecting or depending on the value of this very platform specific field.
So, while I totally agree that if the reported vendor changes, and if there aren't sufficient checks to handle this then yes, this exact same problem would still be there.
However, JDK and it's updates will "never" change the vendor string. If the Eclipse devs had taken the more correct route of determining the properties of the actual runtime they would be running under, we would never have seen this problem.
Also, from the first link:
Note that the jdk7 releases will eventually be changing to Oracle, including the java.vendor and java.vm.vendor properties.
So, we know also for a fact that with JDK 7, even java.vendor, and java.vm.vendor will change. Well, so what? We have plenty of notice, and the Eclipse devs could add code in *right now* to also allow "Oracle" in the vendor string and use the same workaround. That's what I would do.
If the workload of ensuring that your Java IDE (of all things) works with the new releases of the major JVMs is too much for you, then frankly, you're in the wrong business. Now, I accept that this change was difficult to predict, but the devs took such a short-sighted and broken view of what defined the JVM vendor that they really have to accept the blame here. Worse than that - they created an overly complicated proprietary mess to deal with it when they could have achieved the same with about 3 lines of code - code that would be cross-platform and not a special case hack.
You rant quite a lot about how incredibly bad the Eclipse devs did this job
Actually, I ranted about how there's a much better way, and somebody on the cross-platform Java IDE development team really should have known about it since it's also the class that provides you information about the nature of the freakin platform you're running on. Though, now that you mention it - yes, I agree with you, they did do an incredibly bad job, overcomplicating the whole issue, and guess what - they screwed up. Any change, intentional or not in the "COMPANY" field of the DLL (assuming they are even checking the DLL that the runtime is using - that's not even certain) will render their application totally unusable. So yes, they did do an incredibly bad job on this small part of it.
but your "solution" would have resulted in exactly the same situation.
As I've shown, my "solution" would have worked perfectly in this case, since the return value from the API has not changed. Since we also know that it will change with JDK 7, if they were using my "solution" and it still broke, then yes - they would still be doing an incredibly bad job, because they still didn't take into account that the vendor may change.
You know, I really don't like the quotes around solution - since I actually have produced a solution that would have prevented this issue, and would be easy to maintain in future if the devs are doing their due diligence properly, I think it's fair to remove those quotes, don't you?
My solution also has the benefit that should similar tweaks become necessary for Solaris, or MacOS, or Linux, or whatever in future, well the framework to deal with that is already in place and it's totally platform agnostic. No need to write a special case each and every time - one size fits all since we're using publically documented Java APIs instead of some proprietary API that will only work on one platform.