Hi,
No, there is no direct way to convert a Java Map to a real JSON object.
You've to do conversion as you hinted.
-Sundar
On 9/9/2015 2:43 PM, Sebastien Deleuze wrote:
I am updating my Spring + Nashorn talk and the related sample
applications, and I am wondering if in the Nashorn version provided
with java 8u60 there is a better/easier way to convert a Java
Map<String, Object> instance into a real JSON Object (with Iterable
elements being converted to real JSON arrays)?
Currently I am doing that:
// Create a real JSON Object from the model Map
var data = {};
for (var k in model) {
// Convert Java Iterable and List to real JSON arrays
if (model[k] instanceof Java.type("java.lang.Iterable")) {
data[k] = Java.from(model[k]);
} else {
data[k] = model[k];
}
}
Any thoughts?
On Mon, Jul 20, 2015 at 5:09 AM, A. Sundararajan
<sundararajan.athijegannat...@oracle.com
<mailto:sundararajan.athijegannat...@oracle.com>> wrote:
By "reset", if you mean "throw all the stuff in global to get a
blank global", then you can do this:
ScriptContext sc = engine.getContext();
sc.setBindings(engine.createBindings(),
ScriptContext.ENGINE_SCOPE);
This will create fresh (ECMAScript) global and makes it as
ENGINE_SCOPE of the default context.
-Sundar
On Sunday 19 July 2015 02:37 AM, Matt Kime wrote:
thanks, this is very helpful.
one issue remains for me - is there a good way to reset the
script engines
in a development environment without restarting the whole app?
--matt
On Wed, Jul 15, 2015 at 1:02 PM, Sebastien Deleuze
<sdele...@pivotal.io <mailto:sdele...@pivotal.io>>
wrote:
Hi,
We ended up to use thread-local script engines [1] in
Spring 4.2 for
Javascript libraries not designed for concurrency like
React or Handlebars.
Based on my initial tests, it works pretty well. The main
remaining open
question is about the memory consumption, since it creates
one ScriptEngine
instance by thread.
If we see some blocking issues regarding this topic, we
may eventually
experiment with a synchronized ScriptEngine pool, but I
hope the
thread-local approach will be fine.
Regards,
Sébastien Deleuze
[1] https://jira.spring.io/browse/SPR-13034
On Fri, Jun 5, 2015 at 5:08 PM, Matt Kime
<ma...@meetup.com <mailto:ma...@meetup.com>> wrote:
I'm curious if any progress has been made on isolating
whatever isn't
thread safe about handlebars template execution.
I'm also working on using Handlebars.js inside nashorn
however i'm doing a
number of things different. i'm precompiling my
templates using
https://github.com/gruntjs/grunt-contrib-handlebars
and then compile the
js
functions into cached bytecode.
I haven't checked for threading issues yet but I'm
glad i found this
discussion so i know that i should.
