Re: Logging FileHandler: static locks and hardcoded maximum number

ppuser 366 Feb 19 15:16 app.stdouterr.0.0.log === Thanks for your time on this, Behrooz On Thu, Feb 19, 2015 at 3:01 PM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote: Hi Behrooz, On 19/02/15 13:46, Behrooz Nobakht wrote: The version of Java is irrelevant. We

Re: RFR (S) 8073479: Replace obj.getClass hacks with Objects.requireNonNull

Hi Aleksey, +1 for the java.logging changes :-) I wonder whether there was a subtle reason for calling .getClass() in java.lang.invoke? Maybe class initialization or whatever? best regards, -- daniel On 19/02/15 15:51, Aleksey Shipilev wrote: Hi, Please review and sponsor this cleanup fix:

Re: RFR: 8072645: java.util.logging should use java.time to get more precise time stamps

hat respect. Hope that helps It does! I am grateful :-) Here is the updated webrev. http://cr.openjdk.java.net/~dfuchs/webrev_8072645/webrev.02/ best regards, -- daniel Stephen On 17 February 2015 at 19:33, Daniel Fuchs wrote: Hi, Here is a new webrev - which should contain all the feedbac

Re: Logging FileHandler: static locks and hardcoded maximum number

/core-libs-dev/2015-February/031624.html best regards, -- daniel On Thu, Feb 19, 2015 at 3:56 PM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote: Thanks Behrooz. Could you log an issue for this then? If you can attach a small reproducer it will be helpful. Ther

Re: Logging FileHandler: static locks and hardcoded maximum number

rest for you, I can upload the showcase somewhere such as GitHub. Don't bother with that. Thanks for working on this test case and finding out the actual issue! best regards, -- daniel Thanks, Behrooz On Thu, Feb 19, 2015 at 5:18 PM, Daniel Fuchs <mailto:daniel.fu...@oracle.com>

Re: Review Request: 8073361: Missing doPrivileged in com.sun.xml.internal.bind.v2.ClassFactory

Hi Mandy, On 20/02/15 19:54, Mandy Chung wrote: > This fixes a regression due to JDK-8057645 moving JAXB to ext loader > that was tested before the fix for JDK-8054367 went in jdk9. This > was uncovered after JDK-8057645and JDK-8054367 met. > > The fix is simple. Class.getDeclaredConstructor on

Re: java.time.ZoneId.systemDefalut() overhead

Hi Peter, On 22/02/15 21:21, Peter Levart wrote: Hi, I noticed internal JDK class java.util.zip.ZipUtils uses deprecated java.util.Date API for implementing two methods for converting DOS to Java time and back. I thought I'd try translating them to use new java.time API. Translation was straigh

Re: java.time.ZoneId.systemDefalut() overhead

Hi Peter, On 23/02/15 11:29, Peter Levart wrote: Caching of ZoneId in the defensive clone of defualt TimeZone object would not have a desired effect as the clone is thrown away in each call to ZoneId.systemDefault(). We must get hold of the TimeZone instance that is cached. Another way to do tha

RFR: 8073394: Clock.systemUTC() should return a constant

Hi, Please find below a small patch for 8073394: Clock.systemUTC() should return a constant http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/ best regards, -- daniel

Re: RFR: 8073394: Clock.systemUTC() should return a constant

/webrev_8073394/webrev.01/ -- daniel The rest looks fine. Thanks, Roger On 2/23/2015 12:41 PM, Daniel Fuchs wrote: Hi, Please find below a small patch for 8073394: Clock.systemUTC() should return a constant http://cr.openjdk.java.net/~dfuchs/webrev_8073394/webrev.00/ best regards, -- daniel

Re: java.time.ZoneId.systemDefalut() overhead

On 27/02/15 09:36, Stephen Colebourne wrote: On 26 February 2015 at 23:29, Peter Levart wrote: Here's another variant that doesn't use a back link to base TimeZone: http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/ Yes, thats easier to follow. I think I'd be happy w

RFR: 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can throw arithmetic overflow in toEpochMilli()

Hi, Please find below a patch for: 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can throw arithmetic overflow in toEpochMilli() http://cr.openjdk.java.net/~dfuchs/webrev_8074032/webrev.00/ The issue is that when converting milliseconds to seconds + nanos Instant.ofEpochMilli()

Re: LogManager.readConfiguration doesn't document IAE and NPE.

