When loading the help class for watches, use MethodHandles.Lookup.defineHiddenClass where available.

[lahodaj]

When debugger evaluates watches, it sometimes interprets the watch, but if the watch is too complex, it will synthetize a class with the watch, compile, load and execute it.

But consider a case where there's a method like:

class EvalApp {
...
    private static int toLen(String str) {
        return str.length();
    }
...
}

and the watch is like:

java.util.List.of("A", "B").stream().map(EvalApp::toLen).count()

the watch evaluation fails, as the synthetized class is not part of the EvalApp nest, and debugger simply loads the class using the ClassLoader as any other class.

The draft here tries to use Lookup.defineHiddenClass, which allows to inject the class into the nest, and also hopefully allows the class to be unloaded faster.

It falls back to the original behavior if defineHiddenClass is not available in the debugee, but could also use Unsafe.defineAnonymousClass:
https://github.com/openjdk/jdk11u-dev/blob/705236baf53a76f0beb7be29fe45b68b7999fc7e/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L829

although I am personally not really particular about targets that don't have defineHiddenClass.

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)