Re: JEP 269: Convenience Factory Methods for Collections

On 7 October 2015 at 01:13, Stuart Marks wrote: > My question is, is this enough of a problem that we should allow nulls in > these collections? I would prefer not to do this, but if there is evidence > that this would be a mistake, I'd like to hear it. > > And if

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

xisting code which > would need to be examined for behavioral changes due to possibly throwing an > exception. > So perhaps the nonNullorElse name would be more accurate. > > Thanks, Roger > > > > On 10/6/2015 10:00 AM, Stephen Colebourne wrote: >> >> Guava use

Re: Test for JDK-5108778 Too many instances of java.lang.Boolean created in Java application

Moving to core-libs: On 3 October 2015 at 03:20, Stuart Marks wrote: > An interesting exercise would be to add the @Deprecated annotation to the > Boolean constructor and build the JDK and see how many warnings result. That > might be a quick way to find the code that

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

Guava uses firstNonNull(a, b). It ensures that the result is never null, by checking that b is not null. I think the semantics of Guava's method is correct. I tend to think the method name isn't bad either. Calling it nonNull(Object,Object) clashes with the existing nonNull(Object) method. Those

Re: JEP 269: Convenience Factory Methods for Collections

In my view, the proposal is pretty good. I too use Guava's immutable classes as types, because of the extra value obtained. But that does not mean these methods should not be in the JDK. (Not every project uses Guava). I'd argue for two changes to the JEP. Map.fromEntries() -> Map.ofEntries() In

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

Good to see this happen. I agree a test would be good to demonstrate edge cases. 1) I think the code for floorMod(long x, int y); cannot actually overflow. As such, the result could just be cast without the if and throw. 2) My preferred algorithm for floorMod is: return ((a % b) + b) % b; as

Re: RFR 8135248: Add utility methods to check indexes and ranges

Just to note that an ideal location for this would be on a new class, one that has been discussed before, an "argument checker class". See Guava Preconditions: https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java See Commons Lang Validate:

Re: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact methods for java.lang.Math

On 29 September 2015 at 16:02, Brian Burkhalter wrote: > 2) > My preferred algorithm for floorMod is: > > return ((a % b) + b) % b; > > as it contains no Java-side branches, although tests would be needed > to prove performance. > > This also allows an algorithm for

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 29 September 2015 at 21:01, Paul Sandoz wrote: > The concern i have is once Preconditions is let loose the scope expands with > proposals for “just one more method” (there is even the opportunity to bike > shed over the names checkNotNull or requiresNotNull etc. etc.)

Re: RFR 8080418 Add Optional.or()

On 25 September 2015 at 11:58, Paul Sandoz wrote: > Please review this change to add a method Optional.or that allows one to > better compose optionals: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ New method seems fine. > Separately

Re: RFR 9: 8129744 : Documentation in Month refers to quarters

+1 Stephen On 24 September 2015 at 14:23, Roger Riggs wrote: > Please review two java.time editorial changes: > - 8129744: a trivial editorial change in java.time.Month javadoc. > - 8129556: TemporalAdjusters dayOfWeekInMonth wrongly says "in the same > month" > >

Re: RFR 8135248: Add utility methods to check indexes and ranges

While I think I understand the need for the lambda/exception interface (backwards compatibility) it is definitely weird as a method signature. It would seem very worthwhile to add overloaded versions of each of these methods that do not have the OutOfBoundsToException in the argument list.

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 21 September 2015 at 15:28, Paul Sandoz wrote: >> It would seem very worthwhile to add overloaded versions of each of >> these methods that do not have the OutOfBoundsToException in the >> argument list. Instead, these overloads would throw a "standard" >> exception. >

Re: RFR JDK-8133079 LocalDate/LocalTime ofInstant()

e. (Early > Nov) > > Roger > > > > On 9/8/2015 2:53 PM, Stephen Colebourne wrote: >> >> Anyone like to take this on please? >> Stephen >> On 28 Aug 2015 00:07, "Stephen Colebourne" <scolebou...@joda.org> wrote: >> >>> Extern

