Apex Final Property Behaves Like a Member Variable

Question

Assume we have a simple class:

public with sharing class SomeClass {

    public String property {
        get;
        set;
    } {
        property = 'Default Property Value';
    }

    public final String finalProperty {
        get;
        set { finalProperty = value; }
    } {
        finalProperty = 'Default Final Property Value';
    }

    public final String finalAutoProperty {
        get;
        set;
    } {
        finalAutoProperty = 'Default Final AutoProperty Value';
    }

}

Anonymous Execution

SomeClass instance = new SomeClass();
instance.property = 'New Property Value';
instance.finalProperty = 'New Final Property Value'; // Works
instance.finalAutoProperty = 'New Final AutoProperty Value'; // Fails with

System.FinalException: Final variable has already been initialized Class.SomeClass.__sfdc_finalAutoProperty

However, as @sfdcfox сorrectly noticed, neither instance.finalProperty = 'New Final Property Value'; nor instance.finalAutoProperty = 'New Final AutoProperty Value'; reassignments couldn't be compiled within another method giving:

Final members can only be assigned in their declaration, init blocks, or constructors

This behavior gives me questions because:

1. final keyword ApexDocs doesn't mention that the final keyword affects the behavior of properties and the Apex Properties page doesn't mention the final keyword. But the final keyword does affect apex properties.
2. Is it undocumented expected behavior or a new bug?
3. Why it is possible to reassign the property value within anonymous execution via default setter, but not via auto-generated setter?

Answer 1

If you don't provide a property for the final default getter setter property, it also runs just fine instead of "System.FinalException: Final variable has already been initialized".

Generally speaking, Exec Anon is weird, because it's basically a hack to the existing runtime. It doesn't allow classes that are nested, nor can you have static variables in those classes, etc, as if the entire code was wrapped in a class, but you can also intersperse methods and classes with executable code, as if it were not.

Also, you may want to read more about Execute Anonymous. It has a wide range of unusual rules that differ from normal gameplay. For example:

Unlike classes and triggers, anonymous blocks execute as the current user and can fail to compile if the code violates the user's object- and field-level permissions.

This is apparently one of those holes in the system. This behavior is clearly showing that the Exec Anon script is called as if it were executing in a constructor context, even though it allows DMLs (which are normally not allowed in a constructor or getter).

I can't say for certain if this is a bug, but this is definitely an Exec Anon exception to the normal rules for execution. If you're a prolific user of Exec Anon, you may very well find many strange and wonderful quirks hidden within.

However, as far as normal, compiled Apex code goes, you must always follow the prescribed directions as written in the documentation, or you will likely come across compilation errors, weird runtime behavior, etc.