Here at Devoxx 2014, Brian Goetz went a little further than he has before about whether properties will ever be added to Java as a language feature.
No properties for you
Properties as a language feature in Java has been talked about for many years. But ultimately, it is Oracle, the Java stewards, who get to decide whether it should be in or out.
Today, at Devoxx, Brian Goetz, Java Language Architect, went a little further than he has before to indicate that he sees little prospect of properties being added to the language at this point.
Oracle have chosen to prioritize lambdas, modularization and value types as key language features over the JDK 8 to 10 timescale. As such, there was no realistic prospect of properties before JDK 11 anyway. However, the indications today were reasonably clear - that it isn't on the radar at all.
When quizzed, Brian indicated two main reasons. First, that it is perhaps too late for properties to make a difference as a language feature, with compatibility with older getter/setter beans being a concern. Second, that there are many different, competing visions of what properties means, and there is an unwillingness to pick one.
Competing visions include:
- Just generate getters, setters, equals, hashCode and toString
- Generate observable properties for GUIs
- Raising the level of abstraction, treating a property as a first class citizen
- Immutability support, with builders for beans
- New shorter syntax for accessing properties
While it is easy to argue that these are competing visions, it is also possible to argue that these are merely different requirements, and that all could be tackled by a comprehensive language enhancement.
(Just to note that "beans and properties" does not imply mutable objects. It is perfectly possible to have immutable beans, with or without a builder, but immutable beans are harder for frameworks to deal with. Value types are intended for small values, not immutable beans.)
As is well known, I have argued for properties as a language feature for many years. As such, I find the hardening of the line against properties to be intensely disappointing.
Every day, millions of developers interact with beans, getters, setters and the frameworks that rely on them. Imagine if someone today proposed a naming convention mechanism (starts with "get") for properties? It would be laughable in any language, never mind the world's most widely used enterprise development language.
Instead, developers use IDEs to generate getters, setters, equals and hashCode, adding no real value to their code, just boilerplate of the kind Java is notorious for.
Consider that with 9 million Java developers, there could easily be 50,000 new beans created every day, each with perhaps 100 lines of additional boilerplate getters/setters/equals/hashCode/toString - easily 5 million lines of pointless code created, per day.
(And plenty more code in serialization and mapping code that either tries to deduce what the properties are, or results in lots of additional manual mapping code)
Realistically however, we have to accept that in all likelihood Java will never have properties as a language feature.
Summary
The Java language is not getting properties.
Comments welcome, but please no "Foo language has properties" comments!
An alternate way to tackle this problem is to improve / standardize support for tools like project lombok, for example by expanding the annotation processing APIs to include the ability to add methods inside existing classes, at which point a library can provide 'language support' for generating the code needed to add property support. If the community coalesces around one library, then that can be taken as proof that the language spec might need to be extended to embrace that particular library, similar to the JodaTime -> JSR310 trajectory.
ReplyDeleteDISCLAIMER: I was the one quizzing Brian, and I'm also one of the core developers on project lombok.
With Java having no properties, project lombok is the most important reason for me to still like programming in this language (more important than lambdas).
DeleteThank you for this great tool!
As an alternative to allowing annotation processors to modify the AST (which I personally have low hopes for), partial classes (as e.g. in C#) could be used to achieve the same. I've send that as suggestion to discuss@open-jdk:
Deletehttp://mail.openjdk.java.net/pipermail/discuss/2014-November/003607.html
Tools such as Lombok would then generate additional parts (source code) of a Java type which all together would form the final class.
I'd be very glad about any feedback (or support) on that proposal.
Let's hope so by goodness, Reinier! I know the questions about standardizing something like Lombok came up a few times already and it seems you (the team) were frustrated about the downplay from the Oracle side of things. If there's any way one can help to get this rolling again, I guess the Lombok community is happy to help wherever it can.
ReplyDeleteGetting shipped (and updated) with IDE distributions by default would remove the biggest obstacle for most people (judging from the things I hear people complain about when I use Lombok to cut down boilerplate in code examples). So that might be something to try first as it also plays into the significance story a bit.
Maybe Brian should have a look at the Java language enhancement poll whiteboard on the second floor here at Devoxx. Properties are by far the most popular requested feature.
ReplyDeleteAnother argument against properties is that they encourage a style of programming where classes expose their internal state (often in a mutable way). I frequently see programmers write getters and setters for all private fields, without much thought about whether this is necessary or a good long-term plan for the class. A terse syntax would certainly encourage this. I would prefer to see internal state kept hidden and methods provided to do whatever tasks are necessary. I think beans blew away the whole concept of encapsulation and immutability (the latter because of the requirement of no-arg constructor).
ReplyDeleteDifferent development teams have very different views on the "right" style for coding. The "pure OO" style, where getters and setters are not used is rare IMO. Some argue it is rare because people are coding "wrong", whereas the counterpoint is that OO doesn't actually work well for many systems, and a separation of data and behaviour works better. Java is a broad church, and multiple styles of development are perfectly normal.
DeleteProperties can be used to imply getters and setters, but for me it is the abstraction over data that is far more important. Sometimes you want to be able to treat the data in your class as a hashmap of property name to object. Doing so is incredibly powerful, and standard in almost every other language. It enables technologies such as JSON/XML/binary serialization and data mapping tools to work in a far simpler and more effective way than today.
Hi Stephen, can you explain a little bit more what do you refer witch data abstraction with properties, and how to use a map with properties is a data abstraction?
DeleteCompletely agree with Lawrence Kesteloot's point here. The vomit that so many so called "Java Developers" create with their setters and getters is the biggest turn-off to work in any Java project. JavaBeans and its introduction of getters and setters was a massive mistake, and now legions of "Java Developers" have taken this approach to break encapsulation as a standard and acceptable way to create object-oriented software.
DeleteAdding properties would not help people think any deeper about their design (or lack of).
>Value types are intended for small values, not immutable beans.
ReplyDeleteGo home Java, you're drunk.
It is becoming clear that these desired language changes to Java are a really big ask. I see Oracle putting the effort into value types and modules and I think that is good - I'm pleased to see Oracle get those changes sorted for all JVM languages.
ReplyDeleteIf you add up properties + null handling + checked exceptions ... and then consider any realistic timeframe for these issues being addressed in the Java language if at all, are developers really going to wait? It seems to me that polygot is going to be the norm and not the exception. A language that has very good interop with Java + Collections API is going to see a decent amount of uptake.
For example, Kotlin and compile static Groovy provide pretty seamless interop with java types and the collections API and will be an easy adoption for Java developers. Its going to be an increasingly polygot world (with lots of Java to interoperate with for many years).
... well, that is my prediction anyway :)
why do they shy away from implementing getter - setter /properties , even after so much user demand. Being able to use obj1.x =12, instead of obj1.setX(12) is so much of a relief. This is available in C#,Scala,Groovy,Python,Ruby,...Every language worth its sault. What is the problem in implementing getter-setter/properties in java?? What a frustrating wait!
ReplyDeletei don't like properties.
ReplyDeletefirst: get..() and set..() are clearly sorted in CodeAssistant and i don't have so scroll up and down all properties and methods to find the desired item
second: a property might be read only (no setter); in the CodeAssistant i cannot distinguish between get/set or both which slows everything down
Hi. Maybe this could be interesting for you. As I'm big fan of properties, last time I started pushing the compiler extensions which adds properties. The repository could be find here
ReplyDeletehttps://bitbucket.org/radoslaw_smogura/java_properties-jdk9-langtools
Not all changes are uploaded, but I treat it serious and slowly review and push next changes there.
Someone asked on StackOverflow why native properties in Java weren't added to Java 7 ( https://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7 ). erickson stated that adding them to Java would be difficult, and refered to this hard to read thread for details: https://puredanger.github.io/tech.puredanger.com/java7#property . Can someone simply explain why implementing native properties in Java would be difficult?
ReplyDelete