Slashdot Mirror
Oracle Proposes New Native JavaScript Engine for OpenJDK
hypnosec writes "Oracle has proposed a new project for OpenJDK — Nashorn, which aims to implement a high-performance yet lightweight JavaScript runtime that would run on the JVM natively. Nashorn will be headed by Jim Laskey, multi-language Lead at Oracle and the project will be sponsored by HotSpot group. The project proposes an implementation of JavaScript such that it can run standalone JavaScript applications via the JSR 223 APIs. Nashorn's design will enable it to take advantage of new JVM technologies like the MethodHandles and the InvokeDynamic APIs."
Now this will just make describing the differences between java and javascript even more painful . . . :P
I read TFA and all I got was this lousy cookie
There have also been standalone javascript engines running on the JVM; the best-developed is Rhino from Mozilla.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Give me a break, Chicken Little. Look at Oracle's history involving Java APIs though the JCP before spouting your FUD.
As long as it is compile once, debug everywhere I am fine with it... :-D
rm -rf --no-preserve-root /
This was first discussed in July 2011 at the JVM Language Summit (PDF) link. It was discussed at the most recent JavaOne, and there have been more than a few articles about it.
What do you know I wrote a novel
What history? Oracle's only prominent patent dispute is with Google. I remember Oracle suing some second-rate database company, but IIRC it was more about trade secrets than patent infringement. If anything Oracle is better known for dumping or abandoning the opensource projects it inherited from Sun, particularly OpenOffice and Solaris.
This will be most beneficial to tool builders. Also, maybe we won't have to use kludgy 'eval' so often when writing highly dynamic javascript.
Thought people should know
Nashorn is German for Rhinocerus .. So we wonder is this just another Rhino fork??
We're stuck with JavaScript in webapps (where there are plenty of excellent implementations already), but the JVM has little to do with that.
If they just want a native general purpose scripting language for the JVM, then JS seems like a terrible choice.
At least, the work that goes into this project should benefit other dynamic languages on the JVM as well.
sic transit gloria mundi
sethmeisterg - the "off-topic" that you'll see against this comment which was later removed was from me. I brushed the track pad and then had to post a comment to remove the moderation that I never meant to post (I was going for overrated because Oracle is not a company on whose goodwill one should build any edifice). I apologise and thought you deserved an explanation.
I said - don't look Ethel!..., but it was too late..., she'd already looked.
I'm sure that this won't make lay-person misunderstandings of the difference between Java and Javascript worse at all! At all! AT ALL!
The CB App. What's your 20?
I wouldn't trust Oracle further than I could smell them.
I have used Javascipt as the language of configuration files in a Java application. It replaced XML. It is a pleasure to work with Javascript for this purpose, much more comfortable than XML. I also considered YAML, but Javascript is more powerful and considering its ubiquity it does not need more learning.
However, I am not sure if real administrators would like Javascript in configuration files. At least it is standard, and has a good documentation, but the expressiveness of Javascript can be used in the wrong way too.
Nope, written from scratch.
As the actual proposal notes, while Project Nashorn has been in the works within Oracle for some time, what they're doing now is proposing to make it part of OpenJDK, to get more people working on it so that the code can be tightened up for production use.
Breakfast served all day!
Oracle? That's the company that just sued Google over Java. There are already several JavaScript engines for Java, and they'll be updated to use whatever non-proprietary JVM features Oracle deigns to add. So, the only real reason for Oracle to take the lead on this is that they want more control over JavaScript on Java and lock people more into their software "ecosystem". Thanks, but no thanks.
Rhino has been a part of the default Java distro since long before v8.
What I'd like to know is, how does this thing improve on Rhino? And can parts of it be reused in scripting engines for other languages? The article is pretty light on details.
Since JDK 6, the open source Mozilla Rhino Javascript engine is already built-in
Take-off every
If you want server-side javascript, then why not just use node.js, like everyone else is doing?
In the course of every project, it will become necessary to shoot the scientists and begin production.
Perhaps we could get fonts that don't suck in all applications without reprogramming. Or improved GUI performance. Or those bugs which are on your database for nearly a decade which never get fixed. Or LINQ. Or unsigned types. No instead we get a new Javascript VM. As if there weren't enough infection vectors already. Thanks Oracle.
Don't care.
none
before when microsoft decided it would be a really swell idea to have C#, jscript, mono and a host of other shitty analog lock-ins that solve a problem no one has. I guess its never too early to reinvent the wheel.
Good people go to bed earlier.
A fully compliant JVM written in Js. Doppio is the most advanced one that I know of. http://int3.github.com/doppio/
Once complete, it will become instantly redundant, because the non ms browser vendors will put jvms back in the browser to speed things up.
And that's a good thing! This whole js only thing for the web is dumb. At some point in the future, it could be 0 years, 20 years, this will come about and we (you) will all slap our foreheads and go...OMG, we could have been writing our web apps in language (insert favourite here) X this whole time? What were we thinking.
JS is being compiled and minified and closured away. JVM is open, it's bytecode. It can run anywhere. Let's let go of this fiction that its somehow good or more open to have a single client side web language.
No man, Java is the new COBOL, there's gunna be people maintaining and expanding on all the enterprisey java stuff for centuries.
"There has been standalone javascript apps (node.js is just one of them).; given history of Oracle they are going to take this idea present it as their own and then sue everyone and their grandmother.
Oracle-Google case shows patent system flaws
AccountKiller
"What do you know I wrote a novel [jockmurphy.com]"
...
Too many "I"s
AccountKiller
Rhino runs an interpreter that first compiles JavaScript into its own pseudo-bytecode, and then interprets the pseudo-bytecode. I believe what Oracle is proposing is to compile JavaScript directly into Java bytecode, using the new features of the JVM to handle the dynamic aspects that weren't possible with previous versions of the JVM.
cp /dev/zero ~/signature.txt
Totally not true. Enterprise IT people are still jumpy about Java and applets because of, well, the legacy of 1996. So it's not uncommon for individuals in such an enterprise--who've been beaten over the head about running applets or installing Java a million times--to get very concerned when you tell them that the web application that they're running relies on Javascript for many of its features. I know this for a fact; I've done consulting work for a significant number of large enterprise (5k-150k employees) in the context of web application performance, and *at least* once a week, we have someone raising concerns about installing Java--or at least a fear that they'll have to install a specific version of Java--when we discuss Javascript.
The one and only thing I like about C# is that nobody confuses it with Javascript. Of course, it's got its own namespace issues...
The CB App. What's your 20?
True dat. And sometimes building on their favorite flavor of Java. I can't tell you how often I've heard, "We can't install anything later than 1.4.2 because doing so will break X, Y, or Z application."
The CB App. What's your 20?
Who in his right mind would use javascript when not forced to?
On my Windows box I see jrunscript.exe - is that Rhino?
C:\Program Files\Java\jdk1.6.0_34\bin>jrunscript -?
Usage: jrunscript [options] [arguments...]
where [options] include:
-classpath Specify where to find user class files
-cp Specify where to find user class files
-D= Set a system property
-J Pass directly to the runtime system
-l Use specified scripting language
-e Evaluate given script
-encoding Specify character encoding used by script files
-f Evaluate given script file
-f - Interactive mode, read script from standard input
If this is used, this should be the last -f option
-help Print this usage message and exit
-? Print this usage message and exit
-q List all scripting engines available and exit
If [arguments..] are present and if no -e or -f option is used, then first
argument is script file and the rest of the arguments, if any, are passed
as script arguments. If [arguments..] and -e or -f option is used, then all
[arguments..] are passed as script arguments. If [arguments..], -e, -f are
missing, then interactive mode is used.
To nitpick, Rhino does/did supply a command line utility to compile scripts ahead of time to .class files. However, the Oracle included engine based on rhino doesn't expose this as an option.
Nevertheless, as you say, the Nashorn approach is almost certainly more efficient due to the JSR 292 improvements at the JVM level.