Why Java Doesn’t Need Properties (It already has them)
There’s an awful lot of sound and fury right now about adding syntax support for properties to Java 7. The more I think about this the more I think the whole idea is wrong for several reasons:
1. It doesn’t let you do anything you can’t do now. It’s a minor improvement at best.
2. It makes source code that uses it incompatible with previous compilers for no particular reason.
3. It invalidates a lot of books and tutorials, and existing knowledge of how Java works.
4. At least some of the proposals add keywords to the language, thus breaking existing programs.
5. At least one of the proposals adds an operator to the language (->), thus making Java more complex to read, not less.
These aren’t insurmountable hurdles by any means, and objections 4 and 5 can be eliminated completely with a better proposal; but if we’re going to surmount obstacles 1-3, there needs to be a clear benefit. The proposal needs to make code a lot cleaner or let us do something we can’t already do. So far that doesn’t seem to be true.
What’s all too often missing from these discussions is a realization that even the best feature comes with a cost. Everything you add to a language bloats it a little more. It makes the language that much harder to learn, that much harder to document, that much harder to read. Not a lot, mind you, but somewhat; and over time all these little changes add up, especially when you aren’t allowed to take anything out to counterbalance the added feature weight. This is especially true of features that are added years later rather than designed into the language from the start. The debacle that is generics (Can you say “type erasure”?) should have taught us that if nothing else.
Another example: closures. These make sense considered in isolation, but they’re not isolated. Closures are cleaner than anonymous inner classes, but if we can’t remove anonymous inner classes, we shouldn’t add closures too.
Java in a Nutshell has already split once and is still starting to look like a telephone book. How much bigger can we make the language before it collapses under its own weight? At some point, someone needs to put their foot down and say their will be no new features without clear and compelling benefits. Java must not become the Kitchen Sink Language for everyone’s pet project. We need to let Java be Java, and let other languages implement features like properties and closures if developers want them. They can all still be compiled to the Java VM if desirable. However one language cannot be all things to all people, and Java shouldn’t try.
January 25th, 2007 at 8:43 am
[…] Elliotte Harold is absolutely right when he suggests that people should leave Java alone. New technologies compete on features; mature technologies compete on deployment. […]
January 25th, 2007 at 12:33 pm
Absolutely spot on! How long before the whole thing collapses under it’s own weight?
January 25th, 2007 at 2:21 pm
I agree. Java is a mess. Running other languages on the JVM will help us out a whole lot with these types of issues.
January 25th, 2007 at 3:04 pm
This is a moot point, because Java was never “clean”, “elegant” or “pure”. Even Java 1.0 was inconsistent and broken. May as well add more features to make it less painfl to code in instead of trying to keep Java clean when in fact it never was.
January 25th, 2007 at 3:32 pm
The idea behind most proposals is actually to make the language easier to read and easier to document. Especially the proposals for properties and closures.
Furthermore, there are many languages that have most everything Java has, *and* have closures *and* properties *and* continuations (to name but a few). Are they harder to read or to learn because of that?
I really don’t get the “harder to learn” argument that is being used so often to stop changes. If someone is a half-decent programmer, they should be able to grasp the concept of, say, closures; and at least be able to use them. If not, maybe a career change is in order.
By the way, I believe my own proposal for easier properties (http://www.blog.dannynet.net/archives/81) solves obstacles 1-3 without resorting to 4 and 5. Your opinion would be very welcome!
January 25th, 2007 at 4:29 pm
All five points are true for every single JDK that has come out since v1.0. THis has obviously not caused Java to collapse under its (not “it’s”) own weight. Property support will eliminate tons of boiler-plate code, Java will benefit greatly from it (which doesn’t mean we shouldn’t try to improve the current proposal anyway).
—
Cedric
January 25th, 2007 at 6:42 pm
Thank you, Elliotte 🙂
“All five points are true for every single JDK that has come out since v1.0.”
This is not true. For instance, inner classes were introduced to support the new event delivery mechanism based on delegation, while in 1.0 was based on inheritance: the improvement allowed to do things that previously were nearly impossible or extremely awkward to do. Backward compability was mostly preserved with previous changes. Enums made enumeration support easier to write.
“This has obviously not caused Java to collapse under its (not “it’sâ€) own weight”
Well, this argument is equivalent to say that you can put infinitely more stuff on the back of a horse without ever killing it. The truth is that you can start adding some weight, but at a certain point the poor guy will die.
“Property support will eliminate tons of boiler-plate code”
This can be done at IDE level with auto-generated code and code-folding for improving readability, without putting too much burden on the poor compiler and language specs.
January 25th, 2007 at 8:17 pm
Maybe java could use old idea and instead of get,set use public variables. I know its bad if you want to vlidate input, but do we really validate input that much ? plus i tought that
public setSth(boolean b){
this.b=b;
this.c=b && this.i==1;
}
was not cool and you should have made a method for that
January 25th, 2007 at 8:18 pm
Nae… Bring it on… This is evolution. There are two types of programming languages that survives:
1. Those that manages to evolve: Java and C (–>C++) do, Pascal, BASIC not.
2. Those that are so important to a problem domain that they don’t need to: Fortran77, COBOL (mind you large % of thems users will try force evolution… (f90).
Properties syntax seems a bad idea, but hell, I love static import now, guess who everyone reminds being so damned sarcastic about em…
Seriously: So far all the new stuff added to Java in my mind has been okey and ignorable and it is not a bad thing to have to learn new stuff…
January 26th, 2007 at 12:24 am
Although you’re clearly saying that you don’t think properties are a good idea, your arguments seem to me to be good reasons why we need property support in the language. Right now we say “Ok, you *can* make variables public. But you shouldn’t. Instead, you 1. Make it private, 2. Write a set method to set the variable, 3. Write a get method to get the variable, 4. Acess the variables through those values, 5. Then if you’re accessing those variables dynamically, you use a special java class that knows that getFootballScore() magical corresponds to the property “footballScore”.
Wouldn’t it make a lot more sense to simply say “You create a property called footballScore and access it the same way you access any other variable/property – via object.footballScore? Property support is about simplifying the language – after a language has been added to for so long, it’s important to go back and simplify common things it’s used for so the language doesn’t become an unmanagable mess. And property support is the kind of thing people use *all the time*, but it could be made a lot simpler.
Oh, and ditto to the ““All five points are true for every single JDK that has come out since v1.0.” New programming stuff requires new books and learning – that’s the way it goes. I wouldn’t like to see java stagnate and stop adding stuff so that people who have become set in their ways will stop complaining about it.
January 26th, 2007 at 2:39 am
The idea behind most proposals is actually to make the language easier to read and easier to document. Especially the proposals for properties and closures.
Furthermore, there are many languages that have most everything Java has, *and* have closures *and* properties *and* continuations (to name but a few). Are they harder to read or to learn because of that?
I really don’t get the “harder to learn†argument that is being used so often to stop changes. If someone is a half-decent programmer, they should be able to grasp the concept of, say, closures; and at least be able to use them. If not, maybe a career change is in order.
By the way, I believe my own proposal for easier properties (see “Proper Properties” on my blog) solves obstacles 1-3 without resorting to 4 and 5. Your opinion would be very welcome!
January 26th, 2007 at 3:39 am
(1) it lets you reference properties in a IDE-assistable way for beans binding which is why i support “properties in the language”
(2) java5 code was incompatible which wasn’t a trainsmash, and it seems that java7 will be incompatible too. I think only every second release breaking compatibility is better than every release 😉
(3) authors would sell new revised editions for Java7, which will be good news for them. Also it will bring Java and C# closer together which is good for authors, and for developers, eg. C# developers can leverage their C# knowledge on java projects and visa versa, and java developers can better leverage C# material to apply in java projects
January 26th, 2007 at 5:37 am
In most cases, new releases of any software package are incompatible with prior versions. What I see most critical with Java is the speed new releases are spilled out nowadays. Java 5 has not much to do with Java 4 (Generics, Annotations…) if applied consequently, but what about Java 6 or Java 7? Most people do not want to cope with a new release every some months… It is not that Java 7 is out already, it is supposed to be published end of 2008 AFAIK. But reading anywhere about it raises the impression it is already there.
To be honest: I have not much of an interest for Java 6, maybe next year or when a new project starts that requires Java 6 features.
In the context of this post, I like to add that properties would be less incompatible with earlier Java releases than Generics from Java 5 are with Java 4! Just my opinion…
January 26th, 2007 at 6:39 am
Cedric,
You can fill a water tower one teaspoon at a time and I think that this is the point.
How many developers know what a property is? My guess is not very many. Because of this I see this syntax we will be encouraging programmers to violate encapsulation even though part of the proposal would mimic the C# ability to overload the “.” or “->” operator with a set/get method.
IDE’s are so good at generating “boiler plate” code that the benefits of this feature seems minimal at best. Certainly not great enough to justified this change IMHO.
Kind regards,
Kirk
January 26th, 2007 at 8:55 am
[…] The Cafes » Java « Why Java Doesn’t Need Properties (It already has them) […]
January 26th, 2007 at 12:56 pm
Too late….Java already IS a “kitchen sink language”. And that sink has been sitting, full up and fermenting for much too long. 😉
January 26th, 2007 at 2:00 pm
Well, Slava Pestov, been a moron as you are, you better code in brain***k. Just so not to try make Java clean and stable.
To the point: absolutely agreed -> properties doesn’t bring to Java anything it hasn’t now, just add more complexity and ambiguity.
January 26th, 2007 at 2:21 pm
Paul Rivers Property support is about simplifying the language – after a language has been added to for so long, it’s important to go back and simplify common things it’s used for so the language doesn’t become an unmanagable mess. And property support is the kind of thing people use *all the time*, but it could be made a lot simpler.
Ask yourself why properties weren’t added to Java 1.0 in the first place for they could
January 26th, 2007 at 5:43 pm
I think, adding property support, obviously after much refining, will add clarity and contribute simplicity to the language – not complexity. I wouldn’t compare “property support” with Generics, rather i would compare it to varargs. Remember, how many overloaded constructors and methods we used to write before varargs. Hasn’t that reduced? I believe so. Please note that, i am not comparing the 2 features per se, but i want to promote the idea that, property support is not going to be a mess as generics was.
January 26th, 2007 at 6:21 pm
[…] Elliote writes that Java doesn’t need properties. I sort of agree, there’s nothing inherently wrong with get/set methods, specially if you have a good IDE to automate that task for you. On the other hand, I don’t see how adding support for this feature, probably inspired as a reaction to C#, really hurts the language. […]
January 26th, 2007 at 6:59 pm
The author misses the most obvious drawback to properties – that they obfuscate the intent of the code.
What’s wrong with the following?
for (int j=0; j
January 26th, 2007 at 6:59 pm
shite blog. cant post code fuk you all
January 27th, 2007 at 3:31 pm
Dan Howard, thanks for making me ROFL 🙂 we’ve all been there, heh heh
January 29th, 2007 at 8:13 am
[…] Now it’s Java properties. […]
February 1st, 2007 at 12:21 pm
[…] Whilst I don’t agree with all of the points he’s making, anyone who’s interested in the future of Java as a language or generally geeks out on programming language development should check out Elliotte Harold’s recent blog posts. Start here. […]
February 8th, 2007 at 7:52 pm
I agreed, Java is a mess.
February 10th, 2007 at 6:42 am
There is a big difference between changing the language and adding new capabilities through code libraries. From version 1.1 through version 1.4, there were very few changes to the language — almost all changes were new libraries or enhancements to existing libraries. Version 5.0 (1.5) had several major changes, including generics. I think it was a mistake, and I am very much against most of the proposed future language changes, especially closures and properties. Like generics, they will further complicate the language, and they attempt to solve a problem that I don’t have in using Java. PLEASE, MINIMIZE FUTURE CHANGES TO THE JAVA LANGUAGE.
February 11th, 2007 at 5:36 pm
There’s nothing that can be done using assembly either. Heck, use bloody JVM bytecode directly: no need for a friggin’ language!
Why anyone likes the getters/setters pattern is a mystery to me. Also remarkable is everyone’s issue that the language just got more complex.. Did you not have to learn the getter/setter convention? Just removing shitloads of boilerplate from code would be enough validation for properties! This is the same argument as the “enum” argument all over again. Yes, you can code *lots* of basic constructs by hand in Java. But doing it again and again is stupid: a language is meant to make life easier!
Properties, when defined properly, can encapsulate “field access” – which regardless of any rants about data hiding in OO design are very frequent- in a very short way *with* all of the control present in setter/getter methods. In addition it would open the way to another very desirable thing: property references.
In many frameworks one needs a reference to some “field”. Take for instance a database framework like hibernate: when I need to do a query I have to code the fields as strings because I cannot reference them directly. This renders them invisible to all IDE refactorings or access checks. With a properly defined property standard we could have “field” like references that are visible to the compiler and IDE.
Why is it that everyone thinks change is bad? A remark like “New technologies compete on features; mature technologies compete on deployment” really gets me pissed of! What complacence! If Java was the best invention since bread it would be OK but Java is fraught with problems and not even close to perfection. Assuming that it is just leads to obsolescence and replacement. And that replacement might come as C# (which is way better designed IMO) which would really be a disaster – gone cross-platform deployment..
February 11th, 2007 at 5:39 pm
And another thing: having properties work with the exact syntax as field access is a great boon to OO design. It would mean that “blunders” in design where an earlier public field was exposed (java.awt.Point anyone?) could easily be fixed by replacing the public field with a public property which *can* have setter/getter methods controlling values and hiding real representation of the data inside the object.
February 21st, 2008 at 11:13 pm
Properties? What are those?
hahaha. Properties are basics of OO design. It’s laughable that they were not in Java 1.0
Java needs to get with the times. Objects have properties, Simple as that.
October 31st, 2008 at 7:39 am
I think properties will make Java simpler. There were properties in Delphi so I was disappointed not to see Java having properties. C# has properties and I don’t think I had to spend more than 2 minutes understanding the syntax. How difficult could adding Properties to Java be? C# has properties and many newbies understand it more easily than try to explain the Javabean naming convention where get and set has to be all lowercase, whole method camelCase. setXxx where the private field is xxx what if you mistakenly typed setXxz or SetXxx. Compiles perfectly but your code doesn’t work as expected.
I want methods to perform actions only and Properties to give me properties of the object.
November 13th, 2008 at 1:30 pm
I agree with Non-nude Cheerleader’s post above. It’s a damn shame in this day and age that Java still doesn’t have non-nude cheerleader support, especially when you consider the boys in Redmond baked that capability into C# from the start! (although you have to enable it with a CLR compiler flag)
June 16th, 2010 at 9:37 pm
Are you using your brain seriously?
“At least some of the proposals add keywords to the language, thus breaking existing programs.” How on earth your logical process produce such conclusion? I can imagine the withdrawals of keywords breaking existing programs, but add?
June 17th, 2010 at 6:20 am
Phuong, Those who forget history are condemned to repeat it. Do you recall when the assert keyword was added to Java? and promptly broke every single program on the planet that used JUnit?
June 20th, 2010 at 6:30 am
Java should add properties or it will decline in popularity. Just knowing that it can be done simpler in another language is just a nerve wrecking. Java should get rid of its verbosity and allow less typing. The most common design patterns should be incorporated in the language. Design Patterns are invented to compensate for language deficiencies and Java has many.
When some sort of property syntax is added, entire libraries will need to be changed to included them. Is this a problem? Look at the database API. There was no need to rewrite them, yet when java annotations were added it got rewritten anyways. Java Persistence API has annotations everywhere. Hence rewriting all the libraries with a newer property syntax would be no problem at all.
Oracle, just include properties!!!!
July 17th, 2010 at 3:14 pm
If you refure to have a past then you have no future!
none of these argument make much sense.
If your going to keep insisting on backwards compatabilaty for ever then there can never be any progress..
As for invalidating the books of the past well thats laugthable you cant keep reality constant.. books become out of date all the time..
things change… ITS NOT A BAD THING!
Standards are nice and good but there is the trick… you can add numbers at the end…..
Backwardscompatabilaty nazis are retards… literaly.. they are retarding progress!
This is why Java is going to get it ass handed to it…
Microsoft stole all that was wonderfull about java and made it better… I challenge the java world to do the same…
The clearer and more easy to read the syntax the easier and the more fun programming becomes if out languages dont evlove how can our programming evolve…
I mena where would we be today if we limited our comuinication to grunts and hitting each other on the head with clubs just because introducing more advanced features like words would confuse some people….
at least some people in the java world arent insane…. just look at Scala…
March 1st, 2011 at 5:16 am
After 10 years of java programming I’ve spent the last 2 years doing alot of C#, and I have to say I find properties in .NET somewhat cumbersome. Lets say you’ve got a property:
IList<Foo> foos= someObject.Foos;
and you want to override that method to filter the foos. In java you would just add a method:
IList<Foo> filteredFoos = someObject.getFoos(false);
but in C# it gets messy. Do you have one as a property, and one as a method? Yuck.
Properties are just methods with different syntax. There really is no need. Yes, it is very nice and convenient declaring a property in C#, but its also very nice and convenient generating a getter or setter in Eclipse.
March 1st, 2011 at 5:18 am
Ugh – code came out looking bad:
should be
IList foos= someObject.Foos;
and
IList filteredFoos = someObject.getFoos(false);
July 13th, 2011 at 9:44 am
@gusgorman, why wouldn’t you add a second property in C# called FilteredFoos? .FilteredFoos could even do a subquery on .Foos.
IList foos = someObject.Foos;
IList filteredFoos = someObject.FilteredFoos;
It looks cleaner to me. When reading “someObject.getFoos(false)” I have no idea what are the implications of passing either true or false to getFoos. It is clear what I am getting when I call .FilteredFoos.
September 1st, 2011 at 7:18 am
@Jeff Robinson
Thats normally what I do.
Sometimes you would really like to pass in a parameter though. Perhaps a boolean was a bad example (an enum value might be a better example)
June 9th, 2014 at 7:13 am
I simply love Java(less then python), but java is more main stream.
I do not like .net world with a passion, but properties in .net(vb, c#, ..) are really good.
If you need just read/write, you just declare it. If you need complicated logic for getter/setter you can do it. I do not see point in having few members(may be dozens) and for each have getter and setter method which only sets/reads method. If you need to scroll several pages only because you have dozens of getters/setters, it is quite annoying.
If it is for mapping data from database to some POJO, you can live with it. But if you need some members(plus getters/setters), and some method doing some stuff, you can run into complications, which are not necessary.
In .net world for last few years they try to add every possible feature into language, which I do not like much.
January 27th, 2015 at 10:11 pm
You may not need for “get” and “set” prefixes, to make it look more like properties, you may do it like this:
public class Person {
private String firstName = “”;
private Integer age = 0;
public String firstName() { return firstName; } // getter
public void firstName(String val) { firstName = val; } // setter
public Integer age() { return age; } // getter
public void age(Integer val) { age = val; } //setter
public static void main(String[] args) {
Person p = new Person();
//set
p.firstName(“Lemuel”);
p.age(40);
//get
System.out.println(String.format(“I’m %s, %d yearsold”,
p.firstName(),
p.age());
}
}
February 4th, 2015 at 9:07 pm
// Here comes a new year so Lemuel ages:
p.age(p.age() + 1);
I don’t think properties only reduce the length of code. To me, p.age++; sounds pretty much readable.
April 22nd, 2015 at 8:47 pm
I agree to that. I am also a C# developer. C# has properties and uses them a lot. I am just suggesting that:
p.age(p.age()+1)
is shorter than [and still logically clear],
p.setAge(p.getAge()+1)
and it works with Java.
May 11th, 2020 at 4:59 am
[…] Here is an interesting articles about the subject: http://cafe.elharo.com/java/why-java-doesnt-need-properties-it-already-has-them/ […]