Re: RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()

On 28/04/15 09:59, Peter Levart wrote: On 04/27/2015 10:05 PM, David Holmes wrote: The patch proposes to use a Reantrant lock to deal with configurations changes in reset() and readConfiguration(), and avoids lock contention in initializeGlobalHandlers()

Re: RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()

: On 04/30/2015 04:42 PM, Daniel Fuchs wrote: On 28/04/15 17:46, Peter Levart wrote: On 04/28/2015 04:57 PM, Daniel Fuchs wrote: Here's my attempt at simplifying this: http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/ LogManager can be subclassed

Re: RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()

run a test campaign against it and things looked good there as well. best regards, -- daniel Regards, Peter On 05/04/2015 04:09 PM, Peter Levart wrote: On 05/04/2015 03:46 PM, Daniel Fuchs wrote: On 04/05/15 15:26, Peter Levart wrote: Hi Daniel, Mandy, What about the following: http

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Hi Ivan, On 05/05/15 14:55, Ivan Gerasimov wrote: I converted the SubList into an inner class to make the implementations for AbstractList.SubList and ArrayList.SubList similar. It might be not worth doing so, but I thought it would be easier to maintain those classes, if they have similar

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

On 06/05/15 11:41, David Holmes wrote: I don't think you want to de-synchronize the load* methods - you don't want two threads calling load concurrently. But that then raises the problem of concurrent modification while a load is in progress. Synchronization ensures serialization and by removing

Re: RFR: JDK-8074002 java.time.ZoneId.systemDefault() should be faster

Hi Peter, The logic looks good to me. But I'm not an expert of the field, despite my small incursions :-) I wish we didn't have to do defensive cloning - but I don't see any way around. best regards, -- daniel On 27/04/15 17:26, Peter Levart wrote: Hi, Please review the following

RFR: 8079773: java/util/logging/LogManager/TestLoggerNames.java

Please find below a fix for: 8079773: java/util/logging/LogManager/TestLoggerNames.java The issue arises from a race condition in the test logic. The test calls LogManager.getLoggerNames(), reset, and adds and remove loggers concurrently - mostly for the purpose of validating that no CME will

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Hi Ivan, Have you considered to simply override/change subList(int fromIndex, int toIndex) in SubList and RandomAccessSubList - so that 'l'/'parent' points always to the original root list (instead of being a sublist of sublist of sublist)? It seems to me that overriding sublist to create a

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

On 06/05/15 16:47, Paul Sandoz wrote: n May 6, 2015, at 4:08 PM, Ivan Gerasimovivan.gerasi...@oracle.com wrote: Hello everyone! Here's the second iteration of the fix. BUGURL:https://bugs.openjdk.java.net/browse/JDK-8079136 WEBREV:http://cr.openjdk.java.net/~igerasim/8079136/1/webrev/

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

On 05/05/15 10:58, Ivan Gerasimov wrote: Thank you Daniel for taking look at it! On 05.05.2015 11:14, Daniel Fuchs wrote: Hi Ivan, Have you considered to simply override/change subList(int fromIndex, int toIndex) in SubList and RandomAccessSubList - so that 'l'/'parent' points always

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

Hi Stuart, On 5/14/15 3:44 AM, Stuart Marks wrote: Hi all, Please review this change to optimize a test. Basically the test did string formatting for every assertion, but the string was thrown away if the assertion passed -- the most common case. The change is to do the string formatting

Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

Hi Stuart, That's an RFE I have often wished for :-) I've been wondering whether a static method in the class java.util.Collections would be better, since there already are some conversion methods there - like: public static T EnumerationT emptyEnumeration(); public static T EnumerationT

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

Hi Brent, 1163 @Override 1164 public EnumerationObject keys() { 1165 return map.keys(); 1166 } I wonder if you should use: public EnumerationObject keys() { return Collections.enumeration(map.keySet()); } instead. ConcurrentHashMap.keys() returns an Enumeration which

Re: RFR: 8080608: Missing archive name from jdeps -v -e output if no dependency on other JAR

