Re: Time-zone database issues

On Thu, 25 Oct 2018 at 09:37, Andrew Haley wrote: > > On 10/22/2018 11:25 PM, Stephen Colebourne wrote: > > The IANA time-zone database [1] provides details of how time-zones > > change over time. The latest release - 2018f - cannot be processed > > successfully by t

Re: Time-zone database issues

On Tue, 23 Oct 2018 at 09:44, Florian Weimer wrote: > * Stephen Colebourne: > > > No, the day-of-month and day-of-week would remain the same, as the > > time is relative to those dates. > > My expectation is that the values returned by the other methods would >

Re: Time-zone database issues

No, the day-of-month and day-of-week would remain the same, as the time is relative to those dates. I didn't provide that link for IP reasons! Please avoid clicking on the link below! Stephen On Tue, 23 Oct 2018 at 06:45, Florian Weimer wrote: > > * Stephen Colebourne: > > > Fi

Time-zone database issues

The IANA time-zone database [1] provides details of how time-zones change over time. The latest release - 2018f - cannot be processed successfully by the current JDK parser [2]. A workaround exists however unlike previous cases of tzdb incompatibility, this time it makes sense for the JDK parser

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

l/8166138/webrev.03/ > > Thanks, > Pallavi Sonal > > -Original Message- > From: Stephen Colebourne > Sent: Tuesday, September 25, 2018 4:39 PM > To: core-libs-dev > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle > offsets > >

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

ant() method or for DateTimeFormatter.ISO_INSTANT as well ? > > -Original Message----- > From: Stephen Colebourne > Sent: Sunday, September 23, 2018 12:36 PM > To: core-libs-dev > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle > offsets > > Thanks >

Re: [12] RFR: 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values

Thanks, +1 from me (not an OpenJDK reviewer). Stephen On Mon, 24 Sep 2018 at 21:40, Naoto Sato wrote: > > Hi Stephen, > > Thank you for the review. > > On 9/22/18 11:57 PM, Stephen Colebourne wrote: > > The change seems simple enough. > > Does the test prov

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

, Pallavi Sonal wrote: > > Thank you Stephen for your inputs. Based on that, here is the updated webrev > for review : > http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ > > Thanks, > Pallavi Sonal. > > -Original Message- > From: Stephen Colebourne > S

Re: [12] RFR: 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values

The change seems simple enough. Does the test prove the change though? I thought the issue was with months, not years? Stephen On Thu, 20 Sep 2018 at 22:32, Naoto Sato wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8210633 > >

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

/ > > Thanks, > Pallavi Sonal > > -Original Message- > From: Stephen Colebourne > Sent: Thursday, September 20, 2018 2:50 AM > To: core-libs-dev > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle > offsets > > Thanks for looki

Re: RFR - JDK-8203703 String::transform (CSR Review)

On Wed, 19 Sep 2018 at 14:51, Jim Laskey wrote: > HTMLDocument html = ` > > >Hello World. > > > `.transform(HTMLDocument::parse); I

Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

Thanks for looking at this. The proposed fix does not tackle the bug fully. The bug is that the spec says "The format consists of: The ISO_OFFSET_DATE_TIME where ..." As such, the format must parse *any* offset, not just "Z" / "+00:00" etc. In addition, the fix doesn't work properly. Parsers

Re: RFR - JDK-8203703 String::transform (CSR Review)

On Tue, 18 Sep 2018 at 18:57, Jim Laskey wrote: > > Please review the API for String::transform. The goal is to provide a String > instance method to allow function application of custom transformations > applied to an instance of String. > > csr:

Re: 8207690: Parsing API for classpath and similar path strings

On Tue, 11 Sep 2018 at 10:25, Alan Bateman wrote: > On 10/09/2018 21:55, Roger Riggs wrote: > > Nope! there's quoting on Windows that gets short changed with that > > work around. > > > > Other opinions?, Suggestions? > One suggestion is reduce this down to one method that returns a stream >

Re: MethodHandles.Lookup.defineResource?

On Tue, 28 Aug 2018 at 20:43, Peter Levart wrote: > Do you think this functionality is really needed in programs? It seems useful > just for testing. Why do people add classes at runtime? Might they not reasonably want to also add resources for those classes? The key point here is that this

