Re: RFR: 8156153: java/lang/System/LoggerFinder/jdk/DefaultLoggerBridgeTest/DefaultLoggerBridgeTest.java fails with java.lang.RuntimeException

> On May 6, 2016, at 7:22 AM, Daniel Fuchs wrote: > > Hi, > > This is a fix for a subtle test bug caused by a logger being GCed. > > bug id: > https://bugs.openjdk.java.net/browse/JDK-8156153 > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8156153/webrev/ >

Re: RFR: regex changes -- sun.security.util.Debug issue

> On May 10, 2016, at 1:44 PM, Xueming Shen wrote: > > On 5/10/16 1:10 PM, Alan Bateman wrote: >> >> >> On 10/05/2016 19:57, Xueming Shen wrote: >>> webrev has been updated as suggested, now the lazily-init-class-holder is >>> used >>> to delay the Debug

Re: RFR(m): 8140281 deprecate Optional.get()

Consider a library like guava classic. It currently supports jdk 6+, and there's a good chance that library will do that until its end of life, which is likely to be around the time when EVERYBODY is using jdk 8+, which is still many years away. Even there, it would be nice to compile with javac

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

I should mention - if you actually want to run the test you should checkout the source and then build it. Just run mvn clean install. Once you have done that the log4j-perf module has all the performance tests. Most of the tests have the command line you can use to run the test. Ralph > On

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Here is the link to the source - https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-perf/src/main/java/org/apache/logging/log4j/perf/jmh/AsyncAppenderLog4j2LocationBenchmark.java;h=c306ac1a0f475d772b6ccb8afa527dc037d7c646;hb=HEAD

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

> On May 10, 2016, at 5:17 PM, Ralph Goers wrote: > > OK - I try that. My earlier comparison had shown that StackWalker was much > faster but since walking the Throwable is so much slower I’m now wondering > how much better than Java 7 & 8 it will be. > > Any

Re: RFR(m): 8139233 add initial compact immutable collection implementations

On 5/5/16 2:22 PM, Eddie Aftandilian wrote: FWIW, at Google we have a patch against our JDK that randomizes hash iteration order. For test execution we randomize with a unique seed per JVM invocation. For production we force a specific seed for all executions. This approach catches most

Re: RFR(m): 8139233u1 add initial compact immutable collection implementations

On 5/9/16 7:25 AM, Remi Forax wrote: I still think that the code of hasNext of the iterator of SetN and MapN should not do any side effect. Yes, I'm happy to consider further cleanups. I was starting to go off into the weeds with refactoring and cleanups, since they were introducing

Re: RFR(m): 8140281 deprecate Optional.get()

On 4/28/16 7:23 PM, Martin Buchholz wrote: No opinion on Optional.get() itself, but here's an opinion on the high cost of deprecation. If you deprecate the API today, and I have a library that is already using the API, then I should add a @SuppressWarning("deprecation") today and keep it there

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

OK - I try that. My earlier comparison had shown that StackWalker was much faster but since walking the Throwable is so much slower I’m now wondering how much better than Java 7 & 8 it will be. Any idea why walking the Throwable is so much slower? Ralph > On May 10, 2016, at 5:01 PM, Mandy

Review request for JDK-8156680: jdeps implementation refresh

JDK-8156680: jdeps implementation refresh JDK-8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8156680/webrev.00/ This refactors the jdeps implementation that regression tests can be

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

This walks the stack to find a frame with a matching class. Throwable::getStackTrace is taking the entire stack trace. I suggest to try StackWalker and avoids the overhead of dumping the entire stack trace. Mandy > On May 10, 2016, at 10:40 AM, Ralph Goers wrote:

Re: RFR (JAXP) 8152912: SAX XMLReaderFactory needs to be ServiceLoader compliant

On 5/9/16 2:59 PM, huizhe wang wrote: This looks much better to me. I just wonder about the @Deprecated("5") vs @Deprecated("1.5") Yes, the compiler accepted it just fine and produced javadocs similar to that of XMLReaderFactory where since="9". Hi Joe, Daniel, The namespace of the

Memory leak in com.sun.jndi.ldap.pool.PoolCleaner

Hi, While working my way through Tomcat's memory leak protection / detection / fixing code, I have found an issue that remains unresolved in the latest JDK 9 source. The PoolCleaner thread started by the LdapPoolManager when the idle timeout is positive does not explicitly set the context class

RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java - A Revival

Hi! Welcome back to 8029891, "Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java". Our previous discussion is at [1]. Briefly, java.util.Properties isa Hashtable, which synchronizes on itself for any access. System.getProperties() returns the Properties instance accessed

Re: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions

Hi Christian, Thank you for review. Here is updated webrev http://cr.openjdk.java.net/~asmotrak/8152207/hotspot/webrev.01/ Artem On 05/09/2016 01:24 PM, Christian Thalinger wrote: On May 4, 2016, at 1:48 PM, Artem Smotrakov >

Re: RFR: regex changes -- sun.security.util.Debug issue

On 5/10/16 1:10 PM, Alan Bateman wrote: On 10/05/2016 19:57, Xueming Shen wrote: webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev

Re: RFR: regex changes -- sun.security.util.Debug issue

+1 On 5/10/2016 2:57 PM, Xueming Shen wrote: webrev has been updated as suggested, now the lazily-init-class-holder is used to delay the Debug initialization. Tests all passed locally. A jprt job is out to confirm. Here is the updated webrev

Re: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv'

Hi, Stephen, Roger Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8155823/webrev.04/ Apart from the fix, made a correction in the java doc of ZoneRules.java Thanks and Regards, Nadeesh On 5/10/2016 12:54 AM, Roger Riggs wrote: Hi Nadeesh,

Re: RFR: regex changes -- sun.security.util.Debug issue

Sean, Given the "debug" is a private field and it is used only for debug != null in toString() -> seeAllp(), can the following change be a valid update? with the assumption that (1) the toString() is really not performance critical here, as we are changing from debug != null to

Re: RFR (JAXP) : 8046274: Removing dependency on jakarta-regexp

+1 > On May 10, 2016, at 1:15 PM, huizhe wang wrote: > > Hi, > > This change focuses purely on removing the dependency on jakarta-regexp. I'm > leaving all other things in the bcel code to a future bcel update. All tests > passed. > > JBS:

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

The benchmark logs events using Log4j 2’s asynchronous loggers. In the process of doing that it captures the location information using the code below: // LOG4J2-1029 new Throwable().getStackTrace is faster than Thread.currentThread().getStackTrace(). final StackTraceElement[] stackTrace = new

Re: RFR: regex changes -- sun.security.util.Debug issue

On 5/10/16 1:30 AM, Alan Bateman wrote: On 10/05/2016 06:36, Xueming Shen wrote: Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears

RFR (JAXP) : 8046274: Removing dependency on jakarta-regexp

Hi, This change focuses purely on removing the dependency on jakarta-regexp. I'm leaving all other things in the bcel code to a future bcel update. All tests passed. JBS: https://bugs.openjdk.java.net/browse/JDK-8046274 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8046274/webrev/

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

What does your benchmark call? Mandy > On May 10, 2016, at 9:49 AM, Ralph Goers wrote: > > I just ran one of the Log4j performance tests that specifically captures > location information. To run the test I do > > java -jar log4j-perf/target/benchmarks.jar >

Re: Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

I just ran one of the Log4j performance tests that specifically captures location information. To run the test I do java -jar log4j-perf/target/benchmarks.jar ".*AsyncAppenderLog4j2LocationBenchmark.*" -f 1 -wi 10 -i 20 -t 4 -si true And the results are: java version "1.7.0_80 Benchmark

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Hi Roger, On May 10, 2016, at 8:03 AM, Roger Riggs wrote: > Good catch, the javadoc needs to match the code and in this case the new > language > does not match the code. Some cases are harder to follow because they > delegate > to other classes for copying. I think

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Hi Pavel, Good catch, the javadoc needs to match the code and in this case the new language does not match the code. Some cases are harder to follow because they delegate to other classes for copying. It may also be the case that since Writer.write(char[], off, len) is abstract, it cannot

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Good catch, Pavel. I’ll update it again and refresh the webrev. Thanks, Brian On May 10, 2016, at 7:32 AM, Pavel Rappo wrote: > Hold it right there :-) > > There's an open issue about BufferedWriter > > https://bugs.openjdk.java.net/browse/JDK-8029804 > > So in

Re: RFR [9] 8156661: Handful of typos in javadoc

Thanks! Pushed. On 10.05.2016 17:15, Roger Riggs wrote: Looks good, Reviewed, Roger On 5/10/2016 9:32 AM, Ivan Gerasimov wrote: Thanks Pavel! On 10.05.2016 16:28, Pavel Rappo wrote: Hi Ivan, Looks good! // I'm not an Reviewer. On 10 May 2016, at 14:07, Ivan Gerasimov

Re: RFR [9] 8156661: Handful of typos in javadoc

Hold it right there :-) There's an open issue about BufferedWriter https://bugs.openjdk.java.net/browse/JDK-8029804 So in this case what we've added in the @throws for java.io.BufferedWriter#write(java.lang.String, int, int) directly contradicts what it states two paragraphs above, doesn't