On 20/05/15 01:44, Mandy Chung wrote: On 05/19/2015 10:02 AM, Daniel Fuchs wrote: Hi, Please find below a patch for jdeps: http://cr.openjdk.java.net/~dfuchs/webrev_8080608/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8080608 : The fix will make sure that jdeps prints instead

Re: RFR [9] 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader

Hi Miroslav, I haven't looked in all details, but this text in JAXBContext.java looks odd to me - it seems that the bullet is repeated twice (or if they differ - the diff must be subtle): lines 241-257 seem identical to lines 259-275 241 * li 242 * Look for resource

RFR: 8080608: Missing archive name from jdeps -v -e output if no dependency on other JAR

Hi, Please find below a patch for jdeps: http://cr.openjdk.java.net/~dfuchs/webrev_8080608/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8080608 The issue is described in JDK-8080608 as follows: I have 2 jars: indirect2.jar: class use.indirect2.UseUnsafeIndirectly2 {

Re: Review Request: 8080815: Update 8u jdeps list of internal APIs

On 21/05/15 02:57, Mandy Chung wrote: This is 8u only fix. https://bugs.openjdk.java.net/browse/JDK-8080815 https://bugs.openjdk.java.net/browse/JDK-8080815 Webrev: http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8080815/webrev.00/

RfR: 8129880 - Cleanup usage of Class.getResource in jaxp

Hi, Please find below a cleanup patch for jaxp: https://bugs.openjdk.java.net/browse/JDK-8129880 8129880 - Cleanup usage of getResource in jaxp Class.getResource(classFile) was used for printing the class location for debuging purposes. CodeSource.getLocation() is a better fit for that.

Re: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

Hi Frank, The proposed changes look good to me. best regards, -- daniel On 24/06/15 09:58, Frank Yuan wrote: Hi, Would you like to have a review for bug https://bugs.openjdk.java.net/browse/JDK-8080266? This bug is caused by jigsaw change, the context class loader can't load internal

Re: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

Hi Frank, I could push it for you. -- daniel On 6/25/15 5:05 AM, Frank Yuan wrote: So, would you like to push the code for me? Best Regards Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Thursday, June 25, 2015 12:57 AM To: Daniel Fuchs Cc: Frank

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

, Daniel Fuchs wrote: Hi, It was brought to my attention that CodeSource.getLocation() might return null. The javadoc is not very clear on the subject, leading me to believe it could not. Here is a trivial change (with some trivial additional cleanup) that adds guards against null before calling

RfR - 8080933: LogManager.demandSystemLogger should accept a 'caller' argument.

Hi, Please find below a fix for https://bugs.openjdk.java.net/browse/JDK-8080933 8080933: LogManager.demandSystemLogger should accept a 'caller' argument. http://cr.openjdk.java.net/~dfuchs/webrev_8080933/webrev.00 LogManager.demandLogger accepts a caller argument which is later used

RFR- 8130238: Remove com.sun.org.apache.xalan.internal.xsltc.cmdline

Hi, Please find below a trivial patch that removes com.sun.org.apache.xalan.internal.xsltc.cmdline This package is not used in the JDK. http://cr.openjdk.java.net/~dfuchs/webrev_8130238/webrev.00/ Jaxp tests passed locally (jaxp/test, jdk/test/javax/xml/jaxp) JCK for XML APIs also passed.

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

On 29/06/15 20:06, huizhe wang wrote: Maybe it's better to live with PrivilegedActionClassLoader and PrivilegedActionString instead? I'm using NetBeans 8.0.2, it looks like it doesn't support source level beyond JDK 1.8. It's a bit bothersome to have red flags. Plus, we won't be able to build

Re: RFR: 8130051 Cleanup usage of reflection in jaxp

for the review! best regards, -- daniel Thanks, Joe On 6/29/2015 4:17 AM, Daniel Fuchs wrote: Hi, Please find below a patch that cleans up some of the reflection usage in jaxp. https://bugs.openjdk.java.net/browse/JDK-8130051 http://cr.openjdk.java.net/~dfuchs/webrev_8130051/webrev.00

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

