Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

. webrev : http://cr.openjdk.java.net/~mli/8144460/webrev.01/ old one is moved to http://cr.openjdk.java.net/~mli/8144460/webrev.00/ Thank you -Hamlin On 2015/12/1 18:40, Daniel Fuchs wrote: Hi Hamlin, You should probably create a new open RFE for pushing this new test. I'm not sure we can use

Re: RFR 6856817: Poor performance of Writer#append with CharBuffer

Hi Vyom, Looks good to me too. If you don't get more comments from reviewers, send me the exported changeset and I'll push it for you. best regards, -- daniel On 11/25/15 3:29 PM, vyom wrote: Hi All, Please review my changes for below bug. Bug:JDK-6856817 : Poor performance of

Re: RFR 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated

); and the earliest Instant value for which toEpochMilli() will throw is Instant toobig = max.plusNanos(1L); Oh - yes that's a much more readable way to create these instant values :-) I'll take that! Thanks for the feedback. -- daniel s'marks On 12/2/15 12:10 PM, Daniel Fuchs wrote: Hi

Re: [9] RFR of 8143394: PushbackReader throws NullPointerException

Hi Brian, The fix looks good to me! Good that you were able to find these other classes where the same issue appeared. I see that FilterReader.close() calls in.close(). Hopefully wrapping this call (from PushbackReader) in a synchronized(lock) block won't be an issue. I wonder if: 248

Re: [9] RFR of 8143394: PushbackReader throws NullPointerException

Hi Brian, On 12/4/15 9:48 AM, Daniel Fuchs wrote: > I wonder if: > 248 public void close() throws IOException { > 249 synchronized (lock) { > 250 buf = null; > 251 } > 252 super.close(); > 253 } > > would be a safer i

Re: JDK 9 RFR of JDK-8144321: Improve existent tests to check the exact line numbers in Stack Frame.

HI Hamlin, If I understand well any line, comment, etc, added to the test in the future is likely to make the tests fail because the line numbers will no longer match. I have seen other tests (I think they where compiler tests) which exhibited such a characteristic, but those had a big warning

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, Stuart, Here is a potential fix for the issue: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html

Re: Review Request for JDK-8145430: Fix typo in StackWalker javadoc

On 15/12/15 19:18, Mandy Chung wrote: diff --git a/src/java.base/share/classes/java/lang/StackWalker.java b/src/java.base/share/classes/java/lang/StackWalker.java --- a/src/java.base/share/classes/java/lang/StackWalker.java +++ b/src/java.base/share/classes/java/lang/StackWalker.java @@ -304,8

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

Hi Mandy, I believe it would be good to have some test that go over the 1024 limit - as this has been useful to detect bugs when we were actively prototyping the API. So maybe we should first try to reduce from 2000 to e.g. 1028? best regards, -- daniel On 16/12/15 21:30, Mandy Chung wrote:

RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

Hi, Please find below a small enhancement for the method that infers the calling class name and method name in SimpleConsoleLogger and LogRecord. The idea is that since these methods now use the new StackWalker API they should take advantage of that in order to skip classes that implement

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

On 17/12/15 17:07, Mandy Chung wrote: On Dec 17, 2015, at 7:39 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: On 17/12/15 16:22, Mandy Chung wrote: On Dec 17, 2015, at 6:02 AM, Daniel Fuchs<daniel.fu...@oracle.com> wrote: Hi Mandy, I believe it would be good to have some

Re: Review Request 8144553: java/lang/StackWalker/StackWalkTest.java and MultiThreadStackWalk.java fail with stack overflows

On 17/12/15 16:22, Mandy Chung wrote: On Dec 17, 2015, at 6:02 AM, Daniel Fuchs<daniel.fu...@oracle.com> wrote: > >Hi Mandy, > >I believe it would be good to have some test that go over >the 1024 limit - as this has been useful to detect bugs >when we were actively pr

Re: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

On 12/17/15 7:02 PM, Mandy Chung wrote: On Dec 17, 2015, at 8:42 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi, Please find below a small enhancement for the method that infers the calling class name and method name in SimpleConsoleLogger and LogRecord. The idea is that

Re: RFR 4823133: RandomAccessFile.length() is not thread-safe

Hu Vyom, On 17/12/15 17:58, Martin Buchholz wrote: Looks good! Since you got Martin's blessing I will sponsor this and push it for you :-) best regards, -- daniel On Thu, Dec 17, 2015 at 12:14 AM, vyom wrote: Hi Martin, thanks for review, i undated the

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

