Live data from Hacker News

JDK 9 release schedule

mail.openjdk.java.net

51–60 of 161 posts

Re: JDK 9 release schedule

#51
post #32

Earlier quoted context omitted.

> 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 J…

> isn't much shorter than how it is done in java 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; }

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 editor like IntelliJ can automatically display them like that (code folding).

The C# version is about the same length:

    public Foo Foo {
        get { return foo; }
        set { foo = value; }
    }
Also, you don't have to write the get/set methods yourself. You hit a few keys and your editor generates them.

Re: JDK 9 release schedule

#52

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…

Properties mean a lot of things to different people, and C#'s can do stuff that you don't expect so I would guess won't make it into Java as they tend to prioritise reading code over writing it. Having said that if you look at https://www.oracle.com/javaone/on-demand/index.html?bcid=513... about 30 minutes in you might see Brian talking about something that may be close enough to what most people want from properties…

> Properties mean a lot of things to different people

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.

Re: JDK 9 release schedule

#53

Earlier quoted context omitted.

> isn't much shorter than how it is done in java 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; }

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.

Re: JDK 9 release schedule

#54

Earlier quoted context omitted.

> isn't much shorter than how it is done in java 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; }

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?

Re: JDK 9 release schedule

#57

Earlier quoted context omitted.

I'm pretty excited about that one, it's JEP-286, http://openjdk.java.net/jeps/286 . Valhalla is pretty big. Goetz described it as pulling on a very long string. It's going to touch everything in the JVM, including reifing generics, although as I understand it, erasure of Objects may be here to stay for the language.

Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore). What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very r…

Aside from backwards compatibility, what's good about type erasure for generics?

Re: JDK 9 release schedule

#58
post #5

Earlier quoted context omitted.

Here is the list: http://openjdk.java.net/projects/jdk9/

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.

Re: JDK 9 release schedule

#59

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.

Java EE 7 has native JSON capabilities.

https://docs.oracle.com/javaee/7/api/javax/json/package-summ...

Re: JDK 9 release schedule

#60
post #32

Earlier quoted context omitted.

> 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 J…

> isn't much shorter than how it is done in java 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; }

And you forget the declaration of the field itself.

Compare with Kotlin:

    class MyFoo(val foo: Foo)
Done.
Post reply on HN