Thanks Paul. I have another cleaner patch coming - I'll include those changes as well. -- daniel On 29/06/15 11:13, Paul Sandoz wrote: On Jun 29, 2015, at 10:35 AM, Daniel Fuchs daniel.fu...@oracle.com wrote: On 29/06/15 10:06, Paul Sandoz wrote: That's odd i would of expected it to work

Re: RFR - 8129956: jaxp: CodeSource.getLocation() might return null

On 29/06/15 11:13, Paul Sandoz wrote: NetBeans didn't suggest replacing with diamonds either - which it usually does - but then maybe it was busy scanning classpath;-) This is a relatively new 9-based language feature, so i don't expect the IDEs have caught up yet (IntelliJ 15 EAP has not for

Re: RFR: 8080608: Missing archive name from jdeps -v -e output if no dependency on other JAR

On 21/05/15 02:09, Mandy Chung wrote: Actually - I think the test should be type != Type.SUMMARY rather than type == Type.VERBOSE. jdeps has -filter:none option. $ jdeps -s -filter:none -e use.unsafe.UseUnsafeClass *.jar When -filter:none is used, I think it’s right for the summary page

Re: RFR(s): 8072726: add adapter to convert Enumeration to Iterator

On 19/05/15 12:07, Paul Sandoz wrote: Should anything be said also about default remove() method inherited from Iterator interface? Are custom asIterator() implementations allowed to return an Iterator that implements remove() in a way that actually removes elements? Since this method

RfR - 8130649: java/util/logging/LoggingDeadlock2.java times out

Please find below a changeset to address: 8130649: java/util/logging/LoggingDeadlock2.java times out https://bugs.openjdk.java.net/browse/JDK-8130649 The proposed changeset doesn't fix the issue but instruments the test a bit more so that we can get a clue of what is happening.

Re: RFR: 8130051 Cleanup usage of reflection in jaxp

Hi Joe, Paul, On 30/06/15 10:47, Daniel Fuchs wrote: OK - I will replace the offending diamonds before pushing. On 30/06/15 10:49, Paul Sandoz wrote: I am beseech you not to do that! Unless there is a really strong reason why JAXP 8 code should be the same as JAXP 9 code we should be able

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with RuntimeException: Error: poll() returned null; expected ref object

On 30/07/15 13:37, Peter Levart wrote: poll() returning null by itself is not surprising, but if 'r' appears to be enqueued before and after the fact, this is surprising. Agreed - not disputing this. The question for me is whether this should be fixed in the same changeset - or whether we

Re: RfR - 8130058: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/Process.java

will use its own dummy ErrorHandler if it can't managed to instantiate the internal class. This way - we can keep the test :-) best regards, -- daniel On 29/07/15 17:02, Daniel Fuchs wrote: Hi, Please find below a patch that removes a bunch of unused files in jdk9/dev/jaxp: https

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with RuntimeException: Error: poll() returned null; expected ref object

I vote for 1. :-) cheers, -- daniel On 7/30/15 9:54 PM, Kim Barrett wrote: On Jul 30, 2015, at 8:09 AM, David Holmes david.hol...@oracle.com wrote: On 30/07/2015 9:57 PM, Peter Levart wrote: 'r' has been enqueued. Thread-1: r.isEnqueued() q.poll() == null r.isEnqueued() Thread-2:

Re: RFR [9] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

Hi Alexander, I had a look at http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and there's nothing that caught my eye. However - it would be good if you could generate a specdiff so that we could verify that no mistake has crept in. best regards, -- daniel On 03/08/15

Re: RFR [9] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

