The exact problem doesn't seem to be known and seems to be affected by a variety of seemingly unrelated factors (likely suggesting a race condition or similar). Some developers have claimed that avoiding setting the look and feel outside of the Swing thread resolves the problem but for others this hasn't appeared to resolve the issue.
The problem had Java apps like VisualVM, MATLAB, Visual Paradigm and JavaFX Scene Builder hanging at certain points in their use.
Luckily Apple have listened to feedback and released a timely update which appears to resolve the problem however this does highlight a general issue with Java system JRE updates.
Often times when an app has bugs the problem is not a complete lack of testing by the developer but unanticipated environmental factors which have broken assumptions, or simply broken the app. This is a good example where a number of apps could not have predicted the flaw in the 1.6 update yet they are affected by it and, if they are a commercial product, their users will be on the phone asking support for answers.
If a deployed Java app relies on an installed and auto-updated system JRE and in particular relies on that system JRE to not break backwards compatibility then it is vulnerable to API breaks and flaws in updates to that JRE. Through no fault of the app the app can become broken and the vendor has to pick up the pieces.
Another recent incident which highlighted this was Oracle's decision to start throwing an exception during sort methods.
This particular change could have been handled far better but Apple's 1.6 update may simply have been an bug. The problem is not so much that JREs should be perfect and free from errors but that the more unstable (changing) an environment the app finds itself in the more likely it is to be unstable itself.
This has been a central consideration in JWrapper which led us to the decision that, although an app may want to pick up a JRE to save itself a large download, it should get to give it a thorough test first (not just check the version and vendor) and if it does pick up that JRE, it should take a private copy. This means that an installed app doesn't rely on a changing system JRE and can always rely on a constant, unchanging JRE which is known to work well.
The initial reaction from some at this point is that the JRE should be updated for security reasons etc but the private JRE is used only for the app in question so there are no concerns about attack vectors due to newly discovered Applet or Java Web Start vulnerabilities since they are simply not a part of this JRE's usage.
A comparable situation is that of a statically compiled library in a native application. The app is compiled with a particular version of some library and at that time the security of the app can be assessed, along with attack surfaces in the use of the library itself. Even then the only attack surfaces that are relevant are the ones that present as a result of this specific apps use of that library, not all possible attacks on all possible uses of the same library. As newer versions become available these can be shipped with new versions of the app as and when necessary but the decision to do so, test the updated version and make the change comes at a time determined by the vendor, not by a third party that may decide to change the APIs that the app is relying on.
JWrapper currently doesn't allow shipping JREs for Mac app bundles since it is only relatively recently that a redistributable JRE has become available for MacOS but it is something that is under development and will be coming soon.