jodaorg / joda-beans Goto Github PK

Unless it contributes to the "Yoda" brand idea, methods like propertyRename() or propertyDefine() should be called renameProperty() or defineProperty() instead.
Following common Java method naming practice and conventions, and also for consistency with other classes in this library(!) like MetaBean.createPropertyMap() rather than MetaBean.propertyMapCreate().

Need ability to determine whether a property is derived or immutable/buildable via the meta-property at runtime.

The autogenerated equals/hashCode calls JodaBeanUtils. For equals, this boxes all primitive numbers, which is inefficient. For hashCode, int/boolean are not handled.

Class definition:

@BeanDefinition
public class JodaBeanExample extends DirectBean {

    @PropertyDefinition
    private Set<String> someStrings;
}

Then autogenerate the rest of the class which creates a builder method:

@Override
public BeanBuilder<? extends JodaBeanExample> builder() {
  return new DirectBeanBuilder<JodaBeanExample>(new JodaBeanExample());
}

In Java 7 this should instead be:

@Override
public BeanBuilder<? extends JodaBeanExample> builder() {
  return new DirectBeanBuilder<>(new JodaBeanExample());
}

Add immutable beans.

Refactoring can break XML deserialization. Provide a mechanism to handle it.

Need to use guava ImmutableSortedSet.copyOfSorted() not copyOf() to retain the comparator.

When a type is deserialized the type may have been renamed during refactoring. Hanlde this common case of change.

Sometimes need to access data in a builder

If the bean is final then the nested type constructors should be final.

A Class can be loaded without being initialized. This would result in the static initializer not being run, and thus the bean not registering itself with JodaBeanUtils.

Use Class.forName(cls.getName(), true, cls.getClassLoader()) to force initialization.

It uses an implicit toString() call which doesn't show the array contents.

Currently, Joda-Beans can be serialized to and from XML. This issue adds a binary format based on the MessagePack specification v2.0.

If a class is final, then the methods should not be declared as final.

Also, the meta-bean should be declared as final.

The parser is too strict. If you enter public class Foo (two spaces between class and Foo) then it will not match.

The clone() method would be a useful addition to all beans. Immutable beans can optimise the implementation.

Use LinkedHashMap, not HashMap.

If the immutable generic bean has no property referring to the generic then an incorrect suppress warning is added in the builder set method.

BasicBeanBuilder get(String) returns builder rather than the requested data.

Backwards incompatible, but the old code is useless so will never have been used.

Add JodaBeansUtils method to check if two beans are equal ignoring one or more properties.

The Guava MultiSet is serialized using the size of the whole set, not the size of the unique element set.

Avoid this JDK bug

The known types should be ones that make sense to be in beans and make reasonable sense in a non-Java context.

This will reduce the set of types known to v0.9 and v0.9.2.

Meta-bean should be transient.

The toString method can be generated automatically. Any manually written toString must be respected.

Apparently, two generic parameters on a class is not enough...

These were intended as implementation methods so should not clutter the main API.

The immutable builder should be able to be hidden.

The BeanComparisonError class does not match the bean equals.

• It needs to use JodaBeanUtils.equals
• it has a duplicate getClass check that defeats the list/map code
• the list/map code is better than the equals code wrt embedded arrays

The latter will not be fixed as you'd have to be stupid to put arrays in lists/maps...

If a bean is migrated from a normal bean to one that has Joda-Convert annotations, or vice versa, then the parser should still handle it.

If a string is parsed instead of elements, then try it via Joda-Convert.

hello Stephen:
I think joda-beans is similar but more than (reflectasm)[http://code.google.com/p/reflectasm/] . I have a question that why joda-beans don't use asm to create bytecode at run-time? I think it much easier for user.

This (with or without the Deprecated annotation)

  /**
   * The field.
   * 
   * @deprecated  Do not use.
   */
  @PropertyDefinition
  @Deprecated
  private String _field;

generates

  /**
   * Gets the field.
   * 
   * @deprecated  Do not use.
   * @return the value of the property
   */
  @Deprecated
  public String getField() {
    return _field;
  }

  /**
   * Sets the field.
   * 
   * @deprecated  Do not use.
   * @param field  the new value of the property
   */
  @Deprecated
  public void setField(String field) {
    this._field = field;
  }

However, this

  /**
   * The field.
   * 
   * @deprecated  Do not use.
   */
  @Deprecated
  @PropertyDefinition
  private String _field;

generates

  /**
   * Gets the field.
   * @return the value of the property
   */
  public String getField() {
    return _field;
  }

  /**
   * Sets the field.
   * @param field  the new value of the property
   */
  public void setField(String field) {
    this._field = field;
  }

Allow Joda-Beans to be converted to and from XML using the meta-data knowledge. Focus on a human-readable format wherever possible.

Add missing method PropertyStyle.isReadOnly().

Currently, all generated beans must extend DirectBean. This is an unecessary restriction.

The Builder.build() method tries to create a new instance.

The builder generated for a Bean assumes the existence of a no-args constructor. This isn't useful for classes with final fields because those fields can never be given sensible values.

A Bean with final fields should require or generate a constructor with parameters for all final fields, possibly using java.util.ConstructorProperties to map them to properties.

The generics of the static meta() method cause Joda-Beans problems. It seems that the inference generic is particularly prone to problems.

• When using a FlexiBean/MapBean builder properties should be automatically created.
• When querying metaProperty(name) a property should be created
• add DynamicMetaBean

The generated MetaBean has no type parameters and makes an illegal static reference to the enclosing class type parameters.

In COMPACT mode, generating a bean with no children puts the closing slash of the XML element in the wrong place.

Given the following bean definitions:

@BeanDefinition
public class Base implements Bean {

    @PropertyDefinition
    private String _str;
}

@BeanDefinition
public class Derived extends Base implements Bean {

    @PropertyDefinition
    private int _i;
} 

The following equals() method is generated for Derived

@Override
public boolean equals(Object obj) {
    if (obj == this) {
        return true;
    }
    if (obj != null && obj.getClass() == this.getClass()) {
        Derived other = (Derived) obj;
        return (getI() == other.getI());
    }
    return false;
}

This is incorrect because there's no call to super.equals() even though the superclass contains state.

The XML reader is not closed in a finally block, which is a Bad Thing.

Collection properties declared as final with an initializer should be treated as not-null.

For a type parameter T the MetaBean refers to T[].class.

Nullable fields throw NPE in constructor.

Code ignores the withShortTypes method.

Might be an issue when code formatters are used.

This works:

class Person extends DirectBean
{
}

... and this fails:

class Person 
extends DirectBean
{
}

Given the following bean definitions:

@BeanDefinition
public class Base implements Bean {

    @PropertyDefinition
    private String _str;
}

@BeanDefinition
public class Derived extends Base implements Bean {

    @PropertyDefinition
    private int _i;
}

The generated metaclass for Derived doesn't extend Base.Meta. This means the meta() and metaBean() methods have a return type that's incompatible with the equivalent superclass methods. The derived metaclass also doesn't include the properties from the base metaclass.