then maybe simply removing it would be the safest thing... best regards, -- daniel On 05/01/16 22:16, Roger Riggs wrote: Hi Daniel, webrev updated to revert changes to MeteredStream as too risky. http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/index.html On 1/5/2016 1:45 PM, Daniel

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

Hi Roger, Some early feedback: I see that prior to your changes, MeteredStream.close() would be called by finalize. This will no longer be the case after http://cr.openjdk.java.net/~rriggs/webrev-cleaning-finalizers/index.html I see that MeteredStream has a subclass (KeepAliveStream) that

Re: 8049422: Remove @jdk.Exported

Hi Alan, I looked at the jdk/ changes - these look good to me. I didn't spot any error in the sed result ;-) best regards, -- daniel On 07/01/16 12:15, Alan Bateman wrote: It's time to remove @jdk.Exported. As background, this annotation was introduced by JEP 179 in JDK 8 to document the

Re: RFR 9: JDK-8144552 : java/lang/StackWalker/LocalsAndOperands.java fails with java.lang.NullPointerException

On 1/8/16 1:18 AM, Brent Christian wrote: Hi, Please review my change for 8144552 : java/lang/StackWalker/LocalsAndOperands.java fails with java.lang.NullPointerException Bug: https://bugs.openjdk.java.net/browse/JDK-8144552 Webrev: http://cr.openjdk.java.net/~bchristi/8144552/webrev.0/ It's

Re: RFR: 8146665: Test jdk/test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java fails - missing expected output

Hi Mandy, On 1/8/16 8:51 PM, Mandy Chung wrote: On Jan 8, 2016, at 7:36 AM, Daniel Fuchs<daniel.fu...@oracle.com> wrote: > >Hi, > >Please find below a tentative fix for: > >8146665: Test jdk/test/java/util/logging/LogManager/Configuration/updateConfiguration/Upda

Re: RFR: 8145686: SimpleConsoleLogger and LogRecord should take advantage of StackWalker to skip classes implementing System.Logger

Hi Mandy, Thanks for the feedback! New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8145686/webrev.01/ On 18/12/15 03:22, Mandy Chung wrote: It’d be helpful to add some comment in the skipLoggingFrame method. Maybe even better to change this method to isFilteredFrame?? Done. I

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, To complete my earlier reply: On 30/11/15 18:25, Daniel Fuchs wrote: If it can't be undeprecated what is the proper way to target support as low as JDK7 but might end up executing on JDK9? Well - a lib using LogRecord.getMillis() could use @SuppressWarnings("deprecation')

Re: Deprecation of LogRecord.getMillis in JDK9

On 30/11/15 18:04, Jason Mehrens wrote: Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use

Re: Deprecation of LogRecord.getMillis in JDK9

On 30/11/15 18:43, Roger Riggs wrote: Hi Daniel, I think it makes sense to keep getMillis (and document it) as a convenience method. Thanks Roger, Jason, I logged https://bugs.openjdk.java.net/browse/JDK-8144262 best regards, -- daniel Roger On 11/30/2015 12:25 PM, Daniel Fuchs wrote

Re: Deprecation of LogRecord.getMillis in JDK9

an @apiNote instead of the @deprecated comment. best regards, -- daniel Thanks, Jason ________ From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Monday, November 30, 2015 11:32 AM To: Jason Mehrens; Core-Libs-Dev Subject: Re: Deprecation of LogRecord.g

Re: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping.

Hi Hamlin, I see that you're going to push a test for this with JDK-8144215; Looks good to me. Do you need a sponsor for this fix? best regards, -- daniel On 30/11/15 12:28, Hamlin Li wrote: Hi all, Would you please help to review for http://cr.openjdk.java.net/~mli/8144214/webrev.00/,

Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

Hi Hamlin, You should probably create a new open RFE for pushing this new test. I'm not sure we can use internal task ids in commit/push comments. From looking at the test, it would be preferable to create the loggers after setting up the stub that pretend that the VM is not yet booted. In

Re: Deprecation of LogRecord.getMillis in JDK9

is the appropriate thing to do :-) best regards, -- daniel s'marks On 11/30/15 10:20 AM, Daniel Fuchs wrote: On 30/11/15 18:43, Roger Riggs wrote: Hi Daniel, I think it makes sense to keep getMillis (and document it) as a convenience method. Thanks Roger, Jason, I logged https

