Comments on: Why Java Doesn’t Need Properties (It already has them)

By: Graham Wheeler

Graham Wheeler — Thu, 13 Nov 2008 18:30:50 +0000

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)

By: Junior aus Ghana

Junior aus Ghana — Fri, 31 Oct 2008 12:39:50 +0000

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.

By: Chad Grant

Chad Grant — Fri, 22 Feb 2008 04:13:07 +0000

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.

By: non nude cheerleader

non nude cheerleader — Thu, 26 Apr 2007 13:49:21 +0000

non nude cheerleader

Features of non nude cheerleader.

By: Frits Jalvingh

Frits Jalvingh — Sun, 11 Feb 2007 22:39:33 +0000

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.

By: Frits Jalvingh

Frits Jalvingh — Sun, 11 Feb 2007 22:36:37 +0000

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..

By: J. Moore

J. Moore — Sat, 10 Feb 2007 11:42:03 +0000

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.

By: air

air — Fri, 09 Feb 2007 00:52:12 +0000

I agreed, Java is a mess.

By: Unilever Centre for Molecular Informatics, Cambridge - Jim Downing » Blog Archive » Elliotte Harold on Java 7

Thu, 01 Feb 2007 17:21:40 +0000

[...] 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. [...]

By: Pragmatic Dictator » Blog Archive » Why Is Everything a Language Extension?

Mon, 29 Jan 2007 13:13:55 +0000

[...] Now it’s Java properties. [...]