3 ms·

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

by aseipp 8y ago

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

kodablah 8y ago
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.
- kjeetgill 8y ago
  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.
- aseipp 8y ago
  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...

by aseipp 8y ago

kodablah 8y ago

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.

kjeetgill 8y ago
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.
aseipp 8y ago
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...