Hi Alexander, src/java.base/share/classes/java/io/File.java 1. - * blockquotett - * new File(/ttinbsp;f/itt.{@link #toURI() toURI}()).equals(/ttinbsp;f/itt.{@link #getAbsoluteFile() getAbsoluteFile}()) - * /tt/blockquote + * blockquote + * {@code new File(f.}{@link +

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with RuntimeException: Error: poll() returned null; expected ref object

Hi Kim, I agree with your proposed fix. I see that you have added a comment for future maintainers. Thanks for that - as the implication of the ordering between the two volatile writes is not immediately perceptible to the casual reader. You have good eyes - I hadn't spotted the race

RfR - 8130059: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

Hi, Please find below a fix for yet another cleanup for jaxp: 8130059: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java https://bugs.openjdk.java.net/browse/JDK-8130059 http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/

Re: RfR - 8130059: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

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! And, there is a lot more to come :-) 8130059: jaxp: Investigate removal of com/sun/org/apache/xalan

Re: RFR [9] 8132877: docs: replace tt tags (obsolete in html5) for java.naming

the web-page): http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html sdiff out (0 changes at the moment): http://cr.openjdk.java.net/~avstepan/8132877/specdiff.01/overview-summary.html Looks good for me then. best regards, -- daniel Regards, Alexander On 8/4/2015 11:56 AM, Daniel

Re: RFR [9] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

On 03/08/15 11:31, Alexander Stepanov wrote: Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8132468 Just some cleanup for docs (replacing obsolete tt/tt). Thanks, Alexander Hi Alexander,

Re: RfR - 8130058: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/Process.java

On 30/07/15 18:16, huizhe wang wrote: On 7/30/2015 9:08 AM, Daniel Fuchs wrote: On 30/07/15 17:55, huizhe wang wrote: Hi Daniel, On 7/30/2015 6:38 AM, Daniel Fuchs wrote: Hi, Please find below an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/ Looks good

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with RuntimeException: Error: poll() returned null; expected ref object

On 31/07/15 00:56, Kim Barrett wrote: On Jul 30, 2015, at 5:33 PM, David Holmes david.hol...@oracle.com wrote: So I think I can either: 1. Go ahead with my change + Peter's change. 2. Give this back to core-libs while I step carefully away :-) I *think* option (1) is at least an

Re: RfR - 8130058: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/Process.java

On 30/07/15 17:55, huizhe wang wrote: Hi Daniel, On 7/30/2015 6:38 AM, Daniel Fuchs wrote: Hi, Please find below an updated webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.01/ Looks good to me. The only nit is it seems createDefaultErrorHandler method is a dup

RfR - 8132550: java/util/logging/LoggingDeadlock2.java times out

Hi, Please find below a fix for: https://bugs.openjdk.java.net/browse/JDK-8132550 8132550: java/util/logging/LoggingDeadlock2.java times out I was able to reproduce the deadlock consistently by inserting some Thread.sleep() statements at the critical places. The webrev still shows that (as

RfR - 8130058: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/Process.java

Hi, Please find below a patch that removes a bunch of unused files in jdk9/dev/jaxp: https://bugs.openjdk.java.net/browse/JDK-8130058 8130058: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/Process.java http://cr.openjdk.java.net/~dfuchs/webrev_8130058/webrev.00/

Re: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with RuntimeException: Error: poll() returned null; expected ref object

Hi Peter, I'm glad you're looking at this too! We can't have too many eyes :-) On 30/07/15 10:38, Peter Levart wrote: Suppose we have a Reference 'r' and it's associated ReferenceQueue 'q'. Currently it can happen that the following evaluates to true, which is surprising: q.poll() == null

Re: RFR [9] 8132468: docs: replace tt tags (obsolete in html5) for java.io, java.lang, java.math

of File.toURI() it appears that the resulting code is now malformed, so there's clearly an error here. You and Daniel Fuchs had an exchange about this a bit earlier. I suspect the reason for the nbsp; that appears between the opening parenthesis and the italic 'f' is so that the tail of the 'f

Re: RFR [9] 8133040: docs: replace tt tags (obsolete in html5) for java.management

Hi Alexander, Cursory inspection of the patch file has not revealed anything wrong. Specdiff looks OK, so that's good for me. best regards, -- daniel On 05/08/15 19:37, Alexander Stepanov wrote: javax.management - one (expected) change in TabularDataSupport: (full package diff:

Re: RFR 9: 8133022: Instant.toEpochMilli() silently overflows

