JEP 335: Deprecate the Nashorn JavaScript Engine(openjdk.java.net)
openjdk.java.net
JEP 335: Deprecate the Nashorn JavaScript Engine
http://openjdk.java.net/jeps/335
12 comments
What actual reason is there to build anything new on oracle? MySQL is obsoleted by one of MariaDB, Postgres or Galera, especially for new things - and in my book, OracleDB is as well for new things. The OpenJDK supplies enough java to build big things and even the use of java might be debated.
This changed during the last decade, but at this point, oracle thrives on things large corporates depend upon. There is no reason to start anything outside of a large enterprise with Oracle investment with any oracle dependency. Quite the opposite.
This changed during the last decade, but at this point, oracle thrives on things large corporates depend upon. There is no reason to start anything outside of a large enterprise with Oracle investment with any oracle dependency. Quite the opposite.
I think Microsoft is trying (and, so far, succeeding) to consume this market with their C#/.NET offerings. Their open-sourcing of .NET Core and their commitment to cross-platform makes C# (which, of course, has similar syntax and standard libraries to java) an ever more attractive option.
"I think Microsoft is trying (and, so far, succeeding) to consume this market with their C#/.NET offerings. Their open-sourcing of .NET Core and their commitment to cross-platform makes C# (which, of course, has similar syntax and standard libraries to java) an ever more attractive option."
I've seen an interview with one of the managers for .NET who said that directly: they specifically want to compete with Java, and made the platform cross-platform and Open Source partly because Java is those things.
I've seen an interview with one of the managers for .NET who said that directly: they specifically want to compete with Java, and made the platform cross-platform and Open Source partly because Java is those things.
[deleted]
> Can someone give some background on the reasoning? ... So, one is too challenging to maintain but the other isn't?
I'm not sure why you're posing this as some absurd position, you literally answered your own question 2 seconds later... it's a completely valid reason to deprecate something from a maintainer POV, especially if you believe it's rarely used -- in fact the submitter mentions that Nashorn usage is very difficult to track, so ideally any pushback will inform whether this JEP goes through or not. The actual schedule mentions nothing of actual removal, anyway.
Graal and Truffle, from a license point of view, at least aren't really a problem. Graal is already shipped with OpenJDK 10 and you can use it today for your workloads (yes, the regular OpenJDK) with no problem, and Truffle is just a library you install from Maven and can use on any compatible JVM to make interpreters faster, if Graal is there. (It's LGPLv2 I believe.) In fact any of the Truffle-built languages like TruffleRuby could run on an ordinary JVM without Graal, I believe -- they would just be slow, like Nashorn. So I don't really get your comments about proprietary implementation -- you can literally just keep using OpenJDK and ignore it. The actual "GraalVM distribution" they advertise is just a branded, QA'd version of JDK 8 with Graal enabled.
The bigger questions around things like the copyright/API lawsuits is something else. That I can't comment about (and I'm not going to trust random HN users on their interpretation of the law.) The Enterprise Edition is weird but I suspect Oracle is going to find out quickly that very few people are willing to pay for compiler optimizations (IME, as a former compiler person). They're basically rent seekers, and they'll eventually dump it like they did with JMC/Flight Recorder once they move onto something else.
There is also the issue that they employ the main developers, so there's an argument for being a SPOF -- but if anything, Oracle has proven repeatedly they can lay off a team of developers like assholes and the OpenJDK community will pick up the slack (IcedTea, security updates etc), due to the immense existing inertia. (Flight Recorder has a JEP now and I'm willing to bet it will go through, and JMC will be picked up again, because they're both very valuable.)
The fact Oracle are annoying-ass rent seekers and litigous is one thing, but realistically like all of the important tech is in OpenJDK anyway -- so unless they're submarining the whole freakin' ecosystem at this point in a blaze of glory, you probably have nothing to worry about. Graal may even make some of your systems perform better for nothing at all...
> Makes sense, but I sure wish an alternative Oracle-effort-sized OpenJDK maintainer existed.
They're called Red Hat.
I'm not sure why you're posing this as some absurd position, you literally answered your own question 2 seconds later... it's a completely valid reason to deprecate something from a maintainer POV, especially if you believe it's rarely used -- in fact the submitter mentions that Nashorn usage is very difficult to track, so ideally any pushback will inform whether this JEP goes through or not. The actual schedule mentions nothing of actual removal, anyway.
Graal and Truffle, from a license point of view, at least aren't really a problem. Graal is already shipped with OpenJDK 10 and you can use it today for your workloads (yes, the regular OpenJDK) with no problem, and Truffle is just a library you install from Maven and can use on any compatible JVM to make interpreters faster, if Graal is there. (It's LGPLv2 I believe.) In fact any of the Truffle-built languages like TruffleRuby could run on an ordinary JVM without Graal, I believe -- they would just be slow, like Nashorn. So I don't really get your comments about proprietary implementation -- you can literally just keep using OpenJDK and ignore it. The actual "GraalVM distribution" they advertise is just a branded, QA'd version of JDK 8 with Graal enabled.
The bigger questions around things like the copyright/API lawsuits is something else. That I can't comment about (and I'm not going to trust random HN users on their interpretation of the law.) The Enterprise Edition is weird but I suspect Oracle is going to find out quickly that very few people are willing to pay for compiler optimizations (IME, as a former compiler person). They're basically rent seekers, and they'll eventually dump it like they did with JMC/Flight Recorder once they move onto something else.
There is also the issue that they employ the main developers, so there's an argument for being a SPOF -- but if anything, Oracle has proven repeatedly they can lay off a team of developers like assholes and the OpenJDK community will pick up the slack (IcedTea, security updates etc), due to the immense existing inertia. (Flight Recorder has a JEP now and I'm willing to bet it will go through, and JMC will be picked up again, because they're both very valuable.)
The fact Oracle are annoying-ass rent seekers and litigous is one thing, but realistically like all of the important tech is in OpenJDK anyway -- so unless they're submarining the whole freakin' ecosystem at this point in a blaze of glory, you probably have nothing to worry about. Graal may even make some of your systems perform better for nothing at all...
> Makes sense, but I sure wish an alternative Oracle-effort-sized OpenJDK maintainer existed.
They're called Red Hat.
Some points.
> I'm not sure why you're posing this as some absurd position, you literally answered your own question 2 seconds later
My question about background is I'm wanting to know about Oracle's shifting priorities, not the public ECMA-is-too-hard/fast comment.
> Graal and Truffle, from a license point of view, at least aren't really a problem
I mostly agree with this, however so long as a premium version exists, I'd be wary. Proprietary means that it may be open source, but it's not open community. It's about the owner, not the ability to use it.
> you probably have nothing to worry about
This is probably true for the core users, but what about those that have built a reliance on Nashorn and its API? My comment also points to the fact that if they are quick to deprecate one JS impl, will they not be so quick to do it again? But yes, I am not indicting Oracle on their stewardship of Java as a whole here as I mostly have no problem with it.
> They're called Red Hat.
I suppose I'd have to dig into committer prevalence, but I would guess that a lot of their participation is for their own needs. I doubt they would take on a JS impl owned by the OpenJDK community. I don't blame them either, just saying this is a fairly quick come-and-go for public OpenJDK API code.
> I'm not sure why you're posing this as some absurd position, you literally answered your own question 2 seconds later
My question about background is I'm wanting to know about Oracle's shifting priorities, not the public ECMA-is-too-hard/fast comment.
> Graal and Truffle, from a license point of view, at least aren't really a problem
I mostly agree with this, however so long as a premium version exists, I'd be wary. Proprietary means that it may be open source, but it's not open community. It's about the owner, not the ability to use it.
> you probably have nothing to worry about
This is probably true for the core users, but what about those that have built a reliance on Nashorn and its API? My comment also points to the fact that if they are quick to deprecate one JS impl, will they not be so quick to do it again? But yes, I am not indicting Oracle on their stewardship of Java as a whole here as I mostly have no problem with it.
> They're called Red Hat.
I suppose I'd have to dig into committer prevalence, but I would guess that a lot of their participation is for their own needs. I doubt they would take on a JS impl owned by the OpenJDK community. I don't blame them either, just saying this is a fairly quick come-and-go for public OpenJDK API code.
I don't know the breadth of RedHat's contributions to Java but Christine Flood and Aleksi Shipley are highly regarded and have worked on JMH, G1, and Shenandoah.
Sorry if I've left out other big names and projects these were just the few I've been following.
Sorry if I've left out other big names and projects these were just the few I've been following.
Regarding them dropping development, I think we're both more or less agree that relying on a SPOF (Oracle or not) isn't necessarily great, but I guess we just disagree on how much it matters... I don't see them as necessarily substantially more risky than any 3rd party dependency, I guess, given the actual place they exist in the ecosystem. Oracle is just a tainted name, rightly so.
You could definitely make an argument their Node/Truffle implementation isn't a real replacement in a sense, because it's not going to be in OpenJDK, so the level of support/etc isn't the same. Even from a maintainer POV, I do think that argument is valid...
> This is probably true for the core users, but what about those that have built a reliance on Nashorn and its API? My comment also points to the fact that if they are quick to deprecate one JS impl, will they not be so quick to do it again? But yes, I am not indicting Oracle on their stewardship of Java as a whole here as I mostly have no problem with it.
The real question is the timeline you're working on. First, most deprecations seem to take a long time to actually happen. If this happened in JDK 11, for example, there's no clue on when it might actually be removed. That's what deprecation periods are for -- to signal to people when things need to be upgraded.
Second -- why are you not using LTS releases? This sounds off base, but if you're on JDK 8, and presumably move to JDK 11 (the next LTS), you've literally got years to investigate possible alternatives here! Including something like the Truffle Node.js implementation, or a number of others. In fact, someone else could even step up to maintain Nashorn, in that time, as a separate package.
If you're such a massive user of Nashorn that it's literally going to kill you -- you're kind of the exact person who should step up and give input on this JEP! There's no seeming hard fist demanding this go through, so this seems to be precisely the kind of community ownership you want for things in the core OpenJDK -- as it should be!
> I suppose I'd have to dig into committer prevalence, but I would guess that a lot of their participation is for their own needs. I doubt they would take on a JS impl owned by the OpenJDK community. I don't blame them either, just saying this is a fairly quick come-and-go for public OpenJDK API code.
Red Hat is pretty invested -- they're even working on major open projects for OpenJDK like Shenandoah, and they stepped up to the plate to help provide security updates for lots of systems when Oracle dropped the ball on updates for Java 6/7. They do make core improvements to the GCs, to HotSpot, etc. I wouldn't say it's completely benevolent, and they do benefit from it -- but no company is, and they always do. They have top-tier talent on their team, though.
I think ultimately we're going to have to see how much their actual Polyglot vision thing works out in the long run. Personally I think it's neat but I really have no need to use the GraalVM distribution itself -- almost everything, except SubstrateVM, which requires their JDK 8 patches, works upstream with OpenJDK anyway...
You could definitely make an argument their Node/Truffle implementation isn't a real replacement in a sense, because it's not going to be in OpenJDK, so the level of support/etc isn't the same. Even from a maintainer POV, I do think that argument is valid...
> This is probably true for the core users, but what about those that have built a reliance on Nashorn and its API? My comment also points to the fact that if they are quick to deprecate one JS impl, will they not be so quick to do it again? But yes, I am not indicting Oracle on their stewardship of Java as a whole here as I mostly have no problem with it.
The real question is the timeline you're working on. First, most deprecations seem to take a long time to actually happen. If this happened in JDK 11, for example, there's no clue on when it might actually be removed. That's what deprecation periods are for -- to signal to people when things need to be upgraded.
Second -- why are you not using LTS releases? This sounds off base, but if you're on JDK 8, and presumably move to JDK 11 (the next LTS), you've literally got years to investigate possible alternatives here! Including something like the Truffle Node.js implementation, or a number of others. In fact, someone else could even step up to maintain Nashorn, in that time, as a separate package.
If you're such a massive user of Nashorn that it's literally going to kill you -- you're kind of the exact person who should step up and give input on this JEP! There's no seeming hard fist demanding this go through, so this seems to be precisely the kind of community ownership you want for things in the core OpenJDK -- as it should be!
> I suppose I'd have to dig into committer prevalence, but I would guess that a lot of their participation is for their own needs. I doubt they would take on a JS impl owned by the OpenJDK community. I don't blame them either, just saying this is a fairly quick come-and-go for public OpenJDK API code.
Red Hat is pretty invested -- they're even working on major open projects for OpenJDK like Shenandoah, and they stepped up to the plate to help provide security updates for lots of systems when Oracle dropped the ball on updates for Java 6/7. They do make core improvements to the GCs, to HotSpot, etc. I wouldn't say it's completely benevolent, and they do benefit from it -- but no company is, and they always do. They have top-tier talent on their team, though.
I think ultimately we're going to have to see how much their actual Polyglot vision thing works out in the long run. Personally I think it's neat but I really have no need to use the GraalVM distribution itself -- almost everything, except SubstrateVM, which requires their JDK 8 patches, works upstream with OpenJDK anyway...
Any system relying on Truffle depends on Graal. While it may end up being the future JVM JIT compiler, it's not field tested at all in production. I wouldn't yet bet everything on it.
> Can someone give some background on the reasoning
See
https://www.youtube.com/watch?v=-JLhwsbMvjQ
Truffle is just easier to maintain and much faster from what I’ve seen.
I don't doubt that at all. I have investigated its language creation properties myself. I understand the want to move to that for Oracle and stop maintaining two JS impls. It should just be clear it's less open and be clear where Oracle's resources are wrt OpenJDK vs Graal/Truffle, that's all.
Oracle's highly litigious nature ensures no Oracle-effort-sized company would pick up the OpenJDK mantle. It's just asking for trouble.
Since when do new systems get integrated into Java, then officially deprecated for removal less than 5 years later? New technologies take time to be integrated into existing stacks, and new projects take time to come to market. I recognize that it's a lot of work to keep up with the ECMAScript language, but even if the ECMAScript language support lags behind official, that's better than removing a component that was hyped up in the Java 8 release.
My team uses the Nashorn engine as a sandboxed scripting engine in an upcoming game. Because of the nature of the transpiling of javascript into Java, we've got very granular control over what classes, fields, and methods can be accessed from the javascript context. I'm not sure at this point what we're going to do about this, so I'm looking at things like GraalJS. Anyone have any experience with a use case like ours?
My team uses the Nashorn engine as a sandboxed scripting engine in an upcoming game. Because of the nature of the transpiling of javascript into Java, we've got very granular control over what classes, fields, and methods can be accessed from the javascript context. I'm not sure at this point what we're going to do about this, so I'm looking at things like GraalJS. Anyone have any experience with a use case like ours?
I'm not that familiar with Nashorn but the Truffle framework on which GraalJS is built has considerations for sandboxing.
see: hostClassFilter() https://github.com/oracle/graal/blob/master/sdk/src/org.graa...
I suspect that your use-case might be easier to port than most (if it comes to that) since you probably aren't using as many platform APIs.
I agree that the volatility in java-land is new and unsettling and Nashorn is pretty young to be removed but the js ecosystem itself has been changing fast lately. I hope they keep Nashorn around even of they don't keep up with newer language versions.
see: hostClassFilter() https://github.com/oracle/graal/blob/master/sdk/src/org.graa...
I suspect that your use-case might be easier to port than most (if it comes to that) since you probably aren't using as many platform APIs.
I agree that the volatility in java-land is new and unsettling and Nashorn is pretty young to be removed but the js ecosystem itself has been changing fast lately. I hope they keep Nashorn around even of they don't keep up with newer language versions.
What a shame. With Spring you could switch from traditional Java based templates to server-side rendering React templates without changing your controllers.
Sigh... we just built a whole new service with Nashorn.
I was thinking of going that way as well. sigh
Are you using the javax.script API? I believe TruffleJS implements that, so it might not be too difficult to switch.
Mind sharing why you picked Nashorn?
We built a user scripting feature for our product (like Google App Script). Our backend is entirely written in Scala so hooking up JS to our Scala stuff was really, really simple with Nashorn.
The tricky bits are all the hacks to limit resource usage which took a bunch of engineering time to implement and test and aren’t reusable across engines.
It’s not the fastest or the latest or whatever but it works well and gets the job done.
The tricky bits are all the hacks to limit resource usage which took a bunch of engineering time to implement and test and aren’t reusable across engines.
It’s not the fastest or the latest or whatever but it works well and gets the job done.
>The tricky bits are all the hacks to limit resource usage which took a bunch of engineering time to implement and test and aren’t reusable across engines.
Interesting.
I built the same thing. Through some basic script examples, such as `while(true) {}` or `new Buffer(1000 * 1000);`, the conclusion that I came to was that it is impossible to truly interrupt/prevent resource exhaustion attacks. A bug anywhere that would allow reflection to be accessible would have been disastrous as well.
In the end, I built a JNI wrapper over Duktape+flatbuffers, which gave me super fine-grained control over memory allocation and CPU time.
I'd be very interested to hear a summary of how/whether you managed to make Nashorn safe for user scripts.
Interesting.
I built the same thing. Through some basic script examples, such as `while(true) {}` or `new Buffer(1000 * 1000);`, the conclusion that I came to was that it is impossible to truly interrupt/prevent resource exhaustion attacks. A bug anywhere that would allow reflection to be accessible would have been disastrous as well.
In the end, I built a JNI wrapper over Duktape+flatbuffers, which gave me super fine-grained control over memory allocation and CPU time.
I'd be very interested to hear a summary of how/whether you managed to make Nashorn safe for user scripts.
We run the user supplied code through an instrumentation pass (using Google Closure Compiler) where we modify it at the AST level to call a resource check/interrupt check after every instruction. It also modifies any loop constructs. The compiler will save a sourcemap so you can pretend you’re not modifying user code.
We disable all extensions. We do some instrumentation on string ops as well. We use the mbean API to get the memory and CPU usage of the current thread. We have a monitor thread that checks that for all worker threads. I’ve probably forgotten a bunch of things but it was a huge pain. I’m going to tell our guys about your solution and see if that’s something we can look into.
We disable all extensions. We do some instrumentation on string ops as well. We use the mbean API to get the memory and CPU usage of the current thread. We have a monitor thread that checks that for all worker threads. I’ve probably forgotten a bunch of things but it was a huge pain. I’m going to tell our guys about your solution and see if that’s something we can look into.
Wouldn't code instrumentation be trivially bypassable using an eval construct? esp. something like
[]["constructor"]["constructor"]("while (true) { }")()
If you wanted a user scripting feature and not Javascript in particular, then couldn't you embed the Scala REPL with appropriate resource usage limits? You can using Apache Groovy which is used by Gradle and Jenkins Pipelines. Of course Scala and Javascript are both rising in adoption, whereas Groovy is fast sinking so you probably wouldn't want to go that way.
I was mostly going that way because we will be moving to Java 8 and it came with. I saw the possibilities of using it to do utilities etc. My environment is very restrictive and I can't get things installed easily, so because it comes with, that was a bonus.
Is there any relevance to this to the fact that Oracle owns the trademark on JavaScript?
Usually trademarks are only maintained through use; if Oracle stops distributing a JavaScript implementation, could they lose the trademark?
Usually trademarks are only maintained through use; if Oracle stops distributing a JavaScript implementation, could they lose the trademark?
[deleted]
Oracle recently had Apple pull an app from the App Store because it had the word JavaScript in the name. So they are vigorously defending the trademark.
https://news.ycombinator.com/item?id=16862949
https://news.ycombinator.com/item?id=16862949
Has anyone used Nashorn? For what use-cases did it make sense to run JS inside of a JVM process?
JS in the JVM is used heavily in Mirth (https://www.nextgen.com/products-and-services/integration-en...) for scripting of channels and data transformations. It's kinda janky but runs a lot of healthcare systems. It's using Rhino, not Nashorn, FWIW.
User-defined scripting of a system written in Java. Everyone knows Javascript and it's easier to allow a user to submit text scripts and run them via the embedded engine than require users to run some kind of plugin build process.
We are. We use a library called rules.js to do some basic content validations that can run on either/both the client and server.
And now I look foolish for suggesting it (using Nashorn).
And now I look foolish for suggesting it (using Nashorn).
I know of one CMS that uses it extensively underneath to construct the pages.
Yeah Alfresco. Was a stupid idea, second only to their decision to roll their own crappy UI framework.
I use it for server-rendering React in a Spring app
Nashorn is the beating heart for
https://github.com/lorenzoongithub/nudge4j
Around 100 stars in github so probably not worth much consideration to whoever decided to 'deprecate it'
Again, nudge4j is effectively 8 lines of Java code (just enough to kick off the nashorn engine) and the rest is JavaScript on Java.
I hope that JEP 335 won't go ahead. I vote against.
Around 100 stars in github so probably not worth much consideration to whoever decided to 'deprecate it'
Again, nudge4j is effectively 8 lines of Java code (just enough to kick off the nashorn engine) and the rest is JavaScript on Java.
I hope that JEP 335 won't go ahead. I vote against.
Question for those in the know:
What are the Nashorn specific APIs and that would break in a move to graaljs? Presumably all of the pure js code would still be compatible with any js implementation but java/js interop and platform apis specific to nashorn would break. How big of an api surface is this really?
> but java/js interop ... specific to nashorn would break
I think GraalJS implements the same Java/JS interop API.
I think GraalJS implements the same Java/JS interop API.
That's good news then.
If they're is some effort to spec out the Nashorn API and regression test those parts against GraalJS they'd probably benefit from branding it as Nashorn 2.0 or at least Nashorn API Compatible to assuage all the fear.
If they're is some effort to spec out the Nashorn API and regression test those parts against GraalJS they'd probably benefit from branding it as Nashorn 2.0 or at least Nashorn API Compatible to assuage all the fear.
I'm not very familiar with Nashorn, but could they just create a thin Java compatibility layer and outsource the bulk of the work to V8? Are there license issues with shipping V8 alongside Java?
The author of this proposal, Jim Laskey, is also the one behind exactly what you're describing: Project Detroit.
see: http://openjdk.java.net/projects/detroit/
speculation: It looks like he wants Nashorn dead from any angle? GraalJS and V8, lol
see: http://openjdk.java.net/projects/detroit/
speculation: It looks like he wants Nashorn dead from any angle? GraalJS and V8, lol
I’m wondering why Project Detroit, and the background given in the Jim Laskey preso about it, isn’t mentioned in the JEP.
I’m sure it would help quell the outrage.
That project will basically be Nashorn compatible, with better performance and ES6 and Node support.
I wonder how it relates to Graal and TruffleJS though. Seems a bit left hand/right hand from Oracle to have competing projects like this.
For anyone interested in JS on the JVM Jim’s video is a must watch:
https://www.youtube.com/watch?v=-JLhwsbMvjQ
Yup, if Jim is behind this then I am more trusting of the technical reasons.
I can't wait for the first release of Detroit - very exciting!
I can't wait for the first release of Detroit - very exciting!
It's possible. It wouldn't run on the JVM, with JVM gc, JVM security, JVM in-process latency, etc.
The biggest problem is the latency, but yeah separate V8 works alright.
The biggest problem is the latency, but yeah separate V8 works alright.
I thought Nashorn was part of this agenda of keeping the JVM relevant even if Java becomes less so.
I would guess Graal has something to do with this housecleaning.
I would guess Graal has something to do with this housecleaning.
I don't know if this implements the javax.script API, but it does allow you to embed V8 in Java programs: https://github.com/eclipsesource/J2V8
There was a talk about that at last Java ONE, I think, but there are no more news about it.
Is anyone making serious use of nashorn?
TLDR:
With the rapid pace at which ECMAScript language
constructs, along with APIs, are adapted and modified,
we have found Nashorn challenging to maintain.Please don't quote with code blocks. It forces horizontal scrolling which is a huge pain especially on mobile.
> Just use quote arrows to signify instead
> Just use quote arrows to signify instead
I'm glad it's not completely Oracle's call. I see this as a power move. Nashorn is part of OpenJDK, which is becoming less and less Oracle-specific. Graal/Truffle however are squarely under Oracle's umbrella.
> With the rapid pace at which ECMAScript language constructs, along with APIs, are adapted and modified, we have found Nashorn challenging to maintain. [...] GraalJS using Oracle Labs' Truffle technology may soon be publicly available as a Java module. It is understood that GraalJS provides most of the same functionality as Nashorn along with better performance.
So, one is too challenging to maintain but the other isn't? Why don't you just come out and say it? You are shifting resources to your more proprietary impl that you have a premium version of. And if no other OpenJDK maintainers want to step up and maintain Nashorn, I say remove it. But everyone should be clear about Oracle's motives here. I expect we'll start seeing this more and more like we do with mission control...Oracle is going to dedicate fewer and fewer resources to OpenJDK, the Oracle version of which no longer carries reasonable benefits on its own. More ancillary products around the JVM will be focused on. Makes sense, but I sure wish an alternative Oracle-effort-sized OpenJDK maintainer existed.
And for those of you that have used Nashorn and need it to do work, remember what is happening here. And those of you starting the same thing with Graal/Truffle, watch what is happening here. Lots of us work w/ the core of the JDK, but beware of building new products on Oracle tech.