That's reasonable. (I guess you're referring to the final death of the
permgen when you're talking about memory issues?)
So, what are your thoughts on the JVM7 port? Do you think it's entirely
non-viable? Pointless? Would result in a very poorly performing engine?
The future: My burning wish item for Nashorn is to allow for the
generated bytecode to be portable, so that it could be cached (to disk,
etc.). Without this, for my use cases, Nashorn is actually a noticeable
step back from Rhino in terms of startup performance (compilation is
slower). Not sure how I could pitch in, exactly, because that part of
the code seems to be the stickiest and hardest to penetrate... But
perhaps if it becomes a milestone feature I can assist in testing and
patching.
On 12/03/2013 09:03 PM, Jim Laskey (Oracle) wrote:
There might be some aspects of that, but it is 99% technical. There are some
major changes required to the JVM to support Nashorn properly in JDK 7 (perform
well, no memory bloat, security et al.) And then the question is, why don't we
backport those changes to the JVM? Well, then it becomes a slippery slope of
interconnected changes, JDK7 becomes JDK8, why are some people still using 1.4,
shouldn't we have a continuous update model, ...
The reality is, that groups who can't migrate from Rhino to Nashorn right away,
should take the time to do it right. Their users are likely not early
adopters. This gives Rhino projects time to mature their migration properly
and gives the Nashorn team time to respond to feature requests need to migrate.
The team is always listening and willing to help out.
Speaking of which... Nashorn is locking down for JDK8 and planning for the next
releases. This is where y'all come in. Nashorn is Open Source. Let us know
what are your priorities. This also means those willing and able to pitch in,
should do so. If you have any ideas you want to work on and push forward, let
us know. If you want a project to work on, I have a long list, let me know.
Respond to this list or me directly.