Re: RFR JDK-8133079 LocalDate/LocalTime ofInstant()

Anyone like to take this on please? Stephen On 28 Aug 2015 00:07, "Stephen Colebourne" <scolebou...@joda.org> wrote: > External question sites indicate that users have difficulty converting > between java.util.Date and LocalDate, and also between Instant and > Local

RFR JDK-8133079 LocalDate/LocalTime ofInstant()

External question sites indicate that users have difficulty converting between java.util.Date and LocalDate, and also between Instant and LocalDate/LocalTime. This user difficulty can be resolved with some additional methods. Currently, the following methods exist:

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

Fine by me. Stephen On 6 Aug 2015 19:15, Chris Hegarty chris.hega...@oracle.com wrote: On 6 Aug 2015, at 19:07, Roger Riggs roger.ri...@oracle.com wrote: Hi, Please review the update to include the additional case and fix. http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/

Re: ProcessBuilder support for pipelines

Seems like a useful addition to me. Stephen On 28 July 2015 at 09:28, Chris Hegarty chris.hega...@oracle.com wrote: I find this kinda cute. Seems like a reasonable addition to me. -Chris. On 27 Jul 2015, at 15:48, Roger Riggs roger.ri...@oracle.com wrote: On most operating systems,

Re: RFR 9: JDK-8075678 : java.time javadoc error in DateTimeFormatter::parsedLeapSecond

Fine by me Stephen On 28 May 2015 at 21:14, Roger Riggs roger.ri...@oracle.com wrote: Please review 3 editorial issues in the java.time package: Issues: 8075678 https://bugs.openjdk.java.net/browse/JDK-8075678: java.time javadoc error in DateTimeFormatter::parsedLeapSecond 8075676

Re: Add Predicate.of(), Consumer.of(), etc.

On 6 May 2015 at 14:53, Paul Sandoz paul.san...@oracle.com wrote: In some respects i wonder if the default methods on the functional interfaces are an attractive nuisance. Meaning, if .negate(Predicate) were a static method on the Predicate class instead of a default method, then

Re: RFR: JDK-8079063 ZoneOffsetTransition constructor should ignore nanoseconds

I am also happy with this change. Stephen On 6 May 2015 at 15:43, Roger Riggs roger.ri...@oracle.com wrote: Hi Peter, Thanks for the analysis and followup. Yes, I think thesimple check as you propose is the desired clarification. I agree that the change should not affect any existing code

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

be much simpler if the truncation is performed: return Instant.of(epochSecond); Regards, Peter On 4/29/2015 5:33 AM, Peter Levart wrote: On 04/27/2015 06:51 PM, Stephen Colebourne wrote: One additional change is needed. The compareTo() method can rely on the new epochSecond field as well

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

, but perhaps could be tackled here. You need an Oracle sponsor to tell you ;-) Stephen On 29 April 2015 at 10:33, Peter Levart peter.lev...@gmail.com wrote: On 04/27/2015 06:51 PM, Stephen Colebourne wrote: One additional change is needed. The compareTo() method can rely on the new epochSecond

Re: Additional method on Stream

On 27 April 2015 at 16:23, Paul Sandoz paul.san...@oracle.com wrote: One issue is there are zillions of possible more specific convenience operations we could add. Everyone has their own favourite. Some static methods were recently added to Stream and Optional in preference to such

Re: Additional method on Stream

. In general my preference is to keep the stream operation methods as general as possible. Paul. On Apr 27, 2015, at 3:22 PM, Stephen Colebourne scolebou...@joda.org wrote: This is a request for an additional method on java.util.stream.Stream. Having written quite a bit of code in Java 8 now

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

One additional change is needed. The compareTo() method can rely on the new epochSecond field as well. Otherwise good! Stephen On 27 April 2015 at 17:24, Peter Levart peter.lev...@gmail.com wrote: Hi again, Here's another optimization to be reviewed that has been discussed a while ago (just

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

