Course Schedule
Java Performance Tuning
Chania Crete, May 18-21
My RSS Feeds
Java 7.0 language feature considered harmful
posted Wednesday, 27 December 2006
I've just watched the Danny Corward presentation at the Prague JUG on what could be coming in the JSE 7.0. In that presentation he demonstrated the "->" operator. The purpose of the operator is to provide a short hand notation for properties. The syntax that we would normally use is;
a.setFoo( b.getFoo());
With the "->" operator we would see;
a->foo = b->foo;
How we'd currrently coding this is;
a.foo = b.foo where foo would have to be more visiable than private.
Data encapsulation has long been proven to be a useful design and coding abstraction. So much so that the evolutionary pattern of language design is more support for abstractions that support this important concept. The most significant advance was support for the encapsulation of both state and behavior (otherwise known as objects).
Objects are a natural evolution from data structures. In fact, the first C++ implementations were more about translating object like syntax into C syntax using CFront (C with classes) compiler. The biggest advantage of moving to objects from data structures is the further separation of representation from implementation. Separation of representation from implementation is a notion that has now found prominence in API design guidelines. This idea is supported by slogans such as "code to the interface, not the implementation".
Encapsulation offers many advantages including support of the DRY principle. As stated by Dave Thomas in an interview with Bill Venners;
"DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation."
In my opinion the most important idea in this quote is the phrase, "one authoritative unambiguous representation". The fall-out from this from a coding perspective is that not only is the representation encapsulated, the logic for managing the state is also encapsulated. If we (as developers) allow state to be exported we have lost our ability to maintain consistency in our internal state. We are depending upon the client to do the right thing and more importantly, if conditions change, the client to play along with the new rules of the game. The bigger the system, the greater the chance that the client won’t.
So if you’ve made it this far you maybe wondering what the hell does this have to do with the new language feature? Lets review the code.
a->foo = b->foo;
I don’t know what foo is nor do I really care but "a" better care and more importantly it should have a fighting chance to care. Using the operator ( or the "." on a (semi) public variable) means that "a" doesn’t even have a fighting change of caring. The integrity of the object has been totally compromised by a "cool new" syntax that encourages violations of encapsulation.
If this syntax can on encourage behavior that we don’t want than why on earth would the authors of the JSE 7.0 JSR propose such a change? My real answer is; since I’ve not spoken to the authors I don’t really know. However the evidence is the use case is ease of use for Java beans. Simply put, the spec lead for the next version of Java would like to change the language to handle an edge case while ignoring the potential of creating havoc in just about every other language use case.
So to answer Danny Cowards question, wouldn’t it be nicer if we could do something like to do something life a->foo = b->foo;. My answer is no. I think that Danny shares that view though we may want to make sure!
a.setFoo( b.getFoo());
With the "->" operator we would see;
a->foo = b->foo;
How we'd currrently coding this is;
a.foo = b.foo where foo would have to be more visiable than private.
Data encapsulation has long been proven to be a useful design and coding abstraction. So much so that the evolutionary pattern of language design is more support for abstractions that support this important concept. The most significant advance was support for the encapsulation of both state and behavior (otherwise known as objects).
Objects are a natural evolution from data structures. In fact, the first C++ implementations were more about translating object like syntax into C syntax using CFront (C with classes) compiler. The biggest advantage of moving to objects from data structures is the further separation of representation from implementation. Separation of representation from implementation is a notion that has now found prominence in API design guidelines. This idea is supported by slogans such as "code to the interface, not the implementation".
Encapsulation offers many advantages including support of the DRY principle. As stated by Dave Thomas in an interview with Bill Venners;
"DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation."
In my opinion the most important idea in this quote is the phrase, "one authoritative unambiguous representation". The fall-out from this from a coding perspective is that not only is the representation encapsulated, the logic for managing the state is also encapsulated. If we (as developers) allow state to be exported we have lost our ability to maintain consistency in our internal state. We are depending upon the client to do the right thing and more importantly, if conditions change, the client to play along with the new rules of the game. The bigger the system, the greater the chance that the client won’t.
So if you’ve made it this far you maybe wondering what the hell does this have to do with the new language feature? Lets review the code.
a->foo = b->foo;
I don’t know what foo is nor do I really care but "a" better care and more importantly it should have a fighting chance to care. Using the operator ( or the "." on a (semi) public variable) means that "a" doesn’t even have a fighting change of caring. The integrity of the object has been totally compromised by a "cool new" syntax that encourages violations of encapsulation.
If this syntax can on encourage behavior that we don’t want than why on earth would the authors of the JSE 7.0 JSR propose such a change? My real answer is; since I’ve not spoken to the authors I don’t really know. However the evidence is the use case is ease of use for Java beans. Simply put, the spec lead for the next version of Java would like to change the language to handle an edge case while ignoring the potential of creating havoc in just about every other language use case.
So to answer Danny Cowards question, wouldn’t it be nicer if we could do something like to do something life a->foo = b->foo;. My answer is no. I think that Danny shares that view though we may want to make sure!
comments (7)
1. Geert Bevin left...
Thursday, 28 December 2006 5:44 am
Hi Kirk, there's a small typo, your initial snippet:
2. Carsten Saager left...
Thursday, 28 December 2006 8:13 am
You have a valid point that declaring an property gives away degree of
freedom for the implementation. This weakens encapsulation as it limits the
possiblity for refactoring. The property is an interface contract.
synchronized{
o.set(a); assert( a.equals(o.get(a)) ); //transparent
assert( o.get().equals(o.get()) ); //idempotent
}
By this the declaration of a property helps not only the propgrammer to
save some lines of code but also the user of the API.
The irony is: With this contract the simple dot notation makes perfectly
sense (with the syntax simplifcation to drop parentheses for parameterless
methods). A property behaves like a member-access on read and "as expected"
on write. Only side-effects/validations are allowed in the get/set
implementations. The user of a class must never care about this
(encapsulation again), so why "hiding" from him that for him a property
behaves like a member?
3. Scot left...
Thursday, 28 December 2006 8:36 am
Yeah yet another anti-OO and general syntax-uglying feature crammed into
the Java Language Spec and for what? Save some fool implementing "Commando"
pattern and just let them have right there in the language itself. Jebus
help me.
4. Kirk Pepperdine left...
Thursday, 28 December 2006 1:31 pm
errr.. good catch Geert... I went back and took out a number of other
finger problems ;)
5. Matthew Payne left...
Friday, 29 December 2006 12:53 am :: http://sutternow.com/blog
Why don't they just copy the C# style exactly. I don't like the "->".
Seems like a hack.
re
http://www.devsource.com/article2/0,1759,1541911,00.asp
6. Kirk Pepperdine left...
Friday, 29 December 2006 7:46 am
Nice posting Matthew. However lets look at your code;
7. Bill Dauterive left...
Tuesday, 29 May 2007 3:54 pm
I think you are fighting a lost battle.