Property-Alliance

History of JavaBeans and Properties discussions

This document is an attempt to capture discussions about properties and beans.

Property types

Property terminology, Oct 2007

  • Type 1 = bean-independent (per-class, meta-property) - stateless and mainly for tooling
  • Type 2 = bean-attached (per-instance) - stateless property, value on the bean
  • Type 3 = stateful (property object)
  • Type 2 and 3 have same/similar API so good abstraction can get both

Forums

Wikipedia

Javalobby

  • JGoodies Binding, Mar 2005
    • not especially relevant, but code still around
  • Main discussion based on Ideas from Danny Coward, Jan 2007, 136 comments, IMPORTANT
    • immediate expansion to read-only, write-only, bound
    • Danny Coward: “simplicity, readability and productivity are always key considerations to look at”
    • Ray Cromwell: “The issue isn’t just typing the boilerplate, it’s reading it”
    • Ray Cromwell: why not get IDEs to do job rather than language change,
    • Marc Stock: getters/setters “should be like the default constructor…it’s just there even though you can’t see it”
    • Stephen Colebourne: misses opportunity of fixing stringly-typed property names in frameworks
    • Brendan: Mentions null in chains of calls such as person.address.city
    • various discussions of details and syntax
    • Johan Compagner: Wicket has new PropertModel(new Person(), "name")) which should be a standard property
    • proposal tries to put code in annotations, again the variety of property methods is the issue
    • Stephen Colebourne: “bound property objects greatly reduce the need for closures” (before project lambda)
    • Cowwoc: claims properties break encapsulation
    • Alex Prayle: Can be done now (type 3)
    • Steven Coco: Need detailed control over Javadoc on generated code
    • Cay Hortmann: Two approaches: “(1) Make JavaBeans properties more tolerable. (2) Ditch JavaBeans altogether and do properties right. My guess is that the first approach will win out”
    • discussion of performance of type 3
    • lots of discussions about person.surname calling person.getSurname() and issues involved, is it similar to operator overloading?
    • Charlie Hubbard: “I’d love Java to move more towards the Universal Access Principal”, all fields access is indirected via methods
    • “Q: I don’t understand why people who support this change don’t just use public fields. A: Because fields cannot be declared in an interface.”
    • Carsten Saager: “This points less to a language extension, more to some standardized (aka platform) property classes”
    • opposition to language change in general (1.4 to 1.5 migration pain shows through)
    • Joao Del Valle: “more natural to have a language that understands basic constructs than having to generate them all the time”
    • Marcos: “Getters and setters are one of the most painful things of Java”
  • Why Java Properties are BAD, ugly and uncomfortable, Feb 2007, 96 comments
    • anti-properties original post (don’t add anything new)
    • Shai Almog: “problem is that a language based solution is not as simple as many proponents would have you believe”
    • Shai Almog: “requirements for client based solutions vastly differ from the server requirements as the only things they have in common is the get/set/is approach and the name JavaBean”
    • Andy Tripp: “Most of these proposals are fatally flawed in that they don’t spell out what the problem is before proposing a solution”
    • discussion about one way to do things and operator overloading
    • Alexander Hristov: JavaBeans are bad critique (GOOD)
    • Jonathan: Easy to find properties from common prefix, “I type ”.get“ and then I immediately know all of the accessors for that class”
    • Naiden Gochev: “Java Rocks and i love it at 99% becouse of the setXX and getXX methods” (can find in IDE)
  • Pretty Please, we need Properties. Here’s the Middle Ground, Feb 2007, 59 comments
    • Proposal from Mikael Grev
    • Declare using public property String surname = "";, generates normal getters and setters for access
    • Adds ability to refer to meta-property in compile-checked way - person#surname
    • lots of discussion about value of language change vs type 3 property objects vs do nothing
  • Beans Binding (JSR 295) and Properties on JDK7 , Sep 2007, 14 comments
    • author unclear of benefits of property language feature (re paradigm shift issue)
    • Richard Bair: “there will be a significant portion of properties (20%?) that will require custom code”
    • lots of consideration of lines of code, conceptual shift seems hard to grasp
  • Bean-dependent or Bean-independent Properties?, Oct 2007, 50 comments
    • various discussions and confusions, little about syntax, lots about bean-properties project
    • reminder of importance of collections to property querying
  • Typesafe property literals, May 2014
    • “We found that once you have these literals, they just turn out to be useful in many cases.”
    • uses Lombok to generate

