Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Scott Delap on Jan 08, 2007
Giving closures a break to start 2007, the Java community has taken up the topic of properties in recent days. A flurry of commentary revisiting the possibility of a property keyword and arrow operator has appeared. The discussion seems to have started largely as a result of a presentation at Prague JUG by Danny Corward, JavaSE Platform Lead. In the presentation he floates the idea of a few language additions related to properties in Java 7:
public property String foo;
a.setFoo(b.getFoo());
a->Foo = b->Foo;
...I'm of the opinion that if you are willing to make a commitment to closures, then we do the same for properties-- something similar to C#. Spending time extending the long winded get/set convention is the wrong direction for the spec. Do everyone a favor and do properties right-- leaving the old Bean Property spec alone for APIs to accommodate and treating properties as a first class citizen in the metadata starting in SE 7...Kirk commented:
...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...
Moving past the arrow for a moment Cay Horstmann provides a recap of the entire situation and mentions issues found along the way. In summary he writes:
Before vilifying a proposal because of unsightly syntax, let's summarize what one wants in native properties.
- The common case--a private field and public getter/setter pair--should require minimal boilerplate.
- It should be easy to supply getters and/or setters that do some other work.
- It should be easy to specify read-only or write-only properties.
- Javadoc should document properties.
- There should be reflective access to properties.
- Properties need to integrate with annotations.
Here are some issues that have been raised.
- Should getters and setters of native properties be regular methods?
- Should native properties be compatible with JavaBeans properties?
- Should there be support for bound and vetoable properties?
- Should properties have other than public visibility?
The issue that has gotten the most press, namely what operator, if any, to use for property access, seems the least important one.
Unix, Linux Uptime & Reliability Increase While Patch Management Woes Plague Windows (Yankee Group)
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
The 5 Mandates of Software Development Teams - Presto Manifesto
Why this new syntax? There may be some subtle (or not so subtle) reason I can't see at 8am, but I don't understand why we can't just overload the dot operator. That seems much more intuitive and makes it possible to change direct field accesses to properties without changing any client source code. You could even add some special magic to class loading where accesses to fields that are not visible result in an attempt to find a property of the same name before failing. Then you could go retrofit non-properties after the fact, meaning that use of public fields would be fine because you can always change them to properties later.
In his example, Danny Corward seems to plead for a mean to lighten the syntax needed to pass a value from one public variable to another one. This is in fact a call for the introduction of "operator overloading" into the Java language.
It's great to see some people at Sun realizing what a language *must* implement to be called an object oriented language.
See for example the article Conventions for Arithmetic Operations in Java for a discussion on how to deal with Java's lack of operator overloading. See also, the other article on the same site about Java : www.idinews.com/indexJava.html
Jérôme Radix.
The change from an instance variable to a property needs to be transparent not only from a compiler perspective, you need also to be transparent from the reflection API perspective. Then you can start with a public instance variable and evolve to a property when you need to add encapsulation to it.
Cay writes:
Using just the dot is unfortunately a minefield. You'd have to look closely what item.quantity means. Is there an accessible field quantity? Is there a quantity property? Who wins if both are present? Or is that illegal? I am sure that one can cook up a set of rules, but is it worth it? Why are people so attached to the dot?
That's the one part I don't understand at all - I find it totally obvious that having different ways to access public fields from properties is exactly what one wants to avoid. If properties are made part of the language, it should at least be done completely ...
Ok, apparently the Java community has too many code monkeys. So let me break it down for you.
NO! We don't need the new syntax for property accessing. If your IDE can't generates the 'get' with two key strokes, then stop using notepad.
NO! We don't need Operator overloading. For those morons that are ready to say "But it can help make your code easier to read." Or "It makes logical sense in terms of an OOD to override the operators." Don't fool your self. Think in terms of power-to-weight ratio. Does the new features power out weigh the complexity factor? I don't think it does. Java became as popular as it did because it was simple. You don't low level addressing that pointers in C++ provide, you don't need the new -> property accessor, you don't need a broken broom stick jammed six inches inside of your anus and no, you don't need to attract every C++ or Ruby left over that's looking to rant about how Java is lacking something.
Let's stop running around telling people how great we type by bashing ours on the keyboard.
Best Regards,
Richard L. Burton III
Yep. We should stick to solving problems that really need solving. But this is typical. What we are doing here is a perfectly normal human meta-design mistake I call Building the Menus (see third comment).
I totally agree for operator overloading.
At least, with Java, when I read "x = x + 6", I know
what's happening, without browsing any class or variable declaration, and don't want it to change.
For property, if done properly it can be interesting, perhaps increansing readability.
I think property could as well help better design and refactoring. When someone does a myObject.attribute call and then this attribute has to change, then properties are most welcomed.
Indeed, the call to this attribute wouldn't change but behind we would easily be able to do the required trick.
Nowadays, if my attribute changes (for example of type...), then I've to change all the line where myObject.attribute was made. In terms of encapsulation it's pretty poor no ? Similarly, who knows whether someone has called it directly somewhere in the code ?
BTW, why are some asking for a new -> operator ? The reason is simple : the cost of making a call directly to an attribute would be a lot less than calling a property. There, without a new operator, one would not know just by reading whether it's an attribute call or a property call.Hence the new operator.
ZedroS
without a new operator, one would not know just by reading whether it's an attribute call or a property call
Why would I care? From the point of view of the person using the class it should be invisible whether you're using a property or an attribute. It's the designer of the class who makes the decision, do I simply want to expose this data value (i.e. it's an attribute) or is there more behaviour associated here (i.e. it's a property)? As the consumer of the class, when I read the value I don't care whether it's implemented as a property or an attribute: I just want to get the current value. Updating is pretty much the same with the possible exception of PropertyVetoException, but since that's a checked exception the IDE will tell me I need to handle it (and a decent IDE will even generate the catch block for me). So the new arrow syntax adds no value as far as I can see.
I don't understand why Sun are so reluctant to add in new syntax or keywords when it would be genuinely useful (am I the only one that thinks a foreach loop should use a foreach keyword?) but they have no hesitation in introducing unnecessary or just downright annoying new syntax and keywords (nobody ever used enum as a variable name, did they).
So, properties, yes, good idea, bring 'em on. But little pointy arrow things, no, keep them out of my code, thank you very much.
I'm just poiting some justifications of this -> I've seen around, nothing else !
On a personnal note, I would also add that the performance overload of using a property insteand of a normal attribute shouldn't be an issue for the Average Joe Developer, since most of the time performance isn't really an issue (but design for sure, as usual;)).
But then, who am I to comment on a forum without bothering to spam the JSR members ? I did vote for the issue in the Sun database however. I think it could help reduce maintenability issue and provide good value.
So you?re arguing that this simple change will stop world hunger or some how provide clarity to tons of crappy code? Like Jonathan said, we have bigger fish to fry right now. I?d rather debate the removal of checked exceptions than this! I?m not advocating the removal of them, but I believe that conversation alone will produce some very interesting lines of thought.
Conclusion:
CrappyCode cc = new CrappyCode();
cc->doesNothing = "that the following can do.";
cc.setDoesNothing("That the following can do.");
The second reads better.
Best Regards,
Richard L. Burtton III
Richard: Actually, I don't think the choice is simply checked or unchecked exceptions. Neither works and I believe there are other, better ways to do this.
It'd be ridiculous to use anything other than the dot operator for properties. I would be utterly shocked if they moved forward with using alternate operators purely for readability. Properties should *look* like member assignment 'foo.bar = "hello";', developers are already familiar with that behavior. Introducing '->' means a whole different switch of thought on behaviors when really, properties should be as simple and visually seamless as possible.
The property syntax looks like Delphi. I strongly like the idea of the property keyword. It makes the code more terse. This is a good thing.
The getter and setter are implicitly defined with the property keyword. Cool!
I can't stand the "->" operator. I think the dot operator should be used.
Here is how I think it should work....
If you define a property, when you use the dot operator you should always get the property. E.g., <code>foo.bar</code> should always resolve to the property *never* to the field <code>foo</code>.
In fact the only time you can access the field should be inside of the class. And if you use the <code>this.bar</code> you access the property but if you are inside the class and you use just an unqualified <code>bar</code> you will access the field.
If you don't use the <code>property</code> keyword than access to field vs. property should be the same as it always was. This makes the dot usage backwards compatible for code that predates Java 7.
My $0.02.
Hey Rick, I'd like to first say it's great to see you not talking about JSF! Secondly your suggestion would break a lot of existing code. Yes, unfortunately the Java world is full of people that run around telling people that the pot hole in the street is really their ass. So expect a ton of people out there to define public properties with the thought it'll be a great improvement in terms of speed. ?Hey, if there is not method invocation, it'll be faster!?
With that being said, most people don't know how powerful the java compiler really is and the things it does for optimization during this process.
Best Regards,
Richard L. Burton III
Hey Jonathon,
What are your thoughts on checked vs. unchecked exceptions?
Richard L. Burton III
I totally agree for operator overloading.
At least, with Java, when I read "x = x + 6"
I know what's happening
Yet, when you see a.foo(), you don't really know what foo() gets invoked, but that doesn't bother you.
Why the double standard?
--
Cedric
testng.org
The change from an instance variable to a property needs to be transparent not only from a compiler perspective, you need also to be transparent from the reflection API perspective. Then you can start with a public instance variable and evolve to a property when you need to add encapsulation to it.
I think that the problem that really needs solving is a means to add uniform access to Java. I don't think that it's particularly important to support a transparent field=>property upgrade path. I would be perfectly happy with a new declaration-time syntaxt instead:public class Boat {
property String name;
property RigType rigType;
property int berths;
}
It's unlikely that we'll see a new language-level keyword show up, so maybe an annotation-based approach could work:public class Boat {
@Property public String name;
@Property public RigType rigType;
@Property public int berths;
}
Of course, such a change would also require putproperty and getproperty bytecode instructions to avoid issues with code that compiled against old classes that used fields.
This would push us further down the path of using the @ character for new language-level features, which is probably not something that the annotation team anticipated when they added special meaning to the @ character. However, this is proving to be a useful and powerful pattern for extending Java while avoiding difficult and bug-prone changes to the core of the Java compiler.
-Patrick
--
Patrick Linskey
bea.com
Really guys, what does this buy us? Are we aiming to bring clarity to the syntax, make the language less verbose or both? If Java must change this, then they should consider something on the lines that Patrick pointed out. Ideally, we want to reduce the verboseness of get/set on our classes, but at the same time, we don't want to be intrusive to the clarity of our code (Take C# for example). Introducing a new keyword would be extremely rare, especially the keyword property. Why? I know for sure that I've used the word 'property' has a variable before and there's no sure way to introduce a keyword without breaking existing code. That's why Java reserved some keywords such as goto.
Using annotations wouldn't be a solution either. Why? Annotations are just a way to bind meta data to a class and you would need to extract that meta data in order to make any real use of it. Unless Sun finds a creative way to modify the ClassLoader and dynamically enhance the class when it's loaded like Patrick pointed out. Either way, I really don't see the benefit of even attempting this. The power-to-weight ratio is rather low.
Best Regards,
Richard L. Burton III
I know for sure that I've used the word 'property' has a variable before and there's no sure way to introduce a keyword without breaking existing code. That's why Java reserved some keywords such as goto.
Actually, it's a bit more insidious than that. The compiler *could* be context-aware -- it could know that 'property' is a legit word at the beginning of a field declaration block, for example. (Well, not exactly, since that would break if you had a legacy class named 'property'. But it would not necessarily break code that had a field named 'property'.) I imagine that the C# compiler must be context-aware, for example, in order to deal with LINQ. It's my understanding that the real reason that Java can't introduce new keywords is that its compiler is not context-aware (or not context-aware-enough), and changing the compiler is a scary thought. Now, I'm no compiler expert, so I'm not sure about the pros and cons of writing parser generators that can deal with changing contexts. Maybe they're much slower (or were much slower in 1996). Or maybe they're much more complex to implement.
All that said, I'm a big fan of tossing an optional language version number at the top of the source file:package com.example;
version 7.0;
public class Boat {
property String name;
property RigType rigType;
property int berths;
}
Such a construct would get us out of all sorts of language gymnastics, since we could have altogether different compiler internals for different language versions.Using annotations wouldn't be a solution either. Why? Annotations are just a way to bind meta data to a class and you would need to extract that meta data in order to make any real use of it. Unless Sun finds a creative way to modify the ClassLoader and dynamically enhance the class when it's loaded like Patrick pointed out.
Sun has already started down this path: we've got @interface (for declaring annotations), @Deprecated, @Override, @SuppressWarnings, @Target, and @Retention, all of which which must be handled within the compiler. Both @Override and @interface are proper general-purpose language constructs; the others are a bit more specific, but compiler-level nonetheless.
-Patrick
--
Patrick Linskey
bea.com
Honestly, all of this boils down to "power-to-weight ratio". By adding this level of complexity (Context-Aware keywords or a version number. I also believe the version number solution would lead to a lot of bugs.) or any of the other proposed solutions, do nothing but increase the weight ratio and provide very little power. I'm sure there are other area?s of the Java language that can be improved.
Patrick, I'm not saying this can?t be done. I'm just stressing the fact that this isn?t needed. If we must add something, then let's add support for strings within a switch statement or remove the need for the keyword "break" in the switch statement. That'll surely clean up some very verbose code.
Best Regards,
Richard L. Burton III
FTR, I'm not defending the idea of adding uniform access syntax to Java. While I do think that uniform access is a great concept, I agree that it's a big change to an increasingly-brittle language. There are pros and cons to such a language mutation, and I don't have enough background on all of the issues to really have an opinion. The goal of my earlier post was to point out that adding a uniform access syntax does not necessarily mean that we need to change how fields and methods currently work in the language.
Also, my comment about the utility of a means to specify a source version in a Java source file isn't based on the needs of uniform access. A version keyword (or some other means of communicating version information, such as an annotation on the package declaration or the class) would have allowed Java to add a new 'annotation' top-level keyword instead of using '@interface'. It would allow us to gracefully add closures without worrying about syntax collision with esoteric source constructs supported in earlier JDK versions. It would even allow Sun to change the switch statement in some way to allow automatically-breaking case blocks. Generally-speaking, if we had source-level version data in the source file, the Java source language syntax could change in non-backwards-compatible ways without compromising bytecode-level compatibility. Adding version data might fail your power-to-weight test in its own right, but it would enable lots of significant language-level changes in the future.let's add support for strings within a switch statement
I hope that if Sun makes changes to the switch statement, they allow *any* .equals comparison (with corresponding optimizations for primimtives, of course), rather than just adding support for Strings. IMO, the compelling reason to add String support to switch statements is because the switch construct (modulo break issues) is nicer to look at than huge if-else blocks. The benefits for String are just as compelling for any other type. (Of course, it's arguable that huge if-else blocks are antipatterns anyways, but that's another debate.)
-Patrick
--
Patrick Linskey
bea.com
Well it's been refreshing talking to you Patrick. I haven't considered the idea of supporting switching on any object based upon the equals method. It seems fitting since it's more OO and gives greater support for other data types without adding any complexity to the language.
Best Regards,
Richard L. Burton III
I don't think it will break a lot of existing code. You do. So please enlighten us....
For the record... I work with JSF, Tapestry, Spring MVC, Spring, Hibernate, etc. a lot. I don't think I am focused on JSF like you think I am. I don't dislike it. JSF has its strengths and weaknesses. JSF 1.2 fixed a lot of those weaknesses. I look hopeful towards JSF 2.0.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
24 comments
Watch Thread Reply