Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 th

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 ge

Re: RFR: java.time test bug

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 : test/java/time/tck/java/time/format/TCKFormatStyle.java failing Correct to use fixed locale; not locale of test environme

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 sun.reflect.Refl

Re: RFR: java.time test bug

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 : test/java/time/tck/java/time/format/TCKFormatStyle.java failing Correct to use fixed loca

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

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" http://bugs.sun.com/view_bug.do?bug_

hg: jdk8/tl/jdk: 8021841: Remove SSLEngineDeadlock.java from problem list

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

RFR: java.time test bug

Please help review (and commit to jdk-tl or jdk) this java.time test bug 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

Re: CFR: 8020977: StringJoiner merges with itself not as expected

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

CFR: 8020977: StringJoiner merges with itself not as expected

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

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 thei

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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, af

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 t

Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

+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 m

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 part

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 p

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 can

hg: jdk8/tl/jdk: 8020424: The NSS version should be detected before running crypto tests

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 ! test/sun/security/pkcs11/KeyStor

hg: jdk8/tl/jdk: 8012971: PKCS11Test hiding exception failures

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 ! test/su

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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

Re: Java 8 RFR 8020539: Clean up doclint problems in java.util package, part 2

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

Re: Java 8 RFR 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X

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 a

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 al

hg: jdk8/tl/jdk: 8020156: TreeMap.values().spliterator() does not report ORDERED; ...

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 elemen

Re: class SplittableRandom

On 07/16/2013 06:01 PM, Guy Steele wrote: On Jul 16, 2013, at 3:07 AM, Martin Buchholz 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 mix32() { return (i

Re: RFR: 8021591 : (s) Additional explicit null checks

On Jul 29, 2013, at 2:46 PM, Chris Hegarty 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 false; >>

hg: jdk8/tl/nashorn: 2 new changesets

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 ! src/jdk/nashorn/api/scripting/resources/engine.

Re: Review request: JDK-8021245 (process) file leak in jdk/src/windows/native/java/lang/ProcessImpl_md.c

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: http://cr.open

hg: jdk8/tl/langtools: 8020689: Missing LineNumberTable entries in compiled class files

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 ! src/share/classes/com/sun/tools/javac/jvm/Gen.j

hg: jdk8/tl/langtools: 8021338: Diamond finder may mark a required type argument as unnecessary

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 ! src/share/classes/com/sun/tools/javac/comp/Attr

hg: jdk8/tl/jdk: 8021773: print function as defined by jrunscript's init.js script is incompatible with nashorn's definition

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 ! src/share/c

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

+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

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 sugge

Re: 8016036: RMI specification needs to be updated to allow Activation on remote hosts

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 c

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 concl

Re: RFR [8020669] java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0

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/

Remaining doclint issues in java.net

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 offse

Re: 8016036: RMI specification needs to be updated to allow Activation on remote hosts

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 understa

Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 librar

Re: RFR: 8021591 : (s) Additional explicit null checks

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 Duigou wrote: Hello all; This patch adds some missing checks for null that, according to interface contract, should be throwin

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 07/

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

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 :

Re: RFR: 8021591 : (s) Additional explicit null checks

Hi Mike, V. quick review below. On Jul 27, 2013, at 12:31 AM, Mike Duigou 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. > > http://cr.ope

Re: RFR [8020669] java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0

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/ The chang

Re: Java 8 RFR 8020539: Clean up doclint problems in java.util package, part 2

. 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 '< '>', rather than {@code ... }, which I think is more readable. 2) Map Trivially, I would ke

Re: RFR [8020669] java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0

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 f

Review request for 8021773: print function as defined by jrunscript's init.js script is incompatible with nashorn's definition

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

Re: Java 8 RFR 8020539: Clean up doclint problems in java.util package, part 2

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 size manipulation of the exponent was removed instead of 373 * All 224 possible {@code float} values just 373 * All 224 possible {@code float} val