I appreciate this recommendation, but as the main developer on Scripturian, which is a scalable alternative to JSR-223 with a well-defined threading model, I really do have to bypass JSR-223 and call the internal classes. I know it means that breakage can happen with future versions, which is why Scripturian support states clearly which versions it works for. I'm hoping for better collaboration in standardizing these things, which is why I'm asking questions on this mailing list...
On Tue, Oct 8, 2013 at 8:47 PM, A. Sundararajan <[email protected]> wrote: > It is recommended that you please stick to jsr223 API on nashorn and use > jdk.nashorn.api.scripting.* classes (which provide missing stuff in jsr223). > Anything in jdk.internal and jdk.nashorn.internal is ... really internal > implementation detail. > > Thanks > -Sundar > > > On Tuesday 08 October 2013 02:41 PM, Tal Liron wrote: >> >> How? It doesn't seem to support the java.util interfaces, whereas >> ListAdapter does. >> >> Also, it seems that the only implementation of JSObject is >> ScriptObjectMirror, which is specific to the JSR-223. >> >> On 10/08/2013 08:38 PM, Jim Laskey (Oracle) wrote: >>> >>> You really shouldn't be using internal classes. We can and will be >>> changing them over time. Use JSObject instead. >>> >> >
