Using WSUS Target Groups and Approvals is the correct way to address this particular scenario.
Alternatively, with Patch Manager, you can also use the Update Management Wizard to deploy the JRE update as an Unapproved Update to a discrete list of computers, or create a Patch Manager Computer Group with those machines as members, but if the list of exclusions is small compared to the total list, this is not a particularly efficient methodology.
Also, Since this JRE update issue is not likely to be a one-time thing either, I would argue that the best long-term solution is to use a permanent WSUS Target Group to identify those systems with updating restrictions. Since the exclusion list only involves a couple of PCs, the way to implement this is to create a SUBGROUP of each of your existing group(s), which is the NOJREUpdate group, and then explicitly set the JRE updates to Not Approved for that subgroup after approving it for the parent group. If you have many existing groups, you may find it preferable to create a special JREUpdates group and place only authorized systems in that group and approve the update(s) only for that group.
Yes... it is conceivable that you could customize the JRE update package to prevent updating JRE on machines of certain characteristics. For example, if your issue with updating the JRE is a specific application, you could add a Prerequisite Rule to the package to confirm that a known registry key/value or file is NOT present on the system. However, that's significantly more work than maintaining a WSUS Target Group and approvals, and also significantly more work to 'undo' it if things change. Furthermore, once you've customized that package, it becomes unsupported by Solarwinds. My recommendation would be to not modify the package, and use documented and proven techniques for resolving this fairly common deployment scenario.
Having said all of that, I'll also point out that Oracle/Sun claims that JRE updates are fully backward-compatible (although I know of at least one case, JRE7u10, where this is not an accurate statement). To that point, I would also be engaging with any software developers to determine why their product has built-in version dependencies in the first place -- particularly as relates to the Java Runtime Engine, which is known to be a security vulnerability wasteland -- and what their plan is for addressing timely updates to work with the most secure version available.
Arguably, a product that has such dependencies built-in, is itself, a security vulnerability wasteland. :-)
Such products also should be using sandboxed, self-installed, instances of the JRE, which would not be upgradable by standard packages anyway.
Thank you Lawrence. I really appreciate the time you took to answer and advise. I did use sub-groups on the WSUS, because this isn't a one time problem.