Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
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.