Evan Summers's Blog

A Short Note About Properties And Politics

Another reason why we need properties in the language is ... for "native" database queries, eg.

Person warMonger = createQuery(new WhereLikePredicate(Person.name, "G.W. Bush"));

where Person.name is a property, ie. Person.class has an accessor getName().

In this case, our JPA queries are refactorable, yippee! If you have a real query, it's more obvious (no offense), eg.

      SelectQuery query = createSelectQuery();
      query.setTitle("Fido's in region %s", regionId);
      query.selectAll(dog);
      query.selectExclude(dog.address);
      query.select(organisation.organisationId, organisation.organisationName);
      query.join(dog, organisation, region);
      query.whereEquals(region.regionId, regionId); 
      query.whereStartsWithIgnoreCase(dog.dogName, "fido"); 
      query.whereIsNotNull(organisation.organisationName); 
      query.whereIs(organisation.active, true); 
      query.orderBy(organisation.organisationId, dog.dogName); 
      query.limit(100); 

as presented in the SQL Objects precursor to the Jelly Bean series.

Having JPA queries in strings (and any references in strings) is something that i hope people cannot tolerate going forward!? ;)

Comments

• It's too bad that the people in charge don't understand how extremely useful a correctly implemented property addition to Java would be and how it would simplify coding a lot, yet still be strongly typed. Instead we get the worst alternative. A new technology (Beans Binding, JSR 295) that will at worst invalidate a good property solution forever and at best create a new AWT/Swing-like dependency mess.

  I urge Sun to reconsider this and instead do a good, reliable and flexible property solution. They've got until 2009 to craft it, so there should be plenty of time. :)

  Posted by: mikaelgrev on July 07, 2007 at 11:00 AM

• Thanks Mikael! My impression is that JSR295 was, and is, about getting some beans binding "here and now" ie. not dependent on "properties in the language." Personally speaking, i want binding "here and now" as a jar i can use today... but my biggest bestest wish for language changes is... PROPERTIES! Happily for me, both wishes are coming true :) Please everyone join http://beansbinding.dev.java.net - and shout out! You know who you are - you're a java developer aint yer?! so shout out!

  Posted by: evanx on July 07, 2007 at 11:40 AM

• Evan,
  A problem is that no one from Sun officially want to discuss if and when properties are coming. I can't remind me of an occasion where discussion regarding language changes has been taking place outside the inner circle, other than through worthless poles.

  If properties are coming, and I really hope they are, it's really important that they are done right. We don't need some language purist that's holding the pureness of the inner workings of the typing system within HotSpot as the primary goal. We need a properties solution that is solving real world problems and doesn't miss the target. We need to start with the use cases and at the last stage make the unimportant decisions whether #, -> or . (dot) should be used.

  I just get the feeling that when JSR 295 is in the platform, as it surely will be, the momentum for adding real properties will halt since the binding to those new properties can't be compatible with the JSR 295 EL coupling, AFAIU.

  Maybe I'm just pessimistic here, but on the other hand there's no one from Sun that is taking on the discussion about this.

  Posted by: mikaelgrev on July 07, 2007 at 01:33 PM

• 
  looking at the discussion on the beansbinding mailing list, it seems there's a plan evolving to support a Property interface with a couple of implementations (eg. BeanInfoProperty wrapping PropertyDescriptor, and ELProperty supporting EL) - hopefully that will be flexible so as trivially add support for language properties when those become available - and one can use language properties or not, as you wish

  In the meantime, i personally typically create a BeanInfo class for each object whose properties i want to reference, eg. as a presentation model, or a entity, or whatever - as presented in "Gooey Bean Info" and "Bound Gooey Beans"

  Because i have those objects, i use them to specify meta data that could otherwise be done using annotations on the bean - eg. validators, labels, et al - but i find it more convenient and programmable to specify these in a regular java class rather using annotations.

  When language properties come out, it would be nice to be able to attach your own meta data objects to the property object, but otherwise one could use annotations.

  Mikael, i don't now where and if the discussion about properties in the language is happening. If not for java7, then once opensource java7 is out, maybe someone will provide a patch supporting properties, and that can get enough support to become a JSR for java8?

  
  

  Posted by: evanx on July 08, 2007 at 02:46 AM

• I think the debate is over. As with operator overloading we have two irreconcilable groups: the absolutely essentials and the no ways. There may be a third group watching from the sidelines, but determined not to join the either of the combatant groups.

  Posted by: mthornton on July 08, 2007 at 07:32 AM

