Why yes, yes it does. It's not until you are convicted at trial that you are legally guilty.

Until then you are just accused.

Actually, I think you'll find that their "word" is an allegation, not evidence. There's this funny concept that still exists (in name at least) called "Innocent until proven guilty"

Even a broken condom with viable DNA isn't proof - all that means is that they likely had sex at some point in the past. It does mean he likely had the opportunity, but sadly for you, it does not prove motive or intent. To achieve true justice, you'd need to combine all three to secure a conviction, not just the possibility of one. Hell, we all have many opportunities all day to rape, kill, steal, and cheat, but that doesn't mean we did any of those.

If he did it, then nail his balls to the wall, but sadly for you we don't yet live in a distopian police state paradise of the future and based on the alleged evidence so far, there isn't a case to answer.

Well that kinda depends on what the purpose is, doesn't it?

My guess is either:

1. Free publicity
2. Misinformation
3. All of the above

We'll probably hear in a few months how they launch an IPO and the owners/CEO makes $$$$$.

Actually, didn't Sun sue Microsoft for their usual Embrace, Extend, Extinguish tactics when they added proprietary extensions to their Java version and claimed it was still Java, thus violating Suns patents/trademarks/copyright/license terms/whatever?

They didn't sue just because MS created their own runtime/JVM, they sued because MS distributed an incomplete Java implementation, and then passed it off as the Java, something which only Sun had the legal right to do.

Define "safe and secure" in the context of your internet connection.

In the context of a safe deposit box, it means that only you or your properly authorised agent should get access to the contents of the safe deposit box. The sole purpose for a safe deposit box is to keep people out.

In the case of an ISP who, if you look at things like the DMCA, it has already been established that they are merely a conduit, then "safe and secure" suddenly has all kinds of connotations and hidden subtleties. The primary purpose of an ISP is to give you access to the Internet.

As others have asked - it also depends where the ISP equipment ends and where yours begins. If you own the router, then the case can be made that the ISP has no right to be changing the password. If they own it, then you have no right to prevent them from managing their equipment even though it's wholly within your property.

Now, what you expect from your ISP unfortunately means absolutely nothing, it's what is stated in the contract that matters. In the case of the bank, it's going to be a big, non-negotiable clause that they keep your property away from unauthorised people. In the case of an ISP, you'll probably find that they delegate responsibility for maintaining the security of the communications and equipment to the customer, while at the same time reserving the right to take technical measures to address what they may consider to be security issues.

For what it's worth, I agree with your point and would even suggest that all ISPs have a responsibility to be more proactive about network security - I just don't think your bank manager example was very good as the situations are too different.

That's different, because you're paying the bank to keep whatever you put in the safe deposit box safe and secure.

It can, for example, if your application is spending 85% of the time working on a small subset of your storage. Move that hot data to SSD and you could revolutionise the performance profile of the app.

FWIW, pick the right I/O profile to migrate to SSD, and you can expect far more than a 15% performance improvement. OLTP style I/O profiles (many, small random I/O) with a highly parallel RAID layout (say, RAID5 15+1 or RAID6 14+2) could net you a significant performance improvement over typical traditional layouts.

It's not a magic bullet, but for the right I/O profile even only a single RAID5 3+1 raidset on SSD can demolish much bigger raidsets on magnetic disk in terms of performance.

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.

Actually, no it wouldn't, and here's why: from the first link in the summary:

and

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:

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.

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.

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.

I'm not near my usual machine so can't write any proper code, however, take a look here, the relevant parts seem to be:

I'd guess that the VM versions are more relevant for Eclipse, though the VM specification may be the best bet since (I assume, I haven't actually researched that bit), it will likely uniquely identify the Sun/Oracle VM better than the vendor string. Of course, this way means there is more work involved maintaining a database of VMs and their required tweaks.

This kind of stuff isn't publicised well as well as I would hope, but is by no means super-secret hidden knowledge meant only for the elite. Given that I hunted it out when creating a cross-platform (Solaris/AIX/Linux/Windows) utility at my last job just last year, and a quick check here shows it's been in Java since JDK 1.0, I find it utterly unbelievable that nobody on the Eclipse dev team realised there was a better way to get the JVM vendor information.

No, it's not the only way and it certainly isn't the best way.

How about we query the runtime to determine which (if any) switches are required and then use that information to construct the command line for the real app?

If you must, you could even query the vendor string from within the runtime, but querying it from such an ephemeral location as metadata from a Windows DLL? Are you absolutely sure of your position that it's dictated by the platform that you must do it that way?

No, but it does mean you can, because it is yours - that's what "ownership" means.

Here's a thought - write the bootstrapper in Java, have it use reflection to get all the good stuff you're looking for, and then execute the real application with sane options.

With just a tiny little bit of lateral thinking, it really doesn't have to be a chicken and the egg scenario. You may still need a wrapper to get the bootstrapper running, but that's not a big deal when you look at the alternative.

Unfortunately, the Eclipse devs, and many people right here on Slashdot don't seem to grasp the simplicity of the solution, instead getting themselves caught in the chicken and egg trap.

I agree that Eclipse is at fault here, and that they should fix their app instead of hacking the JVM, but the fact remains that the crash is a *direct* result of an"unexpected but still valid string".

So, actually, you and cbhacking are both correct.

No, their detection logic failed because they were lazy and wanted nerd kudos for extracting the vendor string from a DLL.

Simple: Java stub to do the runtime detection and output to STDOUT the correct command line for starting the main application.

How on Earth could they not possibly figure this one out instead of whining that they can't detect the JVM without starting the JVM????? Well, start the freakin JVM, do the detection you need and use *that* information to start a new JVM.

Really, I'd like to know how they could be so short sighted!

How's this: write a short Java stub that detects the runtime environment from within the VM and passes back a guaranteed consistent string to the wrapper that then decides how to start the Java VM and run the main application.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.

Hell, you could even have the runtime detection code return the actual command line to start the main application so that the wrapper can be as simple as possible.

Is this rocket science? No.
Is this difficult? No.
Is this inefficient? No - it's about the best option when you can't change the VM runtime parameters at runtime. You've got one more VM invocation for an app that will probably run for 8 or more hours at a time.
Does this suffer from the schoolboy error of accepting arbitrary unvalidated variable input and assuming it is 100% correct, immutable, and altering your whole user experience based on it? No.
Does this have the geek credit associated with extracting the vendor string from a Windows executable? No.

Considering that the alternative is so simple, and would be cross-platform to boot, I call shenanigans on the Eclipse Windows devs and assume the last point was the one that drove them to do it the way they did.

It doesn't help your confidence in their development skills that their way is also a classic security blunder. Since there's no way to validate the input, they shouldn't be even considering using it without sanitation, and even then - there's no way to know if it's correct. The runtime detection I have described will at least give them the configuration of the *runtime* which is, after all, what they are looking for. While the Java VM may protect them from certain kinds of vulnerability - the fact that their mindset is such that they are happily relying on unverifiable, uncontrollable data as a means to control the entire behaviour of their application is astonishing and makes me question the security of the whole app.