Java library to provide an API for beans and properties.

Not certain but is seems that joda-beans 2.1 (or one of it's transitive dependencies) on the maven repo was compiled with Java 9. This is causing an issue running a web service in TomEE 8.5 given that there is a dependency in tomcat on the ASM 5.0 bytecode manipulation library which only supports <= Java8.

So i have two OSGi bundles, one with interfaces, one with implementations. Lets say, i have public interface Person in one bundle, and public class PersonImpl implements Person in th other. I would like to generate getters, setters and addPropertyChangeListener() in the interface, and the implementations of those in the class. Is this possible with JodaBeans, and if so, how? If not, can you recommend some other library or tool that can do this? ...or am i not seeing some fundamental problem about this idea here?

I have been kicking the tires on this project for a while.

This should be doable but I am wondering best way: Make a Bean from Map?

{Also it be nice to go the other way. Map m = toMap(Bean) }

Cheers

Hi Would you please add "Observable property" feature by invoking firePropertyChange in generated setter method? This also requires to generate addPropertyChangeListener and removePropertyChangeListener methods ,plus PropertyChangeSupport field.

This could be controlled by extending @PropertyDefinition with "observable=true" attribute.

Thanks Alexander

Hi

I am excited to see you added json serialization, because I am guessing that it is going to be faster much faster than components that use reflection or annotations. One component that is missing is the capability to set custom json field names.

Jackson allows the setting of field names via annotations such as:

@JsonProperty("name")

Is it possible to have the same type of support for both json and map instantiation of properties?

I have a projects with 50 JPA objects, but they produce about ~40,000 Checkstyle warnings, with ~39,950 are within the AUTOGENERATED section. So 50 are in code I author.

Working on PR to add //CHECKSTYLE:OFF and //CHECKSTYLE:ON within the auto generated section. Associated PR will be raised shortly for early early review.

Currently one-line property definitions are not supported:

@PropertyDefinition private String forename;

has to be changed to:

@PropertyDefinition
private String forename;

It would be great, if one-line property definitions would be supported, because that's the way google/google-java-format formats simple fields.

Hi, I have a property definition with JPA annotations of the form:

@Entity
@BeanDefinition(builderScope = "public")
public class MyDomainObject implements Bean {

    @PropertyDefinition
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinTable(name = "MY_JOIN_TABLE",
            inverseJoinColumns = { @JoinColumn(name = "AN_ID") },
            joinColumns = { @JoinColumn(name = "ANOTHER_ID") })
    private MyObject myObject;

Upon saving in eclipse I get "Unable to locate field type at line X", if I remove the nested @JoinColumn lines it works. It also works if there's one nested @JoinColumn annotation on a single line.

Maven plugin version 1.1, joda beans version 1.13.

This issue was originally posted at https://github.com/JodaOrg/joda-beans-maven-plugin/issues/4

Reading the documentation, specifically regarding @PropertyDefinition alias. Using the below example I would expect it to generate getCase and setCase methods, but generates getACase and setACase instead.

@BeanDefinition
public class AliasQuery
        implements Bean {
    @PropertyDefinition(alias = "case")
    private String aCase;
}

I've got several POJO's I would like to switch over to using Joda Beans, but because the name conflicts with a keyword the private variable is often prefixed with '_' or a and the getter and setter have slightly different names. e.g. getCase/setCase and getLong/setLong.

Am I missing something from the documentation which might aid me switching to Joda Beans without having to do a mass refactoring exercise.

Adds explicit support for ImmutableList, ImmutableSet, ImmutableSortedSet and ImmutableMap. This allows objects to be serialized using custom meta beans which use the deserialized value to populate the field without any copying.

Fixes #129

Currently if one serializes an immutable bean which holds under an Object reference something implementing a JodaConvert interface with multiple implementations and the type is required to be serialized then the referencing converter chooses to serialize the first concrete implementation class name it encounters, rather than that of the interface itself.

Added a test case for it and deleted some useless code (we don't care about serializing class names for null values; also serializing classes as values is easy, just write the class name!)

Bumps assertj-core from 3.23.1 to 3.24.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Example class:

@BeanDefinition
public final class Example implements ImmutableBean {

  @PropertyDefinition(validate = "notNull")
  private final String exampleProperty;

  private static class ExampleInner {

    private final String innerProperty;

    private ExampleInner(String innerProperty) {
      this.innerProperty = innerProperty;
    }

    @Override
    public boolean equals(Object o) {
      if (this == o) {
        return true;
      }
      if (o == null || getClass() != o.getClass()) {
        return false;
      }
      ExampleInner that = (ExampleInner) o;
      return Objects.equals(innerProperty, that.innerProperty);
    }

    @Override
    public int hashCode() {
      return Objects.hash(innerProperty);
    }
  }
}

JodaBean's code gen spots the implementations of equals and hashcode on ExampleInner and decides to omit generating implementations itself (line 617, in org.joda.beans.gen.BeanParser from the looks of things).

Given the code gen doesn't have a true understanding of class structure perhaps an additional flag on the @BeanDefinition could provide an override of the heuristic being applied?

Can simply work around the issue for now by extracting the inner class into its own file but raising this issue for visibility.

Currently BeanReferences increments counts for values that are collection types, when we never serialize references for collections. Doesn't affect serialization massively, but without we could be using a smaller references array / more efficient reference numbers. e.g in the test example, previously the letters "A" and "B" used references 5 and 6, rather than the 1 and 2 that they should have been (as the most common item to be referenced).

Can't really change the code to reuse collections, as some types of collections are a bit hairy, what if it's first read as Set but later we serialize a SortedSet with the same elements? Can't reuse the original value but instead need a copy constructor, and that's a lot of effort to code. If somebody really wanted that effect they could wrap the collection in an ImmutableBean and get the deduplication for free.

Suppose you have next model:

public abstract class ReportBaseColumn implements ImmutableBean {
    @PropertyDefinition(validate = "notNull")
    protected final String name;

    public ReportBaseColumn(String name) {
        this.name = name;
    }
}

@BeanDefinition(builderScope = "public")
public class ReportAliasColumn extends ReportBaseColumn {
    public ReportAliasColumn(String name) {
        super(name);
    }

    public String getType() {
        return "ALIAS";
    }
}

@BeanDefinition(builderScope = "public")
public class ReportSimpleColumn extends ReportBaseColumn {
    public ReportSimpleColumn(String name) {
        super(name);
    }

    public String getType() {
        return "SIMPLE_COLUMN";
    }
}

So after running code generation, Builder will contain next code for ReportAliasColumn & ReportSimpleColumn :

        @Override
        public Object get(String propertyName) {
            throw new NoSuchElementException("Unknown property: " + propertyName);
        }

        @Override
        public Builder set(String propertyName, Object newValue) {
            throw new NoSuchElementException("Unknown property: " + propertyName);
        }

Then we can try to create new insatnce of ReportAliasColumn and serialize is to JSON:

ReportColumn col = new ReportAliasColumn("abc");
String json = JodaBeanSer.COMPACT.jsonWriter().write(col);
System.out.println(json);

the output will be:

{"@bean":"ReportAliasColumn","name":"abc"}

But when we try to deserialize this json back to ReportAliasColumn, using next code

ReportAliasColumn alias = JodaBeanSer.COMPACT.jsonReader()
    .read(json, ReportAliasColumn.class);

we will get exception:

java.lang.IllegalArgumentException: Error parsing bean: ReportAliasColumn::name, Unknown property: name

Thats happen because of behaviour of code generator: org.joda.beans.gen.BeanGen#generateBuilderSet

When particular bean has no fields, then it simply generate code

data.ensureImport(NoSuchElementException.class);
addLine(3, "throw new NoSuchElementException(\"Unknown property: \" + propertyName);");

I think it will be better to use the same logic as in default block when there are fields, i.e.:

            if (data.isRootClass()) {
                data.ensureImport(NoSuchElementException.class);
                addLine(3, "throw new NoSuchElementException(\"Unknown property: \" + propertyName);");
            } else {
                addLine(3, "super.set(propertyName, newValue);");
            }

First pass at add and put methods for building collections and maps within beans (see #100).

• Creates addPropertyName(value) methods for collections and one-dimensional arrays within beans. Higher-dimensional arrays are currently ignored.
• Creates putPropertyName(key, value) methods for maps within beans.
• The add and put methods use immutable builders to create new instances of the appropriate collection with the new element appended. This is presumably less efficient than initialising the bean builder with instances of the collection builders and simply adding to them - however that looks like it would require a significant re-write of the builder generation code.
• Does not currently attempt to translate the property name into its singular value but this wouldn't be difficult to add (and for my money is nicer). Probably should also have a new property on the @PropertyDefinition annotation (singular?) to allow overriding when the 'smart' generation picks something nonsensical or that clashes with other code.
• All maps and collections are currently constructed using guava's immutable builders. Not sure what the expected collection implementations are for mutable beans?
• The NavigableSet, NaviableMap, Grid, and ImmutableGrid types are not currently supported (due to not having a equivalent builders.
• For put(key, value) methods, the javadoc for key states that it shoud be non-null but the javadoc for the value does not.

I think there is some ambiguity in how the null numeric values are parsed. Or, at least, it would be nice to have a somehow configurable behaviour.

Here is the issue. I have this bean:

@PropertyDefinition(validate = "notNull")
private final Double number;

When I parse the following jsons (which should represent the same content) I get two different results

{"number":null} --> number=Double.NaN
{} --> number=null --> IllegalArgumentException("Argument number must not be null")

I expected to get the exception in both cases. What do you think?

I noticed that AbstractJsonReader leniently accepts null as NaN. Would it be possible to change this in your opinion?