On 18/03/15 14:56, Jason Mehrens wrote: Daniel, It occurred to me after reading Brian's patch for https://bugs.openjdk.java.net/browse/JDK-8075362 that the LogManager.readConfiguration methods do not document NPE or IAE that can be triggered by Properties.load. Do we need to file a bug just

Re: LogManager.readConfiguration doesn't document IAE and NPE.

Properties.load isn't the best choice of exception; though I can see how it can identify the argument (InputStream) is at fault; I'd have stuck to IOException) $.02, Roger On 3/18/2015 11:16 AM, Daniel Fuchs wrote: On 18/03/15 14:56, Jason Mehrens wrote: Daniel, It occurred to me aft

RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException

Hi, Please find below a fix for 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException https://bugs.openjdk.java.net/browse/JDK-8075810 The proposed fix is to catch the IllegalArgumentException and wrap it in an IOException, since LogManager.readConfigur

Re: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException

change such as this typically should be done as part of an errata/MR (due to change of behavior and it is not that big of an issue). Right, my thinking too. Thanks for sharing your opinion! best regards, -- daniel Best Lance On Mar 24, 2015, at 10:42 AM, Daniel Fuchs mailto:daniel.fu

Re: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException

f behavior and it is not that big of an issue). Right, my thinking too. Thanks for sharing your opinion! best regards, -- daniel Best Lance On Mar 24, 2015, at 10:42 AM, Daniel Fuchs mailto:daniel.fu...@oracle.com>> wrote: Hi, Please find below a fix for 8075810: LogManager.r

RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

Please find below a trivial fix for 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable https://bugs.openjdk.java.net/browse/JDK-7113878 http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.00 best regards, -- daniel

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 26/03/15 13:28, David Holmes wrote: Hi Daniel, On 26/03/2015 10:08 PM, Daniel Fuchs wrote: Please find below a trivial fix for 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable As you say in the bug report, now that the map is always accessed

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 26/03/15 14:43, Peter Levart wrote: On 03/26/2015 01:28 PM, David Holmes wrote: Hi Daniel, On 26/03/2015 10:08 PM, Daniel Fuchs wrote: Please find below a trivial fix for 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable As you say in the bug

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

: david.hol...@oracle.com; core-libs-dev@openjdk.java.net Subject: Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable On 26/03/15 13:28, David Holmes wrote: Hi Daniel, On 26/03/2015 10:08 PM, Daniel Fuchs wrote: Please find below a trivial fix for

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 26/03/15 14:32, Daniel Fuchs wrote: The enumeration of keys returned from the map will be iterated outside of any synchronized block. ConcurrentHashMap makes this safe. I'm happy to report that the test in the webrev [1] fails in ConcurrentModificationException if HashMap is used inste

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 26/03/15 15:18, Peter Levart wrote: On 03/26/2015 02:55 PM, Daniel Fuchs wrote: On 26/03/15 14:43, Peter Levart wrote: On 03/26/2015 01:28 PM, David Holmes wrote: Hi Daniel, On 26/03/2015 10:08 PM, Daniel Fuchs wrote: Please find below a trivial fix for 7113878: LogManager

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 26/03/15 15:18, Peter Levart wrote: Hi Daniel, ...or, if you keep CHM, you might be able to use it for a benefit. You say that retrieving a logger by name is the most frequent operation. If you can prove that moving a statement in addLocalLogger method that publishes the Logger via CHM to th

Re: RFR: 8075810: LogManager.readConfiguration may throw undocumented IllegalArgumentException

ption: http://cr.openjdk.java.net/~dfuchs/webrev_8075810/webrev.02 If I don't hear negative feedback that's what I'm going to present to CCC. best regards, -- daniel On 25/03/15 12:41, Daniel Fuchs wrote: Thanks for the review Jason! On 24/03/15 18:01, Jason Mehrens wrote: Hi

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

Thanks all for your reviews! If I don't hear more then http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/ is what I'm going to push. best regards, -- daniel On 28/03/15 00:39, Martin Buchholz wrote: Claes, Right you are - I stand corrected! On Fri, Mar 27, 2015 at 4:02 PM, Claes

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 30/03/15 16:18, Jason Mehrens wrote: For the test shouldn't you include a test for getLoggerNames to check that if the returned Enumeration is an instanceof Iterator then its remove method must throw an UnsupportedOperationException? That makes it clear as to why you are using Collections.

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