Re: MethodHandles.Lookup.defineResource?

On 28 August 2018 at 08:17, Alan Bateman wrote: > On 28/08/2018 07:55, Peter Levart wrote: > Right, and any class injected with Lookup.defineClass can be located with > methods such as Class.forName or Lookup.findClass. There is no equivalent > for resources, at least not without extending the

Re: MethodHandles.Lookup.defineResource?

ttps://baptiste-wicht.com/posts/2010/05/tip-add-resources-dynamically-to-a-classloader.html thanks Stephen On Mon, 27 Aug 2018 at 07:53, Alan Bateman wrote: > > On 14/08/2018 15:07, Stephen Colebourne wrote: > > A new method MethodHandles.Lookup defineClass() was added recently. &g

MethodHandles.Lookup.defineResource?

A new method MethodHandles.Lookup defineClass() was added recently. But what about a defineResource? For adding a new resource to the classpath (such as a .txt file). I just needed such a thing, and though undoubtedly rare, all the recommended solutions use reflection and setAccessible(). thanks

Re: Deprecate java.io.File or at least some methods

>From what I can see, File is more widely used than Path. Thats partly because using Path is non-obvious - it doesn't have any methods for doing anything. I've suggested before that a default method could be added, so you get path.operations().isReadable() path.operations().readAllBytes()

Re: RFR: 8209120: Archive the Integer.IntegerCache

On 9 August 2018 at 12:33, Claes Redestad wrote: > using the new ability to archive immutable heap graphs into the CDS archive, > even archiving small things like the Integer.IntegerCache can be profitable. Interesting. I did consider caching some instances of `LocalDate` when I was developing

Re: [11] RFR: 8042131: DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate

+1 Stephen On 18 June 2018 at 15:55, Roger Riggs wrote: > Hi Naoto, > > Looks fine > > Regards, Roger > > > > On 6/15/2018 6:14 PM, Naoto Sato wrote: >> >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8042131 >> >> The proposed change

Re: Durations in existing JDK APIs

Without commenting on the proposed implementation below, Future seems like a good place to start. I suspect that ExecutorService and ScheduledExecutorService would also be good targets to enhance. Stephen On Fri, 15 Jun 2018, 18:43 Martin Buchholz, wrote: > > > On Wed, May 30, 2018 at 11:32 AM,

Re: JDK-8042131: Proposal of Mapped-values formatter for non-IsoChronology

>From the looks of it, this is a perfectly reasonable enhancement. Sadly I can't sponsor it as I'm not a committer. Stephen On 15 June 2018 at 10:10, Toshio 5 Nakamura wrote: > > Hello core-libs and i18n folks, > > We'd like to request to reconsider JDK-8042131, > "DateTimeFormatterBuilder

Re: BiCollector

In this form (not locked to Map.Entry) it seems like a candidate for the JDK. The implementation is private, so it would be one public method that provides a new way to process streams. Stephen On 14 June 2018 at 05:56, Tagir Valeev wrote: > Hello! > > In my StreamEx library I created a

Re: Durations in existing JDK APIs

