I thought it might be kinda interesting to have a thread on upcoming features.
I just notice that nashorn is now in the JDK source tree. Announcement here: https://blogs.oracle.com/nashorn/entry/open_for_business
Oh cool, this is the new JavaScript engine that utilizes the new “invokedynamic” instruction in the JVM?
I wonder how they’re going about coding that…it’s not like you can use it in Java code! O_o
If there was ever a situation that would finally show everyone, “Look, our JIT beats the pants out of everything”, it would be a JavaScript VM implemented by the Java VM. I look forward to benchmarks with interest.
Cas 
Don’t underestimate the many years spent optimising the JIT-compiler of V8. The Java folks are just new to the problem and it might take them a few years after the first public release to catch up.
I totally agree. The V8 Engine is a beast.
When I download the nashorn engine, can I ship it with Java7, or do I need Java8?
Don’t quote me on this, but I think that it requires JDK8 features.
Nashorn will be part of jdk8, replacing the existing implementation in javax.script afaik.
Repeating annotations and (optional) parameter name storage (other than debug): http://cr.openjdk.java.net/~abuckley/8misc.pdf
I don’t really see what’s so great about project nashorn. I just read these slides: http://www.oracle.com/javaone/lad-en/session-presentations/clientside/24821-enok-1439095.pdf
Unless a browser vendor is going to replace their javascript engine with nashorn, which will never happen given java’s recent security failings, what’s the use? Calling java-class libraries from javascript is cool, but not if it is only going to work in the nashorn JVM-powered javascript engine and not on a real browser.
Well for our purposes it makes using javascript as a scripting language from java more viable. From Oracle’s perspective I’d guess it’s mostly a PR move of attempt to draw more attention to using the JVM for languages other than java.
It wouldn’t be unreasonable to speculate that the performance of JS running on the JVM might actually exceed that of current serverside JS implementations (Node on V8 for example). Seeing as JS is becoming more interesting on the server side this is quite significant… if they can pull off the performance.
Cas
It baffles me as to why you would want to write JS on the serverside, what a nightmare. I thought most devs only used javascript because they had to on the client browser or because they are html devs who never learned a more fully-fledged programming language.
Think less about web pages and more about node.js. Or writing JavaFX apps in JS. Personally I find JS a giant leap backward in language evolution, but hey, it is popular. Another way to look at it is that Nashorn was already written (it was basically a proof of concept for invokedynamic) so they may as well take advantage of the existing work.
Yeah, I think it’s completely mental as well to want to use JS on the server, but this is more I think about people moving skills around than anything else.
Cas
It is very nice to be able to share code between server and client and use json “natively”. Also, if you combine this with mongoDB, you get a very neat package.
Also, please check out the meteor framework for something really crazy using this combo. Made my jaw drop
could be a nice way to intergate jacascript libs in java clients.
Same javascript libs are not that bad.
javafx + webview(webkit) + nashorn
javascript on serverside would be terribble indeed. :o
If you want to share code than go for a java client with javafx. I cant understand why people think a browser(designed to render static content) is a better plaftform than a vm(designed to execute code). But strangely “no deployment” is a killer phrase.
Imho the best new feature in java8 will be javafx8.
For anyone playing with JDK8, there’s been some tweaks: https://blogs.oracle.com/darcy/entry/functional_interfaces
About javascript being popular server-side, I suppose it’s the perceived “advantage” that you can quickly code the first 1000-5000 lines of code.
Beyond that, you need more experienced programmers.
With java, you hit that limit much much later, but it takes a bit more work to setup things.
Also it seems javascript on the server is “cool” because it’s new/unusual.
I don’t really see what javascript on the JVM is useful for. If I ever need a scripting language, I’d use groovy.
It’s useful for when you’re rendering HTML/CSS/JS pages on the client, as you might be doing should you be using JavaFX, for example… and I suppose as a scripting language for games it’s no more or less useful than Groovy, except a lot more people know it.
Cas
Oh ok.
Because JavaFX is using Webkit, I assumed the javascript engine was tied to it.
So they can replace it: V8 in Chrome, Nashorn in JVM…