Re: Code Review for JEP 259: Stack-Walking API

On 17/11/15 01:13, Mandy Chung wrote: I’d like to get the code review done by this week. I renamed the static factory method from create to getInstance since “create” implies to create a new instance but the method returns a cached instance instead. I also changed the spec of getCallerClass

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Alexander Fomin <alexander.fo...@oracle.com> Sent: Friday, November 20, 2015 7:48 AM To: core-libs-dev@openjdk.java.net; Daniel Fuchs; mandy.ch...@oracle.com Subject: JDK 9

Re: JDK 9 RFR [8137005]: java.util.logging.Formatter#formatMessage() swallows Exceptions

ich is already a violation of the spec. It pains me to say it but, as long as you don't break the SLF4J bridge handler then you have covered most of the JUL users. Jason From: Daniel Fuchs <daniel.fu...@oracle.com> Sent: Friday, November 20, 2015 9:32 AM

Re: RFR: JDK-8140364: JEP 264 Platform Logger API and Service Implementation

On 18/11/15 02:56, Mandy Chung wrote: On Nov 3, 2015, at 12:12 PM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi Mandy, I have pushed an update that adds the diagnosability tweaks you asked me for in LoggerFinderLoader. I also added a couple of new tests. No changes in t

Re: Code Review for JEP 259: Stack-Walking API

On 20/11/15 03:13, Mandy Chung wrote: Cross-posting to core-libs-dev. Delta webrev incorporating feedback from Coleen and Brent and also a fix that Daniel made: http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.03-delta/ Full webrev:

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

21:45, Alan Bateman wrote: On 19/11/2015 18:36, Daniel Fuchs wrote: Hi Miran, I would expect this to fail horribly - you may not have the right to create anything under $JAVA_HOME/conf - it may even be a read-only file system... And I would be very uneasy as this may have side effects on tests

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

On 19/11/15 18:31, Miroslav Kos wrote: Hi Lance, I added jtreg test(s) - http://cr.openjdk.java.net/~mkos/8131334/jdk.01/index.html There are several scenarios being tested, all without/with SM. The test preparation I am doing in java (based on test args), so the test creates/deletes

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Hi Joe, On 1/13/16 2:06 AM, Joseph D. Darcy wrote: Hi Iris, Catching up on old reviews, the regular expression for versions is given as ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$ Is this equivalent to ^[1-9][0-9]*(\.[0-9])* Iris's regexp will disallow trailing .0 9.0.1 will match,

Re: Review request: JDK-8157892: StackFrame::getFileName returns null when a source file exists for native methods

Hi Mandy, Looks good to me. Though I wonder whether a better fix would be to not tweak the bci for native methods in the native call that sets the value to 0 (I assume this is what happens somewhere since bci is initialized to -1 in Java). best regards, -- daniel On 01/06/16 20:46, Mandy

Re: RFR: 8153666: Optimize Formatter.formatMessage

Thanks Roger. Here is an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8153666/webrev.01 best regards, -- daniel On 08/06/16 15:56, Roger Riggs wrote: +1 On 6/8/2016 10:37 AM, Daniel Fuchs wrote: On 08/06/16 15:35, Roger Riggs wrote: Yes, I would update the spec to the new

Re: 8153666: Optimize Formatter.formatMessage

anks, Jason From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of Daniel Fuchs <daniel.fu...@oracle.com> Sent: Wednesday, June 8, 2016 8:46 AM To: core-libs-dev Subject: RFR: 8153666: Optimize Formatter.formatMessage Hi, Please find below a patch

Re: RFR: 8153666: Optimize Formatter.formatMessage

Thanks Roger. Here is an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8153666/webrev.01 best regards, -- daniel On 08/06/16 15:56, Roger Riggs wrote: +1 On 6/8/2016 10:37 AM, Daniel Fuchs wrote: On 08/06/16 15:35, Roger Riggs wrote: Yes, I would update the spec to the new

Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi Ramanand, Thanks for looking into this. 1. FileHander.java: 94 *handler-name.append 95 *specifies whether the FileHandler should append onto 96 *any existing files (defaults to false). 97 *java.util.FileHandler.maxLocks 98 *specifies the

Re: Review request: JDK-8157892: StackFrame::getFileName returns null when a source file exists for native methods