• It is possible to do that with Hibernate Criteria (with a different syntax).

  Posted by: schumnana on July 09, 2007 at 01:21 AM

• 
  how can you reference fields eg. Person.name, if not by string eg. "name." Strings are not refactorable/toolable eg. autocompletion, prompting, error highlighting. That's why i would like to have property references that are not strings, but "property literals" eg.

  public class PersonProperties extends BeanInfo<Person> {
  public final PropertyDescriptor name = getPropertyDescriptor("name");
  ...
  public PersonProperties() {
  super(Person.class);
  }
  }

  
  but where the language creates such reflective objects for you, for referencing properties eg. in "native" queries sans strings, and the IDE is cognisant of them for refactoring, error highlighting et al

  a terrible state of affairs is that because JPA queries are in strings, your entities become non-refactorable, otherwise you break all your queries! and of course there's no help in writing the queries either, eg. prompting, autocompletion and error highlighing.

  Posted by: evanx on July 09, 2007 at 02:12 AM

• This is all already possible without a language change using the bean-properties project ORM code. This is implemented but my ORM development skills fall short of Gavin Kings (mapping to columns is trivial but relationships are just hell). Anyway this does work with bean-properties and I started working on a Hibernate port which would fix the criteria API (schumnana the bold is for you) to support compiler checks of the fields rather than use Strings. Unfortunately I don't have enough time to work on that sort of project....

  Posted by: vprise on July 09, 2007 at 10:04 AM

• mikaelgrev, as evanx pointed out, we are moving JSR 295 towards a more flexible property interface. EL will be supported but not required. In addition to allowing developers to plug in other property resolution (XPath for example) a goal is to be compatible with any first-class property support that may be added in the future. Please check out the users@beansbinding.dev.java.net alias archive for more details. It can be found from the project homepage. Thanks!

  Posted by: shan_man on July 09, 2007 at 12:02 PM

• Shai, that's interesting, i didn't realise you were working on ORM with properties. I've been wanting to build such a framework too, because i love ORM/property arena. But it'll be very many months before i get around to that... Right now i'm hectically busy with some web stuff, and also itching to finish off my "Gooey Beans" series... and going travelling overseas in a few weeks, for a few weeks/months...

  Posted by: evanx on July 09, 2007 at 12:27 PM

• Shannon,
  That's, well, Excellent!

  I guess I will cut you guys some slack then. ;-)

  If and when native properties are going to be discussed, please let me know.

  Posted by: mikaelgrev on July 09, 2007 at 12:43 PM