Hi Roger, Not a math expert, but this looks good to me :-) best regards, -- daniel On 06/08/15 17:33, Roger Riggs wrote: Please review a small fix and test for Instant.toEpochMilli ArithmeticOverflow. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/ Issue:

RFR: 8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java

Hi, Please find below a patch that fixes 8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java https://bugs.openjdk.java.net/browse/JDK-8132256 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8132256/webrev.00 The class

Re: RFR 8131052 Documentation of AbstractSpliterator refers to forEach rather than forEachRemaining

On 13/07/15 11:19, Paul Sandoz wrote: Hi Stefan, thanks. See below for a patch to the documentation of all abstract spliterators. Looks good to me Paul. best regards, -- daniel Paul. diff -r a3175de2e354 src/java.base/share/classes/java/util/Spliterators.java ---

Re: RFR 8131052 Documentation of AbstractSpliterator refers to forEach rather than forEachRemaining

On 16/07/15 12:00, Daniel Fuchs wrote: On 13/07/15 11:19, Paul Sandoz wrote: Hi Stefan, thanks. See below for a patch to the documentation of all abstract spliterators. Looks good to me Paul. Sorry - re reading my mail I see that you have an extreneous '}' at the three last places - just

Re: [9] RFR 8129833: Need basic tests for rmic

On 13/07/15 14:53, FELIX YANG wrote: Hi Daniel, please help to review the change for 8129833. Issue:https://bugs.openjdk.java.net/browse/JDK-8129833 Patch:http://cr.openjdk.java.net/~fyuan/felix/8129833/ The patch add a new class to try rmic with. It covers a problem of locating

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

Hi Roger, Peter, On 21/10/15 15:38, Roger Riggs wrote: Hi Peter, I've always assumed that the arguments could not be gc'd at least until the method returns in part because the caller was holding references. But I suppose in a completely inlined case an optimizer might try to make more relaxed

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

that will be ultimately used to commit (8140364): https://bugs.openjdk.java.net/browse/JDK-8140364 On 23/10/15 04:32, Mandy Chung wrote: (sorry for the delay. I realized just now that my reply is not sent … sigh) On Oct 20, 2015, at 2:48 PM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi

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

Hi Mandy, Looking at stackwalk.cpp, I'm puzzled by this comment at line 465: http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.01/hotspot/src/share/vm/prims/stackwalk.cpp.html 463 vframeStream& vfst = anchor.vframe_stream(); 464 if (!vfst.at_end()) { 465 vfst.next(); // skip

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

Hi Mandy, StackFrameInfo.java: 100 public OptionalInt getLineNumber() { 101 ensureMethodInfoInitialized(); 102 return lineNumber != -1 ? OptionalInt.of(lineNumber) : OptionalInt.empty(); 103 } If lineNumber is -2 then empty should probably be returned too. Which

Re: RFR:JDK-8071919 :Add java.time.Clock.tickMillis(ZoneId zone) method

Hi Nadeesh, This looks good to me. Best regards, -- daniel On 11/13/15 8:42 PM, nadeesh tv wrote: Hi , Please see the updated webrev http://cr.openjdk.java.net/~ntv/8071919/webrev.02/ Thanks and Regards, Nadeesh On 11/13/2015 9:23 PM, Roger Riggs wrote: Hi Nadeesh, One suggestion:

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

ll), 178 getLineNumber() .orElse(isNativeMethod() ? -2 : -1)); 179 } best regards, -- daniel On 13/11/15 18:58, Mandy Chung wrote: On Nov 13, 2015, at 9:55 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi Mandy, Stack

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

JDK-8046565-branch http://cr.openjdk.java.net/~chegar/docs/sandbox.html http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/index.html http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/specdiff-api/overview-summary.html On 23/10/15 16:52, Daniel Fuchs wrote: Hi, Please find below

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

. The only difference is that I added tests for verifying the new changes. best regards, - daniel Mandy 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.

Re: Proposed API for JEP 259: Stack-Walking API

