<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> <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. <br>
</font></font></blockquote>
<font size="4"><font face="monospace">Don't other attributes have
this issue too? E.g. LocalVariableTable etc. ?</font></font><br>
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> 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>
</font></font></blockquote>
<font size="4"><font face="monospace">The problem with this approach
is that you need a semantic description of what the attribute
is, in order to be able to understand whether its contents moved
or not. Pack200 allowed this - e.g. it had a little layout
language to describe custom classfile attributes, so that the
pack200 tool could compress even attributes it didn't know about
from the start. Pretty cool, but also hard to use, and probably
adds complexity.</font></font><br>
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> - 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>
</font></font></blockquote>
<font size="4"><font face="monospace">Maybe an option to select
which one of the last two behaviors you want?</font></font><br>
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> <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>
</font></font></blockquote>
<p><font size="4"><font face="monospace">It is a little awkward that
the user feels like PC references are being adjusted in some
attributes (exception tables, local variable related
attributes), but not for TAs. Other than that looks good.</font></font></p>
<p><font size="4"><font face="monospace"><br>
</font></font></p>
<p><font size="4"><font face="monospace">Maurizio<br>
</font></font></p>
<blockquote type="cite" cite="mid:44eea6b4-f00e-154c-d3fd-3675a63934c9@oracle.com"><font size="4"><font face="monospace"> <br>
<br>
</font></font> </blockquote>
</body>
</html>