Fine by me. Stephen On 27 April 2015 at 19:50, Roger Riggs roger.ri...@oracle.com wrote: Please review a timing relaxation so tests do not fail on very slow hardware with more expensive runtime options. (-Xcomp) The change will also be backported to jdk 8. Issue: 8078369: [testbug]

Re: RFR: JDK-8074003 java.time.zone.ZoneRules.getOffset(java.time.Instant) can be optimized

TzdbZoneRulesProvider parses the byte[] of TZ data on demand when a ZoneId is first requested. So, the ZoneOffsetTransition will not be created unless a ZoneId is during startup. Stephen On 27 April 2015 at 22:58, Roger Riggs roger.ri...@oracle.com wrote: Hi Peter, Caching the epochSecond

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

This seems like a good enhancement. Stephen On 27 April 2015 at 16:26, Peter Levart peter.lev...@gmail.com wrote: Hi, Please review the following improvement that caches default ZoneId object and makes the frequently executed ZoneId.systemDefault() method faster:

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

, Just to clarify, by non-offset based ZoneRules do you mean it has a fixed offset meaning no transitions; aka ZoneRules.isFixedOffset() = true? Thanks, Roger On 4/24/2015 5:32 AM, Stephen Colebourne wrote: The code in the webrev changes the behaviour of java.time, so cannot go

Re: RFR: JDK-8074406 DateTimeFormatter.appendZoneOrOffsetId() fails to resolve a ZoneOffset for OffsetDateTime

I think the fix looks good. I haven't had time to look through the tests in detail (as there are lots) Stephen On 4 March 2015 at 19:48, Xueming Shen xueming.s...@oracle.com wrote: Stephen and Roger, This is the DTF.appendZoneOrOffsetId() issues we discussed last year. Somehow the ball was

Re: JEP 238: Multi-Version JAR Files

On 1 March 2015 at 23:37, Remi Forax fo...@univ-mlv.fr wrote: You only maintain one module which depend on the latest version. When you ship the module let say as a jar, you also ship the way to downgrade it as an executable code. At install time, when all the modules are known, before trying

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

Looks good to me. thanks Stephen On 27 February 2015 at 16:25, Daniel Fuchs daniel.fu...@oracle.com wrote: Hi, Please find below a patch for: 8074032: Instant.ofEpochMilli(millis).toEpochMilli() can throw arithmetic overflow in toEpochMilli()

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

On 27 February 2015 at 10:55, Daniel Fuchs daniel.fu...@oracle.com wrote: I don't think I saw an issue raised for caching the clock in ZoneId. That seems like a good plan to me (ZoneId instances are controlled singletons, so there is no big memory issue there) I'd been intending to log that.

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

On 26 February 2015 at 23:29, Peter Levart peter.lev...@gmail.com 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 with that approach. I

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

()) Regards, Peter On 02/23/2015 12:50 PM, Stephen Colebourne wrote: Having recently spent time on performance myself, I know that there are a number of things in the java.time package that need some work. Improving ZoneId.systemDefault() is definitely an improvement I welcome. The change

Re: JEP 238: Multi-Version JAR Files

it (like Fantom). On 25 February 2015 at 16:27, Brian Goetz brian.go...@oracle.com wrote: On 2/12/2015 5:59 PM, Stephen Colebourne wrote: I would expect IDEs to have some considerable work to do. Agree on the work part, but I doubt it is considerable. In Eclipse, there is a 1:1 mapping between

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

On 23 February 2015 at 22:27, Peter Levart peter.lev...@gmail.com wrote: What about the following idea: - create a (maybe still package-private) instance method ZoneId.getSystemClock() and cache the per-ZoneId Clock instance inside the ZoneId. - Clock.system(ZoneId) static method is then

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