On 27/03/15 22:47, Mandy Chung wrote: On 3/27/15 4:27 AM, Daniel Fuchs wrote: Here is a new webrev - with Peter's suggestion implemented. I also made a few tweaks to the test. http://cr.openjdk.java.net/~dfuchs/webrev_7113878/webrev.01/ This version looks good to me. With this chan

Re: RFR: 7113878: LogManager - namedLoggers should be ConcurrentHashMap instead of Hashtable

Hi Mandy, On 30/03/15 19:10, Mandy Chung wrote: I am aware of that while that synchronize is needed for updating the nodes. As synchronized on removeLoggerRef isn't needed, I'd prefer it be taken out. OK - the new webrev is here. I also updated the test as per Jason's suggestion. http://cr.

Re: JDK 9 RFR of JDK-8078334: Mark regression tests using randomness

On 22/04/15 04:13, Joseph D. Darcy wrote: One goal of marking the tests using randomness is to help root out some remaining intermittent test failures. If one of the randomness tests is observed to fail intermittently, if it has not already been updated to print out the random seed and be able to

Re: JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

On 4/23/15 11:28 PM, Roger Riggs wrote: Hi Peter, Setting the user.timezone property doesn't reset the value returned from getDefaultRef(). You can see the new value through java.util.TimeZone but not through java.time.ZoneId. Its a bad idea to allow the default timezone change and in java.t

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

Hi, Please find below a patch that tries to improve the locking strategy in LogManager. The patch proposes to use a Reantrant lock to deal with configurations changes in reset() and readConfiguration(), and avoids lock contention in initializeGlobalHandlers() http://cr.openjdk.java.net/~dfuchs

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

Hi David, On 4/27/15 3:21 AM, David Holmes wrote: Hi Daniel, On 25/04/2015 3:07 AM, Daniel Fuchs wrote: Hi, Please find below a patch that tries to improve the locking strategy in LogManager. The patch proposes to use a Reantrant lock to deal with configurations changes in reset() and

Re: RFR 9: 8078369: [testbug] java/time/tck/java/time/TCKOffsetTime[now] fails on slow devices

Hi Roger, Looks good to me. I'm surprised that only these tests are failing. IIRC I also had to round up some time comparisons in tests when I increased the resolution of the SystemClock - and I believe I rounded them to only 1 second... Anyway - if they fail we know what to do :-) best regard

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() http://cr.openjdk.java.net/~dfuchs/webr

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

Hi Peter, On 28/04/15 16:07, Peter Levart wrote: Hi Daniel, There is a synchronized (lock) { ... } syntax too. Using a reentrant lock also offers more possibility for evolutions like try locking or timeout locking - which you can't do with a monitor (unless you reinvent ReentrantLock)...

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

Hi Peter, Sorry I didn't reply to your last mail. I still intend to. more on the current mail below... On 30/04/15 13:08, Peter Levart wrote: On 04/28/2015 05:46 PM, Peter Levart wrote: On 04/28/2015 04:57 PM, Daniel Fuchs wrote: Here's my attempt at simplifying t

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

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, and subclasses may override reset() for different pur

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

vart wrote: 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

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

have also 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 follow

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 s

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'

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 struc

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 improveme

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 Gerasimov 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/ > This is cleaner. For

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 b

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 onl

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

On 05/05/15 08:19, Mandy Chung wrote: On 5/4/2015 11:52 AM, Daniel Fuchs wrote: On 04/05/15 16:46, Peter Levart wrote: Hi Daniel, Here it is: http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.04/ Looks good for me Peter :-) Hopefully Mandy will like it too

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

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

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 Enumeration emptyEnumeration(); public static Enumeration enumeratio

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 transf

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: 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 * 242 * Look for resource /META-INF/services/javax.

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 Webrev: http://cr.openjdk.java.net/~mchung/jdk8u/webrevs/8080815/webrev.00/

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 shou

Re: RFR(JDK12/NIO) 8202285: (fs) Add a method to Files for comparing file contents