Finally got to check the logic in convert(Duration), and it looks fine to me. All three look good thanks Stephen (not an OpenJDK reviewer). On 6 June 2018 at 18:03, Martin Buchholz wrote: > OK, here is a RFR for low-hanging changes (some of these changes have > already been reviewed by some of

Re: Durations in existing JDK APIs

I'm not convinced TimeUnit::toDuration(long amount) has enough value. We don't have a similar method on ChronoUnit Duration.of(amount, timeUnit.toChronoUnit()) seems sufficient. Maybe document this in the convert(Duration) method? Stephen On 31 May 2018 at 01:19, Martin Buchholz wrote: >

Re: Durations in existing JDK APIs

On 30 May 2018 at 18:15, Kurt Alfred Kluever wrote: > 1. Rename ALL existing unitless primitive method parameters to include > their time unit. This seems like a simple win. AFAIK, parameter names can be changed freely in the JDK. > 2. Add a java.time overload to some APIs ... > Note that new

Re: Durations in existing JDK APIs

On 30 May 2018 at 18:36, Martin Buchholz wrote: > Stephen/Doug: is there any reason we didn't add conversions between Duration > and TimeUnit when we added conversions to ChronoUnit? I don't remember the idea being discussed. The proposed implementation seems reasonable. thanks Stephen >

Re: [11] RFR: 8202088: Japanese new era implementation

The java.time change seems OK to me Stephen On 17 May 2018 at 21:31, Naoto Sato wrote: > Hi, > > Please review the changes to the subject issue: > > https://bugs.openjdk.java.net/browse/JDK-8202088 > > The proposed change is located at: > >

Re: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding

On 30 April 2018 at 09:20, Pallavi Sonal wrote: > Should the PadPrinterDecoratorParsers be allowed to participate in adjacent > value parsing and should this affect both padded followed by non-padded > fields as well as non-padded followed by padded fields ? Since

Re: [11] RFR: 8181157: CLDR Timezone name fallback implementation

I had a quick look through and didn't see anything obvious, but its not an area I know well. Stephen On 17 April 2018 at 22:28, Naoto Sato wrote: > Hello, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8181157 > > The

Re: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding

To add to Roger's comments, the tests should cover parsing as well as formatting. It is the adjacent parsing behaviour that will be most important to test and get right. For example, Pattern "dM" cannot be parsed (is "1122018" the 1st Dec or the 11th Feb?) But this one should be parsed

Re: Raw String Literal Library Support

On 14 March 2018 at 23:05, Michael Hixson wrote: > For example, does ``.lines() produce an empty stream? I believe `` is a compile error. (A mistake IMO, but necessary if you have unlimited delimiters) Stephen

Re: Raw String Literal Library Support

On 14 March 2018 at 23:55, Stuart Marks wrote: > So, how about we define trimLeft, trimRight, and trimWhitespace > all in terms of Character.isWhitespace? This seems like a reasonable approach. I'd expect tab to be trimmed for example. Commons-Lang is a good source to

Re: Weird timezone issues with Timestamp.valueOf(String s)

Just to note that you really need someone from the JDBC maintenance group to comment. However, my understanding is that Timestamp conceptually represents a date and time **without reference to a time-zone**, exactly the same as LocalDateTime. But the implementation is poor, because it stores it

Re: Draft JEP: To use UTF-8 as the default charset for the Java virtual machine.

On 21 February 2018 at 13:37, Alan Bateman wrote: > The proposal is to eventually get to the point that the default charset > cannot be changed. It will take several releases to get there due to the > potential compatibility impact. This seems like a reasonable strategy

Re: RFR: 8197594 - String and character repeat

On 15 February 2018 at 20:52, Louis Wasserman wrote: > Based on this data, I'd recommend providing one and only one method of this > type: String.repeat(int). Only adding the one instance method seems like the best plan in this case. Stephen

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

Is it necessary to add the "String csname" variants at this point in Java's lifetime? Don't most people use instances of Charset now? Stephen On 13 February 2018 at 06:24, Xueming Shen wrote: > Hi, > > Please help review the proposal to add following constructors and

Re: RFR JDK-8194412 : Adding 256 units of IsoFields.QUARTER_YEARS broken

Spelling mistake in tests "qarterYears" Otherwise, looks good. thanks Stephen On 27 January 2018 at 19:37, Ivan Gerasimov wrote: > Hello! > > It was spotted that adding more then 255 quarter-years to a Temporal leads > to a wrong result. > > BUGURL:

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Just to note that JSR-310 had to add a CharSequence comparison method. Not the same as this one, but a data point, and perhaps a target to become public in a future webrev. See DateTimeParseContext.subSequenceEquals(). Stephen On 26 January 2018 at 03:00, Joe Wang

Bug in javac release flag?

I think I have a problem with the java release flag, reported by a user here: https://github.com/ThreeTen/threeten-extra/issues/91 The particular case that is a problem are the new methods on java.lang.Math. Java 8 had these methods: floorDiv(long,long) floorDiv(int,int) Java 9 has these

Re: Microsecond support in java.time.Duration/Instant?

On 22 January 2018 at 02:58, Kurt Alfred Kluever wrote: > I'm curious how these sets of units were chosen or decided upon? I > understand that the line must be drawn somewhere (or else someone may come > along asking for centisecond support), but I'm curious as to the rational.

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On 8 December 2017 at 00:33, Stuart Marks wrote: > Please review this changeset that introduces a new no-arg method > orElseThrow() to Optional, as a preferred alternative to the get() method. I am willing to accept this addition as it has an obvious parallel to the

Re: Add EnumMap.keyType() and EnumSet.elementType()

I'm surprised I've never run into this. This seems like a simple and useful change. Stephen On 7 December 2017 at 11:40, Andrej Golovnin wrote: > Hi all, > > it would be nice if we would have access to the class of the enum type > used to create an EnumMap or an

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

v.06/ > > Naoto > > > On 11/23/17 8:13 AM, Stephen Colebourne wrote: >> >> In DateTimeFormatter line 1508, this would be preferred: >> >>return new DateTimeFormatter(printerParser, locale, ds, >> resolverStyle, resolverFields, c, z); &

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

In DateTimeFormatter line 1508, this would be preferred: return new DateTimeFormatter(printerParser, locale, ds, resolverStyle, resolverFields, c, z); In DateTimeFormatterBuilder.getLocalizedDateTimePattern() there is no spec change wrt using "rg". Should findRegionOverride() just return a

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 19 November 2017 at 03:34, John Rose wrote: > Meanwhile, `toUnmodifiableList` is so ugly to the ear, > eye, and fingers that it will be less used just because of > its long spelling. Many developers are already using Google Guava which has added toImmutableList() and

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

On 21 November 2017 at 01:45, Naoto Sato wrote: >> 2) `DecimalStyle.ofLocale(Locale)` should use "nu" but does not. > > Document it in the javadoc. Javadoc looks good, but the webrev didn't contain matching code last time I looked. >> 3)

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

