71–80 of 161 posts
The next interesting thing for the JVM is value types in Java 10. It may convince me to use it pre release.
Yeah. Unfortunately, unsafe is removed in JDK 9. :( Edit: It seems removing unsafe is just a rumor.
Earlier quoted context omitted.
I really don't understand why people love properties so much. Getters and setters are elements of bad style to me - like global variables or gotos. A language like Java (or indeed C#) - specifically designed for huge teams and enterprise programs - shouldn't provide syntax sugar for writing getters and setters.
"I really don't understand why people love properties", followed by "Getters and setters are elements of bad style". So you don't like either of the following: myObject.name = "Ben"; myObject.setName("Ben"); What alternative would you suggest then?
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.
Earlier quoted context omitted.
True, but if you are running something like WebSphere or Weblogic then upgrading your JVM invalidates product support. So, now you have to upgrade product versions, which often requires changes to deployment scripts, breaking changes in those products, new software licenses, etc. Having said that being on and old supported version of these products means you are at least enjoying Java 6.
... and we use WebSphere 7 because we like to read hackernews while publishing our code ...
My last contact with Websphere was in 2014 and the customer was still using 6.1 on their production servers.
Earlier quoted context omitted.
Adding 8 comment lines doesn't help your argument. More importantly though, you need to consider the mental load of constantly thinking about and remembering whether something is a property or a method. 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 c…
Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?
Earlier quoted context omitted.
Can you clarify what's inconsistent about properties in C# (seeing how this is the most obvious counterpart), and how it doesn't apply to Java's properties-by-convention?
In Java you can be reasonably sure that whenever you need something from an object you call a method of its class. That's one thing you rarely have to think about in practice. Yes there are exceptions (sometimes painfully inconsistent ones) where fields are accessed directly, but at least that gives you some performance guarantees. It's generally not a big concern. In C# you do have to think about it all the time. Mo…
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.
Earlier quoted context omitted.
The C# version was the same length 10 years ago. Now you would write: public Foo Foo { get; set; } and get the backing field for free.
Now write that with validation on set.
Earlier quoted context omitted.
The C# version was the same length 10 years ago. Now you would write: public Foo Foo { get; set; } and get the backing field for free.
Now write that with validation on set.
Bring in properties already.
Earlier quoted context omitted.
"I really don't understand why people love properties", followed by "Getters and setters are elements of bad style". So you don't like either of the following: myObject.name = "Ben"; myObject.setName("Ben"); What alternative would you suggest then?
Probably a rethink of the design. Why are you creating an object, then mutating its name from client code? 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.
So, uh, how many people are using Java 8? I still see projects using Java 5...
Earlier quoted context omitted.
Probably a rethink of the design. Why are you creating an object, then mutating its name from client code? 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.
What would a high level message for changing the name of some object look like, if not setName(newName)?