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

41–50 of 161 posts

Re: JDK 9 release schedule

#41

Post by pjmlp »

bitmapbrother wrote: post #36
pjmlp wrote: post #29

Earlier quoted context omitted.

> they'll assume it's a legacy product suffering from chronic under-investment. Or Android.

Hopefully they'll ditch Java and go with a superior language.

I don't believe, given what they repeat at every Google IO when people ask about it.

Also I don't have any issue with Java as I do like the language and use it since JDK 1.0.1.

My issue is with Android Java, a forked version of Java with cherry picked features of Java 6, 7 and now 8, just because Google didn't want to pay Sun.

A version that will be even harder to write portable code when Java 9 and 10 come out.

Re: JDK 9 release schedule

#42

Post by josho »

djsumdog wrote: post #22
javanese wrote: post #11

So, uh, how many people are using Java 8? I still see projects using Java 5...

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

Re: JDK 9 release schedule

#43

Post by jjoonathan »

pjmlp wrote: post #32
djsumdog wrote: post #26

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…

> 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;
    }

Re: JDK 9 release schedule

#47

Post by dmux »

josho wrote: post #39
pjmlp wrote: 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…

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

Re: JDK 9 release schedule

#48

Post by fauigerzigerk »

jjoonathan wrote: post #43
pjmlp wrote: 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; }

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 code (that are mostly auto generated and need no documentation)

Re: JDK 9 release schedule

#49

Post by benjiweber »

jjoonathan wrote: post #43
pjmlp wrote: 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; }

Thing is you don't really need to write getters and setters in modern Java.

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.

Post reply on HN