Thanks for the change. This reviewer is happy. Stephen On 24 February 2015 at 10:59, Daniel Fuchs daniel.fu...@oracle.com wrote: On 23/02/15 21:40, Stephen Colebourne wrote: The rest of the java.time code tends to put the data provider method before the test, and mostly uses a naming

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

Having recently spent time on performance myself, I know that there are a number of things in the java.time package that need some work. Improving ZoneId.systemDefault() is definitely an improvement I welcome. The change is along the lines of that I would have made, involving a secret location to

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

The rest of the java.time code tends to put the data provider method before the test, and mostly uses a naming convention of data_systemClocks. Neither of which are particularly important things. Stephen On 23 February 2015 at 20:02, Daniel Fuchs daniel.fu...@oracle.com wrote: On 23/02/15

Re: RFR 9 8055330: (process spec) ProcessBuilder.start and Runtime.exec should throw UnsupportedOperationException ...

FWIW, I think UOE is clearly the right exception for a method that is unsupported. An IOExeption is very much associated with the actual IO system. Stephen On 20 February 2015 at 21:06, Martin Buchholz marti...@google.com wrote: I totally disagree about recoverable condition. Instead of

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

A good improvement and ready to go from my perspective, thanks Stephen On 19 February 2015 at 15:19, Daniel Fuchs daniel.fu...@oracle.com wrote: On 18/02/15 12:11, Stephen Colebourne wrote: In LogRecord, the Javadoc of getInstant(): Get event time. could be Gets the instant that the event

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

In LogRecord, the Javadoc of getInstant(): Get event time. could be Gets the instant that the event ocurred. In LogRecord, the Javadoc of setInstant(): Set event time. could be Sets the instant that the event ocurred. (matching change to @param) I'd prefer to see the other methods in the class

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

Elements of the date/time handling here don't really work. Logging is essentially a UTC only problem, using a time-zone is slow and unecessary. This indicates that all uses of ZonedDateTime should be replaced with either Instant or an OffsetDateTime using ZoneOffset.UTC. Any string format should

Re: JEP 238: Multi-Version JAR Files

Interesting direction. Reading carefully, the goal is actually very limited in scope, by preventing any public API changes. It doesn't help adoption of JSR-310 for example, but will be useful for Unsafe, which is clearly a motivating factor. I would expect IDEs to have some considerable work to

Re: JEP 102 Process Updates revised API draft

On 9 February 2015 at 23:44, David M. Lloyd david.ll...@redhat.com wrote: ProcessHandle.Info provides a startTime and totalTime. But it seems odd and inconsistent that startTime is an Instant, yet totalTime is a raw long as opposed to the arguably more consistent Duration. Is there a reason

Re: RFR 9: 8067800: Unexpected DateTimeException in the java.time.chrono.HijrahChronology.isLeapYear

if there is no suitable guess Stephen On 4 February 2015 at 16:05, Roger Riggs roger.ri...@oracle.com wrote: Hi Stephen, On 2/4/15 10:43 AM, Stephen Colebourne wrote: The java.time code generally takes a lenient approach to methods that return a boolean. For example, they tend to accept null inputs

Re: RFR 9: 8067800: Unexpected DateTimeException in the java.time.chrono.HijrahChronology.isLeapYear

an exception or reinforce the value is specified only within the range of the chronology. How about: liexcept if the year is out of range the chronology should return a best effort guess, or false if there is no suitable guess Roger On 2/4/2015 11:18 AM, Stephen Colebourne wrote: The spec

Re: RFR 9: 8067800: Unexpected DateTimeException in the java.time.chrono.HijrahChronology.isLeapYear

-8067800/ Roger On 2/4/2015 3:42 PM, Stephen Colebourne wrote: I think this might be clearer: * Checks if the specified year is a leap year. * p * A leap-year is a year of a longer length than normal. * The exact meaning is determined by the chronology according to the following

Re: RFR 9: 8067800: Unexpected DateTimeException in the java.time.chrono.HijrahChronology.isLeapYear

