Does anyone have the full changelog of added/new features.
http://openjdk.java.net/jeps/228 - Add More Diagnostic Commands. For example more insight into JIT:ed methods and the code cache.
http://openjdk.java.net/jeps/158 - Unified JVM Logging. Logging from the JVM, e.g. GC logging and classloader logging, are configured and printed uniformly.
http://openjdk.java.net/jeps/259 - Stack-Walking API. Efficient API for walking the current call stack.
Oh, nice! At any given moment in time, how many server CPUs are burning cycles to create a full StackTraceElement array, just because the logger is set up to provide the convenience of call site information with every write?
See http://download.java.net/java/jdk9/docs/api/java/util/zip/CR....
The proposed ones "F Pro 9" might just make it on 10.
I'm really glad I get to do Scala development full time. Even with all the recent improvements to Java 8, I feel the future of Java isn't the language, but the JVM and all the other languages that run on top of it (Scala, Groovy, Clojure, JRuby, etc.)
I am yet to work in a Java project where I am allowed to use any of them.
Regarding the properties I really don't get what is the big deal.
No one used to complain about C++ properties, that besides having to write accessors and mutator methods, one needs to declare them on the header files as well.
Or the first version of C# properties isn't much shorter than how it is done in Java, which is still required when extra logic needs to be implemented.
It is been a few years since I have done any Python, but don't do they require two separate functions that are then mapped to a property declaration?
I used to feel the same as you, then I dabbled with Rails. I think the deal is that in Java there is a lot of noise in the code. So, developing feels like you need to do a lot of yak shaving before you get to actually work on what you intend to build.
As a result, properties on their own isn't a big deal, but it's one more thing to slow you down and make things a little less enjoyable.
OTOH IDE-generated code is "normal" source code, adding boilerplate to your "real" code, not tracking changes in it automatically, and perfectly breakable.
What do you think Lombok is doing?
The savings in screen space and visual cortex neurons doesn't come from the one or two properties that need logic, it comes from the dozen avoided
/**
* Gets the foo
* @return the foo
*/
public Foo getFoo() {
return foo;
}
/**
* Sets the foo
* @param foo
*/
public void setFoo(final Foo foo) {
this.foo = foo;
}I used to be an advocate property syntax, but after seeing them used in C# and now in Swift I have completely changed my mind. It's an inconsistent mess that Java has avoided at the small price of some more lines of code (that are mostly auto generated and need no documentation)
In C# you do have to think about it all the time. Most types have both properties and methods and in many cases it's not obvious whether the author of that type had the same idea about whether or not something should be a property or a method as you do. Where you only have to remember a name in Java, you have to remember both a name and its syntactic category in C#. One more thing to keep in mind equals greater mental load.
In fact, the guidelines for choosing between one and the other include considerations that should be of no concern to the user of a public interface (https://msdn.microsoft.com/en-us/library/ms229054(v=vs.100)....). If any of these implementation details change, the logical conclusion would be to change the public interface from property syntax to method syntax or vice versa. That's what I call inconsistent.
If you're saying that the choice between getX() and x() in Java is also somewhat inconsistent then you are absolutely right. It's just not a problem on the same scale as in C#.
And if the implementation of a C# property changes in any of the ways that would make it a method, that probably deserves to be surfaced as a breaking change in the API. That's a feature, not a bug. eg, I would certainly want to know if the implementation of a property was changed from a field access to a network call.
And if you look at the guidelines I linked to, you'll see that the criteria that are supposed to tell us whether or not to use a property are much more subtle than making a network call vs accessing a field. Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?
I think disguising a function call as a direct variable access is much more problematic than calling a function that may or may not do more than return the value of a variable.
That said, I do realize that reasonable people can absolutely disagree on this issue.
>>Can you really justify a breaking change to a public interface because a type conversion is introduced in the implementation of property?
I just quickly re-read that page, but I don't see what you're referring to here.
"The operation is a conversion, such as the Object.ToString method."
But this only pertains to the conversion of the object on which the property is defined. In other words, you should have methods like ToString or AsEnumerable, rather than properties like String or Enumerable, even though other rules would indicate property to be valid (idempotent, fast, no arguments). This rule is just an indication that properties represent conceptual attributes of an object; and the result of a conversion of an object to something else is not an attribute.
Semantically, the difference between properties and methods is the same as the difference between data and behavior. Are you saying that it's not a useful distinction to have?
They're quite a smell that you have no encapsulation, plus mutable state.
I find myself either
- Writing object oriented code with higher level operations that operate on data internally without exposing it via getters and setters.
or
- Value types that take values in constructor and provide naming and additional behaviour on that data (proper Value Types support will really help with this.)
or
- Data pipelines dealing with n-tuples. For which you might be tempted to reach for getters/setters but I'd tend to either use off the shelf tuple types. i.e. tuple(A,B,C) or classes with public fields, or interfaces with static factory to create instances. I'd love better support for tuples with named attributes (Like new c# has)
Loads of getters/setters is something that the frameworks of the last decade encouraged people to do but aren't really a thing any more.
Now you're left with something that could be fit on three lines (the "final" for the parameter is also useless and can be removed):
public Foo getFoo() { return foo; }
public void setFoo(Foo foo) { this.foo = foo; }
The C# version is about the same length:
public Foo Foo {
get { return foo; }
set { foo = value; }
}
public Foo Foo { get; set; }
There are bigger fishes to fry in Java than how properties are defined.
Bring in properties already.
public Foo Foo { get; }
public int Foo => Bar + 1;
foo.getBar().getBaz().blah()
foo.Bar.Baz.Blah()
Compare with Kotlin:
class MyFoo(val foo: Foo)
That is, instead of one line of the code declaring the property, we end up with 10 lines doing the same thing, because we also need to declare getter and setter.
So, a realistic "POJO" that has 8 properties, will have 8 lines of code in C#, but 80 lines of code in Java.
Sure, your IDE will generate the getter and setter, but when you are reading the code, you have to check whether getter and setter are trivial, or perhaps they do something else, too.
It is quite common to get burned by a setter that someone made so that, after setting the value, it also does other shit like, hit Google Analytics, which is why everything is so slow.
The above problem is super easy to spot in 8 lines of code, but much harder to spot in 80 lines of monotonic, repeatable code, especially so when they are decorated with another 100 lines of code that is IDE-generated comments like 'Sets the foo'/'Gets the foo'.
My 5c.
Thing is, this is true whether your language offers syntactic sugar for them, or not. Properties already exist in Java, they just exist as a matter of convention and custom - but the expectations on how they behave are just as strong, and a misbehaving getter, say, is just as surprising and damaging.
So you don't like either of the following:
myObject.name = "Ben";
myObject.setName("Ben");
The whole point of an object is that client code shouldn't be concerned with such details as maintaining the state of each internal field. Try and think of an object as a single thing you send high level messages to you, instead of a struct, or a bag, or a hashtable.
Says who?
For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse.
It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers.
So, the quantity of the item keeps mutating.
How do you propose to deal with the above? Tell the warehouse people that they should only do their thing "rarely"? Seriously.
What is the point here?
Point - say you have a database with 300 tables and ~3,000 columns.
You do not want to play the game of "hide the method to change the value". That is a big waste of time for everyone involved.
Yeah I want to say that for us developers, "rare" is not something that we can code, without some serious sophistication.
More likely we code "if" and it is either "yes" or no".
To capture "rare", we need some serious tools - statistics, analytics etc etc. That is way beyond the regular developer toolset.
For me a better question is - why is the name being changed? What high level goal are you trying to accomplish that truly needs you to to directly mutate internal fields, after the object has already been created? Could the object - or system of objects - have been designed with a higher level interface, so that the outside world didn't have to concern itself with such things?
As an aside, I'd probably make a method called "rename" that does this, as opposed to something like "setName".
Consider a trivial to-do list. You can click on the 'completed' checkbox. So the 'completed' field has chaged.
Or, you can say ooops I mistyped the label. So you change the label.
Is there anything wrong with that?
I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".
I don't know if it's worth the overhead of having unthinking developers writing { get; set } for every field in every class because it makes things "easier".
I do not understand your point. First you claim that we should not mutate the field, then you claim that we should mutate the field.
Which one is it? Mutate or not?
We should generally not use goto or local variables either. Avoid reaching for these constructs first. But if it's by far the cleanest, and simplest way of solving the problem - which it usually isn't - go ahead and do it.
class Circle
{
public Circle(int radius) { Radius = radius; }
public int Radius { get; }
public int Diameter => Radius * 2;
} public int Radius; public final int radius;