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

101–110 of 161 posts

Re: JDK 9 release schedule

#101

Post by jsmith0295 »

int_19h wrote: post #57
whateveracct wrote: post #9

Earlier quoted context omitted.

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?

Doing it a better way is hard

Re: JDK 9 release schedule

#103

Post by carterehsmith »

marc_omorain wrote: post #80
chrisseaton wrote: post #78

Earlier quoted context omitted.

What would a high level message for changing the name of some object look like, if not setName(newName)?

Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.

"Calls to mutate state, such as changing the name field, should be rare."

Says who?

For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse.

It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers.

So, the quantity of the item keeps mutating.

How do you propose to deal with the above? Tell the warehouse people that they should only do their thing "rarely"? Seriously.

Re: JDK 9 release schedule

#104

Post by carterehsmith »

lacampbell wrote: post #82
chrisseaton wrote: post #78

Earlier quoted context omitted.

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…

Things change?

Consider a trivial to-do list. You can click on the 'completed' checkbox. So the 'completed' field has chaged.

Or, you can say ooops I mistyped the label. So you change the label.

Is there anything wrong with that?

Re: JDK 9 release schedule

#105

Post by ap22213 »

smoyer wrote: post #100
merb wrote: post #8

Earlier quoted context omitted.

well as others already pointed out, value types. this changes the way how the JVM uses Memory in certain ways and might be a huge improvement for a lot of stuff. specialized generics. this is a huge one, too, less boxing is always a win. JEP-286 less typing. Maybe Project Panama and maybe a even better AOT. Compared to what JDK 9 brings, this is huge. JDK 9 brings a Module system which was already possible (and a lot…

If you want less typing, then you definitely want Lombok ( https://projectlombok.org/ ). At JavaOne this year, they also showed a proposed shortcut for data object (@Data in Lombok). public class something(String name, int age) { ... }

I'm embarrassed to say that I've never understood the use case for Lombok. So, I write my code in Java with Lombok extensions. Then, another Java programmer goes to maintain it... and they have to learn Lombok?

Re: JDK 9 release schedule

#106

Post by arjie »

carterehsmith wrote: post #103
marc_omorain wrote: post #80

Earlier quoted context omitted.

Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.

"Calls to mutate state, such as changing the name field, should be rare." Says who? For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse. It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers. So, the quantity of the item keeps mutating. How do you propose to deal with the above? Tell the warehouse people that…

He means you'd call `increment(25)` to say you've got 25 more, or `employee.suspend()` instead of `employee.setAccess(SUSPENDED); employee.setPay(0); employee.setBenefits(NONE);`

Re: JDK 9 release schedule

#107

Post by cygx »

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

Something like obj.rename(newName). This might seem like a trivial change, but the underlying idea is that we're no longer dealing with a setter only affecting one particular field, but an abstract message that may affect arbitrary internal state.

Re: JDK 9 release schedule

#108

Post by carterehsmith »

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…

Properties are not a huge deal, I agree, but they sure are annoyance in Java (compared to e.g. C#).

That is, instead of one line of the code declaring the property, we end up with 10 lines doing the same thing, because we also need to declare getter and setter.

So, a realistic "POJO" that has 8 properties, will have 8 lines of code in C#, but 80 lines of code in Java.

Sure, your IDE will generate the getter and setter, but when you are reading the code, you have to check whether getter and setter are trivial, or perhaps they do something else, too.

It is quite common to get burned by a setter that someone made so that, after setting the value, it also does other shit like, hit Google Analytics, which is why everything is so slow.

The above problem is super easy to spot in 8 lines of code, but much harder to spot in 80 lines of monotonic, repeatable code, especially so when they are decorated with another 100 lines of code that is IDE-generated comments like 'Sets the foo'/'Gets the foo'.

My 5c.

Re: JDK 9 release schedule

#109

Post by abiox »

carterehsmith wrote: post #103
marc_omorain wrote: post #80

Earlier quoted context omitted.

Calls to mutate state, such as changing the name field, should be rare. I don't see the value in adding syntactic sugar to make it easier to mutate state.

"Calls to mutate state, such as changing the name field, should be rare." Says who? For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse. It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers. So, the quantity of the item keeps mutating. How do you propose to deal with the above? Tell the warehouse people that…

a guess, but i'd wager "rare" here meant the code should in the main prefer immutable data structures (etc), not that the invocations per unit time of a particular method should be low.

Re: JDK 9 release schedule

#110

Post by carterehsmith »

arjie wrote: post #106
carterehsmith wrote: post #103

Earlier quoted context omitted.

"Calls to mutate state, such as changing the name field, should be rare." Says who? For example, there is a business requirement that we know the on-hand quantity of some item in the warehouse. It's a busy warehouse, and we keep picking that item for delivery, and replenishing it from our suppliers. So, the quantity of the item keeps mutating. How do you propose to deal with the above? Tell the warehouse people that…

He means you'd call `increment(25)` to say you've got 25 more, or `employee.suspend()` instead of `employee.setAccess(SUSPENDED); employee.setPay(0); employee.setBenefits(NONE);`

Increment(25) still mutates the value.

What is the point here?

Point - say you have a database with 300 tables and ~3,000 columns.

You do not want to play the game of "hide the method to change the value". That is a big waste of time for everyone involved.

Post reply on HN