Posted
by
Unknown Lameron Monday November 26, 2012 @07:48PM
from the shiny-new-crap dept.

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

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.

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.

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.

Now this will just make describing the differences between java and javascript even more painful . . .:P

Painful? It's easy: The only thing the languages have in common is the first four letters of their names. Outside of that, they're completely unrelated -- any apparent similarities are just a result of their common heritage of C-like syntax.

As the actual proposal [java.net] 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.

I'd also like to know what they mean by "lightweight JavaScript runtime". That must be completely subjective. If they are able to create a runtime that uses even close to the amount of memory v8 requires, I'll be impressed.

I guess lightweight in this case means that they reuse the Java runtime library and most importantly the Java Runtime with its Just In Time compiler, so they do not add a huge code base to the standard Java deployment.

I'm curious as to what benefits this will offer over Node.js [nodejs.org] or Rhino [mozilla.org]. I mean my biggest aversion to Java has been the amount of boilerplate needed, to a lesser degree C# (.Net). Been really liking Node.js + MongoDB + WebStorm lately. Thinking of stripping down my API and pushing the base as a starting point framework for for building JSON web services.

Java has had an integrated Rhino fork for 6 years. I presume the aim with this new engine is to improve the experience for people who are already using it more than to attract people away from existing standalone JS engines.

The benefit would be faster performance while offering the ability to mix and match JS with Java. Since they run on the same JVM you could call from an object implemented in one language straight through to an object implemented in another. e.g. use node.js like code to service a web request but pulling the data through domain objects filled from a hibernate store. A bit like how Groovy, Jython and other JVM based languages work.

Faster performance than Node.js? I will say I get the desire to utilize both environments... however, I feel that mixing the two would likely add a lot of additional complexity and that a service layer with predictable interface could work better for scalability. I know it can be pretty cool, just seems like the efforts would be better served elsewhere, unless they implement support for say NPM or AMD based modules and can re-use a lot of what's been written.

I think Java is the exception to that since if for some reason you don't like Oracle's Java (which is free and ubquitous) there are a number of other licenced implementations in software and hardware plus an open source version. And numerous app servers, web servers, frameworks, persistence models etc.

I would run a mile from using Oracle hardware and database tech though unless I was totally convinced that I could only obtain the performance and reliability required by the project from using it.

JRuby is still alive and under active development but its main developers are no longer Sun employees.

At the time, Sun took an active interest in Ruby, hired JRuby programmers and built IDE support for it in Netbeans. Puzzlingly Oracle did an about face and removed it from Netbeans 7 while adding support for PHP.

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

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 empl

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

It is similar to JSON, but notice the init function. This example creates a new Java (not Javascript) Car object, sets its driver and color attributes and starts the car when the application starts and stops it when the applicaton stops.

If in your particular configuration there are many such cars, than you are free to define your own Javascript function which can be used as a shortcut:

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 is an interpreter though. Sounds like they want something which compiles JS to actual bytecode and is therefore faster. Perhaps the effort required to make Rhino work the way they want is so high it's easier to write something from scratch.

Node.js uses Google's V8 Javascript engine which is too fast for some applications. Also, it doesn't use enough memory, a problem the JVM is likely to correct. You can't expect much from an app that fails to allocate 900MB of virtual space and an 60MB working set on start-up.

and it won't be as secure as a JVM-based solution that has many, many years of engineering updates and patches applied to it already. In fact, a JVM-based implementation would be so secure there's a new patch being developed for it right now.

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.

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.

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