 |
Properties in Java? Hoorah!
Posted by rbair on January 08, 2007 at 02:09 PM | Comments (45)
Properties in Java? Awesome! As with any new language feature, there has been a lot of debate over whether this is an improvement to the language, or a detriment. And of course, every language-designer-wannabe (myself included!) is pounding the pulpit, declaring the One True Way to Property bliss. Well, sit back and enjoy as I pound the pulpit. Because seriously, I really do have the right solution! I promise!
A Brief Overview of JavaBeans
The JavaBeans spec has been with us for quite a while. Virtually everybody knows about the JavaBeans POJO pattern:
public class Person {
private String surname;
public String getSurname() {
return surname;
}
public void setSurname(String surname) {
this.surname = surname;
}
}
Before throwing any monkey wrenches into the works, I'm going to explain a bit about some of the darker corners of the JavaBeans spec. At least, darker to the majority of developers out there.
Many of you are probably familiar with the Reflection APIs. For example, given the class above, I could call the "getSurname()" method using Reflection like so:
Method m = Person.class.getMethod("getSurname");
String surname = (String)m.invoke(personInstance);
Built above these core APIs is the JavaBeans Introspector, BeanInfo, PropertyDescriptor, and associated classes. These classes inspect an Object for methods that follow the JavaBean pattern, and create various descriptors automatically representing these "properties". You can even write your own PropertyDescriptors, or specify your own BeanInfos, if you don't want them to be automatically generated. Here's an example which get's all the properties for a bean and prints the name of the property and its value to System.out:
BeanInfo info = Introspector.getBeanInfo(Person.class);
for (PropertyDescriptor pd : info.getPropertyDescriptors()) {
String name = pd.getName();
Method m = pd.getReadMethod();
if (m != null) {
System.out.println(name + "=" + m.invoke(personInstance));
}
}
The java.beans package is widely used by frameworks and GUI builders. Swing is a huge user of the Bean APIs and patterns. JSR 295 (beans binding) is based on these APIs as well.
There are a couple other important things to note. First, the class could be defined like this:
public class Person {
public String getSurname() {
return "";
}
}
and it is still a valid JavaBean. The "surname" property still exists (it is just read only), and the Introspector still finds it. Even though there is no instance variable (aka field) called "surname". The JavaBeans pattern is not about breaking the encapsulation of the Person object. It is about exposing configurable state. JSR 273 will (if nothing major changes) introduce the ability to configure beans that are immutable (ie: only have getter methods, and accept all state in the constructor). So I repeat, the JavaBeans pattern is not about breaking encapsulation.
This is important for a couple of reasons. First, for the purists out there, you can stop wringing your hands. Second, there is a big difference between a property, and a field. A Property is a concept, a field is an implementation. When discussing language level property support, don't confuse the two!
Ground Rules
Any discussion centered around Property support has to first establish the ground rules: what are the requirements. Here are my requirements (pounding the pulpit as I say them):
- 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
The rest is all personal taste and other such nonsense :-).
The One True Way
Both Remi Forax and Cay Horstmann and Mikael Grev are on the right track. Each of those blogs has interesting ideas, and even more interesting commentary. Be sure to check those out.
The One True Way is not necessarily the way I'd do it if I were starting from a clean slate, but it is the best solution for Java. All design requires trade offs.Without further ado...
Getter/Setter == Accessor/Mutator
The first key design decision is to continue to support getter/setters as the way to customize the accessor/mutator for the property. C# uses a closure-like syntax for defining the accessor/mutator, but this would be the wrong decision for Java because it doesn't add anything truly useful beyond what the getter/setter already provide. Plus, as Remi points out, it limits your ability to use covariant return types or to override the argument to the setter.
Obviously, we can't ignore the last 10 years of Java code. Getter/Setter has to be supported.
PropertyDescriptor == Property Meta Data
The JavaBeans spec defines the PropertyDescriptor as the metadata for a Property. Stephen Colebourne has an interesting idea regarding exposing Property meta information easily. He has some interesting points, but it is critical that we leverage the existing APIs and the existing body of work that uses PropertyDescriptor. However, we really, really, should make it easier to get a PropertyDescriptor.
For example, Stephen suggests the "->" notation (which has been suggested for other uses with regards to properties, so don't get confused!). Basically, foo.bar would return the value of the bar property, while foo->bar would yield the PropertyDescriptor. I'm not fond of the use of the "->" operator for this task, but something along these lines may be the best choice.
Observable Properties
The JavaBeans specification mentions "bound properties", or in other words, observable properties. Whenever a "bound" property changes, a PropertyChangeEvent is fired to all registered PropertyChangeListeners. They may then take the correct action.
This is a huge deal for JSR 295 (bean binding). Using my previous code example, imagine if I bound the Person.surname property to a JLabel. Whenever the surname property changes, I want to update the label. If the surname property is not observable, then the JLabel will not be automatically notified when the property changes. Which means you'd have to be sure to manually refresh the JLabel whenever the surname changes. Lame!
Writing a setter method to fire a PropertyChangeEvent isn't too hard, but it is trickier than you might think! Here's a broken example:
public void setSurname(String surname) {
if (surname == null) surname = "";
String old = this.surname;
this.surname = surname;
firePropertyChange("surname", old, surname);
}
public String getSurname() {
return surname;
}
...
final Person p = ...;
p.setSurname("Bair");
p.addPropertyChangeListener(new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent evt) {
assert p.getSurname().equals(evt.getNewValue());
}
}
What is wrong with this example? Will the assert always succeed? Answer, no. It may fail. How? Simple: because getSurname() is not final, it is possible for a subclass to be written such that it always returns a single value, essentially becoming read only. That is:
public class SmithPerson extends Person {
public String getSurname() { return "Smith"; }
}
...
final Person p = new SmithPerson();
p.setSurname("Bair"); // set surname sets the field to be "Bair", fires a PCE
p.addPropertyChangeListener(new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent evt) {
//evt.getNewValue() returns "Bair", but p.getSurname() returns "Smith"!
assert p.getSurname().equals(evt.getNewValue());
}
}
A more correct version of the setSurname() method would be
public void setSurname(String surname) {
if (surname == null) surname = "";
String old = getSurname(); // note: calling the getter!
this.surname = surname;
firePropertyChange("surname", old, getSurname()); // still calling the getter!
}
Or, just make the getter final.
The point is, writing an observable setter has some gotchas. It's boring. It's a bunch of boilerplate. It is necessary for really slick (and useful and powerful) data binding. This has to be easier to do! Any talk about including properties in the language must include a provision for dealing with observable properties.
Note that the JavaBeans spec also discusses vetoable property change events, but those are, in my estimation, less critical to handle at this level. At least, whatever mechanism is introduced for observable properties should be capable of extension towards vetoable properties.
Code Generation Rules
Actually, I have reservations on this point, but they are outweighed by practicality. That is, however a property is defined it must actually generate the getter/setter method in the end, so as to be compatible with the JavaBeans spec. However, this is kinda weird. I mean, you define a property, and then call a method "getSurname()". Where was that method defined? "Oh, the compiler creates it for you". I mean, that's just plain freaky.
However, it is the most practical choice at the moment, in my estimation.
Code generation is the means by which we ensure that properties work with existing frameworks and code. A piece of code calling Introspector.getBeanInfo should work exactly the same whether it is introspecting a class defined pre 1.7 or a class defined with properties.
Things To Postpone
One really intriguing idea is to also introduce a way to chain accessors, such that if a null occurs anywhere in the chain, the result is a null. For example, a.getB().getC() would return null instead of throwing a NullPointerException if a.getB() returned null. Some syntax changes have been suggested (such as using a # instead of . to access the property). Very interesting idea, could save a lot of boilerplate, but this is orthogonal to the properties discussion. At least, I hope it is. The death of many a great idea has come about due to too many great ideas being lumped together.
The End of Today's Blog
So, I haven't actually proposed any syntax of any kind. Rather, I'm trying to focus on, and nail down, the core requirements for language level properties, from my perspective. In this discussion, I'm not acting as the official Sun representative for Properties in the language. I'm just an interested bystander. So look to other blogs for official feedback, direction, etc etc.
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Thanks Richard for a great writeup outlining all the requirements, and issues to properties, and the beans spec. I am really glad that you have been closely following all these properties specs that are floating around, because I truly believe that the beans specs current, and upcoming should play a central role in this core feature.
Posted by: mikeazzi on January 08, 2007 at 03:20 PM
-
couldn't the onus be put back on the JavaBean API to continue to be backwards compatable while allowing the introduction of actual 'property' types into the language? I guess I'm not a big fan of continuing with the get/set by name convention as a defined relationship between multiple types (field, method).
Posted by: jhook on January 08, 2007 at 03:34 PM
-
jhook
Not sure I follow. Could you explain a bit what you're thinking?
One other aspect I was considering today was what the Properties proposals mean with respect to other languages, like JRuby. Both JRuby and Java compile to bytecode. It would be nice if "properties" defined in JRuby were usable in Java and vice versa. To make this generally true, it almost requires relying on get/set methods, because every language I am familiar with (which, admittedly, isn't many) has support for methods :-)
Posted by: rbair on January 08, 2007 at 03:53 PM
-
A good writeup. Your JRuby comments highlight a reason for the interface based design of my property object proposal. The interfaces can be implemented in whatever way is necessary to pickup the JRuby equivalent of a property. Even without a PropertyDescriptor or BeanInfo.
Posted by: scolebourne on January 08, 2007 at 04:39 PM
-
Richard, I guess the argument for retaining getFoo/setFoo as the practice in order to stay compatable in SE7-- why couldn't we introduce a Property type, which has a get Method and set Method metatype, similar to C#. Then, the existing Bean API would still produce property descriptors to keep with all existing frameworks, but also return results for the new property type keyword.
Posted by: jhook on January 08, 2007 at 05:36 PM
-
Richard:
Pardon me if this is taking the conversation too far off your intended topic.
But your bound property example, noting the non-final method, is still not bullet-proof. I have had a real problem 100% reconciling this behavior and I have not gotten all the aspects into focus; but my main point is that concurrent access throws that assert out the window in all cases.
It is not possible to write a compliant JavaBean that is observable in a deterministic way. The invoker of setFoo is supposed to cause the state change in the bean to become visible -- and I interpret this as volatile semantics -- and then synchronously deliver the change event to listeners; but during delivery it is supposed to release any locks to prevent deadlocks. This allows "events to be delivered out of order" as the beans spec says.
And if you implement it the way you have shown, then you lose some sort of determinism, in that by passing the argument value to setFoo itself as newValue in the event, then at least the event recipient knows exactly what value change this event is a by-product of and might be able to use that in a comparison to determine how to act -- it might be able to tell if it was the invoker of setFoo and to ignore this event for one example: and not that I think that's the greatest thing to have to try and implement either!
Anyway, I got a bit turned around with the concurrency aspects of beans and never settled into a 100% comfort zone.
It also doesn't make sense the way vetoable properties are supposed to be implemented: Are you also supposed to release locks before firing the veto event? If so, concurrency will kill you! You can have no idea what events come when. And then if there is a "revert" event, again there is no correlation between any of these events! If they come out of order a listening bean may wind up "reverting" to an earlier change that has been superceeded. It did always seem to me that the original design included some kind of implementation code that had the event receivers double-checking the values in the events against expected values and taking action that way. But even that way, I myself don't see how it can be implemented.
Thanks anyway; and I'd be interested if you have any comments on that aspect.
-Steev Coco.
Posted by: steevcoco on January 08, 2007 at 06:32 PM
-
Nice post, Richard!
I agree with the requirements you describe.
And I think that those code generation rules wouldn't be so bad. If you define a property with the new syntax and then you write a 'getXXX()' method, the "default" getter method for this property will not be generated by the compiler (and the same will happen to setter methods). The idea is: you can have the trivial getter/setter methods written by the compiler (it would be interesting to be able to define if a property is readonly or not, etc. to decide which methods will be generated) and, should you need to define a special behaviour for some getter or setter methods, then you can define those methods easily (by writing getXXX() or setXXX.()).
- Xavi
Posted by: xmirog on January 09, 2007 at 12:51 AM
-
Hi Richard,
The PropertyChangeListener handling is maybe not so good to have auto generated. However it would be easy to have the compiler complain if there is no firePropertyChangeEvent(String s, Object oldP, Object newP). It's trivial to write anyways since we have PropertyChangeSupport. Example code should be in the docs for the annotation on how to do this!
Also it is important to have at least non-null handling and, depending on the Validation JSR, handling of validation. Maybe PCE can be modded to have a light-weight validation similar to .consume() in InputEvent? Only is should be a little more powerful so it can throw an IllegalPropertyChangeException? There's 1000 ways to solve this, but it must be solved, again IMHO..
Cheers,
Mikael Grev
Posted by: mikaelgrev on January 09, 2007 at 04:12 AM
-
Great post Richard. Extensible property support is critical! You've inspired me to blog about how observable could be done generically -- with annotations on the fields!
Posted by: jessewilson on January 09, 2007 at 09:25 AM
-
I'd recommend foo.&bar for a property descriptor. This is similar to C so it might have some familiarity. (The main difference is that in C you'd say &foo.bar, but I think associating it closer to the item being referenced is clearer.)
While I'm not as eager for method references, I like static referencing better than using reflection. The same syntax could be used there. That is, you could say foo.&bar(String) or something along those lines. Note no need to say String.class or anything given the context of the method reference.
Posted by: tompalmer on January 09, 2007 at 10:08 AM
-
if jse 7 uses anything other than the '.', I'm jumping ship
Posted by: jhook on January 09, 2007 at 10:29 AM
-
Note, my comment on '.&' was in reference to property descriptors, not property values.
Posted by: tompalmer on January 09, 2007 at 11:02 AM
-
jhook, If you do:
public setName(String name) {
this.name = name;
}
Would you use the field or the setter?
Posted by: mikaelgrev on January 09, 2007 at 11:09 AM
-
how did you declare 'name' ? my impression is that properties would be a new type-- so you would get a compiler error if you tried to introduce:
// compile error
private String name;
public property String name;
or in C#
// safe since 'name' and 'Name' are different
private String name;
public String Name {
get {}
set {}
}
Posted by: jhook on January 09, 2007 at 11:43 AM
-
jhook,
Ok, so you want the new properties to not be compatible with "old" getters and setters at all?
Posted by: mgrev on January 09, 2007 at 01:55 PM
-
nope, compatable only in that the JavaBean API will mine both legacy and new properties. Being 'compatable' with old properties is kind of an odd declaration since Java never really had 'properties', only a convention of method declarations retained within the JavaBean API. Thusly, if Interospector.getBeanInfo(...) returns both legacy and new property type declarations, we're all cake with existing frameworks/libs in my opinion.
Posted by: jhook on January 09, 2007 at 02:01 PM
-
jhook, Hmm. I bet lots of code doesn't use bean APIs directly. I'd bet lots of stuff just assumes the conventions. But people could probably work around such things and gradually upgrade support, too. Interesting thought, there.
Posted by: tompalmer on January 09, 2007 at 02:59 PM
-
I agree, Introspector could hide any differences.
Posted by: rbair on January 09, 2007 at 03:46 PM
-
Sorry. One more comment. Anything meta on properties ought to have java.lang and/or java.lang.reflect presence, not just java.beans. Maybe java.beans would still have some value add, but the core ought to be closer to lang, I'd think. (I suppose the java.lang.Iterable vs. java.util.Iterator for enhanced for loops is an interesting play.)
Posted by: tompalmer on January 09, 2007 at 04:28 PM
-
Nice article.
I don't know much about JavaBeans API, but I like simple annotation + code generation solution appeared in future Java version. like:
@Property
private String name;
@Property(immutable=true)
private Adress address;
As for property access (to avoid NullException), why not just borrow from JSP/JSF/Seam? like:
#{person.address.postcode}
Posted by: zwe on January 09, 2007 at 07:27 PM
-
Don't forget indexed properties. Java bean spec talk about it ! When you observe an indexed property, do you want to know the change of the property or only one of the index of the property.
Posted by: dbonneau on January 10, 2007 at 04:58 AM
-
Hi Richard!
It was nice to read your reasoning about properties. I completely agree with your requirements. I also support the opinion of xmirog: "If you define a property with the new syntax and then you write a 'getXXX()' method, the "default" getter method for this property will not be generated by the compiler (and the same will happen to setter methods)."
But i also think it will be useful to forbid the compiler to generate properties.
-Good Luck!
Posted by: nett on January 10, 2007 at 05:18 AM
-
You may call it whatever you want, I call it for what it is, and it is "removing private and protected fields". The goal is make private and protected fields to behave just like public ones, killing OO in the process and making a bunch of clueless developers happy by doing so.
NOT ALL FIELDS SHOULD BE EXPOSED VIA GET/SET. If you do it then, please, drop programming and go flip some burgers. You will be a lot happier.
If this passes I will start calling Java "Perl++". What are the options? To be sodomized by Microsoft while locked in Windows and their frequent non-backward compatible changes, or to use buggy opensores scripting languages with lots of unfinished stuff in the "Linux style" and zealots shouting it to be the best thing ever invented, or watching Java slowly becoming a (big) piece of crap.
This is probably the one of the stupidest things I have ever heard. Programmers that think this is good should switch to some language like PHP, which didn't have "access mofidiers" in some versions still widely used. I guess they would feel more confortable this way.
PS: The arrow and other symbol proposals are signs that Java is becoming like Perl, with its symbols and special meanings. The difference is that Perl (and Ruby, and Python, etc) doesn't have professional level IDEs, so they need to use vi and such markings help to distinguish things, they are IDE impaired. Java has great IDEs, this won't help at all, it wil just pollute.
Posted by: thiagosc on January 10, 2007 at 06:10 AM
-
Now why they don't just make the field they want to do so "public" is a mistery.
They seem to think a "language feature" is needed.
Posted by: thiagosc on January 10, 2007 at 06:12 AM
-
@thiagosc: When you learn the difference between a property and a public field, I suggest you reread the proposals. Nowhere is anybody suggesting that public fields is, in general, a good idea.
There is a difference between a field and a property. A property is state that is meant to be configured by external clients. A field is part of the internal representation of state in a class. A property is meant to be public API. Spring, EJB, Swing, and many other very common and very successful APIs in Java use the JavaBeans "properties" patterns.
Posted by: rbair on January 10, 2007 at 07:23 AM
-
Properties is just a stupid idea. We don't need this at all. We don't need to copy every bad idea that comes from the VB/C# camp. Java already has JavaBeans.. we don't need questionable syntactic sugar for this. C# isn't much more practical in this regard either.. the properties mechanism is redunant to the language.
This idea is even stupider than templates and annotations. [sarcasm] Why don't we copy C#'s javadoc style too?[/sarcasm]
Posted by: dog on January 10, 2007 at 08:21 AM
-
@rbair: in practical terms, what are the differences between one and another? I am not looking for an answer, just pointing out the obvious, calling a "public field" a "property" won't make it less stupid. The use and effect will be the same.
So why to rename an existing thing if standard Java OO already do it?
This "typist culture" from those scripting languages is starting to infect Java. They count keystrokes because they are IDE impaired, but Java is not. The IDEs does everything already, and you may even choose not to see it if you don't want to.
Posted by: thiagosc on January 10, 2007 at 08:34 AM
-
It just brakes encapsulation by transforming "private" and "protected" in not quite private and protected.
Posted by: thiagosc on January 10, 2007 at 08:36 AM
-
@thiagosc - You are wrong. ;-)
Richard, as another poster said, it is VERY important for this to work 100% with indexed/Collection type properties as well. I didn't mention them in my initial blurb since it would get too long but it is important. So is a lot of other stuff. The question here is where do you/we discuss this is a threaded/issue way?
Cheers,
Mikael
Posted by: mikaelgrev on January 10, 2007 at 09:15 AM
-
Hey Mikael
Email, no doubt :-). For myself, I suspect I'll keep reading the blogs and proposals going around and continue blogging about it as well. As for indexed collections: my quick answer would be "yes", let's suppor them. However, as jhook mentioned, we don't have to support them exactly the same as JavaBeans, as long as the JavaBeans introspector can recognize the old AND new styles and create the appropriate property descriptors, etc.
Richard
Posted by: rbair on January 10, 2007 at 09:40 AM
-
>Email, no doubt :-)
Noooooo!
In Sweden we have the Gregorian Calendar system. It is now the year 2007. What Calendar system do you have at Sun, and has it passed 1995? ;-)
Posted by: mikaelgrev on January 10, 2007 at 10:00 AM
-
In a company that still uses emacs, I'm just glad we have email! :-)
Posted by: rbair on January 10, 2007 at 02:27 PM
-
I think modifying the entire language to ease the implementation of a particular design pattern used often in a particular problem domain is a great idea.
We should iterate over all design patterns and modify the language to ease the implementation of each. We should ignore reservations such as these:
"However, this is kinda weird. I mean, you define a property, and then call a method "getSurname()". Where was that method defined? "Oh, the compiler creates it for you". I mean, that's just plain freaky."
Less typing is far more important than feeling comfortable with the language. After all the goal is to produce as much code as possible, not to develop, robust, secure, long-lasting software infrastructures.
Posted by: kdw on January 11, 2007 at 12:18 AM
-
"VERY important for this to work 100% with indexed/Collection type properties as well".
Right, so you can do something like myObject.secretVector = {"apple", "orange", 1, banana}->[0,2];
Posted by: jwenting on January 11, 2007 at 12:25 AM
-
"Less typing is far more important than feeling comfortable with the language."
When someone is using an anonymous inner class you have to "learn to read" that code also. The same goes for the new typesafety constructs. Change is not nessecarily bad.
Furthermore: the generated setter and getter are not coming out of the blue, there is a construct (keyword) that denotes the behaviour. The coder needs to understand what the "@property" annotation does.
My additions: let the compiler examine the sourcecode and generate smart code upon a @property.
- if there is a firePropertyChange method available, use that in the setter.
- similar vetoablePropertyChange.
The @property annotation has parameters to customize the generation (change=false, vetoable=false, etc).
Posted by: tbee on January 11, 2007 at 01:19 AM
-
This is the cake
jhook,
Ok, so you want the new properties to not be compatible with "old" getters and setters at all?
Posted by: mgrev on January 09, 2007 at 01:55 PM
nope, compatable only in that the JavaBean API will mine both legacy and new properties. Being 'compatable' with old properties is kind of an odd declaration since Java never really had 'properties', only a convention of method declarations retained within the JavaBean API. Thusly, if Interospector.getBeanInfo(...) returns both legacy and new property type declarations, we're all cake with existing frameworks/libs in my opinion.
I really couldnt agreee more with jhook. We are introducing a new framework. Being backward-compatible might make it a bit easier to use an old API(although if youre already using the old API you might want to continue with getters and setters), but we will not gain the perfect solution/syntax. NOT being backwardcompatible does not break anything. We can still use the old getters and setters, we can design the propertysyntax better and it might just be a lot easier to integrate.
Posted by: xodox on January 11, 2007 at 01:32 AM
-
I think properties are a very bad idea. None of this adds anything to what exists other than the ability to say person.age = 20 rather than person.setAge(20). I fail to see why the first is better. I'd say in fact it is worse as it decreases maintainability. To a developer new to the code looking at the first statement it is not obvious that there is potentially more going on than a simple assignment. This would likely waste time in identifying bugs with the setter code. If the setter is used, then this is always obvious with no loss of clarity of intent that tehre is potentially extra work going on. If it aint broke, dont fix it.
Posted by: hoprods on January 11, 2007 at 04:35 AM
-
None of this adds anything to what exists other than the ability to say person.age = 20 rather than person.setAge(20). I fail to see why the first is better. I'd say in fact it is worse as it decreases maintainability. To a developer new to the code looking at the first statement it is not obvious that there is potentially more going on than a simple assignment.
You are right, they are just trying to access private fields as if they were public. Why don't they just make the fields public anyway, without messing with language?
Posted by: thiagosc on January 11, 2007 at 06:43 AM
-
properties with "direct" access and get/set I find horrible: Now there are two ways to access the value although there are the same (at least I hope - but others might think otherwise) - backward compatible with the JavaBeans spec? Nice to have, although the JavaBeans gave Java the bitter taste of "lots of simply objects that do nothing".
Besides JavaBeans, there is another convention on naming RO-properties: name(), size()... does this also has to be supported?
Even if the accessors on the properties were transparent (p=x, x==p) - if there are listeners that interact synchronously , the transparancy might be compromised and thus a syntax a.p =x x= a.p is not advisable as the p will not behave as the simple field as the programmer sees it - if we say that it is how it is meant to be, indeed all fields should be private.
Perhaps we need not one "property" but two: One is a language element for tool and framework interaction (JavaBeans build into the laguage) and the other is for interafce to define a "public field" with controlled access (RO,WO)
Posted by: csar on January 11, 2007 at 11:37 PM
-
What the proposals don't cater for are readonly and writeonly properties, nor properties where the property (thus the getter and setter) don't map 1:1 to a datamember of the exact same type and name.
Without both those requirements taken care of, the entire thing is indeed just another way of enabling full public access to data members.
With those taken care of, it might be a good idea in principle, if the syntax were carefully selected. Properties in other languages use the same assignment/read syntax of fields, and I see no reason that Java should be different in that (would be extremely confusing to break commonly used practice).
Under those conditions the system might have some advantages, especially for true DTOs which are used purely to distribute data between application layers and have little or no logic of their own. Their coding and use would become cleaner, yet remain reasonably futureproof (if it is possible to define the getter and setter explicitly as part of the property definition, including the actual method names to use).
Posted by: jwenting on January 12, 2007 at 12:51 AM
-
@jwenting: that's what Hans Muller proposed--true DTOs, to paraphrase him, are really of course just structs, and that seems to be where the use case sweet spot is in all of this froth.
Posted by: ljnelson on January 14, 2007 at 06:51 AM
-
If this passes I will start calling Java "Perl++". What are the options? To be [victimized] by Microsoft while locked in Windows and their frequent non-backward compatible changes, or to use buggy opensores scripting languages with lots of unfinished stuff in the "Linux style" and zealots shouting it to be the best thing ever invented, or watching Java slowly becoming a (big) piece of crap.
Posted by: ronald45 on August 05, 2007 at 07:40 AM
-
It also doesn't make sense the way vetoable properties are supposed to be implemented: Are you also supposed to release locks before firing the veto event? If so, concurrency will kill you! You can have no idea what events come when. And then if there is a "revert" event, again there is no correlation between any of these events! If they come out of order a listening bean may wind up "reverting" to an earlier change that has been superceeded. It did always seem to me that the original design included some kind of implementation code that had the event receivers double-checking the values in the events against expected values and taking action that way. But even that way, I myself don't see how it can be implemented.
Posted by: ronald45 on August 05, 2007 at 08:05 AM
-
Don't forget indexed properties. Java bean spec talk about it ! When you observe an indexed property, do you want to know the change of the property or only one of the index of the property. 搬運公司-畢業相攝影-生活記事-Tamiya
Posted by: winrelocation on October 30, 2007 at 12:52 AM
-
手机 手机
Posted by: stillstayhere on May 28, 2008 at 12:56 AM
|
java.net RSS Feeds