Hi Peter, You also get Thread.currentThread().getClass() if you call StackWalker.getCallerClass() from main(). Because who is the caller of main()? cheers, -- daniel On 03/11/15 13:45, Peter Levart wrote: Hi Mandy, Great API. One thing I noticed is method StackWalker.getCallerClass()

Re: RFR 8068887 : java.lang.Throwable could use Collections.emptyList for suppressedException

Hi Vyom, I will push this for you. best regards, -- daniel On 13/10/15 17:39, Mandy Chung wrote: On Oct 14, 2015, at 7:23 PM, vyom wrote: Hi All, Please find the updated code, i fixed the missing space.

Re: RFR: JDK-8046565: Platform Logger API and Service

On 14/10/15 18:13, Mandy Chung wrote: There are other methods having similar @throws that should be updated as well. Yes - sorry - I meant I would do it for the method that takes Object as well. When I started working on this I added a new LoggerPermission class similar to

Re: RFR: JDK-8046565: Platform Logger API and Service

Hi Mandy, On 14/10/15 07:21, Mandy Chung wrote: On Oct 8, 2015, at 5:26 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/webrev.01/ System.Logger Several log methods throws NPE if the level is legible and the parameter is

RFR: JDK-8046565: Platform Logger API and Service

Hi, Please find below the webrev for a first prototype of JEP 264 - Platform Logger API and Service. JEP: http://openjdk.java.net/jeps/264 https://bugs.openjdk.java.net/browse/JDK-8046565 specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html webrev:

Re: RFR: JDK-8046565: Platform Logger API and Service

Hi Stephen, On 15/10/15 12:48, Stephen Colebourne wrote: On 14 October 2015 at 12:20, Daniel Fuchs <daniel.fu...@oracle.com> wrote: On 14/10/15 07:21, Mandy Chung wrote: Several log methods throws NPE if the level is legible and the parameter is null. E.g. * @throws NullPointerExc

Re: RFR: JDK-8046565: Platform Logger API and Service

Hi Mandy, I have integrated most of your comments and updated the api specdiff and webrev (new links), and also pushed the corresponding changes to the sandbox. Thanks for working with me on the API doc! specdiff:

Re: RFR: JDK-8046565: Platform Logger API and Service

Hi Mandy, I have updated the links with the modifications we discussed last Friday: - I have removed the tag @apiNote from System.LoggerFinder - I have relaxed the constraint of what happens if several implementations of LoggerFinder are present - the specification no longer mandate

Re: RFR: JDK-8046565: Platform Logger API and Service

-branch updated as well. Please find answers to some of the points you raised: On 20/10/15 09:10, Mandy Chung wrote: On Oct 19, 2015, at 11:18 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: webrev: http://cr.openjdk.java.net/~dfuchs/8046565/proto.02/webrev/inde

Re: RFR: JDK-8046565: Platform Logger API and Service

19/10/15 20:18, Daniel Fuchs wrote: Hi Mandy, I have updated the links with the modifications we discussed last Friday: - I have removed the tag @apiNote from System.LoggerFinder - I have relaxed the constraint of what happens if several implementations of LoggerFinder are present - the

Re: JEP 264: Platform Logging API and Service

Hi, I have pushed an implementation of the prototype in the sandbox. The branch name is JDK-8046565-branch Instructions for cloning a sandbox branch can be found here: http://cr.openjdk.java.net/~chegar/docs/sandbox.html best regards, -- daniel On 05/10/15 12:54, Daniel Fuchs wrote: New

Re: RFR: 8073519: schemagen does not report errors while generating xsd files

Hi Aleksej, This looks good to me. Some blank lines in the test might make it more readable ;-) best regards, -- daniel On 09/10/15 23:09, Aleksej Efimov wrote: Hello, Please, review the fix for schemagen regression bug [1] in JDK9: The JDK9 (and JDK8 too) version of schemagen doesn't

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi Brian, On 09/10/15 13:41, Brian Goetz wrote: The semantics of require* here was that it should throw if the precondition is violated. That lead to a different naming direction than the current use case, in which null is an expected value rather than an error. Not necessarily - as the

Re: RFR: JDK-8046565: Platform Logging API and Service

