Wrapping up Java 9 new Features

https://aboullaite.me/wrapping-up-java-9-new-features/

by submeta • 9 years ago

102 89 9 years ago

bachmeier• 9 years ago

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.

vvanders2• 9 years ago

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

pjmlp5• 9 years ago

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

Waiting for features is not unique to Java.

AlphaSite• 9 years ago

That's project panama.

pjmlp5• 9 years ago

It is planned for Java 10.

I bet Java 10 is probably going to be released earlier than ANSI C++ finally gets modules or concepts finalized.

mcherm2• 9 years ago

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

Huh.... I wonder why that is?

wodencafe5• 9 years ago

They are going to use it to represent lambda parameters.

Please see: http://openjdk.java.net/jeps/302 - Lambda Leftovers

mcherm2• 9 years ago

Ah. Thanks.

avmich• 9 years ago

To introduce pattern matching in the future?

ww520• 9 years ago

Wildcard pattern? Wildcard variable? Dummy placeholder?

buster• 9 years ago

Is jigsaw being shipped or not? (relating to https://jaxenter.com/jigsaw-dispute-means-possible-delays-ja... )

bitmapbrother2• 9 years ago

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

wodencafe5• 9 years ago

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

batter• 9 years ago

i have used OSGI in projects and find it useful to see bundles states, Camel routes/endpoints, lot's of other useful stuff. But i have never seen it working properly in PROD enterprise application. Sadly my eclipse is just confirming that from time to time with errors :(

jcadam• 9 years ago

I know. OSGi needs to die. I'll quit a job before I subject myself to that level of pain and despair ever again.

AdieuToLogic• 9 years ago

  But i have never seen it working properly in
  PROD enterprise application.

FWIW, I have programmed for and deployed OSGi-based enterprise solutions. Karaf[0] was the container using Felix[1] most of the time (Equinox[2] being the other for a brief period). These are/were production systems, so I am curious by what you experienced as "never seen it working properly in PROD ..."

0 - https://karaf.apache.org/

1 - https://felix.apache.org/

2 - https://www.eclipse.org/equinox/

pjmlp5• 9 years ago

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

fauigerzigerk• 9 years ago

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

wodencafe5• 9 years ago

Ok, but do you think JPMS is a better alternative?

geodel• 9 years ago

OSGi, a stable, mature (16+ years old) technology

And hardly used in industry beyond eclipse project.

amyjess• 9 years ago

I used to work for a robotics company that made heavy use of OSGi.

We also wrapped OSGi in a services framework we created (and by that, I mean my boss wrote it, and then I added some features and bugfixes later), which we open-sourced.

What's really cool is that the Flow stuff from the article resembles a publish/subscribe library that we wrote and also open-sourced (under the name JFlux, even), which in turn was built on some interfaces that bear a resemblance to the Java 8 functional interfaces, except written for Java 6.

leastangle3• 9 years ago

I don't think that this is true: OpenHAB, Nexus 3, a lot of the enterprise application servers... One can probably compile a pretty long list of things "running in production" using OSGi.

moomin• 9 years ago

TBH, that's not the right question. I'd argue the right question was why didn't they make Jigsaw Maven-compatible?

aethos• 9 years ago

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• 9 years ago

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• 9 years ago

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.

libria• 9 years ago

There is a http://jpad.io/ which was probably modeled after .NET's LINQpad.

linkmotif4• 9 years ago

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?

sreque2• 9 years ago

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.

bitmapbrother2• 9 years ago

Kotlin supports coroutines/async/await so I'm not sure why you think it would be so difficult to add it to Java.

tormeh3• 9 years ago

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?

aardvark1792• 9 years ago

https://youtu.be/OMk5KoUIOy4 - have a look about 25 minutes in.

linkmotif4• 9 years ago

Thanks! Interesting. So, Java 11 or 12 eh?

pulse7• 9 years ago

At 3:15: "...Java VM and the language began as a sort of a better Smalltalk you might say..."

on_and_off• 9 years ago

isn't kotlin an option if you want async/await on the JVM ?

linkmotif4• 9 years ago

I didn't know Kotlin had async/await. Thanks, I will have a look.

sceutre• 9 years ago

We use https://github.com/electronicarts/ea-async at work and quite enjoy it. Baked into the language would be great though.

crypto5• 9 years ago

Is this the same like following?:

Future<Long> f = executor.execute(() -> myFunc());

kleff• 9 years ago

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.

wodencafe5• 9 years ago

I second this. Java needs default parameter values.

pwaivers4• 9 years ago

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

josteink• 9 years ago

- I love that they are adding REPL. I really wish C# had this

Here you go :)

https://github.com/dotnet/roslyn/wiki/C%23-Interactive-Walkt...

Also: csi.exe. Try it :)

pents90• 9 years ago

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.

saosebastiao• 9 years ago

I think you're suffering from Stockholm syndrome. I have never experienced a bug using scala's type inference that could have been prevented by more required boilerplate. Type inference is 100% benefit with zero drawback.

If you really want to know what a type is resolved to, you have both compilers and IDEs there to tell you. Relying on an IDE to write code is just hacking over a weak or broken language.

pwaivers4• 9 years ago

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.

coldtea2• 9 years ago

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.

It is already the case in lots of languages since 1990s and the sky has not fallen...

richard_todd• 9 years ago

It's not a compiler burden because it already has to determine the type of the right-hand side for typechecking purposes. So, the compiler actually does less work in the 'var' case, simply assigning the calculated type to the left-hand side rather than checking against a user-supplied type.

pacala• 9 years ago

Intellij: View type info [on Mac: Ctrl + Shift + P]. Of any [sub]expression. Whenever you care about that level of detail. On-demand self-documented code.

nonsince• 9 years ago

Rust, ML, Coq and Haskell have type inference and if those four are known for anything it's reliability and bug-free code.

swsieber• 9 years ago

I like the private interfaces thing. It's getting us closer to having "mixin" ability through interfaces. I think if we had "protected" methods, we'd be there (assuming protected methods played nice with interface inheritance).

aardvark1792• 9 years ago

So at Java 8 they added the ability for interfaces to have default implementations - this was so that the collections API (among others) could be expanded with lots of support for the new lambda features without breaking compatibility.

Allowing private methods means default implementations can be easily refactored to move common code to private methods without those internal methods themselves becoming part of the interface. Yes Java does have abstract types, but multiple inheritance is allowed from interfaces (which aren't structural) but not abstract types so interfaces are very widely implemented across the standard and other libraries.

pwaivers4• 9 years ago

I did not realize that Java had implementations in interfaces already. This makes perfect sense why they would add the private method then. Thanks for answer!

daigoba66• 9 years ago

REPL. I really wish C# had this.

Already exists: https://msdn.microsoft.com/en-us/magazine/mt614271.aspx

But I do a lot more these days with https://www.linqpad.net/ instead.

rzzzt• 9 years ago

Lombok implements "var" as an experimental feature: https://projectlombok.org/features/experimental/var.html

nine_k• 9 years ago

Interface methods is an attempt to add traits to Java. I find it especially nice that interface methods are insulated between interfaces. I find traits a much better approach than traditional inheritance.

You can inherit from only one base class; if Java had multiple inheritance, as C++ has, a number of other problems would arise.

jjtheblunt• 9 years ago

on your last point: they did, and it's called Scala. ;)

leastangle3• 9 years ago

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

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

sea6ear• 9 years ago

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

ucho• 9 years ago

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• 9 years ago

Death of the Applet. Yay! Finally.

needusername• 9 years ago

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

Wrapping up Java 9 new Features

Related Stories