Setting final fields

As XStream is a serialization tool, it makes no sense to add fields to XML that cannot be deserialized. I would rather not add the feature as it could lead to hard to track down bugs for users.

.... however I'm happy to add support for final fields if we can set them again. I'll have a go with ben's approach.

Actually, the patch I uploaded supports both reading and writing final fields when you use Sun14ReflectionProvider, which I believe is used by default. As I side-effect of the way I implemented it, PureJavaReflectionProvider also supports reading final fields, but can't write them. However, it could be easily changed to do something else - I wasn't sure what the correct behavior should be.

I was sort of thinking that an XML file originally written using PureJavaReflectionProvider might be read with Sun14ReflectionProvider (for example, on a different machine), so it doesn't hurt to have the fields present, but perhaps that doesn't make sense.

I don't like the current behavior without the patch (skipping final instance fields). That means xstream silently creates a bad file that results in incorrect objects when the file is deserialized. Maybe PureJavaReflectionProvider should throw an exception if a final instance field is encountered during serialization, since it won't be able to correctly restore the object? If it turns out that the final field really doesn't need to be serialized, it should marked as transient.

Patch applied. PureJavaReflectionProvider behaves as it did before. Brian, I agree with your point and have created a new issue for it: XSTR-56

Some profling showed that using Unsafe to set fields instead of vanilla reflection is about twice as quick. So Sun14ReflectionProvider is now always using Unsafe, regardless of whether the field is final.

Reading using Unsafe did not speed things up so I left it as is.