ColumnProperty final - why?

Hello, all!

I am new to vaadin framework, but I must say it's really good and intuitive product. At-least that's my first impression. I am testing it if it fit's my needs atm. Just wanted to ask if there is specific reason why ColumnProperty class is made final? I wanted to extend it to fit my needs, but I can't as it is final. Ofc, I can write my own class instead, but why rewriting already existing code?

I guess there no real reason as to why, Vaadin was not designed to be easily customized at first so there are quite a lot of places with private or final fields or method preventing quick customization.

I seem to recall making customization easier is one of the target goals of vaadin 7 but until then I think you will have to either do some copy/pasting or hack through with reflection...

ty for the answer Mathias. Seams like I will have to stick to copying some of vaadin's source into my own classes. That adds a bit of boilerplate. Also some of their methods used are with package visibility, that does not ease my job as well.
Anyway imo having final classes and methods without a proper reason is not the best style. Especially in a framework that is used by other developers.

Raivis Vasilevskis: ty for the answer Mathias. Seams like I will have to stick to copying some of vaadin's source into my own classes. That adds a bit of boilerplate. Also some of their methods used are with package visibility, that does not ease my job as well.
Anyway imo having final classes and methods without a proper reason is not the best style. Especially in a framework that is used by other developers.

Designing "permanent" public APIs always requires some careful thought - once they are there, it is very hard to change them. There is no way to do this for all parts of the framework at once, so I would recommend creating an enhancement request for those cases that are real pain points so they will not be forgotten. For Vaadin 7, we are planning to make at least a few parts of the framework more extensible (especially around client-server communication and on the client side).

For ColumnProperty, I did not check it now, but I suspect the reason it is final might be that you would need to be careful not to break internal consistency when subclassing it.