Hi Joe, The spec reads very well to me. On the implementation side: 114 } else if (nRead1 != nRead2) { 115 int len = Math.min(nRead1, nRead2); 116 // there's always a mismatch when nRead1 != nRead2 117 return totalRead + 118

Re: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList

Looks good to me Dan! Let's see if the errant failure reappear... best regards, -- daniel On 24/09/2018 17:56, Daniel D. Daugherty wrote: Greetings, The following bug was used to ProblemList a couple of tests:     JDK-8209018 ProblemList tests affected by JDK-8208690     https://bugs.open

Re: RFR [12] 8211920: Close server socket and cleanups in test/jdk/javax/naming/module/RunBasic.java

Looks good to me Chris! Push it! Kudos to Chris & Chris ;-) best regards, -- daniel On 09/10/2018 11:20, Chris Hegarty wrote: When the test fails sometimes the output is truncated, or even absent, as the test's sub-process does not complete. This may happen if the client-side encounters an is

RFR [12] - 8211960: broken links in java.util.logging

Hi, Please find below a doc-only fix for: 8211960: broken links in java.util.logging https://bugs.openjdk.java.net/browse/JDK-8211960 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html The original link was intended to refer to java.util.Formatter#syntax, which is i

Re: RFR [12] - 8211960: broken links in java.util.logging

Hi Mandy, On 10/10/2018 16:32, Mandy Chung wrote: On 10/10/18 3:39 AM, Daniel Fuchs wrote: Hi, Please find below a doc-only fix for: 8211960: broken links in java.util.logging https://bugs.openjdk.java.net/browse/JDK-8211960 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev

Re: RFR [12] - 8211960: broken links in java.util.logging

the spec about the formatting is in the SimpleFormatter::format method javadoc. What do you think? I agree, this is probably the better solution: http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.01/index.html best regards, -- daniel On 10/10/18 3:39 AM, Daniel Fuchs wrote

Re: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents

Hi Joe, There are a few places where {@linkplain } should be used instead of {@link }. For instance: 1545 * The two paths locate the {@link #isSameFile(Path, Path) same file}, This should be {@linkplain } - for the record {@link } will format the text as code, {@linkplain } will format

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, Hmmm... Just thinking aloud: Should InputStream provide a safe but non-optimized version of skipNBytes() that does not rely on skip(), and should subclasses that override skip() for performance also be changed to override skipNBytes too if performance improvement can be gained? best r

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

LDAP tests might be applicable. -Rob On 05/09/18 09:53, Daniel Fuchs wrote: Hi Rob, That looks better but I believe that: 1. closed should be volatile since it's read from outside synchronized block 2. it seems there might be a race where the last response received

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi Rob, Looks better to me know. Though I admit that: 53 this.replies = new LinkedBlockingQueue<>(8 * replyQueueCapacity / 10); is still a bit mystifying... Why not use the full replyQueueCapacity provided? That doesn't look strictly equivalent to the highWatermark logic that you

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Hi Rob, LdapCtxFactory.java 187 for (String u : r.getEndpoints()) { 188 try { 189 ctx = getLdapCtxFromUrl( 190 r.getDomainName(), new LdapURL(u), env); 191 } catch (NamingException e) { 192

Re: Review request: JDK-8211122: Reduce the number of internal classes made accessible to jdk.unsupported

Hi Mandy, I won't comment on the approach, though [1] looks more cryptic to me as it includes suspicious native code changes. I skimmed through the patch file at http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8211122/webrev.02/open.patch and haven't noticed anything wrong at first sight. The

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, If skip(n) returns a negative number, e.g. -1, then you might end up skipping more than n bytes (unless skip returning -1 indicates that EOF was reached). Basically, I don't think you can make any guarantee of how many bytes will be skipped if a subclass has an implementation of skip t

[12] RFR: 8213301 - Fix legal headers in jdk logging tests

Hi, Following Chris's lead in the network area, and Jon’s lead in the langtools area, here is a change to remove the "Classpath exception” from several test in the test/jdk logging area. 8213301: Fix legal headers in jdk logging tests https://bugs.openjdk.java.net/browse/JDK-8213301 http://cr.o

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

nyway. best regards, -- daniel On 06/11/2018 15:52, Rob McKenna wrote: Thanks folks, Vyom, I've updated service to be volatile. On 30/10/18 14:25, Daniel Fuchs wrote: Hi Rob, LdapCtxFactory.java 187 for (String u : r.getEndpoints()) { 188 try { 18

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, I am not sure whether you can trust that a skip implementation that returns -1 has actually rewind 1 byte - for instance: http://hg.openjdk.java.net/jdk/jdk/file/44f34d2c3243/src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java#l99 Not sure there's anything th

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, On 07/11/2018 23:37, Brian Burkhalter wrote: http://hg.openjdk.java.net/jdk/jdk/file/44f34d2c3243/src/java.desktop/share/classes/com/sun/media/sound/AudioFloatInputStream.java#l99 The above class is not a descendent of InputStream. In any case, as InputStream and all its “direct kno

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, I like this version better :-) But I wonder if skip(n) returning a negative value (ns < 0) when n has been asserted to be > 0 should be considered as an error, and if an IOException should be thrown? I mean - in which cases can a call to skip(n) returning a negative value for a positi

Re: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec

Hi Joe, I do not see where the new DTDHandler::endDTD methos is called. Is that an oversight or is there more magic? best regards, -- daniel On 14/11/2018 05:18, Joe Wang wrote: Hi, Please review a patch to bring the small footprint parser for java.util.Properties compliant with the specifi

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Hi Brian, This looks good to me now. best regards, -- daniel On 15/11/2018 01:21, Brian Burkhalter wrote: I tend to agree that covering this sort of aberration is probably a good idea. I have updated the patch per the foregoing comments and have also improved the Skip test: http://cr.ope

Re: RFR: XXS: JDK-8213910: Invalid HTML in java.net.http.HttpClient

Looks good to me Jon! Thanks for taking care of that. best regards, -- daniel On 15/11/2018 00:01, Jonathan Gibbons wrote: Please review the removal of two extraneous in HttpClient.java. $ hg diff -R open diff -r 40098289d580 src/java.net.http/share/classes/java/net/http/HttpClient.java --

Re: adding rsockets support into JDK

Hi Lucy, I'm assuming that the classes in questions should eventually have javadoc generated for them in the as a JDK implementation-specific supported API, yes? If so you might want to try and figure out how the javadoc generation of the jdk.httpserver modules is hooked up in the build system -

Re: RFR (JDK 12/java.base) 8213325: (props) Properties.loadFromXML does not fully comply with the spec

sages when things go wrong. But since this is a Properties usage only, it serves the purpose well enough. Updated webrev: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v02/ Previous: http://cr.openjdk.java.net/~joehw/jdk12/8213325/webrev_v01/ Best regards, Joe On 11/14/18, 2:32 AM, D

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

Looks good to me Brian. I never knew whether positive meant >= 0 or > 0 anyway ;-) best regards, -- daniel On 28/11/2018 17:38, Brian Burkhalter wrote: Hello again, One, hopefully final, one sentence change was requested in a comment on the CSR: --- a/src/java.base/share/classes/java/io/Inp

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

at 9:51 AM, Daniel Fuchs wrote: Looks good to me Brian. I never knew whether positive meant >= 0 or > 0 anyway ;-) best regards, -- daniel On 28/11/2018 17:38, Brian Burkhalter wrote: http://cr.openjdk.java.net/~bpb/6516099/webrev.08/

Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes

typo in my previous mail: On 03/12/2018 17:27, Daniel Fuchs wrote: Hi Brian, Looks good to me, though I don't understand the change at line 214: ^^^ 154 sorry for the noise and confusion... -- daniel The comment says: 152 // skip(n) returns negative

Re: RFR 8214971 : Replace use of string.equals("") with isEmpty()

Hi Roger, The changes look good. best regards, -- daniel On 06/12/18 20:04, Roger Riggs wrote: Please review changing string.equals("") to string.isEmpty(). isEmpty is preferred, performs better and is easier to optimize. The change is a literal substitution in all files and only in these m

Re: RFR 8214971 : Replace use of string.equals("") with isEmpty()

Hi Hannes, On 07/12/2018 09:24, Hannes Wallnöfer wrote: Hi Roger, There are quite a few occurrences of the reverse calling pattern "".equals(str) in core libs. This is a bit more tricky because it allows str to be null, but when used following a null/not-null check it could be replaced with

RFR (trivial): 8211093: Default logging.properties sets log level for com.xyz.foo

Hi, Please find below a fix for: 8211093: Default logging.properties sets log level for com.xyz.foo https://bugs.openjdk.java.net/browse/JDK-8211093 Webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8211093/webrev.00 best regards, -- daniel

Re: RFR: 8215281: Use String.isEmpty() where applicable in java.base

Hi Claes, It might read even better if things like: +resultString = !specarg.isEmpty() ? specarg.intern(): opt; were changed into: +resultString = specarg.isEmpty() ? opt : specarg.intern(); best regards, -- daniel On 12/12/2018 16:53, Claes Redestad wrote: Hi, please revi