JavaPosse

  • Discussion 1 and Discussion 2
    • neither that interesting
  • Episode 145, Oct 2007
    • Joe Nuxoll defines language level property as (based on Pascal, C#, C++) statically typed member (like field)
    • with behaviour (ability to control getter/setter)
    • can have non-public properties but generally public
    • JavaBeans is a pattern/convention
    • language-level property would be part of reflection
    • write components not classes (properties and events, go together)
    • can be virtual/calculated
    • property is encapsulated, hides internals of storage of the value
    • Suggests beans-binding misusing word “properties”, discusses how binding works
    • Two competing binding APIs in Sun (beans-binding and data-provider, ended up in NetBeans)
    • Claims component-based is a paradigm shift from regular object-oriented
    • meta-data critical to enable tooling
    • Emphasises can’t really do properties without events and vice versa
    • Single location for Javadoc and annotations
    • Once had Javadoc version that merged getters and setters into properties section

Artima

  • No getters and setters, Jan 2009, Javier Paniza
    • responding to no properties in Java 7
    • proposes AOP to rewrite field access via getter/setter

Blogs

Alex Miller

  • Java 7 property links
    • lots of links
  • Opinion, Jan 2007
    • argues that public field access should be rewritten to be via getters thus creating properties
    • comments include anti-mutable and anti-encapsulation
    • comments include swing binding is bigger problem than getter/setter generation

Stephen Colebourne

  • Property objects, Jan 2007, 20 comments
    • proposes objects for properties (property and meta-property)
    • proposes generating propertySurname() alongside getSurname() and setSurname()
    • focus on binding
  • More on property objects, Jan 2007, 5 comments
    • uses person->surname to access property object and Person->surname to access meta-property
    • discusses reflection vs property objects as fields
    • comments discuss meta-property vs property and use of property for “isDirty” or “originalValue”
  • Bean keyword, Jan 2007, 6 comments
    • discusses using bean instead of class to allow syntax change within
  • Update on properties, Sep 2007, 10 comments
    • discusses beans-binding JSR and Remi’s proprty compiler code
  • Beans and properties, May 2011, 22 comments
    • review of JavaFX properties
    • comments include desire for multi-level propeties (person.address.city)

Matt Hicks

  • Discussion, Aug 2010
    • suggests type 3 properties
    • public final surname = new Property<String>(null)
    • person.surname.set("Foo"), String surname = person.surname.get()
    • lots about Scala
    • “major reason to use the Property concept instead of methods … is encapsulation”
  • Beans should be deprecated part 1 and part 2, Jul 2009, 9 comments
    • outlines sgine property approach
    • create paths of properties, binding, container for properties and dependent properties
  • Death of beans, Jul 2009, 7 comments
    • argues for type 3 properties

Mike Heinrich

Cay Horstmann

Alex Buckley

  • Properties in Java, Apr 2007
    • Finds proposals unsatifactory (simple props too simple to generate, GUI props too hard)
    • Related Peter Ahe comments on properties, Feb 2007

Hans Muller

  • Property syntax, Jan 2007, 27 comments
    • written from perspective of a GUI developer, argues for handling harder GUI scenarios
    • comments both for and against

Mikael Grev

  • Proposal
    • 2007, A proposal for properties in Java 7
    • GUI focused, based on bound properties
    • person.surname.get(), person.surname.set("Foo"), person.children.add(child1)
    • optional syntax String s = person#surname, person#surname = "Foo"
    • distinguishes simple/collection/indexed/mapped/subBean properties
    • briefly mentions stateless (meta)properties but not suitable for non-framework use
    • Project and Property class source

Evan Summers

  • Dot notation for access, Apr 2008, 13 comments
    • toys with person.surname.property
    • comments mostly favour dot over arrow for access to properties
  • QBeanInfo, Dec 2006
    • a mechanism for declaring metaproperties called QProperty
    • focussed on GUIs, includes date format pattern
  • Bind meta to bean, Feb 2007
    • allows person.beanInfo.surname.firePropertyChanged() where person.beanInfo is a public field accessing the metabean-like QBeanInfo
  • Properties for SQL, Jul 2007
    • emphasising refactoring in SQL queries
  • Problems and solutions, Jan 2007
    • list/table of problems, solutions and whether they need a language change
    • argues that writing getters/setters not that big a deal but IDEs should help more
    • argues that stringly typed property references should be better (lang change)
    • bound properties could be AOP injected
  • Gotcha, Jan 2007
    • discusses language change to obtain PropertyDescriptor (type 1) and BoundPropertyDescriptor (type 2)

Fred Simon

  • Abstract enum blogs
    • includes entry showing abstract enum for properties
  • Extended enum home
  • Kijaro abstract enum Property class
    • with name, type and declaring type (type 1, bean independent)
  • Wild beans part one and part two, Jan 2008
    • key summary of experiments in Remi’s property language change (for type 1 and 2)
    • lots of code demonstrating how abstract enum and standard JDK type 1 and 2 classes would satisfy the need
    • uses public property String surname; syntax
    • ultimate solution uses public property objects and person.surname.get() behind the scenes

Yardena Meymann

  • Properies for Java simple intro, Nov 2007
  • Static yet dynamic, Nov 2007
    • using public static final Property<Person,String> name = new Property<Person,String> ("name") {};
    • to create a typed subclass of a general purpose Property (type 1, independent), but code can be in any
    • class, not just Person
    • See BeanUtopia

Kevin Bourillion

  • Value objects, related though not classic beans, Oct 2007
    • problems with current state of the world

Danny Lagrouw

  • Proper properties, Jan 2007
    • proposal that involves generating get/set methods for all fields on all objects
    • additional control via annotations

Eliotte Rusty Harold

  • Opposes properties, Jan 2007, 41 comments
    • lots of comments focus on avoiding all language change in Java (no longer a relevant debate)
    • blog argues that properties add nothing really new and are incompatible with old code
    • also argues against closures

Joe Nuxoll

  • Proposal pdf, 2004
    • uses public String surname get set to define property
    • access via person.surname = "Foo" and so on
    • lots of additional notes on events
  • Proposal blog, Aug 2010

Ricky Clarkson

  • Blog, Feb 2007
    • discussion, no clear conclusions (prefers existing beans to carry on working)

Kirk Pepperdine

  • Blog, Dec 2006
    • argues for OO solutions and properties are anti-encapsulation

Jesse Wilson

  • Proposal, Jan 2007
    • wants extensible property objects with decorators (observable, not null, etc)
    • proposes private @Property(ObservableProperty.class, NotNullProperty.class) String surname declarations
  • Proposal
    • type 1 bean-independent properties,
    • proposal doc not currently accessible,
    • access by String s = person#surname and person#surname = "Foo",
    • declare by public property Property<Customer,String> city = new BasicPropertyBuilder(property("")).nonNull().observable(##propertyChangeSupport).build();
    • or maybe public Long #id.
  • From Google Doc proposal,
    • “Properties are per-type, not per-instance. Anonymous classes are used for efficient property access. Properties are extensible using the decorator pattern”,
    • propose to generate field and inner classes directly accessing field,
    • open question on whether interfaces expose properties.
    // Bean-independent Properties, direct access:
    Customer customer = ...
    String city = customer#city;
    customer#city = "San Francisco";

    // Bean-independent Properties, access via a Property object:
    Customer customer = ...
    Property<Customer,String> customerCityProperty = Customer##city;
    String city = customerCityProperty.get(customer);
    customerCityProperty.set(customer, "San Francisco");

    // declare (getter/setter for legacy and implementing interface)
    public Property<Customer,String> ##city = property("");
    public String getCity() { return #city; }
    public void setCity(String city) { #city = city; }

    // compilation (before and after
    String city = customer#city
    String city = Customer.$p_city.get(customer)

    // compilation (before and after
    Property<Customer,String> customerCityProperty = Customer##city
    Property<Customer,String> customerCityProperty = Customer.$p_city
    
    // interface
    public interface Property<B,V> {
      V get(B bean);
      V get(B bean, V defaultValue);
      V set(B bean, V value);
      String getName();
      Type<B> getDeclaringType();  // maybe?
      Type<V> getValueType();  // maybe?
    }

Richard Bair

  • Proposal, Jan 2007, IMPORTANT,
    • “The JavaBeans pattern is not about breaking the encapsulation of the Person object. It is about exposing configurable state.”
    • “there is a big difference between a property, and a field. A Property is a concept, a field is an implementation”
    • “Any proposal must be backwards compatible with the existing JavaBeans spec! Leverage existing APIs and existing patterns where possible. Introduce as little as possible to get the job done.”
    • “you define a property, and then call a method ”getSurname()“. Where was that method defined?” (but no better alternative)
    • argues for keeping getter/setter (allows covariant return type overloads)
    • argues for property metadata being PropertyDescriptor
    • argues for bound properties (for GUIs) and states right code for them is hard
  • Reponse to Remi, Jan 2007
    • reviews and tweaks Remi javac changes
    • proposes no getter/setter generation (hidden magic code)
    String s = person.surname; // yields the value of the surname property
    Property p = person#surname; // returns the Property object for the surname property
    p = Person#surname; // also returns the Property object for the surname property
    Method m = Person#formatName(String); // holy toledo! Returns a Method object!

Remi Forax

  • Mixing beans binding and language change, Sep 2007
    • combines beans-binding project and javac language change
  • Initial take, Jan 2007
    • Discusses using get* and set* methods to define templates for getters and setters
    • suggests interceptors instead of language support for bound
  • Property impl v1, Jan 2007
    • supports property int x declaration and abstract property int x (forces manual getter/setter)
    • access via p.x
  • Why not bound, Jan 2007
    • lots of approaches to bound properties so not suitable for language change
  • Property reload, Jan 2007, IMPORTANT
    • allows public property String surname to compile, adjusted like C#,
    • “Unlike my first proposal, i think now that we must not have two ways to access to a property. So ‘dot’ can’t be used to access/change the value of a property”,
    • use getter/setter for value access,
    • gets Person.surname to translate to Person.class.getProperty("surname"),
    • thus Property<Person, String> prop = Person.surname,
    • properties are bound, usable in switch statement
   public class Property<B, T> {
      public Class<B> getDeclaringClass() {}
      public Class<T> getType() {}
      public String getName() {}
      public boolean isReadable() {}
      public boolean isWritable() {}
      public T get(Object bean) {}
      public void set(Object bean, Object value) {}
    }

    public class Class<T> {
      public Property<T, ?>[] getProperties() {}
      public Property<T, ?> getProperty(String name) {}
    }

Matthias Ernst

Shai Almog

Lois Goldthwaite

  • Pdf about C++
    • “If functional programming is ‘programming without side effects’, property oriented programming is the other extreme. Everything relies on side effects that occur as you update state.”
    • emphasises properties (with events) as a style of development as being very RAD/GUI based

Property implementations

Old Joda-Beans

  • 2000 - 2002,
  • Type 3 property objects such as StringProperty and BooleanProperty
  • Includes swing bindings, XML, XPath
  • JavaFX follows many principles from here

New Joda-Beans

  • 2010 onwards
  • Type 1 and 2, focussed on meta-property and meta-bean
  • Includes XML, JSON and binary serialization
  • Integrates with freemarker and MongoDB
  • Effective and efficient for server-side

XJava

  • Type 3 (stateful)

Bean-properties

  • Type 3 (stateful)

Majick-properties

BeanUtopia

Bean binding JSR-295

  • Blog version 1.0, Sep 2007
  • Blog version 1.1.1, Oct 2007
  • “abstract Property class, with two concrete implementations of interest: BeanProperty and ELProperty”
  • “Binding is now an abstract class representing a binding between two Property instances”
  • Type 1, with GUI bound elements, abstract classes instead of interfaces
  • Property surnameProp = BeanProperty.create("surname")
  • surnameProp.getValue(person)
  • surnameProp.setValue(person, "Foo")
  • surnameProp.addPropertyStateListener(person, listener)
  • Abandoned, but clear precursor to JavaFX
  • Project home page
  • Source code

Better bean binding

Bean binding and language support

Back to top

Copyright ©2014-2015. All Rights Reserved.

Version: 0.1-SNAPSHOT. Last Published: 2015-01-03.

Reflow Maven skin by Andrius Velykis.