deem this feature important for Nashorn's adoption: if I could submit
a patch soon, would it be possible to make it in time for release?
On 10/09/2013 04:15 PM, Jim Laskey (Oracle) wrote:
> After consideration and from my own experiences, I'm going to add as a
> feature request
+1
> On Jan 17, 2018, at 11:36 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195123
> Webrev: http://cr.openjdk.java.net/~hannesw/8195123/webrev.00/
>
> This undoes the recent fix for JDK-8193567 (Attila, in case you’re reading, I
> sho
+1
> On Jan 22, 2018, at 10:44 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review.
>
> Webrev: http://cr.openjdk.java.net/~sundar/8195829/webrev.00/index.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195829
>
> Thanks,
> -Sundar
+1
> On Jan 23, 2018, at 2:34 AM, Priya Lakshmi Muthuswamy
> wrote:
>
> Hi,
>
> Kindly review JDK-8147614: add jjs test for -t option
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8147614
> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8147614/webrev.00/
>
> Thanks,
> Priya
+1
> On Feb 14, 2018, at 1:24 AM, Srinivas Dama wrote:
>
> Jim,
>
> May I have second review for this thread in core-libs-dev group.
>
> Regards,
> Srinivas
>
> - Forwarded Message -
> From: sundararajan.athijegannat...@oracle.com
> To: srinivas.d...@oracle.com
> Cc: core-libs-...@ope
+1
> On Mar 7, 2018, at 1:08 PM, Hannes Wallnöfer
> wrote:
>
> Please review 8199236: Nashorn uses deprecated HTML tags in Javadoc:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199236
> Webrev: http://cr.openjdk.java.net/~hannesw/8199236/webrev/
>
> Thanks,
> Hannes
+1
> On Mar 15, 2018, at 10:30 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199443
> Webrev: http://cr.openjdk.java.net/~hannesw/8199443/webrev/
>
> If we make sure the property maps for strict functions and arguments are set
> up corre
+1
> On Mar 26, 2018, at 9:00 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review http://cr.openjdk.java.net/~sundar/8200215/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200215
>
> Thanks,
> -Sundar
+1
> On Apr 23, 2018, at 10:49 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201466
> Webrev: http://cr.openjdk.java.net/~hannesw/8201466/webrev/
>
> Thanks,
> Hannes
+1
> On Apr 23, 2018, at 12:34 PM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198816
> Webrev: http://cr.openjdk.java.net/~hannesw/8198816/webrev/
>
> Thanks,
> Hannes
+1
> On May 7, 2018, at 1:40 PM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200716
> Webrev: http://cr.openjdk.java.net/~hannesw/8200716/webrev/
>
> Thanks,
> Hannes
+1
> On Jun 4, 2018, at 1:42 PM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204288
> Webrev: http://cr.openjdk.java.net/~hannesw/8204288/webrev/
>
> Thanks,
> Hannes
>
+1
> On Jun 5, 2018, at 9:44 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8204290
> Webrev: http://cr.openjdk.java.net/~hannesw/8204290/webrev/
>
> This (like the previous RFR) is another backport from jruby/joni.
>
> Thanks,
> Hannes
+1
> On Jun 27, 2018, at 1:16 AM, Sundararajan Athijegannathan
> wrote:
>
> Please review.
>
> Bug https://bugs.openjdk.java.net/browse/JDK-8204492
> Webrev http://cr.openjdk.java.net/~sundar/8204492/webrev.01
>
> Related:
>
> JEP http://openjdk.java.net/jeps/335
> CSR https://bugs.openjdk.
The Nashorn team has no plans but you might check the GraalVM
https://www.graalvm.org project to see what they might have in this area.
Cheers,
— Jim
> On Aug 9, 2018, at 7:01 AM, Erko Knoll wrote:
>
> Hi,
>
> Great job with Nashorn, I really love it. However, based on the blog post
> of
>
+1
too bad you have to hardcode the version
> On Nov 30, 2018, at 6:58 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214525
> Webrev: http://cr.openjdk.java.net/~hannesw/8214525/webrev.00/
>
> This enables gzip encoding for the YUI downl
+1
> On Nov 29, 2018, at 1:01 PM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210943
> Webrev: http://cr.openjdk.java.net/~hannesw/8210943/webrev.00/
>
> AccessibleMembersLookup#lookupAccessibleMembers adds all nested classes
> returned by
Wouldn’t you still use innerClasses.putIfAbsent in case there is a race?
> On Dec 5, 2018, at 10:33 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214795
> Webrev: http://cr.openjdk.java.net/~hannesw/8214795/webrev.00/
>
> This is to make s
Nashorn is part of the JDK, so should be present. Note however, Nashorn is
deprecated until a replacement finds its way in.
Cheers,
-- Jim
> On May 23, 2019, at 9:48 AM, Houtman, Roland
> wrote:
>
> Dear Devs,
>
> Today I learned by surprise that the AdoptOpenJDK 8 contains the Nashorn
> J
+1
> On Jul 9, 2019, at 11:48 AM, Hannes Wallnöfer
> wrote:
>
> Please review:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8223451
> Webrev: http://cr.openjdk.java.net/~hannesw/8223451/webrev.00/
>
> A lot of Nashorn usage we see is with command line scripts from the Node.js
> and Web
+1
> On Sep 9, 2019, at 11:41 AM, Hannes Wallnöfer
> wrote:
>
> Please review this fix for a test failing because of a changed exception
> message in java.lang.Object.wait():
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8230766
> Webrev: http://cr.openjdk.java.net/~hannesw/8230766/webre
+1
> On Sep 26, 2019, at 7:45 PM, Joe Darcy wrote:
>
> Hello,
>
> Another part of an on-going cleanup of library serialization usage ahead of
> augmented javac -Xlint warnings (JDK-8160675), the non-serializable instance
> fields of serializable types in the jdk.scripting.nashorn module shoul
You want to take this on? File a bug and put the e-mail (change set) in it,
then tell the user Nashorn is deprecated.
> On Oct 28, 2019, at 12:21 PM, Anton Mitrofanov wrote:
>
> Hi.
>
> We have encountered another bug in Nashorn. It can be reproduced by
> evaluation of this script with "jjs
Obviously, this wasn't intended for the list. To clarify, since Nashorn is
being deprecated, we are taking input such as this and recording it as a bug in
case someone adopts Nashorn in future.
Cheers,
-- Jim
> On Oct 28, 2019, at 12:36 PM, Jim Laskey wrote:
>
> You want t
+1
> On Apr 15, 2020, at 12:56 PM, sundararajan.athijegannat...@oracle.com wrote:
>
> Please review.
>
> Nashorn script engine modules (jdk.scripting.nashorn,
> jdk.scripting.nashorn.shell) and jjs tool are removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8241749
>
> JEP: https://op
Nashorn is not going to be removed until JDK 15. So you are free to us it in
JDK 11, 12, 13 and 14.
Cheers,
-- Jim
> On Apr 20, 2020, at 3:19 PM, Abhay Kulkarni wrote:
>
> Hi,
>
> I don't know if this question was asked earlier. Is there any other
> javascript engine which can be used in
Not sure if it will help but you could try the "--optimistic-types=false"
option.
> On Jun 9, 2020, at 6:22 AM, STAMPF Lukas wrote:
>
> Hello,
>
> I wanted to ask if there is any workaround for the memory leak described in
> https://bugs.openjdk.java.net/browse/JDK-8229011
>
> Unfortunatly d
+1
> On Jul 15, 2020, at 12:58 PM, sundararajan.athijegannat...@oracle.com wrote:
>
> Hi,
>
> Please review - removing these tests.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246113
>
> Webrev: http://cr.openjdk.java.net/~sundar/8246113/webrev.00/
>
> Thanks
>
> -Sundar
>
I hereby resign as Nashorn Project Lead.
Nashorn [1] started in 2010 as a small JavaScript prototype to fill in for the
discontinued JavaFX compiler project [2] and as a testing ground for Java's
"new" invoke dynamic instructions [3]. Though Nashorn became somewhat a niche
tool, it found itself
In Nashorn, we introduced __noSuchProperty__ as a means of overriding property
search when a property is not declared. Example;
jjs> var other = { a: 10, b: 20, c: 30 };
jjs> var obj = { delegate: other, __noSuchProperty__: function(name) { return
this.delegate[name]; } }
jjs> obj.b;
20
In the
Recent merge changes with JDK8/TL have caused some issues. Will let you know
when things are corrected.
-- Jim
http://cr.openjdk.java.net/~jlaskey/8013208/webrev.01/index.html
convertKey was called every time an indexed getter was invoked, instead of
conditionally. Reworked the code to be conditionally calledl, also optimizing
for Integer (boxed) values (very frequent) and cases when key is not an index
Please review http://cr.openjdk.java.net/~jlaskey/8006220/webrev.00/index.html
. This is the preliminary work for lighter weight PropertyMaps. The most
significant changes here are the introduction of slot to basic properties,
elimination of embedded fields and the elimination of SpillProperti
Or as Marcus mentioned --print-no-newline.
On 2013-09-09, at 12:41 PM, Jim Laskey (Oracle) wrote:
> Hmmm. We originally had print and println, but then we realized it
> conflicted with rhino and v8
>
>>> rhino
> Rhino 1.7 release 5 PRERELEASE 2013 07 05
> js> pr
Hmmm. We originally had print and println, but then we realized it conflicted
with rhino and v8
>> rhino
Rhino 1.7 release 5 PRERELEASE 2013 07 05
js> print("hello "); print("world");
hello
world
js> quit();
>> v8
V8 version 3.18.5.2 [console: dumb]
d8> print("hello "); print("world");
hello
http://cr.openjdk.java.net/~jlaskey/8024397/webrev.00
+1
On 2013-09-11, at 11:22 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8024615/
>
> Thanks
> -Sundar
+1
On 2013-09-12, at 11:14 AM, Hannes Wallnoefer
wrote:
> Please review http://cr.openjdk.java.net/~hannesw/8024476/
>
> Thanks,
> Hannes
We're hoping to have the new bug tracking system online soon, but in the
meantime to can send an e-mail here. Describe the problem, a "small" test case
that reproduces the problem (we generally don't isolate bugs) and how to
reproduce the problem.
Cheers,
-- Jim
On 2013-09-12, at 3:07 PM,
+1
On 2013-09-13, at 6:16 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8024619/
>
> -Sundar
Viktor,
We will not likely support stringify of Java Objects. It's hard to justify
doing stringify without parse and then getting into the whole serialization
security nightmare that plagued Rhino. If you RFE this feature it would be
very restricted.
I'm not sure if you can accomplish the sa
+1
On 2013-09-18, at 7:51 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8024973/
>
> -Sundar
+1
On 2013-09-19, at 10:22 AM, Hannes Wallnoefer
wrote:
> Please review http://cr.openjdk.java.net/~hannesw/8023154/webrev.01/
>
> This is a new version of the patch that does not change the default value of
> run.test.xmx in order to keep benchmark results comparable.
>
> Hannes
+1
On 2013-09-19, at 12:13 PM, A. Sundararajan
wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025080
>
> Please review http://cr.openjdk.java.net/~sundar/8025080/
>
> Thanks,
> -Sundar
Some people are better at applying Murphy's Law than others. It's a valuable
skill.
On 2013-09-20, at 11:06 AM, André Bargull wrote:
> Yeah, I start to feel nervous reporting all these issues en masse. Especially
> since you like handguns according to your twitter profile! Maybe I should
> c
+1
On 2013-09-20, at 11:48 AM, A. Sundararajan
wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8025147
>
> Please review http://cr.openjdk.java.net/~sundar/8025147/
>
> -Sundar
+1
On 2013-09-20, at 2:32 PM, Hannes Wallnoefer
wrote:
> Please review patch for https://bugs.openjdk.java.net/browse/JDK-8025163:
>
> http://cr.openjdk.java.net/~hannesw/8025163/
>
> Thanks,
> Hannes
+1
On 2013-10-08, at 11:30 AM, Hannes Wallnoefer
wrote:
> Please review JDK-8025213: Assignment marks variable as defined too early
>
> http://cr.openjdk.java.net/~hannesw/8025213/
>
> Thanks,
> Hannes
+1
On 2013-10-08, at 12:20 PM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8026033
>
> Thanks
> -Sundar
+1
On 2013-10-08, at 1:01 PM, Hannes Wallnoefer
wrote:
> Please review JDK-8025965: Specialized functions with same weight replace
> each other in TreeSet
>
> http://cr.openjdk.java.net/~hannesw/8025965/
>
> Thanks,
> Hannes
Var StringArray = Java.type("java,lang.String[]");
var arr = Java.to(["a", "b", "c"], StringArray);
Or just
var arr = Java.to(["a", "b", "c"], "java,lang.String[]");
Nashorn documentation can be found at:
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation
Cheers,
-- Jim
O
Please be more specific with an example. I assume you want to extend a Java
class or some such requirement,
On 2013-10-08, at 1:21 PM, Tal Liron wrote:
> Oh, I meant a Java API. (I'm calling Nashorn programatically and getting
> native objects back.)
>
> On 10/08/2013 07:
Nashorn does not coerce JS arrays implicitly. There were too many ambiguous
cases to do a complete implementation (nested conversions.) In Nashorn you
have to;
myInstance.myMethod(Java.to(['a', 'b', 'c'], "java.lang.String[]"));
or;
var StringArray = Java.type("java.lang.String[]");
function
s myself:
>
> 1. It's possible to call NativeJava.to (equivalent to Java.to in JavaScript)
> 2. More efficient is to test specifically for NativeArray results and wrap
> them in a ListAdapter, which makes them conform to the List interface. This
> is what NativeJava.to does interna
+1
On 2013-10-08, at 2:34 PM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8026039/
>
> -Sundar
0.02, before taxes.
>
> -Original Message-
> From: nashorn-dev-boun...@openjdk.java.net
> [mailto:nashorn-dev-boun...@openjdk.java.net] On Behalf Of Jim Laskey (Oracle)
> Sent: Tuesday, October 08, 2013 8:24 AM
> To: Tal Liron
> Cc: nashorn-dev@openjdk.java.net
> S
+1
On 2013-10-08, at 3:46 PM, Hannes Wallnoefer
wrote:
> Please review JDK-8026042: FoldConstants need to guard against
> ArrayLiteralNode:
>
> http://cr.openjdk.java.net/~hannesw/8026042/
>
> Thanks,
> Hannes
+1
On 2013-10-08, at 4:17 PM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8026048/
>
> -Sundar
Are you multi-threading?
On 2013-10-09, at 8:43 AM, Tal Liron wrote:
> The code uses Logger.getLevel(), but doesn't take into account that the value
> could be null. Exception trace:
>
> java.lang.NullPointerException
>at
> jdk.nashorn.internal.runtime.DebugLogger.levelAbove(DebugLogger.
uld be appreciated.
> Indeed, a simple skeleton for a custom linker would be great!
>
> On 10/08/2013 09:04 PM, Jim Laskey (Oracle) wrote:
>> You could always create your own Dynalink linker plug in to do the wrappers
>> you need. Sundar will follow up.
>>
>
+1
On 2013-10-10, at 9:07 PM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8026264/
>
> -Sundar
+1
On 2013-10-11, at 6:31 AM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8026263/
>
> -Sundar
+1
On 2013-10-11, at 10:55 AM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8026302/
>
> -Sundar
+1
On 2013-10-11, at 10:54 AM, Hannes Wallnoefer
wrote:
> Please review JDK-8026292: Megamorphic setter fails with boolean value:
>
> http://cr.openjdk.java.net/~hannesw/8026292/
>
> Thanks,
> Hannes
t way to send
>> my code to the team?
>>
>> On 10/09/2013 11:27 PM, Attila Szegedi wrote:
>>> You'll also need to sign and send us an Oracle Contributor Agreement:
>>> <http://www.oracle.com/technetwork/oca-405177.pdf>
>>>
>>> On Oct 9
http://cr.openjdk.java.net/~jlaskey/8026309/webrev.00
In general all arguments prior to -- are for the jjs command (see -help) and
all the arguments on the script command line are just a continuation of the
shebang line. At one point it was possible to #!/usr/bin/jjs -- to get all the
script command line arguments as arguments, but this doesn't se
The complication there is that every time you have an Object argument/field you
would have to have an if instanceof ConsString cast String sequence, which is a
huge performance hit. ConsString was introduced to significantly improve
performance (high frequency operation), so it's a bit of a dil
Three cheers.
Sent from Jim's iPhone
> On Oct 14, 2013, at 2:22 AM, Tal Liron wrote:
>
> More good news: Diligence now also works on Nashorn. It is a powerful,
> scalable MonogDB-driven web framework:
>
> http://threecrickets.com/diligence/
>
> MongoVision, an Ext-JS-based front end for Mon
+1
On 2013-10-17, at 12:21 PM, Hannes Wallnoefer
wrote:
> Please review JDK-8026701: Array.prototype.splice is slow on dense arrays:
>
> http://cr.openjdk.java.net/~hannesw/8026701/webrev.01/
>
> Thanks,
> Hannes
+1
Why is there a difference between linux kaleidoscope.png and those of mac and
windows?
On 2013-10-18, at 11:20 AM, Konstantin Shefov
wrote:
> Hello,
>
> Please review a new Nashorn test feature:
>
> JDK-8026871 NASHORN TEST: Enable possibility to test Nashorn use of JavaFX
> canvas.
>
+1
On 2013-10-22, at 8:27 AM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8027024/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8027024
>
> Thanks
> -Sundar
In general the Nashorn docs start here.
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation, but as you
point out, we seem to be lacking JSAdapter details. I should start an FAQ.
From the javadoc (cd make; ant javadoc # ./dist/javadoc/index.html)
public final class NativeJSAdap
+1
On 2013-10-22, at 1:18 PM, "A. Sundararajan"
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8027020/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8027020
>
> -Sundar
gister custom adapters in a “wrap factory” that tells the
> script engine to use these adapters for accessing instances of those
> classes/types. What’s the analog in Nashorn? Can custom types implement
> interfaces that Nashorn will use?
>
> From: Jim Laskey (Oracle) [mailto:j
+1
On Oct 23, 2013, at 9:39 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8027150/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8027150
>
> -Sundar
+1
On Oct 23, 2013, at 8:15 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8027128/webrev.01/
>
> PS. Updated to remove JSObject.callMember
>
> -Sundar
You may not have a vote, but we readily accept input. If you want to
contribute code just sign an OCD
http://www.oracle.com/technetwork/community/oca-486395.html so we can accept
your submissions. After a few significant submissions, you can become an
active contributor. http://openjdk.java.
The Nashorn team does not have any immediate plans to port to Android. But,
since Nashorn is open source, it's possible that some other organization may be
doing so.
Cheers,
-- Jim
On Oct 24, 2013, at 7:49 AM, Durgesh Mishra wrote:
> Hi Folks
>
> Hope you doing great.
>
> I am an Androi
+1
On Oct 24, 2013, at 9:47 AM, Hannes Wallnoefer
wrote:
> Attila found a few cases where unary and binary operators may have side
> effects even when their children do not, such as "new ". I
> uploaded a new patch to fix these.
>
> http://cr.openjdk.java.net/~hannesw/8027042/webrev.01/
>
>
On Oct 24, 2013, at 11:49 PM, Michael Roberts wrote:
> I had another couple of basic questions.
>
> 1) If my script is "pure" javascript provided by someone else, and I don't
> want to interfere with the script by pre-pending some java objects into it,
> what's the prescribed way for getting sa
+1
On Oct 25, 2013, at 10:01 AM, Hannes Wallnoefer
wrote:
> Please review JDK-8027301: Optimizations for Function.prototype.apply:
>
> http://cr.openjdk.java.net/~hannesw/8027301/
>
> Thanks,
> Hannes
http://cr.openjdk.java.net/~jlaskey/8027447/webrev.00/index.html
http://cr.openjdk.java.net/~jlaskey/8027532/webrev.00/index.html
+1
On Nov 1, 2013, at 12:20 PM, Konstantin Shefov
wrote:
> Hello,
>
> Please review a new Nashorn test feature:
>
> JDK-8027708 NASHORN TEST: Create Nashorn test that draws image step-by-step
> using JavaFX canvas.
>
> https://bugs.openjdk.java.net/browse/JDK-8027708
>
> The webrev is: htt
+1
On Nov 4, 2013, at 7:36 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8027753/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8027753
>
> -Sundar
+1
On Nov 7, 2013, at 7:12 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8027828/
>
> Thanks
> -Sundar
+1
On Nov 15, 2013, at 1:49 PM, Marcus Lagergren
wrote:
> Line numbers were wrong for while loop header due to loop inversion
>
> http://cr.openjdk.java.net/~lagergren/8028434/
>
> /M
>
Please review https://bugs.openjdk.java.net/browse/JDK-8029173 - single line
diff in JBS
Will answer off-line. -- Jim
On Dec 2, 2013, at 1:50 PM, Greg Brail wrote:
> Nashorn committers -- it looks like you are all hard at work and producing
> something very promising.
>
> In the meantime, my group is doing a lot of work with Rhino, and from the
> traffic on the mailing list there a
There might be some aspects of that, but it is 99% technical. There are some
major changes required to the JVM to support Nashorn properly in JDK 7 (perform
well, no memory bloat, security et al.) And then the question is, why don't we
backport those changes to the JVM? Well, then it becomes
iest
> and hardest to penetrate... But perhaps if it becomes a milestone feature I
> can assist in testing and patching.
>
> On 12/03/2013 09:03 PM, Jim Laskey (Oracle) wrote:
>> There might be some aspects of that, but it is 99% technical. There are
>> some major changes r
Now that Nashorn is getting ready to ship, I thought it would be a good idea to
explain how to file bugs against Nashorn.
The MOST IMPORTANT STEP YOU CAN TAKE when filing a bug is to help us isolate
the root cause. If you have a million line program that crashes after 2 hours
and you pass it t
Nashorn's release schedule is one and the same as JDK8's.
http://openjdk.java.net/projects/jdk8/milestones
We are currently at M8 - Rampdown phase 2, which means that only showstopper
bugs can be fixed.
-- Jim
On Dec 6, 2013, at 6:00 AM, Tal Liron wrote:
> Is there a release schedule for N
hts?
>
>> On Dec 6, 2013, at 6:45 AM, "Jim Laskey (Oracle)"
>> wrote:
>>
>> Nashorn's release schedule is one and the same as JDK8's.
>> http://openjdk.java.net/projects/jdk8/milestones
>>
>> We are currently at M8 - Rampdown pha
t; Sent: Friday, December 06, 2013 7:32 AM
> To: Rick Bullotta
> Cc: Jim Laskey (Oracle); nashorn-dev@openjdk.java.net
> Subject: Re: Release schedule
>
> Hi Rick,
>
> We ran a couple in London - everyone seemed to get a lot out of them. I'm
> sure there'd be
+1
On Dec 16, 2013, at 1:19 PM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8030182/
>
> Thanks,
> -Sundar
+1
On Dec 18, 2013, at 12:00 PM, Hannes Wallnoefer
wrote:
> Please review JDK-8029667: Prototype linking is incorrect:
>
> http://cr.openjdk.java.net/~hannesw/8029667/
>
> Thanks,
> Hannes
+1
On Dec 19, 2013, at 11:48 AM, A. Sundararajan
wrote:
> Please review http://cr.openjdk.java.net/~sundar/8030809/
>
> -Sundar
http://hg.openjdk.java.net/jdk9/dev/nashorn is the correct repo. We started
ahead of the rest of the JDK team. I'll be migrating change sets to in the
near future.
-- Jim
On Dec 19, 2013, at 12:33 PM, Andreas Rieber wrote:
> Hi,
>
> just while you commit JDK 9 changes to:
> http://hg.ope
1 - 100 of 556 matches
Mail list logo
