(No comment was entered for this change.)

(No comment was entered for this change.)

The original reason for not doing this was that Java 1.4 did not allow it.  The problematic comment is: "If the 
underlying field is final, the method throws an IllegalAccessException."  See the documentation for 
Field.set(Object,Object), for more details.  Pay special attention to

In Java 1.5, this is possible with caveats.  We need to make sure that the following description does not 
negatively impact GWT RPC deserialization: "Setting a final field in this way is meaningful only during 
deserialization or reconstruction of instances of classes with blank final fields, before they are made available 
for access by other parts of a program. Use in any other context may have unpredictable effects, including 
cases in which other parts of a program continue to use the original value of this field.".  See http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/Field.html#set(java.lang.Object,%20java.lang.Obje
ct),for more details.

Any update on this issue? Are there any plans to support serializing final fields in 
gwt 1.5. If not, I would say at the very least, the gwt compiler for 1.4 and 1.5 
should complain about serializing final fields. Currently, it treats it as a 
transient which is wrong. We got burned by this a few times. 

I agree with fazal.asim, final != transient and there's not reason to bite people 
with it.

Can we agree to at least turn the warning back on for GWT 1.5 and reenable 
"gwt.suppressNonStaticFinalFieldWarnings"?

Just committed r3538 which re-enables the final field warning and suppression thereof.

(No comment was entered for this change.)

Whoops, the underlying request to serialize final fields is not implemented.

(No comment was entered for this change.)

(No comment was entered for this change.)

Do you have an ETA for this getting fixed?

The implications trickle through tons of serializable classes, so the sooner you fix
it the easier it will be for the rest of us to adjust...

I believe that Lex owns this issue now.

I would think that now is a good time to make this change, in trunk, since 1.6 is on its way out the door.  That 
would give a lot of time to deal with repercussions before the next release.  Does anyone see a reason not to 
switch over to allowing serializing final fields for GWT RPC?

There will be effects.  For people running on JVMs >= 1.5, the effect will be that more classes and data are 
serialized and sent across the wire.  In cases where this is not desired, the previous behavior can be gotten by 
marking final fields "transient".  This issue can be detected by looking at rpc.log files before and after the 
relevant gwt update.

For people running on 1.4 JVMs, there might additionally be some deserialization exceptions.  This effect could 
be minimized, though, if GWT's server-side support simply ignores such exceptions for final fields.  As with the 
current system, such fields would be left in their default state.

I can't give an ETA, but I see your point and will put this on a shorter list.

Without being the wise guy, I think there is a workaround after all.

If Google's team makes GWT [de]serializators to make use of copy constructors, that
would both:

1. Not force GWT's implementation to stray from standard Java (which generally
rejects serializing final fields);

2. Respect the programming patterns on immutable objects -- never hack them being
mutable in _ANY_ way, rather provide means to easily copy them when necessary.


Plus, since many people will argue that this could break already existing code, I
will modify my suggestion a bit: better provide matchers for classes (or packages) in
the GWT XML module definition where you can override this serialization issue.
Something like:

<module ...>
...

  <serialization-policy>

    <final-fields match-for="com.yourcompany.project.beans.*"
                  policy="use-copy-constructor"/>

    <final-fields match-for="com.yourcompany.project.external.beans.*"
                  policy="use-copy-method"
                  copy-method-name="deepCopy"/>

    <final-fields match-for="com.yourcompany.project.mock.*"
                  policy="use-static-factory-method"
                  static-factory-class-name="MockFactory"/>
                  static-factory-method-name="createAnonymousMock"/>

  </serialization-policy>

</module>


I would love any thoughts on these ideas.

Actually, Java serialization does serialize final fields, with the exception of Java 1.4 VMs.  Here is the Sun bug 
report discussing the change to allow such serialization:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5044412

As discussed, immutable objects deserve to be serialized, too, in which case you either need a way to modify 
final fields during deserialization, or you require objects with final fields to be written in a more constrained 
style than is otherwise necessary.

So, while there are many ways to do RPC, allowing serialization of final fields sure looks like a small and 
positive change to the existing system.

For the compatibility issue, I'm not sure what to do.  It seems like a simple and usable starting point, though, 
to simply not set the fields when on Java 1.4.  That would preserve the GWT <= 1.6 behavior.

This is such a fundamentally important issue for my team. We always use the final
modifier on fields which don't change - and we enforce this with an IDE configured to
warn when fields can be made final.

Our GWT code is littered with annotations to supress this, and comments to explain
why adding final will break the code.

    /**
     * NOTE: Don't make this final, as GWT serialization can not handle it.
     */
    @SuppressWarnings( {"FieldMayBeFinal"} )
    /*final */ private MyDate _date;