I've had a longer think about how to integrate this. Its very tricky, as the unicode extensions create complex conflicts. In general, my view is that Locale is too complex and overloaded with different levels of meaning. Perhaps a different class should have been added for more complex

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

On 14 November 2017 at 23:58, Naoto Sato wrote: > So even with the new suggested method, > > formatter.withZone(locale).withLocalization(locale) > formatter.withLocalization(locale).withZone(locale) > > would produce different formatters. Would it be OK, assuming along with

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

I'd missed that this affects java.time.* I believe that the changes to DateTimeFormatter are a mistake and will cause confusion. Currently, each withXxx() method is independent - they do not interact and operate on a single piece of state. Currently, these two pieces of code have the same

Module naming for logging implementations

I've spent some time discussing module names for logging implementations recently: https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs https://issues.apache.org/jira/browse/LOG4J2-2056 https://jira.qos.ch/browse/SLF4J-407?jql=text%20~%20%22jpms%22 Most logging projects are split in

Re: jdk9/10 reject zip/jar files where seconds value of timestamp is out of supported range 0 - 59

On 9 October 2017 at 14:40, Claes Redestad wrote: > In addition to being a cleanup, the move to use java.time did provide a > speedup, however, which > might become significant when loading lots of jar files. > > I've not found my notes on how big this speed-up was (I

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 22 September 2017 at 21:37, Stuart Marks wrote: > On 9/22/17 5:36 AM, Roger Riggs wrote: >> I think more value can be achieved by creating concrete final immutable >> collections >> that applications can use to be certain that the semantics of the >> collection >> are

Re: [10] RFR 8171049: Era.getDisplayName doesn't work with non-IsoChronology

The formatter should be a static constant in both cases - no need to create each time. I would have expected this to be done without using DateTimeFormatter however, just directly calling an internal API. Stephen On 25 August 2017 at 18:43, Naoto Sato wrote: > Hi, >

Executors.newScheduledThreadPool()

