What Future Java Might Look Like • Hacker News Board

Re: What Future Java Might Look Like

#21

Post by Roboprog » Wed, Dec 07, 2016, 5:01 PM UTC

RyanHamilton wrote: post #3

Lombok already gives you some of this: - Data objects https://projectlombok.org/features/Data.html That generate toString, getters, setters etc as required - Val for local variables https://projectlombok.org/features/val.html I don't start a new project without it. And if you really want stripe down java checkout http://jpad.io/ a little program I made to make running java scripts/snippets extremely easy.

FWIW, I did a presentation on Lombok at the local Java user group recently:

https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup...

It's a nice tool.

Re: What Future Java Might Look Like

#22

Post by mikeevans » Wed, Dec 07, 2016, 5:04 PM UTC

So just like Kotlin then?

Re: What Future Java Might Look Like

#23

Post by dlandis » Wed, Dec 07, 2016, 5:06 PM UTC

I wish they would focus on making the underlying platform and bytecode more amenable to all the other, non-Java languages like Scala that compile to JVM bytecode. The real value is in the highly optimized, stable, and performant underlying JVM platform. If it was easier to create languages like Scala that were "compatible" with Java codebases and had the primitives they require in the underlying platform, then that would lead to an incredible amount of innovation I think. Nobody really cares that Java (on the language syntax level) is going to add some features in 5-10 years that other langs already had 10 years ago, that is ridiculous.

Re: What Future Java Might Look Like

#24

Post by shadowfacts » Wed, Dec 07, 2016, 5:08 PM UTC

The future of Java looks a lot like Kotlin. Aside from value classes, all of the mentioned features are present in Kotlin:

- Data classes: https://kotlinlang.org/docs/reference/data-classes.html

- Type inference: https://kotlinlang.org/docs/reference/basic-types.html

- Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when...

- Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.htm...

Re: What Future Java Might Look Like

#25

Post by shadowfacts » Wed, Dec 07, 2016, 5:08 PM UTC

The future of Java looks a lot like Kotlin. Aside from value classes, all of the mentioned features are present in Kotlin:

- Data classes: https://kotlinlang.org/docs/reference/data-classes.html - Type inference: https://kotlinlang.org/docs/reference/basic-types.html > Absence of implicit conversions is rarely noticeable because the type is inferred from the context - Switch as an expression: https://kotlinlang.org/docs/reference/control-flow.html#when... - Destructuring: https://kotlinlang.org/docs/reference/multi-declarations.htm...

Re: What Future Java Might Look Like

#26

Post by matrix » Wed, Dec 07, 2016, 5:08 PM UTC

While these would be welcome improvements to Java, the future of Java is not about these sorts of tweaks. What Java really needs to revitalize their ecosystem is a sustained focus on improving developer experience with modern applications.

That means elevating languages like Kotlin and Clojure, and producing modern libraries for basic web development so that there's a foundation of high quality components that people can build with, similar to .NET. Today, Java developers have to pick through a confusing mess of implementations for basic things with highly variable levels of quality and interopability (the biggest gap probably being security).

Re: What Future Java Might Look Like

#27

Post by Yhippa » Wed, Dec 07, 2016, 5:08 PM UTC

Roboprog wrote: post #21

RyanHamilton wrote: post #3

Lombok already gives you some of this: - Data objects https://projectlombok.org/features/Data.html That generate toString, getters, setters etc as required - Val for local variables https://projectlombok.org/features/val.html I don't start a new project without it. And if you really want stripe down java checkout http://jpad.io/ a little program I made to make running java scripts/snippets extremely easy.

FWIW, I did a presentation on Lombok at the local Java user group recently: https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup... It's a nice tool.

I've seen many different codebases but have never run into Lombok. I really want to use it. Any practical gotchas I need to worry about?

Re: What Future Java Might Look Like

#28

Post by wtetzner » Wed, Dec 07, 2016, 5:09 PM UTC

tormeh wrote: post #12

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.

I disagree. I mean, I agree that Java isn't good, but the changes made in Java 8 made Java both better and bigger.

Re: What Future Java Might Look Like

#29

Post by odabaxok » Wed, Dec 07, 2016, 5:09 PM UTC

dschuetz wrote: post #18

mixedCase wrote: post #14

Earlier quoted context omitted.

You're being downvoted, but really, the only saving grace in Java is the occasionally useful tooling that can't be used in the other two actually good JVM languages: Kotlin and Scala. And right now the only one I can think of is j2objc. Java should absolutely die.

Isn't this upvote-downvote thing somehow linked to confirmation bias? I'm getting downvoted for having issued an opinion which opposes that of the others? This sounds so horribly wrong to me...

It is because you do not comment according to the guidelines, which encourage people to start conversation with reasoning etc.

Points done bad in your comments:

Avoid gratuitous negativity.

When disagreeing, please reply to the argument instead of calling names. E.g. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them.

Please resist commenting about being downvoted. It never does any good, and it makes boring reading.

Re: What Future Java Might Look Like

#30

Post by lmm » Wed, Dec 07, 2016, 5:10 PM UTC

nradov wrote: post #16

tormeh wrote: post #12

Languages cannot get better, only bigger, without dropping backwards compatibility. This is why Java needs to die. Not because it's particularly horrible, but because we can do better now.

By that standard every language needs to die. Or to put it another way, how long should languages be permitted to survive as we figure out better ways of doing things?

I'd say about 5 years after their replacement becomes production-ready. (Having started switching to Scala 6 years ago I'd say that's about now for Java).