
Wrapping up Java 9 new Features - submeta
https://aboullaite.me/wrapping-up-java-9-new-features/
======
pwaivers
I am a C# developer. My thoughts:

\- I love that they are adding REPL. I really wish C# had this. I use IPython
all the time for Python. It is very helpful to mock something up quickly or
try out different features.

\- Adding private methods to an interface seems very wrong to me. An interface
is just a contract without any implementation at all. I am not sure the reason
behind this. Aren't abstract classes a thing in Java?

\- I was sad to see that they have not included type inference to Java yet. It
is just a syntax thing, but it makes writing code feel so much less wordy.
Here's an open JEP for it:
[http://openjdk.java.net/jeps/286](http://openjdk.java.net/jeps/286)

~~~
pents90
As a long-time Java developer, I really hope they won't implement JEP 286. I
think type inference by the compiler is a bad idea, as it results in less
readable code, more bugs, and an unnecessary burden on the compiler. I think
all the examples where type inference is convenient are trivial cases, but the
downsides start to crop up in real-world, large code bases. So it's something
that makes the easy things slightly easier and the hard the things harder.

Type inference already happens for you when you are using a good IDE, like
IntelliJ IDEA. You can just use the "Introduce Variable" refactoring. And
better yet, it self-documents your code with the variable's type.

~~~
pwaivers
> _Less readable code_

Maybe it is because we are used to our own paradigms, but the following is no
less readable to me because of inference. And these are the 95% of cases.

    
    
      var index = 0;
      var name = "pwaivers";
      var names = new List<string>();
      var nameMap = new List<string, Dictionary<int, Address>>();
    

> _more bugs_

I have never seen a bug arise because of type inference. Do you have an
example?

> _unnecessary burden on the compiler_

The compiler does a lot of work and this would probably be insignificant to
add to it. However, I am totally open to learning more about this.

~~~
kentosi
The examples you've given have direct values. Try:

    
    
      var index = getIndexFromSomewhere();
      var name = getHandleFromUser("peter", "waivers")
    

The type isn't as clear anymore.

*Edit: I'm absolutely a fan of the var syntax, having dabbled with scala. I'm just expressing what I think the original author's complaint is.

~~~
thelazydogsback
I think the code is _much_ more readable and less annoying with inference. And
as for your examples, you don't _need_ to know the types - the compiler will
complain if you try and use them inappropriately whether the type was explicit
or not.

But the issue you have glossed over is that sometimes there is no nominal type
- there is only an anonymous type, as for example returned by a LINQ query
using new{}, or via monad-style combinators where you really don't want to see
the type for fear of your eyes bleeding.

~~~
btschaegg
> I think the code is much more readable and less annoying with inference.

I concur. I've been dabbling with Java a bit again (mainly because of a hobby
project in order to learn Clojure) after a pause of multiple years.

It boggles my mind that compiler inference didn't make it into the language
yet. Everytime I have to declare a totally obvious type, I cringe.

------
buster
Is jigsaw being shipped or not? (relating to [https://jaxenter.com/jigsaw-
dispute-means-possible-delays-ja...](https://jaxenter.com/jigsaw-dispute-
means-possible-delays-java-9-133723.html) )

~~~
bitmapbrother
Yes, the objections by IBM and Red Hat won't stop this train.

------
linkmotif
All of this is super cool but what I really want is async/await. Every day I
wish I had it. I know everyone has some pet thing they want, but I can't
imagine async/await being nothing short of a game changer for Java. Why is it
never mentioned? Will it ever happen?

~~~
sreque
I can only guess, but it is in general very difficult to retrofit what is
essentially green threading, coroutines, and continuations into a runtime that
was built without those features. Scala has tried at least a couple of times,
and as is typical of the language and community, has come up short as the
original contributors lost interest or decided the problem was too hard. This
includes:

* Scala's CPS compiler plugin, now deprecated and unmaintained.

* Macro-based async/await library. It's neat but has many more limitations than C#'s equivalent or Kotlin's, and hasn't had any updates in a couple of yaers.

It looks like Kotlin has recently added experimental support for async/await.
That language may be your best bet for now if you want to code in this style
on the JVM.

~~~
tormeh
What's the difference between async/await and a future? I've only used
futures, but async/await looks like exactly the same thing: You're forking a
thread (green or otherwise) to do some stuff and to set a flag of some sort
when it's done so you can check on it. Right?

~~~
sreque
At a high-level, async/await lets you write non-blocking code as if it were
blocking. Golang has a huge advantage here because the runtime was built from
the ground up so that everything is non-blocking and the language has built-in
support for operations that look like they block, but underneath the hood they
don't actually block a thread.