in Chronology.isLeapYear about not checking the range is too broad and should be qualified by the Chronology. Perhaps the proposed change should include a caveat in that method. Roger On 2/3/15 8:05 PM, Stephen Colebourne wrote: -1 As I indicated on JIRA, I don't believe

Re: RFR 8071670: java.util.Optional: please add a way to specify if-else behavior

Can't say I've used isPresent() much, as map()/flatMap()/orElse() take care of most use cases. What is an issue is that the primitive optional classes do not have ofNullable(), filter(), map() or flatMap(). It seems odd to be adding an additional new method to the primitive optional classes

Re: RFR 9: 8067800: Unexpected DateTimeException in the java.time.chrono.HijrahChronology.isLeapYear

-1 As I indicated on JIRA, I don't believe that this change meets the spec or intent of the definition on Chronology. That is specified to not throw any exceptions and to handle all years, valid or not. I don't foresee any significant issue where a year is not validated by this method. Years out

Re: RFR 8050819: Please add java.util.Stream.ofNullable(T object)

On 28 January 2015 at 17:09, Paul Sandoz paul.san...@oracle.com wrote: I guess having a method like this makes it easier for people to deal with their possibly-null-producing code in a new streams world. Such null-producing code already exists. I guess you could say that providing this

Re: Explicit Serialization API and Security

On 15 January 2015 at 13:01, Peter Firmstone peter.firmst...@zeus.net.au wrote: A third option that hasn't yet been considered would be to investigate an api that various already existing frameworks can implement providers for, so they no longer need to find creative ways to construct instances

Re: RFR 8068730: Increase the precision of the implementation of java.time.Clock.systemUTC()

On 12 January 2015 at 11:36, Daniel Fuchs daniel.fu...@oracle.com wrote: In java.time.Instant, a readObject() has been added. However, I don't believe this will ever be called because Instant has a writeReplace() method and so is not deserialized. (There may be some security related evil

Re: RFR 8068730: Increase the precision of the implementation of java.time.Clock.systemUTC()

On 12 January 2015 at 12:00, Daniel Fuchs daniel.fu...@oracle.com wrote: I'm not a big fan of the current name either. I would gladly rename it. I did think of windows_to_java_time_micros, but it actually returns tenth of micros - so it would be lying... Is there a good name for 'tenth of

Re: Explicit Serialization API and Security

On 12 January 2015 at 11:37, Chris Hegarty chris.hega...@oracle.com wrote: For clarity, I would like to describe how things currently work. 1) Allocate a new instance of the deserialized type. 2) Call the first non-Serializable types no-arg constructor ( may be j.l.Object ). 3) For

Re: RFR 8068730: Increase the precision of the implementation of java.time.Clock.systemUTC()

Well that is a nice surprise ;-) And I think the implementation via an adjustment is very sensible. In java.time.Instant, a readObject() has been added. However, I don't believe this will ever be called because Instant has a writeReplace() method and so is not deserialized. (There may be some

Re: Explicit Serialization API and Security

On 6 January 2015 at 07:27, Peter Levart peter.lev...@gmail.com wrote: readObject() can be used on both ends of the spectrum or anywhere in-between. It can be used for explicit deserialization or just for validation of default deserialized state. Would separate validation method give us

Re: Explicit Serialization API and Security

On 6 January 2015 at 10:25, Chris Hegarty chris.hega...@oracle.com wrote: On 6 Jan 2015, at 08:31, Stephen Colebourne scolebou...@joda.org wrote: I've thought on a number of occasions that what I wanted from serializable was a merger of readObject and readResolve private Object

Re: Explicit Serialization API and Security

On 6 January 2015 at 11:46, Chris Hegarty chris.hega...@oracle.com wrote: With shallow/no hierarchies, and others, the serialization proxy pattern works quite well. The overhead of course being the creation of the proxy itself, but this is typically a minimal container with just the state

Re: JDK 9 RFR of 4026465: Provide more byte array constructors for BigInteger