I recently fell into the trap of misusing the method Executors.newScheduledThreadPool() despite having read the Javadoc: /** * Creates a thread pool that can schedule commands to run after a * given delay, or to execute periodically. * @param corePoolSize the number of threads

Re: [10] RFR: 8181586: DateTimeTextProvider.getInstance() returns a new instance every time

+1 Stephen On 6 Jun 2017 5:29 p.m., "Naoto Sato" wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8181586 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8181586/webrev.00/ As suggested in

Re: Getting a live view of environment variables (Gradle and JDK 9)

On 18 May 2017 at 09:07, David Holmes wrote: > I'm quite surprised by some of the reactions here. Given the read-once > nature of System.getenv was never documented I expected most people to be > surprised that it took a snapshot-on-first-use, and that reading the actual

Re: Java-Time Clock Implementation Note

I'll let you log the issue, as you'll know what flags to set to get it through the process! Stephen On 16 May 2017 at 15:39, Daniel Fuchs <daniel.fu...@oracle.com> wrote: > Thanks Stephen, > > On 16/05/2017 15:32, Stephen Colebourne wrote: >> >> Its not terrible, b

Java-Time Clock Implementation Note

In JDK 9, the implementation of Clock has been improved to be better than millisecond in most cases [1]. However, I've just noticed that the Javadoc of the "Implementation Note" is now wrong. It says: "The clock implementation provided here is based on System.currentTimeMillis(). That method

Re: RFR 8175013: Add @Generated Annotation

+1, I think retention beyond SOURCE makes sense. Stephen On 16 March 2017 at 15:44, Ron Shapiro wrote: > Are there any plans to make the new @Generated annotation have CLASS > retention? We have a number of compile-time tools that would like to know > when files are

Re: JDK 9: 8174128: [testbug] Remove implementation dependency from java.time TCK tests

+1 Stephen On 7 February 2017 at 20:06, Roger Riggs wrote: > Please review minor changes to the java.time.tck tests to avoid the use of > implementation details and the related opening of the modules. > The testng directive to open needed modules is now specific to the >

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

WeekBasedField > 4781 * will be null during construction. > > Is it OK? > > Thanks and Regards, > Nadeesh > > > Other than that, I'm fine with the changes. > > Roger > > > 2. Changed the behavior of 'e' to parse only 1 digit as suggested by > Steph

Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

Looks good Stephen On 21 Dec 2016 6:31 a.m., "Abhijit Roy" wrote: Hi Roger, I have fixed the same error in DateTimeFormatterBuiler. Please see the updated webrev below. Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ Thanks Abhijit On 12/16/2016

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

In the test provider_adjacentValuePatterns2(), please add {"wwe", Y, w, c, "20161201", 2016, 12, 1}, This should succeed, because a single number is all that is needed to parse day-of-week. (So, it will need to be removed from the invalid patterns test). Line 1869 will need to change to

Re: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era

The overridden method includes full Javadoc and an @since 9 tag. I believe that this Javadoc should not be present and the @since tag is wrong. Stephen On 11 December 2016 at 02:26, Masayoshi Okutsu wrote: > Thank you for the review comments. I realized that only

Re: RFR 9: 8169527 : Typo in getCalendarType() method of Chronology class

+1 Stephen On 29 November 2016 at 18:31, Roger Riggs wrote: > Please review editorial javadoc corrections in java.time.chrono.Chronology. > > Webrev: >http://cr.openjdk.java.net/~rriggs/webrev-typo-8169527/ > > Issue: >

Re: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

Returning the writer was my intention. I also intended it to return a new instance, to avoid changing the variable from final to non-final. Stephen On 23 November 2016 at 13:35, Jonathan Bluett-Duncan wrote: > Hi Patrick, > > Have you considered making `withAutoFlush()`

Re: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction

+1 Stephen On 7 November 2016 at 21:23, Roger Riggs wrote: > Looks good, > > Thanks, Roger > > > > On 11/7/2016 7:27 AM, Bhanu Gopularam wrote: >> >> Thanks Nadeesh. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~bgopularam/8160036/webrev.01 >> >> Thanks,

Re: RFR: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors

These are the current constructors: PrintWriter(Writer) PrintWriter(Writer, boolean) PrintWriter(OutputStream) PrintWriter(OutputStream, boolean) PrintWriter(String) PrintWriter(String, String) PrintWriter(File) PrintWriter(File, String) These are the annoying missing ones (not all of the

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

Meena wrote: > > Thanks for the review! > > Here is the updated webrev > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > -Anubhav > > > On Nov 2, 2016, at 4:04 PM, Stephen Colebourne <scolebou...@joda.org> wrote: > > I agree with Nadee

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

d webrev > http://cr.openjdk.java.net/~ntv/others/anubhav/webrev.01/ > > -Anubhav > > > On Nov 2, 2016, at 4:04 PM, Stephen Colebourne <scolebou...@joda.org> wrote: > > I agree with Nadeesh, the updated code can still throw > DateTimeException from the call to ge

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

I agree with Nadeesh, the updated code can still throw DateTimeException from the call to getLong(). Unlike before, this DateTimeException is desired. Stephen On 28 October 2016 at 16:58, nadeesh tv wrote: > > Hi Anubhav, > > > - * @throws DateTimeException if the

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

+1 Stephen On 12 October 2016 at 19:16, Anubhav Meena wrote: > Hi Roger, > > Thanks for the suggestion, have made the suggested changes and shifted the > tests to /java/time/test/java/time/chrono/TestUmmAlQuraChronology.java. > > Updated webrev: >

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

The indentation in TCKHijrahChronology is not correct. In TCKHijrahChronology, it would be better to add the expected values to the provider ie two additional value for aligned week and aligned day: {1437, 9, 1, 1, 1} {1437, 9, 2, 1, 2} ... That way, the test relies on facts, not on a formula.

Re: DateTimeFormatter.format() uses exceptions for flow control

This looks like it should be a worthwhile improvement. Stephen On 9 October 2016 at 16:24, Clément MATHIEU wrote: > Hi ! > > I noticed that DateTimePrintContext.getValue() relies on exceptions to > handle optionality. Using exceptions for flow control seems both >

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

On 6 October 2016 at 00:00, Stuart Marks wrote: >> I think you should perform no change to DateTimeFormatter (other than >> a comment) as part of this changeset. The behaviour of that >> DateTimeFormatter method is subtle, and I now suspect that what we >> have there

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

On 5 October 2016 at 17:07, Jonathan Bluett-Duncan wrote: > Stephen, thank you for getting back about DateTimeFormatter. It's not clear > to me what should be done with > TCKDateTimeFormatter::test_resolverFields_listOfOneNull in this case. Do I > delete it; or do I

Re: RFR: 8159855

Interesting. How likely is it that there will be more than one tool of a given name available? The method name findFirst() seems relatively odd for the lookup operation. I'd also note that the name string to pass in are "magic". There are no constants defined for callers to use. Since there is

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

On 4 October 2016 at 23:27, Stuart Marks wrote: > 4) The 'resolverFields' problem/comment was regarding DateTimeFormatter (see > this part of latest webrev), where I realised I couldn't use Set.of instead > of Collections.unmodifiableSet(new HashSet<>(Arrays.asList(*))),

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

The date/time changes seem reasonable. Stephen On 14 September 2016 at 21:55, Patrick Reinhart wrote: > Hi Jonathan, > > Here are your changes in a webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 >

Re: RFR: 8164669: Lazier initialization of java.time

Really, we should add a TemporalAmountFormatter to the JDK, but its a bigger piece of work and quite tricky. Stephen On 23 August 2016 at 22:52, Claes Redestad <claes.redes...@oracle.com> wrote: > > > On 2016-08-23 22:52, Stephen Colebourne wrote: >> >> This loo

Re: RFR: 8164669: Lazier initialization of java.time

This looks fine to me. I suspect that we could hand write a parser to avoid the regex, but this probably suffices. Stephen On 23 August 2016 at 19:49, Claes Redestad wrote: > Hi, > > this tiny cleanup reduces number of loaded classes from a minimal test > touching

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

I'm less comfortable with the compareTo change because it may make it slower and that may have knock on effects. I think a comment saying that both are bounded would be enough in compareTo() Stephen On 19 August 2016 at 13:52, Ivan Gerasimov wrote: > Thanks Nadeesh.

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Looks good Stephen On 18 August 2016 at 17:53, Ivan Gerasimov wrote: > Hello everybody! > > The factory methods of ZoneOffset class demonstrate a minor inconsistency. > Normally, invalid values of arguments are rejected (e.g. when minutes > 59), > but the value of

Re: NIO Path enhancements?

Any thoughts on this? Stephen On 8 August 2016 at 18:29, Stephen Colebourne <scolebou...@joda.org> wrote: > I've been using the java.nio.file.Path API in the last few days and > have found it a little tricky to use. I'd like to understand if the > following ideas were ever consider

NIO Path enhancements?

I've been using the java.nio.file.Path API in the last few days and have found it a little tricky to use. I'd like to understand if the following ideas were ever considered (to consider whether an issue should be raised). Currently, developers create a Path instance and it contains various

Re: Why is there no Math.ceilDiv?

On 31 July 2016 at 20:45, Philipp Nowak wrote: > I was wondering why there is no Math.ceilDiv() method, when a floorDiv() > method got added in Java 8 through JDK-8023217 [1]. > > Is there any reason why such method did not get added with floorDiv() floorDiv() was added as

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

the suggestions of Stephen > > Thanks and regards, > Nadeesh > > > > On 7/22/2016 3:38 PM, Stephen Colebourne wrote: >> >> These tests are expected to throw exceptions: >> >> test_strict_appendOffsetId() >> test_strict_appendOffset_1() >> test_s

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

These tests are expected to throw exceptions: test_strict_appendOffsetId() test_strict_appendOffset_1() test_strict_appendOffset_2() test_strict_appendOffset_3() test_strict_appendOffset_4() As such, they should not contain assertEquals(). They should only contain the code that is expected to

Re: RFR: 8153044: Allow a property to control location of tzdb.dat file

I won't block this change, but I remain unenthused. There are other ways to control the time-zone data, and since tzdb.dat is currently a private format file that is part of the internals of the JDK, it seems odd to be exposing it. Having the tzdb.dat as a versioned module that could be replaced,

Re: RFR:JDK-8160681:LocalDate.ofEpochDay input validation

Fine by me, thanks Stephen On 1 July 2016 at 12:38, nadeesh tv wrote: > Hi all, > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681 > > Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating > > Webrev:

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

updated webrev > http://cr.openjdk.java.net/~ntv/8066806/webrev.08/ > > Thanks and Regards, > Nadeesh > > On 6/9/2016 4:29 PM, nadeesh tv wrote: >> >> Hi Stephen, >> >> On 6/9/2016 4:19 PM, Stephen Colebourne wrote: >>> >>> "absHours

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

>>> There should be test cases for offsets over the limit of hours, minutes, >>> and seconds: 24:60:60 >>> >>> Thanks, Roger >>> >>> >>> >>> On 6/8/2016 2:59 AM, nadeesh tv wrote: >>> >>>> Hi, >>

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

gt; There should be test cases for offsets over the limit of hours, minutes, and > seconds: 24:60:60 > > Thanks, Roger > > > > On 6/8/2016 2:59 AM, nadeesh tv wrote: > > Hi, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8066806/webrev.06/ &

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

Where the new patterns are described in Javadoc, there is no discussion of the difference between "H" and "HH". Add after "Patterns containing "HH" will format and parse a two digit hour, zero-padded if necessary. Patterns containing "H" will format with no zero-padding, and parse either one or

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

hanu > > -Original Message- > From: Stephen Colebourne [mailto:scolebou...@joda.org] > Sent: Tuesday, May 17, 2016 5:11 PM > To: core-libs-dev > Subject: Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported > non-Iso Temporal fields > > I would

Re: RFR(s): 8133977 add specification for serial form of immutable collections

My original blog on the topic was in 2010: http://blog.joda.org/2010/02/serialization-shared-delegates_9131.html Bear in mind that a key reason for sharing the serialization proxy is to share the "serialized object header, serial version UID, class descriptor" etc. It is that header overhead that

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

I would also like to see the test case methods be named "getFrom" not "getfrom". Stephen On 17 May 2016 at 05:18, nadeesh tv wrote: > Hi Bhanu, > > I think you should add a test case comparing the return value of getFrom() > >( Not an official reviewer) > > Regards, >

Re: RFR(s): 8133977 add specification for serial form of immutable collections

com> wrote: > > On 17 May 2016, at 09:55, Stephen Colebourne <scolebou...@joda.org> wrote: > >> CollSer should not be public, especially not just for serialization >> reasons. > > Right, and I see no reason to refer to it by name in the javadoc, the > link sho

<    1   2   3   4   5   >