Futures are interesting, but at the end of the day they are basically not that
different from callbacks. Instead of writing a function that takes a callback,
you write a function that returns a future that you essentially register
callbacks onto. In Java 8 this type is called a CompletionStage. In fact, in
one of Scala's coursera courses they teach you how to take callback-oriented
code and convert it into code that returns futures. The fact that it is so
easy to convert between the two helps illustrate that futures aren't really
adding much. Yes you can compose using flatMap, but, again, I don't think this
makes the code that much easier to write, or, more importantly, debug and
maintain.

As an example, at $lastjob I converted a blocking networking library to a non-
blocking one. I started out using futures but I found that it generated a lot
of Lambdas, which made debugging much harder because the stacktraces were long
and incomprehensible. I ended up switching to callbacks and used named, not
anonymous classes to improve readability. Not only did the code feel easier to
read and debug but I got better performance out of the library due to reduced
memory pressure.

------
wodencafe
Why didn't they just use OSGi, a stable, mature (16+ years old) technology for
modularity, instead of re-inventing the wheel with JPMS?

~~~
pjmlp
Because OSGi is a pile of needless complexity for selling consulting support,
the less I have to touch it the better.

~~~
fauigerzigerk
Aren't you an IT consultant though? ;-)

~~~
pjmlp
Yes, but getting to do JEE and stuff like Websphere is already enough, I don't
need to fight with OSGi as well. :)

Having written a few Eclipse plugins was already enough.

~~~
wodencafe
Don't let Eclipse give you a bad impression of OSGi.

There are now some very cool things that make starting a new OSGi project a
lot easier:

* Declarative Services, for simplifying Component definitions (No more editing XML)

* bnd / bndtools for building your OSGified jar (No more manually editing the Manifest)

------
mcherm
> underscore character is reserved. A variable can no longer be named only '_'

Huh.... I wonder why that is?

~~~
wodencafe
They are going to use it to represent lambda parameters.

Please see:
[http://openjdk.java.net/jeps/302](http://openjdk.java.net/jeps/302) \- Lambda
Leftovers

~~~
mcherm
Ah. Thanks.

------
kleff
Has there been any hints of adding default parameters to Java at some point?
It's one of those things I find really useful in Python or C#, but for some
reason never seems to find its way into Java.

~~~
wodencafe
I second this. Java needs default parameter values.

------
aethos
Simple, but I am most excited to see a REPL here -- JShell. I have written so
so many Tester classes when I just wanted to run a few lines of java.

~~~
revscat
I used the Groovy shell for this. Since Groovy is Java, you can paste Java
code into the Groovy REPL and it works fine.

~~~
vorg
> Since Groovy is Java, you can paste Java code into the Groovy REPL and it
> works fine

Did you mean Java 7 and previous versions? You certainly can't paste Java 8
code into the Apache Groovy REPL if it has lambdas because Groovy hasn't been
updated for Java 8, not to speak of the new features in Java 9. My guess is
the sad state of the Groovy ecosystem is probably why Oracle even created
JShell.

In fact, you can't even paste Java 7 code in there and have it behave the same
because of lots of little incompatibilities like the meaning of the ==
operator. Every Java developer should know never to paste Java code into a
Groovy REPL and rely on the result for testing purposes.

Groovy isn't Java. Like Java, Groovy generates JVM code, though it typically
runs slower than Java code because Groovy is a dynamically-typed language.
Although it added annotations for static typing into Groovy 2, they don't work
for bulk code, only isolated test cases, and the latest versions of Groovy are
still written in Java, not statically-annotated Groovy.

------
needusername
The HTTP/2 client is incubator only [1]. Strictly speaking it's not part of
Java 9. But that's not a big deal because ALPN is part of Java 9 so you can
use 3rd party clients.

[1] [http://openjdk.java.net/jeps/110](http://openjdk.java.net/jeps/110)

------
leastangle
One additional thing which is missing in the post is that AES-GCM is
(finally!!) becoming usable:
[http://openjdk.java.net/jeps/246](http://openjdk.java.net/jeps/246)

> performance increase is large compared to JDK 8 GA, ranging from 34x to 150x

------
bachmeier
I don't see anything in there about improving interoperability with native
code. Years ago there were discussions of a project to do that. Maybe that is
dead - perhaps everyone interested in native code interop has already moved
on.

~~~
vvanders
Or value types, which would remove some of the need for native code(yes yes, I
know it's coming in Java 10 which means we'll see it in 2030 or so).

~~~
pjmlp
C++ devs are still waiting for concepts and modules as well.

Waiting for features is not unique to Java.

~~~
vvanders
Really? I'm certainly not waiting for those. If I'm using C++ it's to go wide
across platforms or for performance and none of those help me much in that
area.

------
sea6ear
List<String> list = new ArrayList<>(){ };

~~~
ucho
Yeah, worst example ever. They should make it harder to make inner anonymous
classes, not easier. When such code is used inside JEE/CDI/Spring Beans it
leads to some annoying leaks or issues with serialization.

------
joshmarinacci
Death of the Applet. Yay! Finally.

