Comment by spiralpolitik | Hacker News Reader

Comment by spiralpolitik | Hacker News Reader

I have to admit I thought Java was dead in the water after Java 6, but Java 7 while a fairly quiet release was a decent release and Java 8 actually moves the language forward into a better place. As for the future here's what I would like to see:

- Separation of language and libraries. Really the JDK should just ship with just a very small core of classes and everything else should be optional installed via a dependency or package manager. I know jigsaw is going in this direction, but I fear they are going to go the same way as J2ME with profiles. They should also clean up the cruft while they are doing this. This would allow the libraries to evolve separately from the JDK and even allow 3rd party framework to flourish while still keeping things reasonable manageable.

- Multiple return types. Scala has hacked around it, Python has them, Go has them. Bite the bullet and implement them so you can do sensible error handling without exceptions or returning `null`. While they are at it they could also fix the type system to finally allow `Integer hello()` and `String hello()` to exist in the same class.

- Implement Categories (or mix-ins). Seriously if I have to see another class called StringUtils or IntegerUtils I will gouge my eyes out.

- Get rid of the primitives. I read somewhere that this was on the cards for Java 10.

- Implement proper Generics.

- Implement @property just like Objective-C and .NET so that 80% of class files aren't getters and setters. I'm really surprised they never did this when they implemented annotations as this was the first obvious annotation to add. I know you can do it with Aspect J but you shouldn't have to. There was a JSR for this at one point but it seemed to disappear into the ether.

Multiple return types: Questionable benefit there. Exceptions are nice when used properly. Option classes handle the rest.

Categories: Default methods probably do what you want.

Get rid of primitives: Are you nuts? It turns out computers work on primitives. It's good to support them.

"Proper" generics: maybe you mean specialization, or maybe you mean reification. It's a choice.

Properties: If they irritate you that much, just use something that will generate them for you, using standard annotation processing.

Default methods work nothing like categories. For example you can't use a default method decorate String with an additional method usable on every instance of String.

http://rypress.com/tutorials/objective-c/categories.html

There is work going on to introduce value types which would allow for primitives to be got rid of in their current form and unification of the type system.

I admit I find my-self thinking from time to time that I need to "return multiple values from this method". But this is not often, and in most cases I find that it is a result of bad design. A method should be short and have a single responsibility, that is at-least the java best practice mantra, having only a single return type help enforce this.

The problem with this is you are forced to violate Occam's Razor by introducing unnecessary classes and methods when you need to return two related but distinct results from an operation.

For example a method to calculate the value of an asset portfolio could return the value of the portfolio and the set of assets that are missing prices in a single call rather than having to make two separate ones (and potentially two iterations through a data collection). Cleaner to be able to return a number (or a money class) and a set of assets rather than having to return CalculationResult. As a bonus you also get to dodge the hardest problem in programming, naming things ;)

Most of my issues with Java stem from violations of Occam's Razor of this manner.

Compare with say Python where introducing classes is much less necessary and ends up with cleaner and clearer designs.

> Multiple return types. Scala has hacked around it, Python has them, Go has them. Bite the bullet and implement them so you can do sensible error handling without exceptions or returning `null`.

Heh? How are these things related to each other? Who in their sane mind would use tuples for error handling?

`Go` uses them in that manner.

f, err := os.Open("filename.ext") if err != nil { log.Fatal(err) }

Ouch, forgot that. That's of course beyond stupid.

Reply on news.ycombinator.com