Bean-Properties 1.0 provide JavaBean templates for clean syntax

Discussions

News: Bean-Properties 1.0 provide JavaBean templates for clean syntax

  1. Bean-Properties 1.0, a Java library providing templates for properties in Java, has been released. Bean-Properties replaces the typical getX() and setX() patterns, while providing a bytecode generator to create these methods for compatibility with the JavaBean specification if necessary. From the home page:
    The basic idea behind this framework is simple we use public final fields implementing get/set methods to implement properties. Types are defined by generics and practically all the problems above are solved, furthermore many added bonuses are gained as a result! Compatibility to the get/set implementation is trivial... But we are getting ahead of ourselves, first an example of how to implement a simple property X:public class NewBean { public final Property x = new PropertyImpl(); }Which you use like this:NewBean b = new NewBean(); b.x.set(5); b.x.get();First I would like to say a word about public fields, notice that this is not a typical public field... It is marked as final and thus the pointer is unmodifiable preventing the first weakness of a public field. The second weakness is the ability to mutate an object since there is no direct access to the object other than via the get/set methods encapsulation is preserved just as it would normally be preserved! Now lets discuss the issues above one by one and see how they are solves!
    The Property templates provide capabilities like observation, and annotations provide validation among other features. Future plans also include an object/relational mapping capability.

    Threaded Messages (16)

  2. Public fields[ Go to top ]

    Why not use methods instead of public fields? public interface NewBean { Property x(); } public class NewBeanImpl implements NewBean { private Property x = new PropertyImpl(); public Property x() { return x; } } That would be much more flexible.
  3. Joda Beans[ Go to top ]

    A quick survey of the project goals reminds me of Joda Beans [1] from a number of years ago. I wonder why the Joda Beans project died off? And how is Bean-Properties any different? http://joda.sourceforge.net/beans.html
  4. I have to say I don't agree with much of the post and the arguments for exhibiting properties dynamically in this way. If you read the post, the "10 Things" difficult to achieve with getters/setters are arguable, at best. This does, however, reasonably demonstrate the power and simplicity of generics. I'd argue if you're just after auto-generation of the getters/setter directly for a field, we need a simple addition to the language: public int rw property x; for a read/write property or similar. But propertis are not always related to field members and there may be some logic behind the getting or setting of a "property". Food for thought... I'll be posting to TSS soon regarding a new technology related to beans, expressions and other stuff as we approach launch of the BeanPlanet framework. Hopefully I won't be flamed for these somewhat critical comments today. Fact is, I think the beans/reflection APIs have stood the test of time very well: pre-Spring stuff I worked on with Rod Johnson, Spring itself which uses beans in its configuration, countless app server and other IOC frameworks use beans. The list is endless but there are some calls for a new incarnation. I look forward to bringing some beans related stuff to the table. Best, Gary Watson _______________________________________________________ BeanPlanet.org (site in-progress ...)
  5. Bean Spec Update Proposal...[ Go to top ]

    In regard to bean properties, what I'd really like to see is this... At the interface level, a properties could be defined like this: public interface MyBean { property rw long id; property rw String message; property rw List fungi; property rw MapaddressEntry addresses; } You'll notice that I'm actually giving names to the collection items ("fungi" is a collection of "fungus" items). Likewise, I'm giving names to the key and value of a map entry, "description" and "address" as well as the map entry itself ("addressEntry"); This would produce the byte-code equivalent of: public interface MyBean { // basic property methods... public long getId(); public void setId(long id); public String getMessage(); public void setMessage(String message); // list property methods... public List getFungi(); public void addFungus(Fungus fungus); piblic setFungus(int index, Fungus fungus); piblic removeFungus(int index, Fungus fungus); // map property methods... public Map getAddresses(); public Address getAddress(String description); public void putAddress(String description, Address address); public void removeAddress(String description); } The "indexed" set and remove methods are generated because the property is a List. If this were a general collection or set, the methods would be slightly different. For example, there would be no indexed set method, and the remove method would only take one parameter, the object to be removed. To implement the above interface, one could implement any of the methods manually. Or, for quick implementation, bind them to fields... public class MyBeanImp { bind protected long id = -1; bind protected String message = null; bind protected List fungi = new ArrayList; bind protected Map addresses = new HashMap(); } This would produce the byte-code equivalent of: public class MyBeanImp { protected long id = -1; protected String message = null; protected List fungi = new ArrayList; protected Map addresses = new HashMap(); private List unmodifiableFungi = Collections.unmodifiableList(this.fungi); private Map unmodifiableAddresses = Collections.unmodifiableMap(this.addresses); // along with all the implementation methods that you might expect... // the unmodifiables would be returned in the get methods... } You could mix between binding properties to fields, and manual method implementation. This gives you full control over what properties are (they needn't be actual fields). And when you do want to bind properties to fields, you still have full control over what exact types the fields are, their modifiers (public/protected/private), and their initial values. The real power of the above would come at bean introspection time. You could access the properties of a bean from an introspector with methods like: public List> getProperties(); public Property<?> getProperty(String propertyName); public CollectionProperty<?> getCollectionPropertyByItemName(String itemName); public MapProperty<?, ?> getMapPropertyByEntryName(String entryName); etc... While the Property interface would have methods for setting and getting property values, finding the property type etc. A CollectionProperty would extend Property and define methods for finding the item name, the item type, and adding/removing items to/from the collection property. Likewise, a MapProperty would define map-specific methods. With a solution like this, the developer doesn't loose any customization of property "accessors", has a quasi code-generation tool that reduces typing, has both static and dynamic access to properties, and yet everything is still checked at compile time. With the addition of collection properties and map properties that give names to the items of a collection, and the entries/keys/values of a map, you gain a very useful tool for representing your object graph in XML, dynamic GUI generation, etc. The bean spec is feeling its age a little, and with a little work, we can bring it up to date, while remaining backwardly compatible to the existing spec. NOTE: The formatting of greater-than and less-than signs in generic types get messed up a bit in the post for some reason.
  6. I'm the author of the above project. This is not a 1.0 version only its release from incubator, the project is roughly 1 month old. However, it already has some preliminary proof of concept JDBC bindings as well as functional validation and Swing binding. Possible binding to JSF/Echo2 is also very possible. Notice that what is probably the greatest advantage of this approach is the ability to type safely point at properties which is demonstrated by the ORM article: https://bean-properties.dev.java.net/orm.html This allows to separate concerns from beans which is something that is rather complex with the current API's, in order to mimic it there is usually extensive bytecode generation. Still many things aren't possible even after all of that generation which isn't free.
    Why not use methods instead of public fields?
    Public fields are encapsulated by methods, they can be overridden just by subclassing in an anonymous inner class. The advantage of this approach over a method is that you write a single line of code that is fully introspectable and manageable by the VM. With a method you would have to both have an actual field and the method + the internal methods for mutation.
    Joda Beans
    Its mentioned in the FAQ: https://bean-properties.dev.java.net/faq.html Joda Beans is a part of the inspiration although I took a different approach...
    I have to say I don't agree with much of the post and the arguments for exhibiting properties dynamically in this way.
    I'd actually like to hear why? I might argue, but I would appreciate constructive criticism and I hope this isn't a flame. I would also appreciate if you can find anything wrong with the 10 things article.
    But propertis are not always related to field members and there may be some logic behind the getting or setting of a "property".
    The great thing about the properties implementation is that it is in essence a set of clients and interfaces, your field can just be a class that invokes logic on a different class. One of my earlier experiments with DB binding was building an SQLProperty implementation, this didn't work out as well as I had hoped because of the result sets cursor but the idea is the same. The advantage here is that you can reuse these property delegates e.g. there is a "delegate property" explained in the tutorial that is defined as a property exposed by a bean encapsulated within the bean see the end of: https://bean-properties.dev.java.net/tutorial.html
    The real power of the above would come at bean introspection time. You could access the properties of a bean from an introspector with methods like
    Assuming a language change that would allow such a code, that language change would be remarkably complicated and less extensible. Still even then when you access the method that returns a Property object such an object would either have to be formed on the fly by the VM or stored in the object permanently. Both approaches are inefficient and don't provide any advantage I can see other than syntactic "taste". Bean properties can be returned by methods in an interface just as well, the only difference is that you don't have to and it must be in addition to the field.
  7. Shai Almog[ Go to top ]

    Hi Shai, I think your project has some interesting ideas. However, with this convention, how would you define properties on an interface? I don't see anyway of doing this using fields instead of methods. This is why a "property" keyword would be very useful, in my opinion. Then at the interface level, you could have something like... public interface MyBean { property rw long id; property rw String message; property rw List fungi; } And an implementation... public class MyBeanImpl implements MyBean { property protected long id = -1; property protected String message = null; property protected List fungi = new ArrayList; } ...and the methods that would be generated, in this case, would be something like... public long getId(); public void setId(long id); public String getMessage(); public void setMessage(String message); public List getFungi(); public void addFungus(Fungus fungus); piblic setFungus(int index, Fungus fungus); piblic removeFungus(int index, Fungus fungus); This way interfaces can define properties. Also, this saves you from writing boiler-plate get/set/add/etc methods, but still allows for custom overrides by manually implementing the get/set/add/etc methods. It also allows you to define property fields (if there is a field) as private or protected. And, this too, would be backwardly compatible.
  8. Re: Shai Almog[ Go to top ]

    However, with this convention, how would you define properties on an interface?
    Technically thats quite easy, you just define them in a method just like you would and in a field. The field is required since it managers the 1 to 1 relationship between bean and property. The method is defined if you want to access the beans property through an interface. e.g.: interface I { public Property prop(); } class C implements I { public Property prop = new PropertyImpl(); public Property prop() { return prop; } } Notice that since Property is already encapsulated I only need an access method and could use either i.prop().get() or c.prop.get() This is useful as long as this usecase isn't common, since even EJB has abandoned the idea of specifying all the properties in the component interface I can't think of a reason to do that often.
  9. Re: How to specify the properties[ Go to top ]

    Hi Shai & Fox I think the ideas are converging on this. I like the previous examples of specifying them (I'll use Fox's example here as it is more complete than my version specified even earlier): public interface MyBean { property rw long id; property rw String message; property rw List fungi; // plus ... property r int age(); property rw String name(); property w Date dob(); property rw Set favoriteColours(); // English spelling #;-) } the default could just be to auto-genrate a field and the getters/setters for the developer and would be 100% backwards compatible with th current java class spec. Perhaps the auto-generate functionality could be configurable, allowing for Shai's Property field type and accessor to be generated instead? Thx, Gary ____________________________________________________ BeanPlanet.org
  10. Re: How to specify the properties[ Go to top ]

    Hi Gary, The main problem I have with the property keyword is that it would hardcode a solution into the language. The property keyword is very limited in some of the more complex use cases such as observable and validatable properties. Remi Forex has made some suggestions on the subject of observability but they require a "magic" method on the bean to fire events and doesn't solve event binding or compiler checking of properties. E.g. to listen on a property rather than add a listener to "myProperyName" you can add a listener to bean.property no string used. This is important since the compiler will verify that such a property exists. Validations and other complex behavior such as binding etc. is hard to define in the property keyword without building things into the language. Sure annotations can be used and a bean container concept like my approach can be used as well, but that might be a technical problem.
    Perhaps the auto-generate functionality could be configurable, allowing for Shai's Property field
    type and accessor to be generated instead?
    I have given this some thought when I started, but came to the conclusion that the use case is weak. It would save some typing and make the code look like a regular field, but why would we need that? Besides aesthetics which are subjective, the code is not considerably more verbose than the property keyword so I can't think of a real benefit. Shai.
  11. Bad smells[ Go to top ]

    I never liked those object design styles that became popular with Java "Beans" - people where educated to think of objects in terms of "getters" and "setters". You know, this style of defining classes which are nothing else but simple data value containers. And nowadays, with all these XML clutter leading to more "beans" style Java "objects" and those emerging scripting languages like Groovy and their trials to make things simpler, it becomes even worse. There is no shame on making all the inerts of objects public, violating OOs information hiding principle. These advocates of doing things simpler just forget the other part of the famous sentence "Keep things simple as possible , BUT NOT SIMPLER!".
  12. Re: Bad smells[ Go to top ]

    I never liked those object design styles that became popular with Java "Beans" - people where educated to think of objects in terms of "getters" and "setters". You know, this style of defining classes which are nothing else but simple data value containers.
    I would like to agree, but the tide of convention is against us. Most frameworks and toolkits demand getters and setters. There are places where the bean convention makes sense - say the model that a GUI attaches listeners to, or injecting dependencies into a object via an interface. However, many of the uses I see are for DTO type uses which use getters and setters purely out of convention. Given that we must use these frameworks and/or conform to convention so that other understand out code, I really don't see a reason for designing a replacement.
  13. One stuff i miss a lot from the Delphi language is the properties. The propertioes are described here: http://www.delphibasics.co.uk/RTL.asp?Name=Property It is very nice to not have to code the getters and setters and still not to show the private member and be able later to add a setter to ensure a constrain.
  14. I'm quite familiar with Delphi properties, bean properties emulate them but IMO in a far more powerful way. Check out this article: https://bean-properties.dev.java.net/10things.html These things are remarkably hard to do properly with Delphi style properties.
  15. One stuff i miss a lot from the Delphi language is the properties. The propertioes are described here: http://www.delphibasics.co.uk/RTL.asp?Name=Property

    It is very nice to not have to code the getters and setters and still not to show the private member and be able later to add a setter to ensure a constrain.
    Amen mate. The reinvention of the wheel - reloaded. A very similar approach is available in c# btw. And I would surely hope that the properties find there way into a future version of the language.
  16. Properties are a hackjob in java. When you access a method from a class, even from ancestor castings of that class, it uses the most recent implementation of that method signature. so: class A { public int call() { return 1} } class B extends A { public int call() {return 2} } public static void main(String[] args) { A a = new B(); a.call() == 2; // a.call() does NOT return 1 } When you "access" a variable value or assign it directly, this OOP mechanism is not in effect, so: class A { public int call = 1 } class B extends A { public int call = 2 } public static void main(String[] args) { A a = new B(); a.call == 1; // NOT 2, unlike method calls. } A property accessors convert variable access inside of classes to a mechanism that mimicks the core OOP mechanism. thus: class A { public Property call = 1 } class B extends A { public Property call = 2 } public static void main(String[] args) { A a = new B(); a.call.get() == 1; // NOT 2, unlike normal property // boilerplate code } So your Property while it does eliminate boilerplate code, is no different than having public variables in classes. Unless I missed something fancy. If you had something really crazy like (I'm dropping your beautiful generics for simplicity sake in the constructor here): public class A { public IntegerProperty prop = new IntegerProperty(5,this); } The key thing there is the this keyword. This ties the property to the class that contains it. Then your accessor method uses this back-reference to look for newer implementations of the variable in descendent classes via reflection, just like the java method resolver. So when you do a.prop.get(); the Property does does something like this: class Property { Object backrefence; int value; String fieldname; public Property(int initialvalue, Object backref, String name) { value = initialvalue; backreference = backref; fieldname = name; } int get() { // this should get you the most recent class definition Class clazz = backreference.getClass(); // now loop, looking through each class until you find // the desired property in the most-recent class def while (true) { if (ClassHasField(name)) ReturnFieldValue(name,clazz); else clazz = clazz.getSuperClass(); } } // same type of thing for assignment } Unless I missed something.
  17. Carl, didn't you post the exact same comment in the JavaLobby thread here: http://www.javalobby.org/forums/thread.jspa?messageID=92139771#92139768 I responded relatively fast here: http://www.javalobby.org/forums/thread.jspa?messageID=92139771#92139771 I don't see why you needed to cross post? Do you disagree with my response?