This post is mostly just organizing all the info that's been posted lately about Java 7 problems.
Update 2013-01-13: Update now available from Oracle for Java 7 Update 11 to fix this vuln.
Defining the current problem
There is a Java 0-day going around (CVE-2013-0422 the one discovered by @Kafeine). Java was once viewed as being the most secure language to write code in because many common memory corruption vulnerabilities are difficult (impossible?) to create. Lately, however, Java is getting a bad reputation due to it's growing list of vulnerabilities, and slow reactions from Oracle, and in the case of this bug, it improperly patched the problem.
Many security professional are advocating the naive binary reaction "Java is bad, get rid of Java now!" Really? You're being paid 6-figures to give the response of a 6-year-old? This is not a business reality. We can't command every user out there to not use a product until this storm blows over. Because Java historically has been viewed as the option of choice for those security minded developers, many applications have been written in it. For the home user, they likely encounter Java in their banking site. For the enterprise user, there are likely using Java applications to do their jobs. You might as well advocate "If your company made best practice decisions in the past and wrote many applications in Java, which you use to do your job, take a vacation until a patch comes out, or rewrite all your applications to not use it. I changed my mind about Java being secure." These are the problems we're supposed to assist the world in solving. I'm in this profession to help make computers secure, because I use them, I believe the world is better because of them, and I want them to be secure.
First, let's understand the problem. To really dig into the guts of it, here are some good resources:
Current solutions
Let's explore the options to handle this vulnerability. The nuclear option is to uninstall Java completely (check the directories C:\Program Files\Java\ or C:\Program Files (x86)\Java\). The basic problem though is that Java runs in the browser and this is where the trouble happens, so if you still need Java, but not in the browser, just disable Java in the browser. If you have a Java app that runs locally on your system, it's likely not going to be affected by this vulnerability. You're only vulnerable if you are executing arbitrary Java files, which is what the browser does. Even if you don't go to sketchy sites, those sites could have been hacked, or they could have advertisements which bad guys can "advertise" things on which execute Java.
Disable Java in the browser
If you use IE, you can't really disable Java from the browser, so if possible use Mozilla or Chrome. If you use Mozilla or Chrome, those browser now force you to "Click to play" the java code, effectively stopping the exploit unless you click on it. Interestingly, Apple took the approach of black-listing Java entirely. Krebs on Security discusses how to disable Java on various browsers, in case the "Click to play" solution is not enough for you. To check if your browser is still running Java, go to https://www.java.com/en/download/testjava.jsp.
Restricting Java in the browser
If you still need Java in the browser, you can restrict it to only certain sites as described on darkoperator.com. This may still have XSS issues. Or alternatively, for Firefox and Chrome (on Linux or OSX only) you can use nssecurity.
Patch
If you'd like to patch this problem, you can get an unofficial patch from http://schierlm.users.sourceforge.net/CVE-2013-0422.html. This adds some additional checking code to vulnerable code to disable it. Unfortunately, things might be in a weird state when the next Java update comes along.
Desired future solutions
White-list signed jars
Java has for a long time come with the ability to sign jar files, but this only allows for additional privileges to be added to signed code. See the post Sandboxing Java Code on securesoftwaredev.com. I would like to have the ability to say "Only code that has been signed by the following entities can run at all". I don't know of any way of currently making that possible.
Reduce the Java Attack Surface
Just as you can patch the JRE, you can also just remove entire classes. A lot of Java problems are due to it's Reflection library, so you could just remove those. Java provides functionality to play sounds and graphics libraries for games. Java provides a lot of backwards functionality to use old, out-dated crypto libraries. If I just need Java for business uses, I can strip the JRE of all this additional functionality. However, it's a pain. There should be an easier way. If you run java with the verbose:class flag, you can see the classes as they are loaded. Someone ought to write a tool to hook that, and provide a way to disable most of the JRE, and be able tell the user "This class tried to access restricted class X, so it was killed." Obviously, this is much more technical than is useful for the average user, but I think such a tool should probably exist.