Changeset: f6588f168d79
Author:hannesw
Date: 2013-07-26 13:50 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f6588f168d79
8020719: Run tests with reduced splitter threshold
Reviewed-by: lagergren, sundar, jlaskey
! make/build.xml
! make/project.properties
+
On 07/18/2013 02:19 PM, Brian Burkhalter wrote:
On Jul 17, 2013, at 10:07 PM, Joe Darcy wrote:
In Random.java, I would prefer if the font size manipulation of the exponent
was removed instead of
373 * All 2fontstyle=font-size:smaller;sup24/sup/font possible
{@code float} values
just
Thank you, Alan. I really appreciate it.
Here's the mercurial export:
http://cr.openjdk.java.net/~igerasim/2commit/8020669-jdk8-readAllBytes.patch
Sincerely yours,
Ivan
On 29.07.2013 3:43, Alan Bateman wrote:
On 28/07/2013 15:08, Ivan Gerasimov wrote:
Hello Alan and everyone else
Thank you
.
http://cr.openjdk.java.net/~bpb/8020539/
Brian,
Looks fine ( I did not go through the Scanner changes ).
Some minor comments:
1) List
Trivially I wonder why you decided to go with 'lt; 'gt;', rather
than pre{@code ... }/pre, which I think is more readable.
2) Map
On 29/07/2013 00:43, Alan Bateman wrote:
On 28/07/2013 15:08, Ivan Gerasimov wrote:
Hello Alan and everyone else
Thank you for review!
Here's another version of webrev:
http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/
http://cr.openjdk.java.net/%7Eigerasim/8020669/5/webrev/
The change
Hi Mike,
V. quick review below.
On Jul 27, 2013, at 12:31 AM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This patch adds some missing checks for null that, according to interface
contract, should be throwing NPE. It also improves the existing tests to
check for these cases.
Just so that everyone understands how important this subject is, this change to
getCallerClass(...) is being labeled a disaster for logging frameworks
everywhere. Here's a benchmark for getting Classes from the following methods:
1,000,000 calls of all alternatives were measured as follows :
I find it very interesting that reflection is no less than two orders of
magnitude faster than the security manager solution. How big was the
stack in these tests? It makes me wonder if maybe the implementation of
the security manager's getContext() method should be reevaluated a bit.
On
On 29/07/2013 12:20, Paul Sandoz wrote:
Hi Mike,
V. quick review below.
The changes look ok to me. Some small comments below.
On Jul 27, 2013, at 12:31 AM, Mike Duigoumike.dui...@oracle.com wrote:
Hello all;
This patch adds some missing checks for null that, according to interface
If it is not possible in the remaining dev time for JDK8 to expose
Reflection.getCallerClass() functionality through some public API, why must
-Djdk.reflect.allowGetCallerClass be discontinued so soon? Why the hot
potato? I don't see how impacting the many (most? or all?) open source
logging
Alan,
Excuse me if I'm a bit frustrated by this issue ...
We keep going around and around on this issue. We had a discussion with Stuart
and the JCK
team and Stuart didn't want to change the specification. Has he now changed
his mind?
Security and configuration issues aside, I don't
There are two remaining doclint warnings in the java.net package.
:javac -Xdoclint:all/protected
src/share/classes/java/net/DatagramPacket.java
src/share/classes/java/net/DatagramPacket.java:142: warning: no @throws
for java.net.SocketException
public DatagramPacket(byte buf[], int
On 29.07.2013 14:27, Chris Hegarty wrote:
On 29/07/2013 00:43, Alan Bateman wrote:
On 28/07/2013 15:08, Ivan Gerasimov wrote:
Hello Alan and everyone else
Thank you for review!
Here's another version of webrev:
http://cr.openjdk.java.net/~igerasim/8020669/5/webrev/
On 29/07/2013 07:12, Bob Vandette wrote:
Alan,
Excuse me if I'm a bit frustrated by this issue ...
We keep going around and around on this issue. We had a discussion with Stuart
and the JCK
team and Stuart didn't want to change the specification. Has he now changed
his mind?
Security and
I wasn't the one who ran the test, so I don't know for sure. My theory
was that getCallerClass() returns a single frame, but the
SecurityManager must allocate an array of appropriate size (which
involves some overhead) and then return all of the frames. I chalked
the difference up to that. My
The numbers are from this link:
http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
Even if this benchmark suffers from micro-benchmark issues:
a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
I'd
+1
On 29. Juli 2013 at 15:50:36, Paul Benedict (pbened...@apache.org) wrote:
If it is not possible in the remaining dev time for JDK8 to expose
Reflection.getCallerClass() functionality through some public API, why must
-Djdk.reflect.allowGetCallerClass be discontinued so soon? Why the hot
Changeset: 24bda55fca48
Author:sundar
Date: 2013-07-29 21:39 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/24bda55fca48
8021773: print function as defined by jrunscript's init.js script is
incompatible with nashorn's definition
Reviewed-by: hannesw, lagergren
!
Changeset: cd9e8cea1b3c
Author:jlahoda
Date: 2013-07-28 10:17 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cd9e8cea1b3c
8021338: Diamond finder may mark a required type argument as unnecessary
Reviewed-by: mcimadamore
!
Changeset: 8c4b2987edac
Author:jlahoda
Date: 2013-07-28 10:17 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c4b2987edac
8020689: Missing LineNumberTable entries in compiled class files
Reviewed-by: ksrini, mcimadamore
!
Thanks, Alan
I did if reformatting and small refactoring for the code in function
in accordance with
https://jbs.oracle.com/bugs/browse/JDK-5008166
recommendations. I am sure that the presence of path separator has no
dependence from search direction.
Here is the webrev:
Changeset: 0532397d0732
Author:sundar
Date: 2013-07-29 18:07 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0532397d0732
8012792: print function defined in engine.js does not handle multiple arguments
Reviewed-by: hannesw
!
On Jul 29, 2013, at 2:46 PM, Chris Hegarty chris.hega...@oracle.com wrote:
diff --git a/src/share/classes/java/util/Map.java
b/src/share/classes/java/util/Map.java
--- a/src/share/classes/java/util/Map.java
+++ b/src/share/classes/java/util/Map.java
@@ -804,6 +804,10 @@
* return
On 07/16/2013 06:01 PM, Guy Steele wrote:
On Jul 16, 2013, at 3:07 AM, Martin Buchholz marti...@google.com wrote:
Read Appleby and Stafford ...
Hmmm mix32 has almost the same job as mix64 - have all the bits in the seed
affect all the bits in the output, so the obvious implementation is
Changeset: e83fc6d9cf03
Author:psandoz
Date: 2013-07-29 19:41 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e83fc6d9cf03
8020156: TreeMap.values().spliterator() does not report ORDERED
8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but
the
Some interesting things to note:
1) Someone has been asking for a public API replacement for getCallerClass()
since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I
/would/ have been asking for this for that long, except I haven't needed it
until recently and assumed it
On 7/28/13 10:13 PM, David Holmes wrote:
On 27/07/2013 3:53 AM, Brent Christian wrote:
Please review my fix for 8011194 : Apps launched via double-clicked
.jars have file.encoding value of US-ASCII on Mac OS X
http://bugs.sun.com/view_bug.do?bug_id=8011194
In most cases of launching a Java
Joe / Chris:
The updated webrev is in the same place,
http://cr.openjdk.java.net/~bpb/8020539/
If this looks good I will need an approval.
On Jul 29, 2013, at 12:05 AM, Joe Darcy wrote:
I recommend a few changes here:
* For readability, rename NonASCIIDigit as NonAsciiDigit
Changed.
*
I second all of that.
It was my understanding that the whole purpose of EA and DP was pinpointing
problems like these before they hit consumers. What's the point of them if
feedback can't cause the reverting of a breaking change?
If this is not rectified then the old Java is slow-mantra will
Changeset: c042fd498f79
Author:ascarpino
Date: 2013-07-19 11:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c042fd498f79
8012971: PKCS11Test hiding exception failures
Reviewed-by: vinnie, valeriep
! test/ProblemList.txt
! test/sun/security/pkcs11/PKCS11Test.java
!
Changeset: e47569593fa0
Author:ascarpino
Date: 2013-07-29 13:43 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e47569593fa0
8020424: The NSS version should be detected before running crypto tests
Reviewed-by: valeriep
! test/ProblemList.txt
!
I expect that at this stage, patches speak louder than words :)
On 07/29/2013 03:57 PM, Jörn Huxhorn wrote:
I second all of that.
It was my understanding that the whole purpose of EA and DP was pinpointing
problems like these before they hit consumers. What's the point of them if
feedback
I would happily contribute a patch if I were able to. However, I have almost no
idea what I'm doing on the native side, and I spent three hours perusing the
Mercurial repository and still can't figure out where anything is.
Even so, I would be willing to try. But I can't just blindly make up a
I don't see how Throwables could be deserialized with the proposed
changes to that class (Class.forName() only works when everything is
visible from one class loader - a trivial case which is rarely true in
practice, especially in an app server situation). I think you'd have to
leave that
+1 with Nick. There's no point in submitting a patch unless someone who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no official
responses -- it's been quiet on their front for sometime. I don't know if
that
Okay. Some questions then:
1) Instead of Executable, StackTraceFrame could simply have the method name.
Using Executable would be more future-proof (I anticipate someone wanting to
know that someday), so if it turns out it's available I'd prefer to use it, but
if it's not physically available
Answers:
1) Seems reasonable enough.
2) I think this will be quite complicated in practice. First, we don't
want to obliterate performance, so we need some way to only assemble
this information if necessary (assembling two stack traces is likely to
be twice as expensive as assembling one,
On 29/07/2013 15:48, Paul Benedict wrote:
+1 with Nick. There's no point in submitting a patch unless someone who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no official
responses -- it's been quiet on
On 07/29/2013 08:38 PM, Alan Bateman wrote:
On 29/07/2013 15:48, Paul Benedict wrote:
+1 with Nick. There's no point in submitting a patch unless someone
who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no
Hi,
Please review a simple fix for 8020977.
The fix grab the length before initiate copying operation, so that the
'delimiter' added for this won't be included in copy.
For rest cases, the timing window changed a little, but that's fine as
simultaneous changes is not determined.
Cheers,
Henry
Sorry, the webrev is at
http://cr.openjdk.java.net/~henryjen/tl/8020977/0/webrev/
Cheers,
Henry
On 07/29/2013 07:30 PM, Henry Jen wrote:
Hi,
Please review a simple fix for 8020977.
The fix grab the length before initiate copying operation, so that the
'delimiter' added for this won't be
Please help review (and commit to jdk-tl or jdk) this java.time test bug
8021767 http://bugs.sun.com/view_bug.do?bug_id=8021767:
test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Correct to use fixed locale; not locale of test environment
The test incorrectly uses the locale
Changeset: 613cc7beba64
Author:xuelei
Date: 2013-07-29 19:36 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/613cc7beba64
8021841: Remove SSLEngineDeadlock.java from problem list
Reviewed-by: wetmore
! test/ProblemList.txt
On 30/07/2013 5:54 AM, Brent Christian wrote:
On 7/28/13 10:13 PM, David Holmes wrote:
On 27/07/2013 3:53 AM, Brent Christian wrote:
Please review my fix for 8011194 : Apps launched via double-clicked
.jars have file.encoding value of US-ASCII on Mac OS X
On 29/07/2013 19:17, David M. Lloyd wrote:
Your phrasing makes me think I missed something: is the
Reflection.getCallerClass() method being removed due to some technical
issue that it can only be somehow emulated as a workaround? Or is it
just a general cleanup effort?
The
Looks good to me.
Masayoshi
On 7/30/2013 11:57 AM, Roger Riggs wrote:
Please help review (and commit to jdk-tl or jdk) this java.time test bug
8021767 http://bugs.sun.com/view_bug.do?bug_id=8021767:
test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Correct to use fixed
On 29/07/2013 19:57, Roger Riggs wrote:
Please help review (and commit to jdk-tl or jdk) this java.time test bug
8021767 http://bugs.sun.com/view_bug.do?bug_id=8021767:
test/java/time/tck/java/time/format/TCKFormatStyle.java failing
Correct to use fixed locale; not locale of test
On 7/29/2013 9:31 PM, Alan Bateman wrote:
On 29/07/2013 19:17, David M. Lloyd wrote:
Your phrasing makes me think I missed something: is the
Reflection.getCallerClass() method being removed due to some
technical issue that it can only be somehow emulated as a
workaround? Or is it just a
On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:
On 7/29/2013 9:31 PM, Alan Bateman wrote:
On 29/07/2013 19:17, David M. Lloyd wrote:
Your phrasing makes me think I missed something: is the
Reflection.getCallerClass() method being removed due to some technical
issue that it can only
49 matches
Mail list logo
