For over a decade now, the JVM has supported the most (by a large margin) languages of any multi-language runtime. I remember there were well over a hundred different languages implemented on the JVM, including all the common ones and a few you've probably never heard of. (See http://www.is-research.de/info/vmlanguages/ for page after page of language implementations on the JVM.)
The amazing thing -- in the case of dynamic languages -- is that these languages were running on the JVM without any real help from the JVM itself. This resulted in some combination of (a) additional complexity for the language implementer and (b) far less than optimal performance. Over the several years since Oracle acquired Sun, Oracle has been investing (fairly heavily, considering that there is no "product for sale" in this area) in making the JVM much more friendly for dynamic languages. The example most commonly cited is the "new" invokedynamic byte code, but there's also quite a lot of work going on in the Java libraries and in the JVM itself to make other languages easier to implement and to make their performance significantly better. The Nashorn project represents some of the early fruit of this work, for example by making extensive use of call-site capabilities with invokedynamic. However, projects like jRuby and Nashorn that have taken advantage of the early JVM work for dynamic language support have also given rise to an additional wave of ideas on how to optimize the JVM further, so there's already work on a "v2" of these ideas (e.g. full support for inlining of dynamic invokes, which is something I don't even understand at this point). It's important to understand that there is no single use case for the JVM, just as there is no single use case for Linux. Dynamic languages are one constituency that are pushing the boundaries of performance optimizations on the JVM, but that is just one facet of the investments being made in the Java platform. Just as with Node, the OpenJDK development is done in open source and involves many different organizations and individuals, and fortunately is not limited by the imagination and resources of a single company. One benefit that we believe is inevitable from this work is the ability of a platform -- like Node -- to be able to run literally *as part of* any Java environment, including as part of a full Java Enterprise server, meaning that Node could take advantage of the various "enterprisey" services of that environment, and vice-versa. I think that it will be quite interesting to see what emerges. Peace, Cameron Purdy | Oracle *(Working at Oracle, but posting my own opinions as an individual.) * On Thursday, October 4, 2012 11:52:44 PM UTC-4, Jonathan Buchanan wrote: > > There's been an interesting thread I've been following throughout this (my > first) JavaOne of "polyglot" - pretty much: "Java the language is way, > waaay far from perfect: use whatever JVM language best suits the job/domain > at hand." Obviously, there's been that "on the JVM" bent, but the message > dynamic language guys have been selling is: "if you need middleware which > already exists in a Java EE app server and there's a wrapper for <favourite > dynamic language>, just *use* the <favourite dynamic language> wrapper." > Other talks have gone further and pretty much said: "look: when you need to > scale, just use whatever's best at the task at hand, doesn't matter what > it's written in/runs on," at which many mental high-fives were given by > myself and a a certain amount of confuzzled questions were asked. > > The JRuby guys are way ahead on this front: Charles Nutter has had a bunch > of great talks here, and from listening to the Oracle & JVM guys it sounds > like he's been a key driver as an initial user of the JVM-specific details > (invokeDynamic). He and Tom Enebo (another JRuby guy) had a packed talk > where they did a great job of sellling dynamic languages in general and for > build/testing tools in particular as an entry point. Given that Oracle have > people working on a more efficient JavaScript implementation than what's > standard in Java-land, and that they're working on a Node API > implementation (a talk today about implementation details such as > https://github.com/szegedi/dynalink was a programmer geeking-out-fest, as > someone who's been stuck in webapps-land for too long), I guess this just > is a bit of a heads-up. > > (I should point out, FWIW, that I use (server-side) JavaScript and Python > almost exclusively in my free time and Java/JVM/enterprisey stuff almost > exclusively at work, so I'm currently a bit stoked (and drunk on free > alcolhol, and overwhelmed by SF partially due to the former) about having > attended days of talks which merge stuff I'm interested in personally and > stuff I *have* to be interested in professionally) > > Thanks, > Jonny. > > On 4 October 2012 19:05, Ben Noordhuis <[email protected] > <javascript:>>wrote: > >> On Thu, Oct 4, 2012 at 7:16 PM, Jonathan Buchanan >> <[email protected] <javascript:>> wrote: >> > I'm at JavaOne, for my sins, and I've been attending all the sessions >> > related to Oracle's new JavaScript implementation in Java, called >> Nashorn. >> > >> > What initially caught my eye was that they're also porting the Node.js >> APIs, >> > module system etc. in a project called Node.jar. Nashorn itself is >> going to >> > be open-source, but it sounds like it's hard to get a hold of Node.jar >> even >> > if you work for Oracle, and there are no plans to open-source Node.jar, >> but >> > it could be another deployment option in the future and another way to >> get >> > at multi-threading. >> > >> > These are what I can decipher from my scribbled notes: >> > >> > >> https://insin-notes.readthedocs.org/en/latest/JavaOne2012/meet_nashorn_bof.html >> >> - > >> >> https://insin-notes.readthedocs.org/en/latest/JavaOne2012/nashorn_node_jpa_persistence_bof.html >> >> >> > >> > They at pains to point out they hadn't looked at any other >> implementations >> > to keep the JavaScript engine "pure", but it sounds like the Node port >> is >> > trying to reuse as much of the Node JS libs as possible and Node's >> tests. >> > >> > Has the Node dev team been involved with or consulted about any of this >> > stuff? >> >> Very interesting, thanks for posting that. And no, we've not been >> consulted. :-) >> > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
