+1 on your webrev.02;
You could still enhance few things, such as:
- you could just write the code for getInvokeByName and getDynamicInvoker once
if you wrote a generic version as private static T getLazilyCreatedValue(final
Object key, final Callable creator, final ConcurrentMap) (that's
bas
Updated based on comments from Attila.
Update webrev @ http://cr.openjdk.java.net/~sundar/8022524/webrev.02/
-Sundar
On Thursday 08 August 2013 10:54 AM, A. Sundararajan wrote:
Thanks. I got it. Basically InvokeByName/MethodHandle may be created
by Callable atmost twice -- and the second one w
Thanks. I got it. Basically InvokeByName/MethodHandle may be created by
Callable atmost twice -- and the second one will be thrown away.
I'll make these changes.
-Sundar
On Thursday 08 August 2013 10:41 AM, Attila Szegedi wrote:
On Aug 8, 2013, at 5:45 AM, A. Sundararajan
wrote:
I'd like
On Aug 8, 2013, at 5:45 AM, A. Sundararajan
wrote:
> I'd like to lazily initialize InvokeByName and dynamic method handles in
> global instance. I am not sure of the refactoring in NativeArray that you
> suggested.
>
> Are you talking about these?
>
>private final MethodHandle s
Please review update webrev @
http://cr.openjdk.java.net/~sundar/8022524/webrev.01/
Additional changes from webrev.00:
* retain "source" private field in generated script classes (Jim noted
that debugger needs to be able to get Source field from script Class
objects).
* Removed OutOfMemoryE
I'd like to lazily initialize InvokeByName and dynamic method handles in
global instance. I am not sure of the refactoring in NativeArray that
you suggested.
Are you talking about these?
private final MethodHandle someInvoker =
getSOME_CALLBACK_INVOKER();
If I pass key to a refa
On Thursday 08 August 2013 02:29 AM, Attila Szegedi wrote:
- CompileUnit: While making fields non-final and nulling out fields is
certainly a solution, I don't like it as it feels fragile - you end up with an
object that has a member nulled out, and what if something later would want to
depend
- CompileUnit: While making fields non-final and nulling out fields is
certainly a solution, I don't like it as it feels fragile - you end up with an
object that has a member nulled out, and what if something later would want to
depend on it etc. As an example, consider CompileUnit, which now ha
Filed as JDK-8022555 [macosx] AppleScriptEngine.jar MUST call
java.awt.Toolkit.getDefaultToolkit() lazily
On 2013-08-07, at 2:21 PM, "Jim Laskey (Oracle)"
wrote:
> I'm filing a bug against AppleScriptEngine.jar. Other than removing it,
> there is no long term fix. BTW, if you do need AppleS
I'm filing a bug against AppleScriptEngine.jar. Other than removing it, there
is no long term fix. BTW, if you do need AppleScript you can do it from
Nashorn; https://blogs.oracle.com/nashorn/entry/playing_itunes_from_nashorn .
Cheers,
-- Jim
On 2013-08-07, at 12:26 PM, Kasper Nielsen wr
Please review http://cr.openjdk.java.net/~sundar/8022524/
Thanks
-Sundar
My code is pretty simple:
import javax.script.ScriptEngineManager;
public class EngineTest {
public static void main(String[] args) throws Exception {
new ScriptEngineManager();
Thread.sleep(10);
}
}
> Javac EngineTest.java
> Java EngineTest
-> A window pops up.
Apple
Changeset: 9a3e3bb30db3
Author:attila
Date: 2013-08-07 16:38 +0200
URL: http://hg.openjdk.java.net/nashorn/jdk8/nashorn/rev/9a3e3bb30db3
8022509: Various Dynalink security enhancements
Reviewed-by: jlaskey, hannesw
! src/jdk/internal/dynalink/ChainedCallSite.java
! src/jdk/internal
All Macs have that (I use a Mac). I don't run into that problem though. So
you are walking through the engines list?
On 2013-08-07, at 11:19 AM, Kasper Nielsen wrote:
> On Wed, Aug 7, 2013 at 2:13 PM, Jim Laskey (Oracle)
> wrote:
> Kasper,
>
>
> - Check to see if you have other script e
On Wed, Aug 7, 2013 at 2:13 PM, Jim Laskey (Oracle) wrote:
> Kasper,
>
>
> - Check to see if you have other script engines installed that might
> trigger a GUI.
>
> Yup, it was this one.
I'm on OSX and
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/690161232823/src/macosx/classes/apple/applescrip
+1
On Aug 7, 2013, at 5:22 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8022483/
>
> * JSAdapter change: __call__ for method calls in Nashorn
> * No __proto__ assignment support in Nashorn - changed to copy functions from
> proto
> * Wrapperless Java object ac
Kasper,
It should work as is. I regularly use Nashorn for shell scripting headlessly.
- Check to make sure you are using the latest JDK 8. There was a bug in
ScriptManager that was fixed many releases ago.
http://jdk8.java.net/download.html
- Check to see if some other command line option is
17 matches
Mail list logo
