Vaadin version: 8.0.5
Properties are now in random order when you for example list beans/DTOs in Grid. It would often be the right order out of the box if the properties would be stored in order they are read from the bean.
Java makes no guarantees about the order of elements returned from various reflections APIs. Older versions of Oracle's JRE did still return them in the order they were defined in the source, but this is iirc no longer the case.
For instance, the order of properties returned using Introspector.getBeanInfo(Person.class).getPropertyDescriptors() when I run it is born, class, name, even though name is before born in the source file: https://github.com/vaadin/framework/blob/master/server/src/test/java/com/vaadin/data/provider/bov/Person.java#L20
Leif, Java indeed makes no guarantees about the returned order, but it is exactly the opposite to what you said: old JREs used indeterministic order, from JDK 6 and newer use the order in which they are declared. So they indeed could be given in the correct order.
It appears you are using Introspector, which appears to use TreeMap (alphabetical order):
public static class Person {
private long id;
private Date birthDay;
private String name;
private Boolean colleague;
private String phoneNumber;
private String email;
public Person() {
}
public long getId() {
return id;
}
public void setId(long id) {
this.id = id;
}
public Date getBirthDay() {
return birthDay;
}
public void setBirthDay(Date birthDay) {
this.birthDay = birthDay;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPhoneNumber() {
return phoneNumber;
}
public void setPhoneNumber(String phoneNumber) {
this.phoneNumber = phoneNumber;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public Boolean getColleague() {
return colleague;
}
public void setColleague(Boolean colleague) {
this.colleague = colleague;
}
}
public static void main(String[] args) throws IntrospectionException {
System.err.println("Fields in Person (with getDeclaredFields):");
Field[] declaredFields = Person.class.getDeclaredFields();
for (Field declaredField : declaredFields) {
System.out.println("\t" + declaredField.getName());
}
BeanInfo beanInfo = Introspector.getBeanInfo(Person.class);
System.err.println("Fields in Person (with BeanInfo = alphabetical):");
PropertyDescriptor[] propertyDescriptors = beanInfo.getPropertyDescriptors();
for (PropertyDescriptor propertyDescriptor : propertyDescriptors) {
System.out.println("\t" + propertyDescriptor.getName());
}
}
That would mean that we'd first have to change BeanPropertySet to manually find bean properties using reflection instead of using Introspector (or alternatively use some existing similar library with desired functionality).
Related to this, Introspector is part of desktop module in JDK9, so it might make it possible to make Vaadin run on a much lighter JVM, if Introspector is not used. I don't know what else we might be using from desktop module.
A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time. No further work will be done on this ticket. If the ticket seems to be still actual, please verify the problem existence over latest framework version and then open a new ticket in vaadin/framework with all the suitable information.
The issue was automatically closed due to inactivity. If you found some new details to it or started working on it, comment on the issue so that maintainers can re-open it.
blows dust from the issue
Hi,
im currently having exactly this issue with JsonSerializer, since i need them in the order of definition. Has this been ever discussed again? Im working on vaadin addons now and I kinda would need this as a feature...
Whatever that stupid stale bot says, I think it should be discussed. It would open a lot of possibilities for RAD. Also getting rid of the JDK Introspector would help us to use Vaadin apps with smaller JDK (without the heavy desktop module).
I actually contributed to this library at some point, as an ultimate goal to get this issue fixed: https://github.com/panga/java-beans-lite . Haven't followed what other alternatives we would have nowadays.
Most helpful comment
Whatever that stupid stale bot says, I think it should be discussed. It would open a lot of possibilities for RAD. Also getting rid of the JDK Introspector would help us to use Vaadin apps with smaller JDK (without the heavy desktop module).
I actually contributed to this library at some point, as an ultimate goal to get this issue fixed: https://github.com/panga/java-beans-lite . Haven't followed what other alternatives we would have nowadays.