/docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngineFactory.html#getProgram-java.lang.String...-
The other diffs being simple white space removals, I/we'll take care as
part of another fix.
Thanks,
-Sundar
On Tuesday 14 July 2015 09:30 AM, A. Sundararajan wrote:
Forwarding this cont
Forwarding this contribution from Ahmed to core-libs-dev alias as the
change is going to be in "jdk/java.scripting/javax.script" code.
PS. I'll send out webrev after build, test.
Thanks Ahmed,
-Sundar
Forwarded Message
Subject:Re: [PATCH] javax,script.ScriptEngineFac
My understanding is that the new file won't have old copyright year
(2011 in this case).
-Sundar
On Thursday 18 June 2015 09:20 PM, Jan Lahoda wrote:
On 18.6.2015 16:40, A. Sundararajan wrote:
* jdk/make/lib/Lib-jdk.jline.gmk
has copyright year 2011, 2015 despite being a new file
* jdk/make/lib/Lib-jdk.jline.gmk
has copyright year 2011, 2015 despite being a new file. Any
specific reason?
* jdk.jline depends on java.desktop. Is that needed by the code by jline
code? I am asking because Nashorn requires only "compact 1" profile so
far and so can be used on compact
+1 on Nashorn changes.
-Sundar
On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote:
8 jun 2015 kl. 11:34 skrev Alan Bateman :
On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
This review request covers the main part of the work for JEP-223, the new version string format
[1]. Basically,
Please review http://cr.openjdk.java.net/~sundar/8068978/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8068978
Thanks,
-Sundar
Please review http://cr.openjdk.java.net/~sundar/8072002/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8072002
Thanks,
-Sundar
Thanks for the review. Updated test as per your suggestion. Uploaded
fresh review @ http://cr.openjdk.java.net/~sundar/8072853/webrev.01/
Thanks
-Sundar
Paul Sandoz wrote:
On May 18, 2015, at 12:44 PM, A. Sundararajan
wrote:
Please review http://cr.openjdk.java.net/~sundar/8072853
Please review http://cr.openjdk.java.net/~sundar/8072853/webrev.00/ for
https://bugs.openjdk.java.net/browse/JDK-8072853
Thanks,
-Sundar
Please review http://cr.openjdk.java.net/~sundar/8068587/ for
https://bugs.openjdk.java.net/browse/JDK-8068587
Thanks,
-Sundar
Thanks. Broke that sentence into two for clarity.
-Sundar
On Tuesday 06 January 2015 04:46 PM, Alan Bateman wrote:
On 06/01/2015 07:57, A. Sundararajan wrote:
Please review http://cr.openjdk.java.net/~sundar/8068462/ for
https://bugs.openjdk.java.net/browse/JDK-8068462
I think this is okay
Please review http://cr.openjdk.java.net/~sundar/8068462/ for
https://bugs.openjdk.java.net/browse/JDK-8068462
Thanks,
-Sundar
Please review a typo in javadoc comment..
http://cr.openjdk.java.net/~sundar/8068279/ for
https://bugs.openjdk.java.net/browse/JDK-8068279
Thanks,
-Sundar
+1
-Sundar
On Wednesday 22 October 2014 08:39 PM, Kumar Srinivasan wrote:
Hello,
Please review fix for JDK-8061830, this is merely a refresh of the
existing source
base from upstream ObjectWeb/ASM, the webrev is here:
http://cr.openjdk.java.net/~ksrini/8061830/webrev.00/
All the validatio
Hi,
Please review http://cr.openjdk.java.net/~sundar/8044647/
Thanks,
-Sundar
Looks good to me.
-Sundar
On Friday 30 May 2014 08:23 PM, Paul Sandoz wrote:
On May 28, 2014, at 1:20 AM, Kumar Srinivasan
wrote:
Hello,
Please review the following webrev which updates internal ASM to v5.0.3, the
individual bug fixes are
listed in the JBS issue for reference,
https://bu
+1
-Sundar
On Wednesday 12 February 2014 06:49 PM, Alan Bateman wrote:
I need a reviewer for a trivial change to remove a tiny number of
unused imports. The motive is experimental compilation of the JDK as
modules rather than one big compilation unit. I've no doubt that there
is other code
Looks good.
-Sundar
On Wednesday 12 February 2014 06:17 PM, Alan Bateman wrote:
On 11/02/2014 11:44, Paul Sandoz wrote:
:
Scrub it!
AFAICT it is not widely used (looking at the use of s.m.Service
static methods on grep code there are only a handful of dependent
artifacts). And the upgrade i
The test sets compile threshold to be zero
(-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=0 ). I think
compilation occurs on the first invoke.
Also, I ran the test on a jdk8 build without Vladimir's fix - I saw the
exception being thrown. I ran it by passing the above option in the
comman
Looks good to me
-Sundar
On Wednesday 15 January 2014 09:01 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8031502
InvokeBytecodeGenerator can produce incorrect bytecode for a
LambdaForm when invoking a method from O
- not just ClassLoader instances).
-Sundar
On Tuesday 03 September 2013 11:03 PM, Jochen Theodorou wrote:
Am 03.09.2013 16:12, schrieb A. Sundararajan:
[...]
If Groovy or any third-party framework gets away with that -- that is
because you need to use modified security policy that gives those
I don't think it is possible to get every Class object in the system.
Either you should have a reference to an object (in which case you can
call Object.getClass method) or the classloader that loaded your class
should be able to resolve the referred class.
For example,
Class.forName("sun
Bug: 8021773: print function as defined by jrunscript's init.js script
is incompatible with nashorn's definition
Please review http://cr.openjdk.java.net/~sundar/8021773/
Thanks
-Sundar
Bug: http://bugs.sun.com/view_bug.do?bug_id=7187144
Please review http://cr.openjdk.java.net/~sundar/7187144/
Thanks
-Sundar
make sure build
finishes fine.
Please review.
Thanks
-Sundar
On Monday 13 May 2013 05:56 PM, Alan Bateman wrote:
On 13/05/2013 13:14, A. Sundararajan wrote:
Incorporated changes as suggested. Uploaded webrev for historical
purpose:
http://cr.openjdk.java.net/~sundar/8012975/webrev.02/
PS.
Incorporated changes as suggested. Uploaded webrev for historical purpose:
http://cr.openjdk.java.net/~sundar/8012975/webrev.02/
PS. I am going ahead with push..
Thanks
-Sundar
On Friday 10 May 2013 06:17 PM, A. Sundararajan wrote:
Okay, thanks. com.sun.script.util is not supported API (no
Okay, thanks. com.sun.script.util is not supported API (no CCC done for
it in the past). I'll remove it as suggested and run "make profiles" to
check
Thanks
-Sundar
On Friday 10 May 2013 04:09 PM, Alan Bateman wrote:
On 10/05/2013 11:23, A. Sundararajan wrote:
com/sun/script/
this?
Thanks
-Sundar
On Friday 10 May 2013 03:03 PM, Alan Bateman wrote:
On 10/05/2013 10:26, A. Sundararajan wrote:
Please review the updated webrev @
http://cr.openjdk.java.net/~sundar/8012975/webrev.01/
Thanks
-Sundar
PROFILE_3_RTJAR_INCLUDE_PACKAGES needs to have com/sun/script re
Please review the updated webrev @
http://cr.openjdk.java.net/~sundar/8012975/webrev.01/
Thanks
-Sundar
On Friday 03 May 2013 02:56 PM, Alan Bateman wrote:
On 03/05/2013 07:47, A. Sundararajan wrote:
Thanks. Looks like the first one has not been removed. But second one
was removed: hg stat
On Friday 03 May 2013 11:53 AM, Tim Bell wrote:
On 05/ 2/13 01:24 PM, I wrote:
Hi Sundar:
Oracle JDK includes Rhino based javax.script implementation (which
lives mostly in "closed" code). Rhino is being removed from Oracle
JDK builds and there are the changes to the jdk open repository as
w
Hi,
Oracle JDK includes Rhino based javax.script implementation (which lives
mostly in "closed" code). Rhino is being removed from Oracle JDK builds
and there are the changes to the jdk open repository as well like
com.sun.script.javascript package, makefiles etc. Please review the open
jdk c
Hi Kumar,
So long as those nashorn tests (jtreg tests under
$jdk/test/javax/script, $jdk/sun/tools/jrunscript, $nashorn/test and
nashorn ant tests - $nashorn/make - ant test) run fine, we've no
objections from nashorn team.
Thanks
-Sundar
On Tuesday 30 April 2013 03:55 AM, Kumar Srinivasan
Please review http://cr.openjdk.java.net/~sundar/8010083/
Thanks
-Sundar
Hi,
Please review http://cr.openjdk.java.net/~sundar/8009140/
Thanks
-Sundar
Yes, that is the plan (i.e., removal of rhino in Oracle builds). I am
looking at jrunscript tests too.
Thanks
-Sundar
On Wednesday 27 February 2013 05:52 PM, Alan Bateman wrote:
On 27/02/2013 11:20, A. Sundararajan wrote:
Thanks Alan. Yes, nashorn is a "js" engine as well and so u
n the underlying jdk.
-Sundar
On Wednesday 27 February 2013 04:47 PM, Alan Bateman wrote:
On 27/02/2013 10:44, A. Sundararajan wrote:
Hi,
Please review http://cr.openjdk.java.net/~sundar/8009115/
Changing javax.script tests to use nashorn engine explicitly.
Adjusted tests for differences b/w
Hi,
Please review http://cr.openjdk.java.net/~sundar/8009115/
Changing javax.script tests to use nashorn engine explicitly. Adjusted
tests for differences b/w nashorn and rhino engines.
Changes documented here: http://cr.openjdk.java.net/~sundar/8009115/README
Thanks
-Sundar
Please review http://cr.openjdk.java.net/~sundar/8009115/
Changing javax.script tests to use nashorn engine explicitly - also
adjusting tests to reflect (minor) changes b/w nashorn and rhino.
Thanks
-Sundar
Looks good to me.
PS. Remi notes that only constructor and "add" method of WeakInternSet
are accessed from the containing class. The rest can be made private.
-Sundar
John Rose wrote:
Thanks, Jim.
-- John (on my iPhone T-1000)
On Mar 28, 2012, at 6:01 PM, Jim Laskey wrote:
The Weak
39 matches
Mail list logo
