<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">We currently divide attributes
into two buckets: those for which an attribute mapper exists,
and those for which one doesn't. The latter are represented
with `UnknownAttribute`. There is also an Option to determine
whether unknown attributes should be discarded when reading or
writing a classfile. The main reason to be cautious about
unknown attributes is that we cannot guarantee their integrity
during transformation if there are any other changes to the
classfile, because we don't know what their raw contents
represent. <br>
<br>
The library leans heavily on constant pool sharing to optimize
transformation. The default behavior when transforming a
classfile is to keep the original constant pool as the initial
part of the new constant pool. If constant pool sharing is
enabled in this way, attributes that contain only pure data
and/or constant pool offsets can be bulk-copied during
transformation rather than parsing and regenerating them. <br>
<br>
Most of the known attributes meet this criteria -- that they
contain only pure data and/or constant pool offsets. However,
there are a cluster of attributes that are more problematic: the
type annotation attributes. These may contain offsets into the
bytecode table, exception table, list of type variables, bounds
of type variables, and many other structures that may be
perturbed during transformation. This leaves us with some bad
choices:<br>
<br>
- Try to track if anything the attribute indexes into has been
changed. (The cost and benefit here are out of balance by
multiple orders of magnitude here.)<br>
- Copy the attribute and hope it is good enough. Much of the
fine structure of RVTA and friends are not actually used at
runtime, so this may be OK. <br>
- Drop the attribute during transformation and hope that's OK.
<br>
<br>
(There are also middle grounds, such as trying to detect whether
the entity with the attribute (method, field, etc) has been
modified. This is lighter-weight that trying to track if the
attribute has been invalidated, but this is already a
significant task.) <br>
<br>
I haven't been happy with any of the options, but I have a
proposal for incrementally improving it:<br>
<br>
- Add a method to AttributeMapper for to indicate whether or
not the attribute contains only pure data and/or constant pool
offsets. (Almost all the attributes defined in JVMS meet this
restriction; only the type annotation attributes do not.) For
purposes of this mail, call the ones that do not the "brittle"
attributes. <br>
<br>
- Add an option to determine what to do with brittle attributes
under transformation: drop them, retain them, fail. <br>
<br>
This way, nonstandard brittle attributes can be marked as such
as well, and get the same treatment as the known brittle
attributes. <br>
<br>
<br>
</font></font>
</body>
</html>