* <td>Specifying a bootstrap method for invokedynamic, within a class of the given name</td>
* <td>An attacker could attempt to attach a bootstrap method to a class which
* has just been loaded, thus gaining control of its invokedynamic calls.</td>
* </tr>
*
* <tr>
* <td>invalidateAll</td>
* <td>Force the relinking of invokedynamic call sites everywhere.</td>
* <td>This could allow an attacker to slow down the system, or perhaps surface timing bugs in a dynamic language implementations, by forcing redundant relinking operations.</td>
* </tr>
*
*
* <tr>
* <td>invalidateCallerClass.{class name}</td>
* <td>Force the relinking of invokedynamic call sites in the given class.</td>
* In addition, the replacement character for the escape character itself is
* <code><big><b>-</b></big></code> (hyphen),
* and the replacement character for the null prefix is
* <code><big><b>=</b></big></code> (equal sign).
* </p>
* <p>
* An escape character <code><big><b>\</b></big></code>
* followed by any of these replacement characters
* is an escape sequence, and there are no other escape sequences.
* An equal sign is only part of an escape sequence
* if it is the second character in the whole string, following a backslash.
* Two consecutive backslashes do <em>not</em> form an escape sequence.
* </p>
* <p>
* Each escape sequence replaces a so-called <cite>original character</cite>
* which is either one of the dangerous characters or the escape character.
* A null prefix replaces an initial null string, not a character.
* </p>
* <p>
* All this implies that escape sequences cannot overlap and may be
* determined all at once for a whole string. Note that a spelling
* string can contain <cite>accidental escapes</cite>, apparent escape
* sequences which must not be interpreted as manglings.
* These are disabled by replacing their leading backslash with an
* escape sequence (<code><big><b>\-</b></big></code>). To mangle a string, three logical steps
* are required, though they may be carried out in one pass:
* </p>
* <ol>
* <li>In each accidental escape, replace the backslash with an escape sequence
* (<code><big><b>\-</b></big></code>).</li>
* <li>Replace each dangerous character with an escape sequence
* (<code><big><b>\|</b></big></code> for <code><big><b>/</b></big></code>, etc.).</li>
* <li>If the first two steps introduced any change, <em>and</em>
* if the string does not already begin with a backslash, prepend a null prefix (<code><big><b>\=</b></big></code>).</li>
* </ol>
*
* To demangle a mangled string that begins with an escape,
* remove any null prefix, and then replace (in parallel)
* each escape sequence by its original character.
* <p>Spelling strings which contain accidental
* escapes <em>must</em> have them replaced, even if those
* strings do not contain dangerous characters.
* This restriction means that mangling a string always
* requires a scan of the string for escapes.
* But then, a scan would be required anyway,
* to check for dangerous characters.
*
* </p>
* <h3> Nice Properties </h3>
*
* <p>
* If a bytecode name does not contain any escape sequence,
* demangling is a no-op: The string demangles to itself.
* Such a string is called <cite>self-mangling</cite>.
* Almost all strings are self-mangling.
* In practice, to demangle almost any name “found in nature”,
* simply verify that it does not begin with a backslash.
* </p>
* <p>
* Mangling is a one-to-one function, while demangling
* is a many-to-one function.
* A mangled string is defined as <cite>validly mangled</cite> if
* it is in fact the unique mangling of its spelling string.
* Three examples of invalidly mangled strings are <code><big><b>\=foo</b></big></code>,
* <code><big><b>\-bar</b></big></code>, and <code><big><b>baz\!</b></big></code>, which demangle to <code><big><b>foo</b></big></code>, <code><big><b>\bar</b></big></code>, and
* <code><big><b>baz\!</b></big></code>, but then remangle to <code><big><b>foo</b></big></code>, <code><big><b>\bar</b></big></code>, and <code><big><b>\=baz\-!</b></big></code>.
* If a language back-end or runtime is using mangled names,
* it should never present an invalidly mangled bytecode
* name to the JVM. If the runtime encounters one,
* it should also report an error, since such an occurrence
* probably indicates a bug in name encoding which
* will lead to errors in linkage.
* However, this note does not propose that the JVM verifier
* detect invalidly mangled names.
* </p>
* <p>
* As a result of these rules, it is a simple matter to
* compute validly mangled substrings and concatenations
* of validly mangled strings, and (with a little care)
* these correspond to corresponding operations on their
* spelling strings.
* </p>
* <ul>
* <li>Any prefix of a validly mangled string is also validly mangled,
* although a null prefix may need to be removed.</li>
* <li>Any suffix of a validly mangled string is also validly mangled,
* although a null prefix may need to be added.</li>
* <li>Two validly mangled strings, when concatenated,
* are also validly mangled, although any null prefix
* must be removed from the second string,
* and a trailing backslash on the first string may need escaping,
* if it would participate in an accidental escape when followed
* by the first character of the second string.</li>
* </ul>
* <p>If languages that include non-Java symbol spellings use this
* mangling convention, they will enjoy the following advantages:
* </p>
* <ul>
* <li>They can interoperate via symbols they share in common.</li>
* <li>Low-level tools, such as backtrace printers, will have readable displays.</li>
* <li>Future JVM and language extensions can safely use the dangerous characters
* for structuring symbols, but will never interfere with valid spellings.</li>
* <li>Runtimes and compilers can use standard libraries for mangling and demangling.</li>
* <li>Occasional transliterations and name composition will be simple and regular,
* for classes, methods, and fields.</li>
* <li>Bytecode names will continue to be compact.
* When mangled, spellings will at most double in length, either in
* UTF8 or UTF16 format, and most will not change at all.</li>
* </ul>
*
*
* <h3> Suggestions for Human Readable Presentations </h3>
*
*
* <p>
* For human readable displays of symbols,
* it will be better to present a string-like quoted
* representation of the spelling, because JVM users
* are generally familiar with such tokens.
* We suggest using single or double quotes before and after
* mangled symbols which are not valid Java identifiers,
* with quotes, backslashes, and non-printing characters
* escaped as if for literals in the Java language.
* </p>
* <p>
* For example, an HTML-like spelling
* <code><big><b><pre></b></big></code> mangles to
* <code><big><b>\^pre\_</b></big></code> and could
* display more cleanly as
* <code><big><b>'<pre>'</b></big></code>,
* with the quotes included.
* Such string-like conventions are <em>not</em> suitable
* for mangled bytecode names, in part because
* dangerous characters must be eliminated, rather
* than just quoted. Otherwise internally structured
* strings like package prefixes and method signatures
* could not be reliably parsed.
* </p>
* <p>
* In such human-readable displays, invalidly mangled
* names should <em>not</em> be demangled and quoted,
* for this would be misleading. Likewise, JVM symbols
* which contain dangerous characters (like dots in field
* names or brackets in method names) should not be
* simply quoted. The bytecode names
* <code><big><b>\=phase\,1</b></big></code> and
* <code><big><b>phase.1</b></big></code> are distinct,
* and in demangled displays they should be presented as
* <code><big><b>'phase.1'</b></big></code> and something like