Re: RFR [9] 8156661: Handful of typos in javadoc

Sorry for the incorrect subject field. Should've been Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds > On 10 May 2016, at 15:28, Pavel Rappo wrote: > > Hold it right there :-) > > There's an open issue about

Re: RFR 8062804: IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR too lenient

Looks fine, Roger p.s. I don't see existing tests of the getFrom method for unsupported non-Iso temporals but that would be a new issue. On 5/10/2016 6:38 AM, Stephen Colebourne wrote: Looks great thanks Stephen On 10 May 2016 at 08:56, Bhanu Gopularam

Re: RFR [9] 8156661: Handful of typos in javadoc

Looks good, Reviewed, Roger On 5/10/2016 9:32 AM, Ivan Gerasimov wrote: Thanks Pavel! On 10.05.2016 16:28, Pavel Rappo wrote: Hi Ivan, Looks good! // I'm not an Reviewer. On 10 May 2016, at 14:07, Ivan Gerasimov wrote: Hello! A couple of dozens of typos

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

Looks good Brian, Thanks On 5/10/2016 5:36 AM, Chris Hegarty wrote: On 10 May 2016, at 00:29, Brian Burkhalter wrote: Hi Roger, So modified: http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ This looks good to me. I have to admit that I reviewed the

Re: RFR [9] 8156661: Handful of typos in javadoc

Thanks Pavel! On 10.05.2016 16:28, Pavel Rappo wrote: Hi Ivan, Looks good! // I'm not an Reviewer. On 10 May 2016, at 14:07, Ivan Gerasimov wrote: Hello! A couple of dozens of typos has been collected, so it's time to fix them. Would you please help review

RFR [9] 8156661: Handful of typos in javadoc

Hello! A couple of dozens of typos has been collected, so it's time to fix them. Would you please help review this trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8156661 WEBREV: http://cr.openjdk.java.net/~igerasim/8156661/00/webrev/ With kind regards, Ivan

Re: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes

Hi, I think this shows the compiler isn't doing anything really strange; it'd be fun to know if it's the different instruction order or the use of one less constant that shows an effect, but it's not really significant either way. I think the latest patch is fine as it is and will push it

RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c

Hi all, can I please get a review for a change to NetworkInterface.c bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ Apart from quite a few whitespace changes to clean up the coding, I went through and replaced all

Re: JDK 9 RFR of 8130679: Writer/StringWriter.write methods do not specify index out bounds

On 10 May 2016, at 00:29, Brian Burkhalter wrote: > Hi Roger, > > So modified: > > http://cr.openjdk.java.net/~bpb/8130679/webrev.01/ This looks good to me. I have to admit that I reviewed the current wording in Reader.read, but on reflection it would be better

Re: RFR [9] 8153737: Unsupported Module

On 9 May 2016, at 20:43, Richard Opalka wrote: > Fixed in JBoss Marshalling upstream. Thanks for fixing this, and getting back to us on the list. I assume then that, at least, this part of JBoss is working on JDK 9 b115, right? -Chris. > Thanks, > > Rio > > On

Re: Proposed patch: further wrapping of FileInputStream's native method

On 10/05/2016 08:13, Chan, Sunny wrote: The available() and sync() are the only native methods in the FileInputStream that has not been "wrapped". Our use case is that we have an internal storage implementation and we would like to be able to provide support for older applications that use

Re: RFR: regex changes -- sun.security.util.Debug issue

On 10/05/2016 06:36, Xueming Shen wrote: Hi, While testing for the attached regex changes, a fatal vm init error was triggered for test case with -Djava.security.debug=xyz turned on, as showed in following stacktrace. It appears sun.security.util.Debug is being initialized even before the

RFR 8062804: IsoFields WEEK_BASED_YEAR and QUARTER_OF_YEAR too lenient

Hi all, Please review fix following issue Bug Id : https://bugs.openjdk.java.net/browse/JDK-8062804 Solution: Added check for unsupported fields in IsoFields rangeRefinedBy methods Webrev : http://cr.openjdk.java.net/~bgopularam/bhanu/JDK-8062804/webrev.00 Thanks, Bhanu

RE: Proposed patch: further wrapping of FileInputStream's native method

The available() and sync() are the only native methods in the FileInputStream that has not been "wrapped". Our use case is that we have an internal storage implementation and we would like to be able to provide support for older applications that use java.io api without modify the apps to use

Re: RFR: regex changes -- sun.security.util.Debug issue

Security-dev, If we can live with "engine=keystore" happily, why not just make the whole string lowercase and search for "permission=java.io.filepermission"? I don't think there are permission types or URL names that are only different in cases. Although file names are case-sensitive in Unix,