Re: RFR 8215309 : Convert package.html files to package-info.java files

Hi Roger, Thanks for doing this. The java.util.logging package-info looks good to me. best regards, -- daniel On 12/12/2018 19:03, Roger Riggs wrote: Please review a conversion of some package.html files to package-info.java files. This bunch targets packages:    package com.sun.rowset.pr

Re: RFR 8215309 : Convert package.html files to package-info.java files

Hi Roger, As a side note: http://cr.openjdk.java.net/~rriggs/webrev-package-info-8215309/src/java.smartcardio/share/classes/javax/smartcardio/package-info.java could probably use {@link } instead of and {@code } instead of < > at some places. Similarly the converted java.sql.rowset, java.sql,

Re: RFR: 8215281: Use String.isEmpty() where applicable in java.base

, Daniel Fuchs wrote: Hi Claes, It might read even better if things like: +    resultString = !specarg.isEmpty() ? specarg.intern(): opt; were changed into: +    resultString = specarg.isEmpty() ? opt : specarg.intern(); best regards, I only found this pattern in this file, so incremental

RFR: 8213402: [Testbug] java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates an invalid nest relationship

Hi, Please find below a fix for: 8213402: [Testbug] java/lang/System/LoggerFinder/internal/PlatformLoggerBridgeTest creates an invalid nest relationship https://bugs.openjdk.java.net/browse/JDK-8213402 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8213402/webrev.01/ These tests use a Cu

Re: RFR: 8182992 Typo in DatagramPacket constructor API doc

Hi Roger, On 03/01/2019 17:51, Roger Calnan wrote: + * suitable for retrieving large{@code LONGVARCHAR} values. The JDBC driver will I believe there's still a space missing after `large` in the line above. best regards, -- daniel

[testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference

Hi, Please find below a fix for: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference https://bugs.openjdk.java.net/browse/JDK-8217353 webrev: http://cr.openjdk.java.n

Re: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference

frequency of failures. Re testing in progress... best regards, -- daniel On 24/01/2019 12:14, Lance Andersen wrote: Morning Daniel, The change seems like a good approach Best Lance On Jan 24, 2019, at 6:42 AM, Daniel Fuchs <mailto:daniel.fu...@oracle.com>> wrote: Hi, Please fin

Re: [testbug] RFR: 8217353: java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java fails with Unexpected reference: java.lang.ref.WeakReference

rest looks good. I've chosen a slightly different path and adjusted the number of iterations instead: http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.01 best regards, -- daniel Thanks, -- Igor On Jan 24, 2019, at 4:20 AM, Daniel Fuchs wrote: Thanks Lance. Meanwhile I noticed

[testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive

Hi, Please find below another test fix for: 8195716: BootstrapLoggerTest : Executor still alive https://bugs.openjdk.java.net/browse/JDK-8195716 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8195716/webrev.00/ This test has been seen failing intermittently with -Xcomp and some other combin

Re: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive

sources/loggers are correctly released) are seen failing again. Maybe then a global pass on all these test would be warranted. Thanks for the pointer! It is good food for thoughts :-) best regards, -- daniel On Thu, Jan 24, 2019 at 8:17 AM Daniel Fuchs wrote: Hi, Please find below anoth

Re: RFR (JDK 13/java.xml) 8216408: XMLStreamWriter setDefaultNamespace(null) throws NullPointerException

Hi Joe, I was wondering whether: return Objects.equals(uri, defaultNamespace) would be more appropriate (or not) - given the action taken by setDefaultNamespace above? I mean - what if both uri and defaultNamespace are null? Just double checking - as I have no idea what would be the right

Re: [testbug] RFR: 8195716: BootstrapLoggerTest : Executor still alive

Hi Mandy, Thanks for the review. On 30/01/2019 22:24, Mandy Chung wrote: Looks okay.  This gets quite complicated to verify the executor gets GC'ed.  It may be helpful to add a comment to describe the situation when a new one may be created. I have added some comments: http://cr.openjdk.java.

Re: RFR 8218195: [testlibrary] Diagnostic output for test library ProcessTools

Hi Roger, Looks good to me - although it might hide bugs in Process.waitFor ? best regards, -- daniel On 01/02/2019 16:47, Roger Riggs wrote: Please review the addition of diagnostic output to the test library ProcessTools.executeProcess to aid in diagnosing several unexplained timeouts. It

<    4   5   6   7   8   9   10   11   12   13   >