I agree that the javadoc/contract of the method is correct, but the implementation throws unexpectedly and this isn't correct.

This inconsistency causes apparently problems like described in this issue #13393.

Investigated this a bit further. One thing to consider is that regardless of the discrepancy between javadoc and real functionality, this logic has been in place about six years and care should be taken if it will be changed - especially if it is done via silently ignoring bean-level validators. On the other hand, writing the bean will eventually run the bean-level validators so changing the functionality to match javadoc is probably not too dangerous.

That said, one option might be to:

1. Update current javadoc of validate to match current functionality
2. Provide an overloaded validate -method with a parameter where the developer has to explicitly request ignoring bean-level validators

Benefit of this would also be earlier release (or backporting) since current functionality would not be changed.

Unfortunately there already is an overloaded validate(boolean fireEvent) function; creating another overloaded validate() would further complicate the API. Also, isValid() would need to be overloaded as well.

Also, having the overloaded function would basically bring back the old behavior of throwing an exception if bean-level validators are defined; I wonder what value this use-case brings, except for the compatibility reason of course.

You are right on both counts. But I'm afraid that if the validate functionality is changed to silently ignore validators, releasing this might be pushed quite far into the future. Not sure if we can do such change in a minor release, but definitely not in a bugfix release. @mshabarov any thoughts?

True, it's always good to be conscious on the backwards compatibility. I'd say that this ticket has been present in Vaadin for 6 years, so waiting a bit wouldn't hurt; and personally I would prefer to have simpler&cleaner API. So, personally I would vote to go for the "breaking change" option, and release this as part of next major version.

As I said, the contract of validate method sounds correct to me, so I agree with you guys that it shouldn't throw, when the bean is just red to the fields and not bound.

The javadoc says for validate: Validates the values of all bound fields, which should happen when the fields aren't bound.

I cannot come up with a good example, but there might be existing use cases in projects when form validation relies on IllegalStateException thrown in validate.

Older versions need an update of javadoc to reflect the implementation (tell that this methods might throw). It means a behaviour change.

Finally, I propose to follow what Martin said and apply this patch to the next major version (I have a list of TODOs and going to add this there).