Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JDK 9 release schedule

mail.openjdk.java.net

Post reply on HN
Print view View original

81–90 of 161 posts

Re: JDK 9 release schedule

#81

Post by fauigerzigerk »

breischl wrote: post #75
fauigerzigerk wrote: post #66

Earlier quoted context omitted.

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…

I would argue that the distinction is actually a good thing. If you're working with a reasonably well-designed library, then the fact that something is a method instead of a property tells you it might be doing some serious (or just slow) work. Whereas in Java calling getX() might do just about anything. And if the implementation of a C# property changes in any of the ways that would make it a method, that probably d…

The syntactical distinction makes us believe that there is a technical difference as well, but that is not the case. I find that misleading. If properties don't give us any technical guarantees, then a naming convention as in Java seems more appropriate to me.

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.

Re: JDK 9 release schedule

#82

Post by lacampbell »

chrisseaton wrote: post #78
lacampbell wrote: post #72

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)?

It would probably look exactly like setName(newName).

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?

Re: JDK 9 release schedule

#84

Post by agentgt »

djsumdog wrote: post #62
dmux wrote: post #47

Earlier quoted context omitted.

Are people manually writing getters and setters? Every Java IDE I've used has the ability to generate them for you.

Code generation is a design smell. You shouldn't need it, and it makes the code terrible and less readable. Use Lombok, not the IDE.

When I see some one complaining code generation being design smell I gag a little at this hackneyed Fowler expression. I'm curios what do you think lambok does?

Re: JDK 9 release schedule

#87

Post by DiabloD3 »

ape4 wrote: post #86

If you are doing dates the nice way as yyyy/mm/dd you should use dashes - ie yyyy-mm-dd. Let the slashes mean other styles.

Or nothing at all, the "filename" way of 20161018, my brain natively parses it that way now.

Re: JDK 9 release schedule

#88

Post by yuhong »

erl wrote: post #23
ygra wrote: post #12

Earlier quoted context omitted.

The annoying thing is that Java 8 is the only currently supported version of the language. The glacial development speed somehow still manages to deprecate versions faster than they fall out of use.

While Java 8 is the only version that is freely supported from Oracle, it is still possible to buy commercial support for older versions of Oracle's Java platform. The speed at which they stop freely supporting older versions feels much like a way to squeeze big, slow moving organizations for support contracts.

Indeed, see http://www.oracle.com/technetwork/java/eol-135779.html

Re: JDK 9 release schedule

#89

Post by pjmlp »

breischl wrote: post #76
pjmlp wrote: post #63

Earlier quoted context omitted.

Now write that with validation on set.

So your argument is that because there are some uses that require boilerplate, therefore all uses should require at least that much boilerplate?

My argument is that I use Java since 1998 and C# since 2002, and I don't see that as a big issue.

There are bigger fishes to fry in Java than how properties are defined.

Re: JDK 9 release schedule

#90

Post by pjmlp »

kentosi wrote: post #77
pjmlp wrote: post #63

Earlier quoted context omitted.

Now write that with validation on set.

You could do this in Java, but therein lies the cultural problem: From my experience, the Java world is so accustomed to get/set method doing nothing other than getting and setting the value that any attempt to do more (validation included) is seen as "surprising" and is frowned upon in code reviews. I'd typically have to create a special "setWIthValidation" method to please people... Bring in properties already.

I have been using Java since 1998 and hardly seen it.
Post reply on HN