19

Is there any rational reason, why native properties will not be part of Java 7?

trunkc
  • 6,223
  • 4
  • 34
  • 49
  • 3
    Don't measure a language's abilities by the amount of it's features. Think about the platform, the ecosystem, ... – ivan_ivanovich_ivanoff Jun 21 '09 at 01:04
  • that was a phenomenal comment Ivan. I am learning C#, and many of the features I come across that Java lacks, doesn't scream as though they would solve remarkably more challenging problems. Also some just seem like they could yield to more complicated code like having multiple things return from a method via outs. Or the infamous goto statement. – Frank Visaggio Jun 29 '12 at 20:57

5 Answers5

18

There are some high-level reasons related to schedule and resources of course. Implementation of properties and understanding all of the ramifications and intersections with other language features is a large task similar to the size of various Java 5 language changes.

But I think the real reason Sun is not pushing properties is the same as closures:

1) There is no consensus on what the implementation should look like. Or rather, there are many competing alternatives and people who are passionate about properties disagree about crucial parts of the implementation.

2) Perhaps more importantly, there is a significant lack of consensus about whether the feature is wanted at all. While many people want properties, there are also many people that don't think it's necessary or useful (in particular, I think server-side people see properties as far less crucial to their daily life than swing programmers).

Properties history here:

Alex Miller
  • 69,183
  • 25
  • 122
  • 167
  • Interesting. I wasn't aware of controversy over properties, at least not the sort of flaming hate closures has provoked. Can you provide any links to fill in the background of pros and cons? I do agree about properties being less important server-side, and JavaFX addressing the need on the client. – erickson Apr 02 '09 at 17:59
  • 1
    Being a server-side person, properties is all I have. – trunkc Apr 02 '09 at 18:41
  • Added a link on older property discussions. Personally, I'm vigorously ambivalent. I find most of the proposals don't get me too excited. I'm not sure Java can go far enough to really satisfy like Groovy or Scala in this department. – Alex Miller Apr 02 '09 at 21:30
17

Doing properties "right" in Java will not be easy. Rémi Forax's work especially has been valuable in figuring out what this might look like, and uncovering a lot of the "gotchas" that will have to be dealt with.

Meanwhile, Java 7 has already taken too long. The closures debate was a huge, controversial distraction that wasted a lot of mind-power that could have been used to develop features (like properties) that have broad consensus of support. Eventually, the decision was made to limit major changes to modularization (Project Jigsaw). Only "small change" is being considered for the language (under Project Coin).

JavaFX has beautiful property support, so Sun clearly understands the value of properties and knows how to implement them. But having been spoiled by JavaFX properties, developers are less likely to settle for a half-baked implementation in Java. If they are worth doing, they are worth doing right.

erickson
  • 265,237
  • 58
  • 395
  • 493
  • 4
    For the less informed, could you briefly explain the difficulty in implementing properties properly in Java? – Jason Feb 21 '15 at 07:23
11

Any given thing is "not done" by default, so no particular reason is needed for something to remain not done. Rather some compelling reason is needed to move something from "not done" to "planned" or "done". No sufficiently compelling reason has yet arisen for this language feature.

Neal Gafter
  • 3,293
  • 20
  • 16
5

There are two more reasons to avoid properties in any language:

  • Properties are not very object-oriented. Making them easy to write encourages the pattern where the object just serves up its internal state and the caller manipulates it. The object should provide higher-level methods and keep its internals private. Next time you're tediously implementing a getter, consider what the caller will do with the data and whether you can just provide that functionality directly.

  • Properties encourage mutable state (through setters), which makes a program less parallelizable. As the number of cores goes up, we should all be trying to make our objects immutable to make concurrent reasoning easier. Next time you're tediously implementing a setter, consider removing it and making the object immutable.

Lawrence Kesteloot
  • 4,149
  • 2
  • 31
  • 28
  • 3
    I object _"Properties are not very object-oriented"_. And so do others: _"["objects", which are data structures that contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.](http://en.wikipedia.org/wiki/Object-oriented_programming)"._ Forcing a user of an (API/class/)object to ignore half of that what it has by definition is unconvenient, at least. It's both unnatural and bloats code: `person.name = "Nimoy";` vs. `person.setName("Nimoy");` and `name = person.name;` vs. `name = person.getName();.` – Gerold Broser Mar 21 '15 at 18:46
  • 2
    I suggest avoiding the phrase "not very object-oriented" too (which is almost meaningless at this point) but keeping both points (which are about good design, plain and simple). Otherwise readers will focus on their own personal definition of OOP and ignore what is really being said here. – tne Sep 29 '15 at 10:27
3
  • Not enough time?
  • Not yet specced properly?
  • Difficult to add to java due to java's implementation?
  • Deemed not important enough, ie other things were prioritiesed?
willcodejavaforfood
  • 43,223
  • 17
  • 81
  • 111