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

Hi, Please review the updated Webrev at: http://cr.openjdk.java.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:

RFR: 9: 8158274: ProblemList java/nio/file/Files/probeContentType/Basic.java on solaris-sparc

Please review this patch to put Basic.java test in ProblemList for solaris-sparcv9. SeeJDK-8146215 , this test is seen to fail several times on solaris-sparc.JDK-8146215 is targeted to fixed in

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

So does that mean you can't use Java to represent a snapshot (instant) in the past where a leap second existed? On Jun 8, 2016 4:17 PM, "Roger Riggs" wrote: > Hi Paul, > > Java.time defines a day as exactly 86400 seconds; seconds are slightly > elastic as defined > by the

RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev/ http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8146975 the type checking in

Re: RFR: 8153666: Optimize Formatter.formatMessage

Thanks, Daniel. I only gave it a quick look, but Looks Good To Me.

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

Hi Paul, Java.time defines a day as exactly 86400 seconds; seconds are slightly elastic as defined by the clock source (usually the OS and the time servers). Having the time servers smoothly adjust the time around leap seconds has been a successful technique for robust application behavior

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

I might be wrong on this issue, but I think 24 could be valid -- but when (if ever) is the question. Google was the news for their 61 second minute [1] in their "leap minute" adventure. I am not sure how time corrections are always implemented, but if you can have a leap minute, couldn't you also

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

HI Nadeesh, Looking better DateTimeFormatterBuilder: - line 3678: If array[1] == 24, offsetSeconds will be greater that seconds in a day; that's not right. I don't think hour=24 is valid. (and there would be test case(s) for it.) There should be test cases for offsets over the limit

RFR JDK-8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException

Hi, Please help review the change for JDK-8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException JDK-8072582: Scanner delimits incorrectly when delimiter spans a buffer boundary issue: https://bugs.openjdk.java.net/browse/JDK-8139414

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 8158023: SocketExceptions contain too little information sometimes

Christoph, You should not remove conversion codes (platform string to Java String) at JNU_ThrowByNameWithLastError, and you have to add conversion codes at JNU_ThrowByNameWithMessageAndLastError. It seems that you assume strerror returns only ascii characters, but actually not. It depends on

Re: RFR: 8153666: Optimize Formatter.formatMessage

Looks good, Thanks, Roger On 6/8/2016 11:47 AM, Daniel Fuchs wrote: 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

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

Hi Jason, On 08/06/16 15:31, Jason Mehrens wrote: Hi Daniel, Thanks for taking this on. Looks good. This might be a new issue altogether but, if record.getMessage returns null a NPE can be generated during 'catalog.getString' (per RB.handleGetObject contract) or

Re: RFR: 8153666: Optimize Formatter.formatMessage

+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 behavior. What about: * Otherwise, if the string contains {@code "{"} * where {@code } is in {@code [0-9]} * then java.text.MessageFormat is

Re: RFR: 8153666: Optimize Formatter.formatMessage

On 08/06/16 15:35, Roger Riggs wrote: Yes, I would update the spec to the new behavior. What about: * Otherwise, if the string contains {@code "{"} * where {@code } is in {@code [0-9]} * then java.text.MessageFormat is used to format the string. -- daniel On

Re: RFR: 8153666: Optimize Formatter.formatMessage

Yes, I would update the spec to the new behavior. 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

Re: RFR: 8153666: Optimize Formatter.formatMessage

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. I will do the paperwork for the spec change. I

Re: 8153666: Optimize Formatter.formatMessage

Hi Daniel, Thanks for taking this on. Looks good. This might be a new issue altogether but, if record.getMessage returns null a NPE can be generated during 'catalog.getString' (per RB.handleGetObject contract) or 'java.text.MessageFormat.format' (undocumented) It is handled by the catch

Re: RFR: 8153666: Optimize Formatter.formatMessage

Hi Daniel, Looks ok, but... Formatter.java: - line 104: the javadoc says it looks for '{0' but the implementation looks for '{'[0..9] It looks like the spec is out of sync with the implementation (the implementation is more lenient) and has been for a while. According to the

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: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist

Hi Hannes, lower-case thumbs up for both the JDK and Nashorn changes. Best, Michael > Am 08.06.2016 um 13:18 schrieb Hannes Wallnöfer > : > > Please review the following changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 > JDK webrev:

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: RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist

+1 On 6/8/2016 4:48 PM, Hannes Wallnöfer wrote: > Please review the following changes: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 > JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/ > Nashorn webrev:

RFR: 8159031: jjs throws NoSuchFileException if ~/.jjs.history does not exist

Please review the following changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8159031 JDK webrev: http://cr.openjdk.java.net/~hannesw/8159031/jdk/webrev.00/ Nashorn webrev: http://cr.openjdk.java.net/~hannesw/8159031/nashorn/webrev.00/ These are two one-liners that add a file existence

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

Hi all, Please review the following bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8153955 Webrev: http://cr.openjdk.java.net/~rpatil/8153955/webrev.00/ Fix: A new configurable java property- "java.util.logging.FileHandler.maxLocks" is added to the FileHandler which can be set in the

RE: RFR 8158023: SocketExceptions contain too little information sometimes

Hi Kenji, thanks for this very good point. I thought that JNU_ThrowByNameWithLastError just tries to throw the exception manually and if that fails it calls JNU_ThrowByName which basically does the same. But I missed the point that it does the conversion and tries JNU_ThrowByName only as

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

Hi, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.06/ I reused code provided by Stephen and handled the edge cases accordingly Thanks and Regards, Nadeesh On 5/31/2016 7:15 PM, Stephen Colebourne wrote: Where the new patterns are described in Javadoc, there