On 27/02/2013 02:31, Dan Xu wrote:
Thank you, Mike.
The reason not to throw out an exception is for the backward
compatibility. Due to that, the constructorof File object with NUL
willnever fail.While in NIO, it is defined in the spec to throw out
exceptions when invalid NUL character is foun
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
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
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 nashorn and rhino engines.
Changes documented here:
http://cr.openjdk.java.net/~sundar/800
Thanks Alan. Yes, nashorn is a "js" engine as well and so user's java
code can use getEngineByName("js") and get it. The current change is to
make sure that javax.script tests use nashorn engine - rather than any
other "js" engine that may be present in the underlying jdk.
-Sundar
On Wednesda
On 02/27/2013 03:52 AM, David Holmes wrote:
On 27/02/2013 12:31 PM, Dan Xu wrote:
Thank you, Mike.
The reason not to throw out an exception is for the backward
compatibility. Due to that, the constructorof File object with NUL
willnever fail.While in NIO, it is defined in the spec to throw out
On 27/02/2013 12:07, Peter Levart wrote:
What does a FileInputStream for example do when trying to open a File
with embedded NUL chars on UNIX/Windows ? Does it try to open a
"truncated" path? If so, then perhaps "normalize" could do that
beforehand...
Yes, it's truncated. Dan's fix covers Fi
On 27/02/2013 11:20, A. Sundararajan wrote:
Thanks Alan. Yes, nashorn is a "js" engine as well and so user's java
code can use getEngineByName("js") and get it. The current change is
to make sure that javax.script tests use nashorn engine - rather than
any other "js" engine that may be present
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 user's java
c
Hi,
Please review http://cr.openjdk.java.net/~sundar/8009140/
Thanks
-Sundar
Changeset: 1d3dca059b3e
Author:alanb
Date: 2013-02-27 14:12 +
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1d3dca059b3e
8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains
missing directory -c on Windows
Reviewed-by: chegar, sundar
! makefiles/Build
On 27/02/2013 14:14, A. Sundararajan wrote:
Hi,
Please review http://cr.openjdk.java.net/~sundar/8009140/
This looks okay to me.
-Alan
Changeset: 093fdf8937bd
Author:vladidan
Date: 2013-02-22 17:12 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/093fdf8937bd
8005545: Add System property to identify ARCH specific details such as ARM
hard-float binaries
Summary: Adding sun.os.abi Java Property support
Reviewed
CVS has been updated with some more internal doc clarifications.
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadLocalRandom.java?view=co
Martin's "random" wishlist:
- I wish the cool convenience methods in TLR like nextInt(least, bound)
could be promoted t
On 02/27/2013 05:10 PM, Martin Buchholz wrote:
CVS has been updated with some more internal doc clarifications.
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ThreadLocalRandom.java?view=co
Thanks Martin,
Once the CCC approves these changes, I will push them
Ouch. That is unfortunate that File cannot reject bad input.
Perhaps FileInputStream etc. should throw a specialized "Bad Filename" FnF for
paths containing NUL if the underlying filesystem does not support NUL?
Masking garbage input always really scares me.
Mike
On Feb 27 2013, at 02:40 , Ala
Changeset: f4b01f4e8f35
Author:mduigou
Date: 2013-02-27 11:00 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4b01f4e8f35
8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167
Reviewed-by: alanb
! src/share/classes/java/util/IdentityHashMap.java
+ test/java/ut
Because we cannot change the behaviour of File constructorsto error out
the bad input immediately, the changes will be scattered all over many
java io methods, especially methods in File.java, if we choose to reject
bad inputs. And due to the delay of the rejection, it also brings a
little head
Here's the latest version of the proposed patch:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/JNIEXPORT/
that has been tested, but only with gcc 4.6,
but is also written to work with llvm.
I have another iteration of this change
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/
that adds exciting new exception detail message for the InternalError I was
scratching my head about earlier.
-msg = strm->msg;
+msg = ((strm->msg != NULL) ? strm->msg :
+
System.out.println( new StringBuilder().toString() == "" );
-> "false"
Any reason for not returning the "" instance?
public String toString() {
return new String(value, 0, count);
}
-->
public String toString() {
return (count > 0) ? new String(value, 0, count) : "
21 matches
Mail list logo