So that I don't sound bitter, let me try to suggest a constructive
solution to the "meta" bug:
Could Nashorn have its own, separate, "download" page of post-JDK releases?
This would require different versioning, too. Right now, the Nashorn
version is tied to the JDK -- if I build it from hg, it is always marked
as version "0.1". Why not have Nashorn have its own internal version
march, parallel but ultimately separate from the JDK?
That way, instead of telling my users that my product requires 8u40, I
can specify a Nashorn version. Per JDK release, it can specify which
Nashorn version is included out of the box. My product could even check
for that version and provide an error message with instruction on how to
solve it.
I think it was fine to experiment with tying Nashorn to the JDK. But
it's also clear, to me at least, that the experiment has failed. It's
more than a year since Nashorn was released, with so much promise, but I
still can't recommend it to my users.
On 03/09/2015 10:34 AM, Krause, Michael wrote:
Absolutely - please consider that Java and the embedded JavaScript Engine is
used in production-systems.
Is Nashorn really ready for production use? Seriously, since I am on the
nashorn-dev list
I have read about three bugs that are not mentioned in the official
release-notes of Java.
We have no (real) option to use Rhino in Java 8 any more, and Java 7 is near
end-of-life. Should I port my scripts to Groovy in order to be safe?
