RE: [aspectj-dev] supporting serialVersionUID

[Jim.Hugunin@xxxxxxxx]

Nuno Oliveira wrote:
> I'm considering customizing my copy of aspectJ for a very specific
> application, to support each class's defined serialVersionUID.
> I've just taken a quick glance at the src structure. Before going any
> further, would anyone have the time to give me some pointers reggarding
> the
> difficulty of the task (maybe it's not worth the trouble...) and/or the
> places to touch ? Is it at all rejected by the AST creation process ?

For classes that have an explicitly defined 'public static final long serialVersionUID' field, ajc-1.1 shouldn't make changes to that field and you should find this works today.  The easiest solution would be for you to define this field explicitly for the classes that you want to weave -- and then not worry about modifying the weaver.

However, being able to maintain the computed serialVersionUID value for classes that don't explicitly define it would be a nice addition to the weaver (possibly enabled with a -X option).  Here's how I'd do it:

1. Write several test cases for the weaver that look for serialVersionUID being unchanged before and after weaving.

2. (possibly HARD) Write a method that computes the serialVersionUID from a bcel JavaClass of ClassGen (add this to the org.aspectj.weaver.bcel package).  If you're lucky, this is already done by someone in the bcel community.  If not you're going to have to understand the serialVersionUID spec fairly well to get this right.

3. Hook this into org.aspectj.weaver.bcel.BcelClassWeaver.  Before weaving any Serializable class that doesn't have a serialVersionUID field defined compute the pre-weaving value (using step 1) and insert an explicit serialVersionUID field into the ClassGen.

* To move beyond a -X option, there is one more hard step.  You need to think through (and write-up for this list) those cases where the above behavior is wrong.  Then you need to make sure that the weaver can detect those cases and act appropriately.  The one case that comes quickly to mind is if you're introducing fields onto a class then you want the serialVersionUID to be changed -- but in well understood ways.  I bet there are other cases like this.

I hope this helps you get started - Jim

PS - This sort of new functionality can't be considered for the soon to be released 1.1.0; however, I believe it would be fine to consider for a 1.1.1 release (as a -X option) or a 1.2 release (as the default behavior) if it is implemented well.