• Its all in CVS/code drops and there is a bit of an outdated document on the website (https://bean-properties.dev.java.net/ for those who don't know).
  Sadly I'm not really working on this particular feature at the moment because it just proved too hard for a weekend project... I should probably pick it up again because a project I'm working on with properties (commercial tool) needs DB storage and using JPA just feels "wrong". But then again I also need to work on the network layers and a million and one things to get this working...

  Posted by: vprise on July 09, 2007 at 12:45 PM

• Not only the people in charge don't understand the importance of first-class properties and closures to get rid of string references. Suppose you have to display a bunch of beans in a table (Swing, JSF, whatever) with a certain sort order, allowing the user to change the order by clicking on a column header, whereby the beans may come from JPA or from an in-memory list. Legions of Java developers would accept to implement such a trivial task by using 3 different languages (Java, EL, JPA-QL), forget all what they have learned about the benefits of type safety, happily abandon their IDE's refactoring capability, and wouldn't even think about the obvious question: Why can't we express this bread-and-butter stuff in pure Java?

  Posted by: scotty69 on July 09, 2007 at 12:57 PM

• Sorry evan but that query is just unreadable and in my mind that means unreasonable
  Personally I dont get the need for properties as a regular developer, perhaps it is useful for component building and IDE functionality. But as far as building business apps there is no way in hell I am embedding SQL into my source code unless it is autogenerated.

  It seems to me people thrust far too much logic into their UI code - sorting on a table based directly upon a bean??? I'm sure Im missing the point but all my POJOs implement an interface which enables table binding, sorting etc.
  Bottom line I dont like operating overload and I dont like properties because I like to minimize what I cant see and trace.

  Posted by: aronsmith on July 09, 2007 at 07:45 PM

• 
  aron, that query example, i wrote the query API to be as close to SQL as possible - it was for BI reporting servlets running big queries across big messy databases.

  I added various conveniences, eg. selectExclude() means exclude that property from the select. So you can selectAll() and then selectExclude() - eg. exclude long text fields eg. address for performance sake, but otherwise include all the properties. Most of the methods involved WHERE predicates. I don't think it's that bad!? You should have seen the equivalent SQL queries, eg. once all the joins had been generated!

  i'm not suggesting that people embed SQL - we embed JPA queries these days. EJBQL is modelled on SQL of course, but using the nice mapped names. Unfortunately the query is an embedded string, so you can't refactor their entities properties without breaking your queries.

  So to my mind JPA queries in strings are terrible because you get no refactorability and toolability. No completion et al.

  I guess IDEs could get fancy and support JPA queries, ie. refactoring, syntax highlighting, navigation, completion, error detection et al. But it's not just JPA queries that are essentially property-bound, ie. referencing properties (of entities).

  if properties were introduced in the language, then people who don't care about refactorability and toolability (no offense), don't have to use them! I don't understand how developers would wish to deny a feature that the language desperately needs, to deny other developers what they need, just to avoid having something new to contend with!? Software development has always involved contending with new things, eg. new toolkits, new languages, new features, so...

  Posted by: evanx on July 10, 2007 at 12:08 AM

• aron, the benefits of this approach can be seen if some of the WHERE-predicates are optional, depending on the user's input. If you don't use an API-like mechanism as the above, then you have to perform a weird (EJBQL) query-string concatenation, which is by far less readable and much more error prone.
  Defining an interface for table binding and sorting just shifts the problem to the implementor of the interface: Either you code by hand (which again means messy query string concatenation), or you use a tool for query generation (which has some other drawbacks and again leads to the question: Why can't I express such a common thing like sorting and table binding in the Java language itself?).
  You might have a look at the Hibernate Criteria API or at db4o's "native queries". These APIs lead to highly readable code, but they all suffer from the fact that they also need strings for identifying properties. And you even might have a look at Microsoft's LINQ-project (language integrated native query), which is the most radical approach I have ever seen in this area.

  Posted by: scotty69 on July 10, 2007 at 01:05 AM

• just as you say scotty, the queries i used it for were servlets with a large number of optional parameters for the query. For convenience, i added where predicates like

  
  query.whereEqualsNullable(person.name, name);

  
  where if name was null, that WHERE clause would not be included. Otherwise one would write,

  if (name != null) query.whereEquals(person.name, name);

  
  Actually these were all convenience methods eg. for

  query.where(new EqualsPredicate(person.name, name));

  What i wanted was convenient completion, on query object, and the entities/properties (ie. java mapping of the SQL tables and columns), and i got that, and enjoyed it immensely, as i wax lyrical about at the end of "SQL Objects."
  

  Posted by: evanx on July 10, 2007 at 01:21 AM

• Evan
  I don't think anyone is against the property keyword because its "something new"... People are against it for many reasons such as a potentially bad implementation (which is the current approach being discussed by the JSR guys), for duplicate syntax (when using the dot notation) for "odd" syntax (when using the pound, arrow etc... notations) etc...
  People are generally weary from language changes in Java because they were done in such a rush and so badly in the past that we just don't trust Sun/the JCP to do anything remotely decent when it comes to a language change.

  Posted by: vprise on July 10, 2007 at 01:23 AM

• Agreed, Generics suffer badly from erasure (backwards compatibility issue), but property literals are less intrusive. They are a just a quite natural generalization of already existing class literals: Foo.class is better than Class.forName("Foo"), right?

  Posted by: scotty69 on July 10, 2007 at 01:57 AM

• along those lines, if Person#name referrenced a static PropertyDescriptor, like Person.class is a Class instance, i'd be very happy, as i've always said. I know the discussion of "properties" is around getters and setters, ie. like C#, but personally all i want is property literals!

  Posted by: evanx on July 10, 2007 at 02:31 AM

• Groovy provides a LINQ-style approach that doesn't even require data-access objects or data transfer objects (based on Groovy SQL). This is described in Groovy in Action, and no, it's not Grails, it's standard.
  - Chris

  Posted by: chris_e_brown on July 12, 2007 at 08:57 AM

• Chris, sounds very interesting! is there a web link?

  Posted by: evanx on July 12, 2007 at 09:42 AM

This work is licensed under a Creative Commons License.