Couldn't they just distribute the JVM DLL with their app, providing the option for customers to use the system wide installed one if required?

I got rid of Java months ago when I found out the sites I visit didn't need it any more. The whatever java that's built into Firefox or IE is all I need.

Java 6

Oracle could have supported Java 6 indefinitely if they put the code support behind it. They just didn't want to. You can support any number of legacy products if you can be bothered (Windows XP) or not (virtually any consumer wireless router, it seems)

Even before JRE7u11 they had indicated that JRE6 updates would be run down.

Has anyone here tried it?

On the two PC's where I had to do Java updates last week, (by hand), the installer gave a clear and prominant warning that is "might" remove Java 6. But did not do so.

I removed Java 6 after the Java 7 installation was completed.

Tough love

They should learn to maintain your systems. If it can't run with the newest and best, it shouldn't be running. That's probably not popular with management. Perhaps their paychecks should be reduced to pay for it.

stuck with it - for now

I've tabled a motion to our dev team to consider removing Java as a client side requirement from our businesss app. Their response is that java is the only (free) tool that allows access to the client local path from the browser. So I guess we're stuck with it for the time being.

Tried it... I'll say

I work for a major corp. This appears to have killed most people's extranet access, if Mac users. not vm users though

They've only just noticed this?

Does this company not do testing of their software? This should have been picked up and added to the support docs a long time ago.

The windows installer for java 1.7 runtime has for a long time removed java 1.6, I even mentioned that on here way back in August last year, when I pointed out the fix for a vulnerability that was being pushed also wanted to remove it.

Personally I think Oracle did this to try and kick start java 1.7 usage :-(

Some responses

Hi guys -- I wrote the blog post that John (the article's author) cited. This is a great discussion. I just have a couple of comments on some of the comments here.

Our product does handle Java 7 (and 6, and 5, etc -- our stuff works with Java back to 1.3.1, although we'll probably move that up to Java 5 in the next release) just fine. But it's a tool that customers use to run and deploy their own software -- it allows .NET code to communicate with Java code. The Java runs in its own JVM, and the users get to choose whichever JRE they want -- it can be any version, it can be 32-bit or 64-bit. It can be be from just about any vendor. That's a good thing, because our users have their own environments, and it's their own business -- we don't dictate or judge. So, the problem isn't ours (we're not making people use Java 6, as some people say -- but our customers might choose to use Java 6), except that our customers' problems become our problems, and then we have to scramble. But it bothers me when we have to scramble to solve a problem that really wasn't caused by us, and which really shouldn't have been a problem to begin with.

Someone mentioned we should use the registry to choose the Java that we use. But that only tells us what Java is on the machine -- it doesn't tell us what Java the user wants or needs. Again, we let the user make that decision -- checking the registry won't tell us what we want to know. (Nor will JAVA_HOME, as someone else suggested.)

As for why any enterprise customer would allow auto-updates... the answer is that they shouldn't. But clearly it happens -- it happened to the customers of our customer. (Our customer is an ISV that uses our product. Their customers are the end users.) And when it happened, our customer heard about it from their customer, and called us, and we had to scramble, and the problem was easily corrected, but it shouldn't have been a problem in the first place, as someone mentioned.

As for the comment about why we don't supply the jvm.dll -- first because it should be up to our users to determine which version we need -- we can handle just about any one chosen and don't dictate. Second because jvm.dll doesn't work in isolation and we'd have to supply an entire private JRE -- it's much more than a single file.

Finally, I just want to point out that in our case, the problem is just the validity of a file path -- Java 6 and Java 7 reside in different places, and a single path won't work with both. However, this discussion has certainly come up with plenty of examples of Java software that works with Java 6 that simply won't work with Java 7.