can not access a member of class with modifiers "public"

I get this error:

when I try the following
code example

package com.example.vaadintest;

import java.util.Arrays;

import com.vaadin.Application;
import com.vaadin.ui.Table;
import com.vaadin.ui.Window;

public class VaadintestApplication extends Application {
	public void init() {
		final Window mainWindow = new Window("Vaadintest Application");
		mainWindow.addComponent(new ArchiveTable());


class Archive {

	private short id;
	private String date;
	private byte nr1;
	private byte nr2;
	private byte nr3;
	private byte nr4;
	private byte nr5;
	private byte nr6;

	public Archive() {

	public Archive(int id, String date, int nr1, int nr2, int nr3, int nr4,
			int nr5, int nr6) { = (short) id; = date;
		this.nr1 = (byte) nr1;
		this.nr2 = (byte) nr2;
		this.nr3 = (byte) nr3;
		this.nr4 = (byte) nr4;
		this.nr5 = (byte) nr5;
		this.nr6 = (byte) nr6;

	public short getId() {

	public void setId(short id) { = id;

	public String getDate() {

	public void setDate(String date) { = date;

	public byte getNr1() {
		return this.nr1;

	public void setNr1(byte nr1) {
		this.nr1 = nr1;

	public byte getNr2() {
		return this.nr2;

	public void setNr2(byte nr2) {
		this.nr2 = nr2;

	public byte getNr3() {
		return this.nr3;

	public void setNr3(byte nr3) {
		this.nr3 = nr3;

	public byte getNr4() {
		return this.nr4;

	public void setNr4(byte nr4) {
		this.nr4 = nr4;

	public byte getNr5() {
		return this.nr5;

	public void setNr5(byte nr5) {
		this.nr5 = nr5;

	public byte getNr6() {
		return this.nr6;

	public void setNr6(byte nr6) {
		this.nr6 = nr6;


class ArchiveTable extends Table {
	public final static Object[] NATURAL_COL_ORDER = new Object[]
 { "id",
			"date", "nr1", "nr2", "nr3", "nr4", "nr5", "nr6" };

	public static String[] COLUMN_NAMES = { "Id", "Date", "Nr1", "Nr2", "Nr3",
			"Nr4", "Nr5", "Nr6" };

	public ArchiveTable() {
		this(new BeanItemContainer(Archive.class,
				Arrays.asList(new Archive[] { new Archive(1, "2012-1-1", 1, 2,
						3, 4, 5, 6) })));

	public ArchiveTable(Container dataSource) {



Make your Archive-class public.

Anyone care to explain? Reflection logic didn’t expect a default access class?

As per
Java Language Specification

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
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.