Review request for 8020731: Revisit checkPermission calls in Context class

2013-07-17 Thread A. Sundararajan
Please review http://cr.openjdk.java.net/~sundar/8020731/ -Sundar

Re: setNashornGlobal usage

2013-07-17 Thread Tobias Schlottke
Hi Jim, this example shows it pretty well: https://gist.github.com/tobsch/6026942 as the script itself is very simple and does nothing special. It's only its invocation or doPrivileged to be precise. This is the profiler output: Any ideas? Best, Tobias Am 17.07.2013 um 18:23 schrieb Jim

Re: FXML Scripting and Nashorn Error Messages

2013-07-17 Thread A. Sundararajan
Hi, Addressing one of the questions: * importClass : by default, Nashorn does not support importClass. But, it is possible to load "mozilla_compat.js" to support rhino extensions like importClass. load("nashorn:mozilla_compat.js"); importClass(java.util.Vector); Also, it is possibl

Re: FXML Scripting and Nashorn Error Messages

2013-07-17 Thread Jim Laskey (Oracle)
Going to forward to the fx experts. On 2013-07-17, at 1:55 PM, TA Hubbard wrote: > Dear Sirs; > > A fundamental feature of JavaFX's FXML is scripting. The process is simple; > add the 'processing instruction' to standard FXML > processing instructions (JavaFX import declarations or stateme

FXML Scripting and Nashorn Error Messages

2013-07-17 Thread TA Hubbard
Dear Sirs; A fundamental feature of JavaFX's FXML is scripting. The process is simple; add the 'processing instruction' to standard FXML processing instructions (JavaFX import declarations or statements) then script. As you know, some of the scripting languages include JavaScript, JavaFX,

Re: setNashornGlobal usage

2013-07-17 Thread Jim Laskey (Oracle)
Tobias, Would you send some more detailed code snippets (or gist link)? Cheers, -- Jim On 2013-07-17, at 1:35 PM, Tobias Schlottke wrote: > Hi Jim, > > sounds pretty reasonable to me. > I still have the problem that I want to return something in run() though, so > this renders a bit more co

Re: setNashornGlobal usage

2013-07-17 Thread Tobias Schlottke
Hi Jim, sounds pretty reasonable to me. I still have the problem that I want to return something in run() though, so this renders a bit more complicated. I understand that you have to check security once but I don't really understand why in my case because the object should not have changed. Do

Re: setNashornGlobal usage

2013-07-17 Thread Jim Laskey (Oracle)
Tobias, We'll look into removing the doPrivileged on first entry (security is checked elsewhere), but we need to do a security assessment before proceeding. That said, I would recommend as a best practice to use a per-thread JavaScript loop instead, to avoid such issues. I generally use a jav

hg: nashorn/jdk8/nashorn: 8020356: ClassCastException Undefined->Scope on spiltter class generated for a large switch statement

2013-07-17 Thread hannes . wallnoefer
Changeset: 3d6f6b8d8bc8 Author:hannesw Date: 2013-07-17 18:20 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/3d6f6b8d8bc8 8020356: ClassCastException Undefined->Scope on spiltter class generated for a large switch statement Reviewed-by: jlaskey, attila ! src/jdk/na

Re: Review request for JDK-8020356

2013-07-17 Thread Jim Laskey (Oracle)
+1 On 2013-07-17, at 12:22 PM, Hannes Wallnoefer wrote: > Please review JDK-8020356 - ClassCastException Undefined->Scope on spiltter > class generated for a large switch statement: > > http://cr.openjdk.java.net/~hannesw/8020356/ > > Thanks, > Hannes

setNashornGlobal usage

2013-07-17 Thread Tobias Schlottke
Hi there, I've built a small case where I evaluate a compiled script equipped with a custom bindings. The script is equipped with some variables and and compiled like this: engine.put("shopId", "test"); runner = (Bindings) engine.compile(ad.getCondition_script().getCode()).eval();

Review request for JDK-8020356

2013-07-17 Thread Hannes Wallnoefer
Please review JDK-8020356 - ClassCastException Undefined->Scope on spiltter class generated for a large switch statement: http://cr.openjdk.java.net/~hannesw/8020356/ Thanks, Hannes

hg: nashorn/jdk8/nashorn: 8020596: Initialization of white space strings in scanner should be done with \u strings

2013-07-17 Thread james . laskey
Changeset: 71cfe4e66bcb Author:jlaskey Date: 2013-07-17 11:53 -0300 URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/71cfe4e66bcb 8020596: Initialization of white space strings in scanner should be done with \u strings Reviewed-by: attila, hannesw Contributed-by: james.las.

Re: Review request: JDK-8020596: Initialization of white space strings in scanner should be done with \u strings

2013-07-17 Thread Attila Szegedi
+1 On Jul 17, 2013, at 4:25 PM, Jim Laskey (Oracle) wrote: > http://cr.openjdk.java.net/~jlaskey/8020596/webrev.00/index.html >

Re: Review request: JDK-8020596: Initialization of white space strings in scanner should be done with \u strings

2013-07-17 Thread Hannes Wallnoefer
Looks good to me. Hannes Am 2013-07-17 16:25, schrieb Jim Laskey (Oracle): http://cr.openjdk.java.net/~jlaskey/8020596/webrev.00/index.html

Review request: JDK-8020596: Initialization of white space strings in scanner should be done with \u strings

2013-07-17 Thread Jim Laskey (Oracle)
http://cr.openjdk.java.net/~jlaskey/8020596/webrev.00/index.html