
What Future Java Might Look Like - reactor
http://blog.codefx.org/java/dev/future-java-might-look-like/
======
shadowfacts
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](https://kotlinlang.org/docs/reference/data-classes.html)

\- Type inference: [https://kotlinlang.org/docs/reference/basic-
types.html](https://kotlinlang.org/docs/reference/basic-types.html)

\- Switch as an expression: [https://kotlinlang.org/docs/reference/control-
flow.html#when...](https://kotlinlang.org/docs/reference/control-
flow.html#when-expression)

\- Destructuring: [https://kotlinlang.org/docs/reference/multi-
declarations.htm...](https://kotlinlang.org/docs/reference/multi-
declarations.html)

~~~
cle
These existed long before Kotlin.

~~~
chei0iaV
But was there source-level compatibility with Java?

~~~
cle
What does that have to do with anything? My comment was mainly a protest of
what appeared to be Kotlin fanboyism, which I see a lot lately on HN. There is
nothing special about these features in Kotlin, they are common features in
many popular languages preceding Kotlin, and have been on Java developers'
radars long before Kotlin.

~~~
chei0iaV
My point is that you can take an existing Java codebase, stick in a Kotlin
file, and use those "future Java" features right now, in your Java project.

But the fact that those features might have existed in Haskell or Algol68 or
whatever is largely irrelevant since we're taking about Java.

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

~~~
pjmlp
When looking at the common Java shops scattered all around the world, not the
SV darlings, Java (the language) is the only option.

Why do you think Lightbend now offers Java services in addition to Scala ones?

Most of us only get to use Java, customers don't allow for anything else on
JVM related projects.

~~~
Roboprog
Welcome to Sacramento :-(

------
matrix
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).

~~~
overgard
Its weird how far java has fallen behind C# (especially given that C# was, to
put it kindly, originally just basically "microsoft java".) It would seem like
Oracle could just follow the blueprint, so I'm sort of surprised they haven't

~~~
jpitz
The falling-behind happened early, and fast. MS took full advantage of second-
mover status to change fast and add features. They also targeted fewer
platforms initially.

While the market niche was certainly aimed squarely at the same demographic as
Java users, the language owes as least as much to Borland Object Pascal as it
does to Java.

Speaking of Object Pascal, MS also got Anders Hejlsburg to design it.

Oracle/Sun, stuck with a huge, conservative enterprise user base, was shackled
by backwards compatibility.

In hindsight, I don't think it weird that Java fell behind the way it did.

~~~
douche
There was a huge gap of time where effectively there was no forward progress
with Java. I learned Java 6 in high school - by the time I graduated college
Java 7 still hadn't been released.

------
Roboprog
To me, most of the JVM languages have 2 similar problems with the "defaults":
references are optional, rather than mandatory; objects are mutable, rather
than immutable.

It's past time for a language that makes it's references mandatory unless you
explicitly indicate "optional" / "maybe" or whatever. Slapping "Optional<...>"
on stuff when "mandatory" isn't enforced seems to just make things worse.

Similarly, classes/objects, methods, modules, packages should be side-effect
free, unless there is a flag for mutation or other side effects.

We don't need Java 1.9, we need 2.0, with "breaking" (fixing) changes :-)

Scala shows some good ideas, but it doesn't go far enough. That, and I kind of
liked Groovy, too, as I would like to be able to turn on and off strong/static
type checking. (default on, but if you ask nicely...)

~~~
overgard
As much as I think immutable-by-default is a good idea for code correctness,
it does have a really big performance penalty since it means a LOT of GC
pressure (since you have to make a lot of allocations). Side effect free is
great, but, at the moment anyway you can't really do it in real time systems
where a GC pause is a huge problem

~~~
tormeh
A lot of those deallocations should be easy to figure out by a compiler,
though. Maybe the JVM can accommodate a delete instruction? If I say
list(1,2,3).par.map(x=>x*x) there's a couple of intermediate objects that can
immediately be deallocated. The GC shouldn't be bothered with cases that are
so obvious.

~~~
Roboprog
Beside generational GC, I also forgot to mention escape analysis, which sounds
like what you are leading up to.

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

~~~
nradov
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?

~~~
tormeh
Very interesting question. The benefits of a new language has to be weighed
against the learning that has to be done to use it and the load of maintaining
things in different languages. It's not every 3 years or anything like that,
but Java is 20 years old now, and it shows.

~~~
afandian
And another generation of programmers wastes time rewriting the same stuff in
the language du jour.

~~~
greydius
This is going to happen anyway.

------
RyanHamilton
Lombok already gives you some of this:

\- Data objects
[https://projectlombok.org/features/Data.html](https://projectlombok.org/features/Data.html)
That generate toString, getters, setters etc as required

\- Val for local variables
[https://projectlombok.org/features/val.html](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/](http://jpad.io/) a little program I made to make running
java scripts/snippets extremely easy.

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

[https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup...](https://docs.google.com/presentation/d/1XouaIJ5d3CaqEW87Fpup7YTcEQc4ZW3UF3hyrnDgx0M/edit#slide=id.p)

It's a nice tool.

~~~
Yhippa
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?

~~~
twic
The gotcha is that Lombok thinks classes should be structs, and will try to
persuade you of that too.

A fundamental plank of good object-oriented design - which i admit that i
rarely see or even practice - is information hiding. Lombok rips that up and
burns it. And that may give you a warm feeling for a while, but at some point,
you're going to fall through the floor.

~~~
Roboprog
Most java shops create a lot of "do nothing" scut work "beans". If that's what
much of the work you are forced to do is, make short work of it.

Lombok of course doesn't help much for classes with "Actual Work" (TM) in
them, but that's OK.

Was there something more subtle that I'm missing? (quite possible)

------
ygra
> 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 < 8\. I actually tried
finding out how far the value types proposal had progressed (since we convert
the code from C# we actually _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.

------
michaelcampbell
So... scala with some boilerplate?

~~~
tomp
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.

~~~
sixbrx
Is the excessive virtual dispatch still really slowing down simple for loops
in Scala? I thought Paul Phillips did a special-case fix for that. That's very
disappointing if that's still a problem.

When I programmed in Scala, I felt like this sort of thing showed that
priorities weren't quite right in the leadership somehow. For-loops are pretty
basic and their performance is important - simple ones shouldn't have ever
been slower than the equivalent Java ones IMO.

Another instance of misplaced priorities (again IMO), was the problem that you
couldn't have local/temporary variables in your class constructors (see for
example [http://www.scala-lang.org/old/node/1198.html](http://www.scala-
lang.org/old/node/1198.html)). Any values that you created inline in your
class body (which is your primary constructor) could be used but would
_implicitly_ become fields in your class instances even if they were never
used in any methods. Sure you can make factory methods in a companion object
etc but should have to do that always? That's _worse_ than Java and for no
good reason! The "simplified" syntax of not having an explicit block
representing scope for the actual constructor _code_ , separate from member
declarations, really bites in this case.

An example of this was the gcd value in Oderski's rational number class which
is one of the first examples in his book. The gcd value is needed to
initialize the numerator and denominator values, and you want to save it after
it's first computed temporarily so you don't have to compute it twice. But
naming it at all made it an actual instance field, not just a temporary in the
constructor. So every Rational would be carrying around this significant extra
storage unbeknownst even to a programmer who would have reviewed the source
code, unless they are in the habit of examining javap output for everything or
already knew to watch for this issue.

I don't know if that's been fixed or not. The very fact that this could stand
for so long, and how implicit the whole thing was about something so
fundamental ( _object construction_!), really bothered me about Scala though.

~~~
paulddraper
You can have local variables in the constructor.

The discussion you linked to shows you how.

~~~
sixbrx
Which post # in the discussion did you have in mind? There's some
misdirections in that thread with ideas that didn't survive the javap test
(which I think rather makes my point). I may do Scala again in the future and
would like to know how to avoid this (without factory methods as I mentioned).

If you mean Paul P/extempore's self described "if you can handle a little
perversion" method then - "no thanks", that's pretty bad, I'd rather just do
factories.

~~~
paulddraper

        class Rational(n: Int, d: Int) {
          require(d != 0)
    
          val (numer, denom) = {
            val g = gcd(n.abs, d.abs)
            (n / g, d / g)
          }
    
          // ...
          private def gcd(a: Int, b: Int) = if (b == 0) a else gcd(b, a % b)
        }
    

Now `g` is a local variable.

~~~
sixbrx
As discussed in the thread, that doesn't work given that we're trying to avoid
extra storage, it adds an extra tuple member to the class. It's still true as
of the latest compiler just like it was in 2009:

    
    
        $ scalac -version
        Scala compiler version 2.12.1 -- Copyright 2002-2016, LAMP/EPFL and Lightbend, Inc.
    
        $ javap -private Rational
        Compiled from "Rational.scala"
    
        public class Rational {
          private final scala.Tuple2 x$1;
          private final int numer;
          private final int denom;
          public int numer();
          public int denom();
          private int gcd(int, int);
          public Rational(int, int);
        }

~~~
paulddraper
Sure, okay. But the point remains that "you couldn't have local/temporary
variables in your class constructors" isn't quite true.

FYI, you could avoid that but not without giving up `final`.

This isn't exactly unusual. Lots of source languages (e.g., C) don't expose
all the abilities of the target language (ASM).

I'm surprised you mention this shortcoming compared to Java. I would have
mentioned the lack of a Java enumeration equivalent.

~~~
sixbrx
It was short for the explanation in the following paragraphs (OK I should have
added "without unwanted storage side effects" which was the whole point
though). WHich I still haven't seen resolved in a memorable/non-gross way (I
do assume extempore's hack works). Even Martin's private[this] idea from that
thread was apparently never implemented, I just tried it also.

I'm a Scala fan by the way, and this is a solvable problem (the private[this]
solution would be fine I think). But it's currently a landmine IMO and an
unfortunate because it's such an unforced error.

------
cbdfghh
What I would personally like (and I'm kind of surprised all projects which
tried to implement it died) is a Java -> static exe/elf compiler (sort of like
Go) or at least java -> exe/elf +libjava.so .

I hate that deploying Java requires that everything has to be configured
_exactly_ right, and write once run anywhere turns into write once debug
everywhere.

~~~
twic
That's been around since 2014:

[https://docs.oracle.com/javase/8/docs/technotes/guides/deplo...](https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-
contained-packaging.html)

------
mikeevans
So just like Kotlin then?

------
hashhar
I really started hating Java when I had to write a government office's Licence
Management web application using Java.

The tooling is brain dead, except JetBrains IntelliJ. The dependency
management system is braindead too (if not for IntelliJ's maven integration).
The MVC architecture implementation using Struts and Spring annotations
reminds me of PHP. The resulting applications are painful to step through, I
don't know why since Visual Studio can easily step through .aspx or .cshtml
files.

I then picked up ASP.NET MVC and haven't look back but unfortunately most of
the jobs in my country (India) still use Java for legacy web applications.

------
st3v3r
It'll look like this, except on Android. There, despite constantly being asked
when newer improvements to Java would come, they still had to ask if people
wanted them to update to Java 8, and why they'd want that.

~~~
pjmlp
It is because of this attitude that I side with Oracle.

Google just forked Java 6, and we only get cherry picked updates from newer
versions, which will only get worse every time a new Java version gets
released.

Looking at the current Java 8 half-backed support in Android 7, try to imagine
writing Java 10 library with all these goodies that also needs an Android
version.

------
geooooooooobox
still doesn't look bright imo

~~~
joncampbelldev
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.

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

~~~
estefan
Is anyone actually using Kotlin outside jetbrains? Seems like it doesn't have
much mindshare or any high profile projects using it.

~~~
bdavisx
I'm not sure, but I know the Gradle people worked with Jetbrains to integrate
it into Gradle, so you can use it instead of Groovy. SpringBoot initializer
will allow you to choose Kotlin as a language (along with Java and Groovy).
Corda (an open source distributed ledger was built with it) - not sure how
many are using Corda since it's so new. Quasar (an JVM actor library) supports
it. Here's an article about KeepSafe converting their Android app:
[https://medium.com/keepsafe-engineering/lessons-from-
convert...](https://medium.com/keepsafe-engineering/lessons-from-converting-
an-app-to-100-kotlin-68984a05dcb6#.c6dnkag4h). There are several companies
listed on the Kotlin website as well.

edit: The list of companies from the Kotlin website:
[https://github.com/JetBrains/kotlin-web-
site/blob/master/dat...](https://github.com/JetBrains/kotlin-web-
site/blob/master/data/companies-using-kotlin.yml)

I guess my point is you can find people using it. I just wonder why anyone who
is currently using Java doesn't at least consider it and try it out -- it's
much more concise and nicer to develop in. But then again, I guess a much
larger percentage of Java developers don't ever learn anything new and
probably have never even heard of the name.

~~~
vorg
Kotlin's backed by Jetbrains which makes IntelliJ which many Java developers
have heard of, whereas Apache Groovy was dropped by Pivotal which also still
backs Spring. I imagine more and more software which enables Groovy for
scripting will follow in the footsteps of Gradle and SpringBoot by allowing
Kotlin to be used as well, such as Jenkins and maybe even Grails one day.

------
dschuetz
Dead, finally? ..Ow, damn, false alarm! Just another vile article :(

~~~
mixedCase
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.

~~~
dschuetz
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...

~~~
odabaxok
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._

~~~
unclebucknasty
> _It is because you do not comment according to the guidelines, which
> encourage people to start conversation with reasoning_

Not strictly. The guidelines encourage people to start conversation with
reasoning, but also encourage people to downvote for disagreeing.

So, there's some dissonance in there as it says, effectively: "make well-
reasoned arguments with which everyone can agree."

~~~
odabaxok
We are going OT here, but one last comment in this thread to clarify what I
meant.

Putting a comment saying just "Just another vile article", without any
thoughts about why it is vile, is just completely against the guidelines (from
the points mentioned in my previous comment). Even if you agree with its
content or not.

Also, I do not believe the guidelines encourage people to down-vote for
disagreeing (or at-least from my understanding). It is just in our nature and
the consequence of the fact, that there is a down-vote button. (I have never
tried it, still under 500 karma.. :) )

~~~
unclebucknasty
> _Putting a comment saying just "Just another vile article", without any
> thoughts about why it is vile_

I agree that it doesn't add to the discussion, which might be a good reason
for downvoting (i.e. as a form of "quality control"). OTOH, if you happen to
agree with the statement, then the ethos is that it's cool to upvote it on
that basis alone. Yet, it still adds no more to the discussion.

My overall point is that agreement/disagreement as a basis for surfacing (or
submerging) people's comments/ideas is a poor choice in either direction, if
it's stimulating, challenging discussion we want.

> _I have never tried it, still under 500 karma.._

Meh. It's overrated. Can't even remember the last time I downvoted a comment
(as you might've guessed) :)