Just to note that an IndexOutOfBoundsException is mentioned in the text (line 274, 350) but there is no matching @throws clause. The IndexOutOfBoundsException could have a message added. In general, I would expect an offset/length overload for most methods that take an array, so this seems like a

Re: JEP 187: Serialization 2.0

I've checked the bug database [1], JEPs list [2] and Google but this JEP appears to have disappeared. Can this be confirmed? Stephen [1] https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20JEP [2] http://openjdk.java.net/jeps/0 On 13 February 2014 at 11:05, Florian Weimer

Re: Explicit Serialization API and Security

Just to note that there is some overlap between improving serialization and the meta-model for Java (Beans v2.0) work I'm looking at [1][2]. The key tool that a meta-model provides is to enable class authors to select which pieces of their state form the published properties. In most cases, the

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

I'm happy with this updated patch. Stephen On 24 March 2014 18:24, Xueming Shen xueming.s...@oracle.com wrote: Hi Stephen, The webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8033662/webrev/ Thanks! -Sherman On 03/24/2014 08:59 AM, Stephen Colebourne wrote

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

This really needs to make 8u20 IMO, so I need to get it into jdk9 first thanks Stephen On 12 March 2014 12:29, Stephen Colebourne scolebou...@joda.org wrote: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8033662 and the duplicate: https

Re: RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed

then consider rechecking all of java.time for non-normative stuff to go in a separate commit. Stephen On 19 March 2014 10:53, Alan Bateman alan.bate...@oracle.com wrote: On 12/03/2014 10:52, Stephen Colebourne wrote: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK

Re: RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect

ping On 12 March 2014 10:48, Stephen Colebourne scolebou...@joda.org wrote: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8035099 The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime with(MICRO_OF_DAY, n) fails to match the specification

Re: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

On 3/12/2014 6:45 AM, Stephen Colebourne wrote: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8036818 The method DateTimeFormatter withResolverFields() is supposed to accept null. This is to allow a coy of the formatter to be returned reset to the original

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

ping On 12 March 2014 12:29, Stephen Colebourne scolebou...@joda.org wrote: This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8033662 and the duplicate: https://bugs.openjdk.java.net/browse/JDK-8033659 The javadoc of the method

RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8036818 The method DateTimeFormatter withResolverFields() is supposed to accept null. This is to allow a coy of the formatter to be returned reset to the original state of having no resolver fields. The docs say:

RFR: JDK-8035099 LocalTime with(MILLI_OF_DAY/MICRO_OF_DAY) incorrect

This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8035099 The implementation for LocalTime with(MILLI_OF_DAY, n) and LocalTime with(MICRO_OF_DAY, n) fails to match the specification. LocalTime base = LocalTime.of(12, 30, 40, 987654321); LocalTime result =

RFR: JDK-8036785 ChronoLocalDate refers to generics that have been removed

This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8036785 During development, ChronoLocalDate had a generic type parameter. It was removed during the development of JSR-310. The Javadoc was not updated to reflect the removal. The necessary change is to text that

RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

This is a request for review of this bug: https://bugs.openjdk.java.net/browse/JDK-8033662 and the duplicate: https://bugs.openjdk.java.net/browse/JDK-8033659 The javadoc of the method java.time.format.DateTimeFormatter::withZone says: If no zone has been parsed, then this override zone will be

Re: RFR: JDK-8036818: DateTimeFormatter withResolverFields() fails to accept null

not be suitable for 8u. Though I'm not sure how these tests feed from the OpenJDK repo into the actual TCK. -Chris. On 12/03/14 13:54, roger riggs wrote: Looks fine, (not a reviewer). I can sponsor the fix when reviewed. Thanks, Roger On 3/12/2014 6:45 AM, Stephen Colebourne wrote

Re: Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

On 26 February 2014 20:54, Martin Buchholz marti...@google.com wrote: It does seem that being able to tell whether a java object monitor is currently locked is useful for debugging and monitoring - there should be a way to do that. Perhaps it would be useful to be able to expose a java object

