Community
Participate
Working Groups
If a secondary transform that modifies a class reorganizes the constant pool, this can break the compression 1.6.9 added for attributes. Compression is done through referencing common strings in the constant pool from attributes rather than writing them out 'long hand' in the attributes themselves. If a secondary transform affects the constant pool (moving things around or removing entries) then when AspectJ runs later (perhaps ltw), it cannot decode the compressed attributes and (usually) a classcastexception will occur. The only (quick) solution here is to reduce the amount of compression - the longer term solution would be to manage our own mini constant pool that is serialized in another attribute. This wouldn't save as much space (because it would duplicate some of the strings in the regular pool) but it would save some.
unsetting the target field which is currently set for something already released