Apple apparently takes this seriously, since they "disabled Java" in users' computers, which is a rather drastic move. This actually smells like a pretext to kill off the technology, as part of a wider strategy.
For this specific hole, there are a few details there. It is all about the Java applet model. To understand:
Java is a programming language and a huge library of code, all running within a virtual machine. The VM means that code is much easier to port between architectures. So far so good; the same applies to several other frameworks, including .NET.
The strong typing of Java and the VM conceptually allows an extra feature, which you cannot have (at least not easily) with more bare-metal languages like C++: the possibly of safely running potentially hostile code. With C or C++ or assembly or whatever, such a feat requires some help from the hardware and the operating system (namely the privilege levels of protected mode, or, for the extreme cases, specialized virtualization opcodes). Strong types and the VM allow for a software-only sandbox solution, which could be integrated in, for instance, a Web browser.
It turns out that managing this system of "permissions" is very hard to do for the VM and library; namely, the library is very rich in code which offers access to various OS facilities, and they must all be plugged without forgetting any. There are hundreds, maybe thousands of "sensitive calls" to care about. The long history of security holes in Java is a testimony to the nigh impossibility of the task. If the competing technology from Microsoft (Silverlight, built over .NET) seems a bit less impacted, it is mostly because it is much less used worldwide, giving it far less exposure.
For the time being, the safest thing to do is to disable support for Java applets in your browser. Note that Java applications, and in particular anything which runs server-side, are not impacted.
The problem of safely running hostile code, while simultaneously maintaining rich functionality and fine-grained access control, is not a new problem. What this yet another Java mishap shows is that this old problem is still unsolved.