Hi, I have updated the materials for the first prototype of JEP 264 - Platform Logging API and Service. I have done some minor editorial changes in the API doc ( null -> {@code null} ) fixed a few minor issues, and added some new tests. Sandbox has been updated. JEP:

Re: Idea to Java ArrayLists

Or Stream.of(1, 2, 3).collect(Collectors.toList()); :-) -- daniel On 09/07/15 19:46, Louis Wasserman wrote: Pavel, what you can do there is new ArrayList(Arrays.asList(1, 2, 3, 4, 5)); On Thu, Jul 9, 2015 at 10:40 AM Pavel Rappo pavel.ra...@oracle.com wrote: Not quite. You don't have the

Re: RFR <8064470 > JNI exception pending in jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c

Hi Vyom, Thanks for taking care of this issue. This looks good to me as well. I can sponsor this change for you. best regards, -- daniel On 01/09/15 10:38, Vyom Tewari wrote: Hi everyone, Can you please review my changes for below bug. Bug: JDK-8064470 : JNI exception pending in

Re: RFR 8080486: JNI exception pending in jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c

Hi Vyom, I'm not a net/JNI expert but what you are proposing looks good to me too. Ivan has already given his assent. Unless I hear objections - or comments from other reviewers, I will sponsor this change and push it for you (I'll wait for Monday). best regards, -- daniel On 02/09/15 15:55,

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Oh - sorry - I hadn't seen Mark question. I will wait until those are resolved... On 07/09/15 19:24, Daniel Fuchs wrote: Hi Vyom, I will sponsor that and push it for you. best regards, -- daniel On 07/09/15 18:52, Alan Bateman wrote: On 07/09/2015 14:08, Vyom Tewari wrote: Hi All

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

Hi Vyom, I will sponsor that and push it for you. best regards, -- daniel On 07/09/15 18:52, Alan Bateman wrote: On 07/09/2015 14:08, Vyom Tewari wrote: Hi All, Please find the latest diff, which contains the latest fix. http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/ I

Re: RFR: 8033661: readConfiguration does not cleanly reinitialize the logging system

Hi Mandy, On 13/09/15 00:44, Mandy Chung wrote: Have you considered keeping the same method name, readConfiguration with the new remapper parameter? The downside is the difference that the reset is not invoked. It might not matter because as you add in @apiNote that the existing

Re: RFR 8073542 : File Leak in jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c

Hi Vyom, I will sponsor your change and push the fix for you. I'll sync up with Rob to check that we don't step on each other's toes. best regards, -- daniel On 16/09/15 16:03, Chris Hegarty wrote: The changes look good to me Vyom. -Chris. On 16/09/15 10:08, Vyom Tewari wrote: Hi All,

Re: RFR: 8033661: readConfiguration does not cleanly reinitialize the logging system

Hi Mandy, Thanks a lot for the feedback! On 13/09/15 00:44, Mandy Chung wrote: On Sep 9, 2015, at 9:55 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: Hi, Please find below a candidate fix for: 8033661: readConfiguration does not cleanly reinitialize the logging system

Re: RFR 8038075 : JNI warnings in jdk/src/share/native/sun/misc/VMSupport.c

Hi Vyom, I will sponsor your change and push the fix for you. best regards, -- daniel On 28/09/15 18:03, Roger Riggs wrote: Hi Vyom, Looks fine. Roger On 9/28/2015 11:46 AM, Vyom Tewari wrote: Hi All, Please review my changes for below bug. Bug: JDK-8038075 : JNI warnings

Re: RFR (JAXP) 8138721 : ElementTraversal: javadoc warning; also, hasFeature shall return true

