The access via reflection occurs from Vaadin code, not your code. Your default accessible type is not accessible to MethodProperty, and I am not certain if even direct reflection calls within your package would consider it accessible as the access takes place via reflection API and implementation classes.
For discussion completeness sake, is there a reflection method that changes the type (not the type’s member) accessibility at runtime?
And if there is, why isn’t it used in such cases? Encapsulation is not an end in itself, it’s a means, which if it’s wrong, makes reflecting legit.
Reflection is also a means, which if is wrong (as it usually is), yearns for a change in design
No. #setAccessible is only on Fields and Methods, not Classes (well, more specifically, on
AccessibleObject which both Field and Method extend, but class does not.
If one needs to be able to externally configure a system to use a class by name, there is no choice but to use reflection. Configuring which Application is used in web.xml means that reflection is a must for Vaadin in this part of the system.
Java Beans specification was designed by Sun largely around reflection.
In Vaadin, you can avoid most (at least developer-visible) use of reflection by implementing your own containers, items and properties - Bean(Item)Container, BeanItem and MethodProperty exist to make certain common cases easier, but you do not need to use any of them. Quite often, a custom Container/Item/Property can also simplify code by not forcing the application to use entities compatible with BeanContainer etc.
You could also subclass AbstractApplicationServlet to create the application instance explicitly, eliminating one more use of reflection APIs, but there is rarely need for this unless the classloader used to load ApplicationServlet does not have access to your application class in some deployment scenario.
The third main use of reflection in Vaadin is some internal listeners etc. (you can also explicitly register reflection based listeners, but that is not recommended). This, however, is quite internal and you should not need to care about it. Vaadin 7 extends this to management of RPC and shared state implementations of components, but this should be relevant only for component developers.