Live data from Hacker News

What Future Java Might Look Like

blog.codefx.org

1–10 of 105 posts

Re: What Future Java Might Look Like

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

Re: What Future Java Might Look Like

#7

still doesn't look bright imo

yes I feel that scala or clojure already offer all these advantages (depending on your preference of static vs dynamic typing) and have great java interop.

And Kotlin as well, with java interop considered a top priority.

Re: What Future Java Might Look Like

#8

So... scala with some boilerplate?

Exactly. That's the primary reason I use Scala these days - all that's good in Java (libraries, JVM) but with a much nicer surface language! The only thing that's missing, really, is fast for loops (either Java-like, or automatic optimisation when looping over things like arrays or ranges). Conversely, a major thing missing in the post above is some sort of implicits, or at least C#-like extension methods.

Re: What Future Java Might Look Like

#9
> Brian went to great lengths to stress how very, > very speculative all of the following is and how > much things might evolve or simply get dropped. He > went so far to let everyone in the audience sign an > acknowledgment thereof (just mentally but still) and > explicitly forbade any sensationalist tweets.

> Well… first of all, this is no tweet and second of all, > I wasn’t in that audience.

Oh well. So they agree it's sensationalist and I won't hold my breath for those things to appear in the near future. For a recent new release of our library at work we dropped compatibility for Java have value types that were turned into classes in Java again) to see whether we can do things now that would integrate cleanly into a new Java language version later without drastic API changes on our part. Alas, nothing was to be found except for the original 2014 proposal.

Another point is the upgraded switch statement with pattern matching. The next version of C# is currently trying to add this and the current form looks a lot different from the initial proposal. I expect reality to change a fair bit of how those features will end up in Java eventually.

Post reply on HN