Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Simple question about generated bean setX method  RSS feed

 
Jamie Lantzy
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A bean gen app we used in the past generated set methods in the following form:


Is there any point to this? When you get down to the byte code, does this impact performance one way or another (versus just setting the memberField regardless if it's already been set).
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't think of any reason why this makes sense, especially given the "==" comparison.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dithered over setters/getts versus direct field access way back when C++ was new. I finally decided that despite the nuisance value, setters and getters were better. Not all debuggers have a good, easy-to-use way of detecting changed fields. Also a setter allows the flexibility to add validation, logging, breakpoints, etc. And, occasionally, I end up changing the underlying data type, so the abstraction of set/get methods minimizes the impact on other parts of the program. I do a lot of datatype changes, which is why I have an especial antipathy for Hungarian Notation.

As far as overhead goes, I expect that the optimizer can detect simple set/get operations and inline them to direct access where feasible, so the ultimate generated code would potentially be identical using either approach, with the edge on flexibility going to the set/get methods.

Why test-before-set? This mostly makes sense in an ORM or remoting environment. Setting a value can cause a "dirty" flag to be set in the underlying metacode in cases where the metacode is naive and doesn't itself check for changes that don't actually change anything. So doing this can reduce the overhead in remote transmissions and result in tighter SQL code generation in an ORM system.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!