Live data from Hacker News

Java 9 features announced

jaxenter.com

31–40 of 228 posts

Re: Java 9 features announced

#31
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

Amen. How about some language keywords like "readable" and "writeable"? public class Foo { public readable int canSeeeMeButCantChange; public writeable int cantReadMe; public int existingBehavior; } These are pretty simple changes to the compiler and verifier. You would make canSeeeMeButCantChange an invalid "left hand" variable in the compiler, and the verifier would have to check for any writes to the fields. cantR…

Is that not what final does?

I'd be interested in seeing C#-like getters and setters. As long as they're just getting and setting, they're implied, but if you want to introduce a check or some other logic, you can do so without changing the signature of the class.

Groovy does some of this, but it requires you to use the name of the field - ie. person.age will check for a getAge() method first, then fall back on the "age" field. I quite like that methods have verb-names, but I don't want to verb my fields.

Re: Java 9 features announced

#32

Still no hash literal :-(

Not really a place for it in a strongly typed language like Java :/ I could maybe see language support for creating Maps or something, but in Java you're supposed to create your own Objects and let the compiler check your code for errors.

Re: Java 9 features announced

#33
post #16

Earlier quoted context omitted.

What is hot swapping?

Replacing code while it's running. Currently this is possible but quite limited in the official JDK, you can only replace the contents of method bodies. Edit: Demo of it in action here, notch is rapidly developing a game in Eclipse by changing the code while it's running: https://www.youtube.com/watch?v=rhN35bGvM8c

There's always JRebel!

Re: Java 9 features announced

#34

Still no hash literal :-(

Not really a place for it in a strongly typed language like Java :/ I could maybe see language support for creating Maps or something, but in Java you're supposed to create your own Objects and let the compiler check your code for errors.

I assume you meant statically typed, rather than strongly typed.

Swift has this: var airports: [String: String] = ["TYO": "Tokyo", "DUB": "Dublin"]

Re: Java 9 features announced

#35

Earlier quoted context omitted.

Amen. How about some language keywords like "readable" and "writeable"? public class Foo { public readable int canSeeeMeButCantChange; public writeable int cantReadMe; public int existingBehavior; } These are pretty simple changes to the compiler and verifier. You would make canSeeeMeButCantChange an invalid "left hand" variable in the compiler, and the verifier would have to check for any writes to the fields. cantR…

The other "Missing feature" is null safe ".". Other languages have it, but I don't know what the technical name is... basically: Integer val = some.other.chain.of.objects.value; In Java, this code has a huge potential for NullPointerExceptions. Instead a new operator (yes, I know) like: Integer val = some.?other.?chain.?of.?objects.?value; If any of the intermediate objects are null, the whole assignment becomes null…

This is solved in a more general way in Java 8 via monadic optionals. The basic idea is to wrap your nullable objects in an Optional, which then both forces you to deal with the possibility of the value being absent and gives you good tools for doing so. Your example, with Optional, looks like this:

T obj = ...;

Optional.of(obj).map(T::some).map(U::other).map(V::methods).getOrElse(null);

Not quite as clean syntactically, but much more general, as the same operations can be applied to other monadic objects.

Re: Java 9 features announced

#36

Earlier quoted context omitted.

Amen. How about some language keywords like "readable" and "writeable"? public class Foo { public readable int canSeeeMeButCantChange; public writeable int cantReadMe; public int existingBehavior; } These are pretty simple changes to the compiler and verifier. You would make canSeeeMeButCantChange an invalid "left hand" variable in the compiler, and the verifier would have to check for any writes to the fields. cantR…

Is that not what final does? I'd be interested in seeing C#-like getters and setters. As long as they're just getting and setting, they're implied, but if you want to introduce a check or some other logic, you can do so without changing the signature of the class . Groovy does some of this, but it requires you to use the name of the field - ie. person.age will check for a getAge() method first, then fall back on the…

Yes, sort of like final... but different.

I was thinking this is more for _public_ variables... so like internally, a class could modify it's own readable fields, but code external could read only.

Re: Java 9 features announced

#37
post #11

Nothing pollutes java source more than getters and setters. I can't believe this still isn't being address. Wish they'd move in the direction Groovy has in this regard.

Sorry to ask, but as a noob who just picked up Java, how do other languages address this issue? What's wrong with getters and setters?

Re: Java 9 features announced

#39

Earlier quoted context omitted.

Not really a place for it in a strongly typed language like Java :/ I could maybe see language support for creating Maps or something, but in Java you're supposed to create your own Objects and let the compiler check your code for errors.

I assume you meant statically typed, rather than strongly typed. Swift has this: var airports: [String: String] = ["TYO": "Tokyo", "DUB": "Dublin"]

:D Thanks for the correction

I like the swift example... Map map = new HashMap(){"TYO": "Tokyo", "DUB": "Dublin"};

Post reply on HN