Live data from Hacker News

JDK 9 release schedule

mail.openjdk.java.net

61–70 of 161 posts

Re: JDK 9 release schedule

#61
post #4
post #2

well not too bad if they could deliver the jdk 10 (valhalla) a faster. jdk 9 is less important than jdk 10.

Looking at http://openjdk.java.net/projects/valhalla/ , I don't see a whole lot of value compared to JDK9. What's your basis for wanting 10 so badly?

JDK 10 will have TLS Fallback SCSV and native ChaCha20 support, though I wish they were in JDK 9.

Re: JDK 9 release schedule

#62
post #47
post #39

Earlier quoted context omitted.

> Regarding the properties I really don't get what is the big deal. 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…

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.

Re: JDK 9 release schedule

#63
post #53

Earlier quoted context omitted.

Those Javadoc comments are useless. If you have useful comments, they would take up the same space even if the language supported properties. 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; } Even if you don't write the actual source like that, a good ed…

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.

Re: JDK 9 release schedule

#65

This is posted a year early. Please post this in a year. I see no JSON, I have to use a 3rd party lib. And ... no word on fixing logging divergence.

You can map JSON onto java interface types with the built in Nashorn.

http://paste.debian.net/883460/

( May be incredibly unsafe, only just thought of it now. )

Re: JDK 9 release schedule

#66
post #54

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?

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. 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#.

Re: JDK 9 release schedule

#67
post #42

Earlier quoted context omitted.

> I still see projects using Java 5... Are you serious? Even the worst shops I've been at have at least moved their JVMs to Java7 back around 2014. I mean you can take all your existing JARs from Java4 and run them on Java8 and nothing should break. Recompiling them might be another issue, but still not a huge one.

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 ...

Re: JDK 9 release schedule

#68

Earlier quoted context omitted.

Am I missing properties? Dear god it's 2016, with Java8, and we still don't have real, language-defined properties? I mean you can use Lombok (and if you're not, you should be!), but that's something that really need to be built into the language. C# has them, Python has them, Ruby has them .. even other JVM languages like Scala have them! I'm really glad I get to do Scala development full time. Even with all the rec…

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?

Re: JDK 9 release schedule

#69

Earlier quoted context omitted.

Yeah. Unfortunately, unsafe is removed in JDK 9. :( Edit: It seems removing unsafe is just a rumor.

BS

No seriously Unsafe is not removed, it's not even deprecated because there is no replacement. I don't know where people get this idea from. Did anybody check the source? Of course not. Just repeating something somebody wrote on the internet somewhere.

Unsafe is going to stay

https://www.youtube.com/watch?v=4HG0YQVy8UM&t=1s

Re: JDK 9 release schedule

#70
post #47
post #39

Earlier quoted context omitted.

> Regarding the properties I really don't get what is the big deal. 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…

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

I think that the point is that you shouldn't have to rely on an IDE in the first place.
Post reply on HN