Hi Mandy, On 6/3/16 12:55 AM, Mandy Chung wrote: On Jun 2, 2016, at 3:11 PM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > > Hi Mandy, > > Looks good to me. Though I wonder whether a better fix would be > to not tweak the bci for native methods in the native call that >

RFR: 8153666: Optimize Formatter.formatMessage

Hi, Please find below a patch for a small optimization in Formatter.formatMessage. This patch also removed the synchronized keyword which was there for historical reasons - but which has become needless. More background available at: https://bugs.openjdk.java.net/browse/JDK-8153666 (thanks

Re: RFR: 8153666: Optimize Formatter.formatMessage

is out of sync with the implementation (the implementation is more lenient) and has been for a while. According to the spec/javadoc; no formatting should occur unless it contains "{0" Roger On 6/8/2016 9:46 AM, Daniel Fuchs wrote: Hi, Please find below a patch for a small op

Re: RFR: 8153666: Optimize Formatter.formatMessage

On 6/8/2016 10:31 AM, Daniel Fuchs wrote: Good point Roger! I was already wondering whether looking for {[0-9] instead of {[0-3] deserved a small mention in the release note. The fact that the spec needs updating confirms that this little behavior change probably needs to be mentioned.

Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

net/~rpatil/8153955/webrev.01/ FileHander.java and logging.properties files are updated as per Daniel's suggestion. Regards, Ramanand. -Original Message- From: Daniel Fuchs Sent: Wednesday, June 08, 2016 6:57 PM To: Ramanand Patil; core-libs-dev@openjdk.java.net Subject: Re: RFR: 81

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

On 27/05/16 15:47, Roger Riggs wrote: Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match that to the valid patterns. The use of numeric

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

s ) throws JAXBException In this scenario, appropriate static method is used instead of instance method. This approach is incompatible with ServiceLoader so it can't be used with step 3. Thanks, Georgiy. On 21.06.2016 20:39, Daniel Fuchs wrote: Hi, Please find below a somewhat tr

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

, -- daniel On 21/06/16 07:57, Daniel Fuchs wrote: Hi Hamlin, There's no difference in behaviour - mergeConfigWithSystemPeer is called unconditionally but the handlers from the application logger will be copied in the system logger config only if the system's logger list is empty - just like before

Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

To: Ramanand Patil; Daniel Fuchs; Bernd Eckenfels; core-libs-dev@openjdk.java.net Subject: Re: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access Looks fine Ramanand. Please ensure the CCC is approved before pushing. 2 comments on the testcase

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Hi Mandy, On 21/06/16 20:51, Mandy Chung wrote: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation https://bugs.openjdk.java.net/browse/JDK-8150173 Patch:

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi Hamlin, On 22/06/16 02:40, Hamlin Li wrote: Just another minor comment, I'm not sure if following line is necessary in Logger.java, as it's already been checked in LogManager.java line 577: 439 if (cfg == other) return cfg; Yes, you're right - but it makes sense for the method to have it

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

iy. On 21.06.2016 20:39, Daniel Fuchs wrote: Hi, Please find below a somewhat trivial patch for 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation https://bugs.openjdk.jav

RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

Hi, Please find below a patch for: 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code. Issue: https://bugs.openjdk.java.net/browse/JDK-8150173 Patch:

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

On 21/06/16 16:12, Mandy Chung wrote: On Jun 21, 2016, at 4:54 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi Hamlin, I was mistaken in my first assessment. The case where the system handler's list is not empty should only happen if by misfortune two different threads

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Hi Georgiy On 23/06/16 13:48, Georgiy Rakov wrote: Hi Daniel, if I understand correctly JAXBContextWithSubclassedFactory is supposed to capture the idea of Test9 but it doesn't. FactoryBase shouldn't implement JAXBContextFactory but Factory should: public static class FactoryBase {

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Hi, Here is the new webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8150173/webrev.03/ On 23/06/16 14:55, Daniel Fuchs wrote: if I understand correctly JAXBContextWithSubclassedFactory is supposed to capture the idea of Test9 but it doesn't. [...] Oh - I see, I missed that - I was chasing

Re: RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.

handlers configured from the logging.properties file then the user handlers are going to be garbage collected before being closed - which is not ideal - even if it should rarely happen. Let me think on it. best regards, -- daniel Thank you -Hamlin On 2016/6/21 0:34, Daniel Fuchs wrote: Hi, Please

Re: RFR: 8150173: JAXBContext.newInstance causes PrivilegedActionException when createContext's declared in absract class extended by discovered JAXB implementation

Thanks Georgiy! On 24/06/16 11:25, Georgiy Rakov wrote: After some thoughts I agree, redefining createContext would just check that reflection deals with methods overriding properly. BTW if a factory is an instance of JAXBContextFactory it would seem more natural to invoke createContext by

Re: RFR 9: 8160278 Remove java/time/test/java/time/TestClock_System from the problem list

+1 -- daniel On 6/24/16 8:13 PM, Roger Riggs wrote: Please review removing TestClock_System from the problem list for Solaris. The underlying issue[3] has been fixed and propagated to jdk9 and this test can be re-enabled. 8157175 GetNanoTimeAdjustment.java fails with excessive adjustment

Re: Review Request: JDK-8159524 jdeps -jdkinternals throws NPE when no replacement is known

Hi Mandy, JdepsTask.java: 616 .filter(e -> e.getValue() != null) is this still needed? I thought the use of optional at line 602 already filtered out the null values. 617 .sorted(Map.Entry.comparingByKey()) I believe you could get rid of

RFR: 8146691: @since 9 tag missing for System.getLogger

Hi, Please find below a trivial fix for 8146691: @since 9 tag missing for System.getLogger https://bugs.openjdk.java.net/browse/JDK-8146691 best regards, -- daniel --- old/src/java.base/share/classes/java/lang/System.java 2016-01-08 16:45:12.0 +0100 +++

Re: RFR 9: JDK-8146028 : Common Cleaner for finalization replacements in java.base

On 08/01/16 16:51, Roger Riggs wrote: Webrev for removed finalizers: http://cr.openjdk.java.net/~rriggs/webrev-rmfinalizers-8146567/ Looks good to me Roger! best regards, -- daniel

RFR: 8146665: Test jdk/test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java fails - missing expected output

Hi, Please find below a tentative fix for: 8146665: Test jdk/test/java/util/logging/LogManager/Configuration/updateConfiguration/UpdateConfigurationTest.java fails - missing expected output https://bugs.openjdk.java.net/browse/JDK-8146665 Webrev:

Re: Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

Christoph On 7/28/2015 10:32 AM, Daniel Fuchs wrote: /On 28/07/15 19:20, huizhe wang wrote:/ /Hi Daniel,/ // // /On 7/28/2015 8:22 AM, Daniel Fuchs wrote:/ /Hi,/ // /Please find below a fix for yet another cleanup for jaxp:/ // /Thanks for yet another cleanup

Re: RFR 9: 8146773 java/lang/ref/CleanerTest.java CleanerTest.testRefSubtypes() fails

Hi Roger, Looks good to me - but I'd suggest to call fullGC at least once before waiting on the semaphore (e.g. add a call to whitebox.fullGC() when entering checkCleaned() before line 285). That might maximize the chances that the referred object will be GC'ed before you start waiting on the

Re: RFR 9: 8146773 java/lang/ref/CleanerTest.java CleanerTest.testRefSubtypes() fails

On 01/02/16 15:47, Roger Riggs wrote: The number of cycles was scaled by the timeoutFactor but it is more intuitive to scale the timeout itself. checkCleaned is invoked for cases where the cleanup function will not be called so increasing the timeout will just increase the running time of the

RFR: 8150533 - Test java/util/logging/LogManagerAppContextDeadlock.java times out intermittently.

Hi, Please find below a simple fix for 8150533 - Test java/util/logging/LogManagerAppContextDeadlock.java times out intermittently. This is a test bug. The issue is that the logger created by thread t2 might get garbage collected before the main thread calls LogManager.getLogger(). If that

RFR: 8150856 - Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger

Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8150856 8150856: Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger http://cr.openjdk.java.net/~dfuchs/webrev_8150856/webrev.00 The @param caller clause says that caller

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

Hi Mandy, On 06/03/16 00:29, Mandy Chung wrote: On Mar 4, 2016, at 9:05 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8150840/webrev.01/ Looks okay in general. I’m not a fan of using GetPropertyAction. While it’s convenient as the

Re: RFR 8153123 : Streamline StackWalker code

Hi Brent, This looks good! Thanks for taking care of this one. In http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/hotspot/src/share/vm/prims/jvm.cpp.frames.html 548 objArrayOop fa = objArrayOop(JNIHandles::resolve_non_null(frames)); 549 objArrayHandle frames_array_h(THREAD, fa);

RFR: 8148568: LoggerFinder.getLogger and LoggerFinder.getLocalizedLogger should take a Module argument instead of a Class.

Hi, Please find below a patch that slightly modifies the JEP 264 initial implementation to take advantage of the module system. The change modifies the LoggerFinder abstract service to take the Module of the caller class as parameter instead of the caller class itself. The caller class was used

Re: 8152436: Add a test to verify that the root logger correctly reports the caller's information

subclasses of java.util.logging.Logger when inferring caller information. And then I'll just have to extend the new test to also test this new scenario. best regards, -- daniel Regards, Jason From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf

RFR: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient

Hi, Please find below a patch for: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient https://bugs.openjdk.java.net/browse/JDK-8152606 Now that JDK-8151281 is fixed, java.base module-info.java can be cleaned up to no longer export sun.util.logging to

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

.* properties are only used when java.logging is present, and the jdk.system.logger.* properties when java.logging is not present. best regards, -- daniel On 14/03/16 15:03, Daniel Fuchs wrote: Hi Mandy, On 06/03/16 00:29, Mandy Chung wrote: On Mar 4, 2016, at 9:05 AM, Daniel Fuchs

Re: JAXP default implementation and JDK-8152063

On 24/03/16 15:29, David M. Lloyd wrote: Daniel, I have hacked together a way to use the system class loader (which should be "good enough", I hope), but there is one further problem: org.xml.sax.helpers.XMLReaderFactory does not have a factory method which accepts a class loader like the others

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

On 24/03/16 18:56, Daniel Fuchs wrote: getSimpleFormat should probably check the given key argument is either DEFAULT_FORMAT_PROP_KEY or JUL_FORMAT_PROP_KEY; otherwise throws IAE. Otherwise, this method would pass if key is unexpected key if security manager is absent but fails if security

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

On 24/03/16 18:40, Mandy Chung wrote: On Mar 24, 2016, at 7:52 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi Mandy, Here is the new webrev - I have added comments for the string constants as well as for the permissions passed through to the limited doPrivileged call:

Re: JAXP default implementation and JDK-8152063

Hi David, On 22/03/16 13:53, David M. Lloyd wrote: Am I understanding it correctly that you're pointing the system property to a "proxy" as stated in JDK-8152063, not an actual implementation? So it's sort of a provider-locating mechanism outside of jaxp, that locates the actual

RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

[Resending with a link to the patch] Hi, Please find below a patch for: https://bugs.openjdk.java.net/browse/JDK-8150840 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Coleen, Nice improvement! Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/ 1. StackTraceElement.java Does the new constructor in StackTraceElement really need to be public? Can't we keep that package protected? 2. Throwable.java:902 902 * package-protection for use by

Re: RFR: 8150856 - Inconsistent API documentation for @param caller in System.LoggerFinder.getLogger

On 29/02/16 18:54, Martin Buchholz wrote: You need to delete the orphaned semicolon Thanks Martin! -- daniel On Mon, Feb 29, 2016 at 9:46 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi, Please find below a trivial fix for: https://bugs.openjdk.java.net/browse/JDK-8150856 8

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

property actions instead of anonymous inner classes. static Level getDefaultLevel() { String levelName = AccessController.doPrivileged( new sun.security.action.GetPropertyAction("jdk.system.logger.level", "INFO")); ... Roger On 3/4/2016 6:48 AM, Daniel Fuchs wrote: [R

RFR - 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier)

Hi, Please find below a trivial fix for 8148820: Missing @since Javadoc tag in Logger.log(Level, Supplier) https://bugs.openjdk.java.net/browse/JDK-8148820 This method was added to java.util.logging.Logger in jdk 8, but the @since tag was missing. -- daniel diff --git

RFR: 8152436: Add a test to verify that the root logger correctly reports the caller's information

Hi, Please find below a new test that verifies that JDK-8152389 does not occur in JDK 9. bug: 8152436: Add a test to verify that the root logger correctly reports the caller's information https://bugs.openjdk.java.net/browse/JDK-8152436 Issue being verified by the test:

Re: RFR: 8148568: LoggerFinder.getLogger and LoggerFinder.getLocalizedLogger should take a Module argument instead of a Class.

Hi Mandy, On 08/04/16 22:26, Mandy Chung wrote: On Apr 8, 2016, at 7:52 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi, Please find below a patch that slightly modifies the JEP 264 initial implementation to take advantage of the module system. The change modifies the Logger

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

Hi Mandy, This looks good to me. Regarding final methods, I believe it might be prudent to make toStackTraceElement() final - and possibly also all the getters that call it. It would be imprudent to try to override any of these methods in a subclass without looking at the implementation in the

Re: (S) RFR: 8154710: [Solaris] Investigate use of in-memory low-resolution timestamps for Java and internal time API's

Hi Aleksey, On 29/04/16 12:12, Aleksey Shipilev wrote: On 04/29/2016 01:05 PM, David Holmes wrote: On 29/04/2016 7:50 PM, Aleksey Shipilev wrote: On 04/29/2016 02:09 AM, David Holmes wrote: This change is small in nature but somewhat broad in scope. It "affects" the implementation of

RFR: 8139982 Re-examine java.management dependency on java.util.logging.LoggingMXBean

Hi, Please find below a patch [2] that eliminates a static dependency of java.lang.management on java.util.logging.LoggingMXBean. When JDK-6876135 was fixed, it introduced the PlatformLoggingMXBean interface, and recommended using PlatformLoggingMXBean over LoggingMXBean. However, it left a

RFR: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch

Hi, Please find below a patch for: 8146389: java/util/logging/XMLFormatterDate.java fails during year switch http://cr.openjdk.java.net/~dfuchs/webrev_8146389/webrev.00/index.html https://bugs.openjdk.java.net/browse/JDK-8146389 When JDK-8072645 (java.util.logging should use java.time

Re: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options

Hi Mandy, I played with that a bit (-I/-addmods) and it looks good. 92 main.opt.I=\ 93 \ -I -inverse Analyzes the dependences per other given options\n\ 94 \and then find all artifacts that directly\n\ 95 \

Re: Review request 8153042: jdeps should continue to report JDK internal APIs that are removed/renamed in JDK 9

On 5/20/16 6:21 AM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153042/webrev.00/index.html Several JDK internal APIs have been removed JDK 9. It’d be helpful to continue to flag those internal APIs if they are used by existing libraries. This fix is an interim

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

Hi Ralph, On 10/05/16 19:40, Ralph Goers wrote: 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

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

Hi, On 11/05/16 18:57, Ralph Goers wrote: But my point is that if obtaining the StackFrame and Class could be done so quickly that it wouldn’t add any noticeable overhead we could do that in every Logger.info, debug, etc. call. If we could just get the stack frame index so that we could obtain

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

Hi Ralph, On 11/05/16 18:14, Ralph Goers wrote: You are correct that most of the time it would be faster to start from frame 0. However, the problem we have with walking the stack from frame 0 is that it is possible to have a situation like

Re: Review request for JDK-8156680: jdeps implementation refresh

Hi Mandy, I had a look at the first webrev. Code reorganization in some of the files makes it difficult to follow what is going on. I will try to import the changes in my local workspace tomorrow and play with it a bit. I have two small comments so far: On 11/05/16 02:12, Mandy Chung wrote:

Re: Review request for JDK-8156680: jdeps implementation refresh

On 11/05/16 02:12, Mandy Chung wrote: JDK-8153481: tools/jdeps/modules/GenModuleInfo.java and ModuleTest.java fails intermittently Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153481/webrev.00/ Mandy second webrev above looks good. best regards, -- daniel

Re: Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options

Hi Mandy, I am a bit surprised that the verbose option doesn't seem to have any effect on the output of jdeps -I I have built 4 jars: unsafe.jar has some class that depend directly on sun.misc.Unsafe, and some that don't. indirect.jar has some classes that depends indirectly

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

hod1? But maybe I misunderstood. Best regards, -- daniel Ralph On May 11, 2016, at 10:20 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi, On 11/05/16 18:57, Ralph Goers wrote: But my point is that if obtaining the StackFrame and Class could be done so quickly that it wouldn’t add

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

Hi Joe, This look good but the implementation might be overly complex, which makes it difficult to read. First: 141 ClassLoader cl = ss.getContextClassLoader(); is misnamed, because as far as I can see this method returns the context class loader if not null, otherwise the system

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

Hi Stuart, It will be good to have really immutable collections! But I have one comment: I wonder about serial interoperability with earlier versions of the JDK. For instance it will not be possible to send a Set created with Set.of(...) in JDK 9 to a JDK 8 VM. I wonder if there is any good

<    1   2   3   4   5   6   7   8   9   10   >