Looks fine to me Joe. Strange that a trailing '.' could produce such a warning. I have a question however about: (feature.equalsIgnoreCase("ElementTraversal") 128 && (anyVersion 129 || version.equals("1.0")) Does this means that

Re: RFR (jaxp) 8136778: SAXParser: support stopping a parsing process

Hi Joe, The spec for stop says: 561 * This method can be called anywhere from any event method of a SAX 562 * handler. Once called, it does not terminate the parsing process 563 * immediately. Instead, it will continue finishing and returning the 564 * current event,

Re: JEP 264: Platform Logging API and Service

On 20/09/15 15:46, Peter Levart wrote: On 09/18/2015 06:17 PM, mark.reinh...@oracle.com wrote: New JEP Candidate:http://openjdk.java.net/jeps/264 - Mark Hi, What is the purpose of exposing a factory for loggers in the generally exported package (java.lang) and making it standard Java API

RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs

Hi, Please find below a fix for: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs https://bugs.openjdk.java.net/browse/JDK-8137289 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8137289/webrev.00/ There are in fact two failures reports under similar configuration: (slow

Re: JEP 264: Platform Logging API and Service

Hi Ralph, On 20/09/15 07:54, Ralph Goers wrote: I do have some questions on this. Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the implementation? The logging implementation needs to be able to configure itself before logging can realistically be performed. If

Re: JEP 264: Platform Logging API and Service

Hi Ralph, On 30/09/15 18:30, Ralph Goers wrote: What would be preferable is to have the serviceLoader accept “criteria” (which are callbacks) that can evaluate each of the located services based on any additional properties that are included in the properties file and either eliminate them or

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

On 09/09/15 17:54, Mark Sheppard wrote: Hi Vyom, yes, I believe the consensus is to proceed with the changes. OK - I will be pushing them then. best regards, -- daniel regards Mark On 09/09/2015 16:23, Vyom Tewari wrote: Hi Mark, Is it OK to go ahead with the patch as it is, or

RFR: 8033661: readConfiguration does not cleanly reinitialize the logging system

Hi, Please find below a candidate fix for: 8033661: readConfiguration does not cleanly reinitialize the logging system https://bugs.openjdk.java.net/browse/JDK-8033661 http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.00/ LogManager.readConfiguration() presents a number of

Re: RFR: 8033661: readConfiguration does not cleanly reinitialize the logging system

Hi Mandy, On 23/09/15 01:02, Mandy Chung wrote: On 09/22/2015 09:27 AM, Daniel Fuchs wrote: http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.02 Looking quite good. Thanks for making the change. Below are mostly javadoc comments and some minor implementation comments. 1474

Re: RFR: 8033661: readConfiguration does not cleanly reinitialize the logging system

, -- daniel On 17/09/15 06:52, Mandy Chung wrote: On Sep 14, 2015, at 9:25 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote: So with that in mind, I have slightly altered the @apiNotes: in readConfiguration(): * @apiNote {@code readConfiguration} is principally

Re: JEP 264: Platform Logging API and Service

New JEP Candidate: http://openjdk.java.net/jeps/264 Hi I have uploaded an initial prototype specdiff: http://cr.openjdk.java.net/~dfuchs/8046565/proto.01/specdiff-api/overview-summary.html LoggerFinder methods that take a Class caller argument will take a java.lang.reflect.Module callerModule

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

On 12/8/15 1:11 AM, Brian Burkhalter wrote: The only point of the threads is to provoke a race condition so I don’t know that it matters in this case. Nonetheless I updated the test case per the suggestion and verified that it still provokes the failure in the build not containing the patch.

Re: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

Hey Rob, The @run line seems to be wrong in the new test file: 26 * @run main/othervm LdapTimeoutTest cheers, -- daniel On 08/12/15 15:00, Rob McKenna wrote: Hi folks, Hopefully this fix puts this tests' failures to bed. (mind you I've thought that before) Basically I've separated the

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

Hi, Please find below a fix for 8144262: LogRecord.getMillis() method is a convenience API that should not have been deprecated https://bugs.openjdk.java.net/browse/JDK-8144262 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00 specdiff:

Re: Deprecation of LogRecord.getMillis in JDK9

On 02/12/15 02:13, Stuart Marks wrote: I'd recommend making setInstant() be more explicit about the range of Instant values that are allowed, namely those created from Instant.ofEpochMilli(long), which allows ± 292 million years from the epoch. Otherwise the reader is forced to try to understand

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