Re: Type of Class

On 21 February 2014 08:14, David Holmes david.hol...@oracle.com wrote: Would it be reasonable to add the following methods: - isNestedClass() This would be !isTopLevelClass() but otherwise isAnonymousClass() || isLocalClass() || isMemberClass() - isInnerClass() isAnonymousClass() ||

Re: Type of Class

you are looking for. On Feb 21, 2014, at 2:27 AM, Stephen Colebourne scolebou...@joda.org wrote: On 21 February 2014 08:14, David Holmes david.hol...@oracle.com wrote: Would it be reasonable to add the following methods: - isNestedClass() This would be !isTopLevelClass() but otherwise

Type of Class

In JDK 5, three methods were added to java.lang.Class [1] - isAnonymousClass() - isLocalClass() - isMemberClass() Unfortunately, these do not cover the complete range of possible types of class. Would it be reasonable to add the following methods: - isNestedClass() - isInnerClass() -

RFR: JDK-8034906 Fix typos, errors and Javadoc differences in java.time

A set of minor wording fixes in Javadoc: https://gist.github.com/jodastephen/8984256 Comments welcome. Stephen

Re: RFR: JDK-8034906 Fix typos, errors and Javadoc differences in java.time

On 19 February 2014 11:39, Alan Bateman alan.bate...@oracle.com wrote: On 19/02/2014 11:08, David Holmes wrote: Hi Stephen, This could be construed as a spec-change, even if a typo :( - * which are too large to fit in an {@code int} and throw a {@code DateTimeException}. + * which are too

Re: RFR: JDK-8034906 Fix typos, errors and Javadoc differences in java.time

Patch updated: https://gist.github.com/jodastephen/8984256 with differences: https://gist.github.com/jodastephen/8984256/revisions thanks for the spots, Stephen On 19 February 2014 11:58, Ivan Gerasimov ivan.gerasi...@oracle.com wrote: Hi Stephen! May I ask you to add some more typo fixes to

Re: RFR java.time cleanup of javadoc and messages

+1 by me Stephen On 3 February 2014 22:43, roger riggs roger.ri...@oracle.com wrote: Please review this group of java.time updates: 8032749 https://bugs.openjdk.java.net/browse/JDK-8032749: Typo in java.time.Clock 8032888 https://bugs.openjdk.java.net/browse/JDK-8032888: Error message

Re: RFR java.time serialization

Looks fine AFAICT Stephen On 17 Dec 2013 09:23, roger riggs roger.ri...@oracle.com wrote: Hi Sherman, Thanks for the comments, corrected and updated the webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-serialization/ On 12/16/2013 1:00 PM, Xueming Shen wrote: On 12/16/2013 09:02

Re: RFR java.time.chrono equals and hashCode

Looks good to me Stephen On 17 Dec 2013 06:48, roger riggs roger.ri...@oracle.com wrote: Please review this change to explicitly document the behavior of equals and hashCode for java.time.chrono concrete types. The behavior is not changed. (They had been documented but the javadoc was not

Re: Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge must refuse null values]

See https://bugs.openjdk.java.net/browse/JDK-8029676 Stephen On 26 November 2013 13:20, Stephen Colebourne scolebou...@joda.org wrote: I took a quick look, but jumped back in horror at the start of the Javadoc for the new methods in Map. A Javadoc description should start with the positive

Re: RFR: Add value-type notice to java.time classes

Pretty much looks good. However, I notice that the equals, hashCode and toString methods of the 4 calendar specific date classes are inherited rather than written. Without additional spec, I'm not sure that they can claim to be value types. Adding the 12 Javadocs should be relatively easy.

Re: There needs to be support for java.time in java.text.MessageFormat

On 2 December 2013 19:47, Xueming Shen xueming.s...@oracle.com wrote: That said, it might be desired to add the support of the JSR310 date/time for the DateFormat, but it will not make jdk8. FWIW, I think this should have been fixed in jdk 8. https://bugs.openjdk.java.net/browse/JDK-8016743

Re: Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge must refuse null values]

