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 d

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