On 26 November 2013 17:35, Martin Buchholz marti...@google.com wrote: I haven't looked in depth, but I agree with Stephen's analysis. This API and its javadoc needs work. E.g. It's not clear that the purpose of Map.compute is to *update* the mapping for key in the map. I actually felt that

Poor Javadoc of Map default methods [Re: RFR: 8029055: Map.merge must refuse null values]

I took a quick look, but jumped back in horror at the start of the Javadoc for the new methods in Map. A Javadoc description should start with the positive, not the negative. I had to read the code to figure out what they are supposed to do. Here are the four poor Javadocs and some proposed

Re: RFR: 8029055: Map.merge must refuse null values

See the new thread for the general Javadoc issues. I'll focus on null here. Given a map {Key - null} I find the notion that putIfAbsent() or computeIfAbsent() ignore the existing mapping just plain wrong. While I can rationalise it (just) it is a horrible reworking of the meaning of absent.

Re: RFR: 8027470: AnnotationSupport uses == rather than .equals to compare Class objects

On 15 November 2013 03:21, Joseph Darcy joe.da...@oracle.com wrote: Catching up on email, the specification of java.lang.Class does not explicitly promise that its notion of equality must be identity for all time. Therefore, while not required for today's implementations, I would prefer that

Re: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable

On 23 October 2013 17:33, Alan Bateman alan.bate...@oracle.com wrote: I might have been tempted to conserve on classes and code duplication to share a serialization proxy between the classes and maybe even shorten the name. But it is hard to argue with the simplicity and directness of this

Re: Please Review Cleanup of java.time serialization source 8024686

Fine by me (not an official reviewer) Stephen On 22 October 2013 15:34, roger riggs roger.ri...@oracle.com wrote: Hi, Please review to address issues in the serialization source files [1] - The OffsetTime and OffsetDateTime classes have inconsistent serialization. - Order of modifiers

Re: [JBS] (JDK-8026842) Remove Time-Zone IDs HST/EST/MST

the webrev for it http://cr.openjdk.java.net/~sherman/8026842/webrev/ Thanks! -Sherman On 10/17/13 3:16 PM, Stephen Colebourne wrote: On 17 October 2013 22:14, Xueming Shen xueming.s...@oracle.com wrote: On 10/17/2013 02:01 PM, Stephen Colebourne wrote: I'm happy with the contents

Re: RFR 8025971 and 8026197

/~sherman/8025971_8026197/webrev thanks! -Sherman On 10/16/2013 01:09 AM, Stephen Colebourne wrote: On 15 October 2013 20:35, Xueming Shenxueming.s...@oracle.com wrote: Please help codereview the changes for 8025971: Remove Time-Zone IDs HST/EST/MST The method ZoneId.systemDefault() now

Re: RFR 8025971 and 8026197

On 17 October 2013 22:14, Xueming Shen xueming.s...@oracle.com wrote: On 10/17/2013 02:01 PM, Stephen Colebourne wrote: I'm happy with the contents of this webrev. As pointed out previously, it doesn't address the specific issue in 8025971 I will file a separate issue to address the issue

Re: RFR 8025971 and 8026197

On 15 October 2013 20:35, Xueming Shen xueming.s...@oracle.com wrote: Please help codereview the changes for 8025971: Remove Time-Zone IDs HST/EST/MST The method ZoneId.systemDefault() now does not match its specification: /** * Gets the system default time-zone. * p * This queries {@link

Re: Please Review Late binding of Chronology with appendValueReduced

Fine by me (not a formal reviewer) Stephen On 15 October 2013 17:03, roger riggs roger.ri...@oracle.com wrote: Hi, Spot fix for a date time parsing case witha reduced value field when the chronology is parsed after the reduced value field. The fix is to add a callback when the chronology

<    1   2   3   4   5   >