Re: Optional.or name Re: RFR 8080418 Add Optional.or()

Maybe "an optional equivalent to {@code this}" The original text is quite obtuse. Stephen On 14 October 2015 at 09:54, Paul Sandoz wrote: > >> On 13 Oct 2015, at 22:43, Stephen Colebourne wrote: >> >> I'd prefer to see "this" mentioned: >>

Re: Optional.or name Re: RFR 8080418 Add Optional.or()

On 12 October 2015 at 08:48, Paul Sandoz wrote: > Now that the overall documentation changes and functional behaviour of > Optional.or has been agreed i would like to see if we can find a better name, > suggestions welcome, so lets get our paint brushes out :-) "or" seems reasonable for this me

Re: RFC: draft API for JEP 269 Convenience Collection Factories

On 9 October 2015 at 00:39, Stuart Marks wrote: > 1. Number of fixed arg overloads. Guava follows this pattern: of(T) of(T, T) of(T, T, T) of(T, T, T, T... elements) whereas the proposal has of(T) of(T, T) of(T, T, T) of(T... elements) I'd be interested to know why Guava did it that way and w

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

On 9 October 2015 at 01:31, John Rose wrote: > This leads me to yet another bikeshed color, FWIW: > > - T requireNonNull(T) (cf. Optional::get) > - T requireNonNullElse(T,T) (cf. Optional::orElse) > - T requireNonNullElseGet(T,Supplier) (cf. Optional::orElseGet) > - T requireNonNullElseThrow(T

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

On 7 October 2015 at 23:24, Roger Riggs wrote: > Please consider and comment: > > T nonNullOf(T obj, T defaultObj); > T nonNullOf(T, obj, Supplier defaultSupplier); > > Details are in the updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/ I think I can liv

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 disallowing nulls will cause deve

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

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 uses firstNonNull(a, b). It ensu

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 t

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 needs to be fixed. I'd real

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: 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.) I don’t want > to disc

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 floorDiv with no Java-side bran

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: https://common

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 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 while we are on the topic o

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" > > Webrev: > http://cr.openjd

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. > > That seems reasonable e

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. Instead

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

r > > > > 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" wrote: >> >>> External question sites indicate that users have difficul

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

Anyone like to take this on please? Stephen On 28 Aug 2015 00:07, "Stephen Colebourne" wrote: > External question sites indicate that users have difficulty converting > between java.util.Date and LocalDate, and also between Instant and > LocalDate/LocalTime. This user difficu

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: ZonedDateTime.ofInstant(Instan

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

Fine by me. Stephen On 6 Aug 2015 19:15, "Chris Hegarty" wrote: > > On 6 Aug 2015, at 19:07, Roger Riggs wrote: > > > Hi, > > > > Please review the update to include the additional case and fix. > > > > http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/ > > The updated version looks goo

Re: ProcessBuilder support for pipelines

Seems like a useful addition to me. Stephen On 28 July 2015 at 09:28, Chris Hegarty wrote: > I find this kinda cute. Seems like a reasonable addition to me. > > -Chris. > > On 27 Jul 2015, at 15:48, Roger Riggs wrote: > >> On most operating systems, creating pipelines of processes is simple and

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 wrote: > Please review 3 editorial issues in the java.time package: > > Issues: > 8075678 : java.time > javadoc error in DateTimeFormatter::parsedLeapSecond > 8075676

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 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 outside the JDK

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

On 6 May 2015 at 14:53, Paul Sandoz 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 >> stream.filter(Pre

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

epends on the truncation or should I just pretend that >>> truncation has been performed and make this change accordingly or should I >>> 1st do the JDK-8079063 and then this one on top? >>> >>> Also, getInstant() can be much simpler if the truncation is performed: >>>

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

perhaps could be tackled here. You need an Oracle sponsor to tell you ;-) Stephen On 29 April 2015 at 10:33, 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 e

Re: Additional method on Stream

On 27 April 2015 at 16:23, Paul Sandoz 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 > operations. > > There has t

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 wrote: > Hi Peter, > > Caching the epochSecond moves the computation fr

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 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] java/time/tck/java/

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 wrote: > Hi, > > Please review the following improvement that caches default ZoneId object > and makes the frequently executed ZoneId.systemDefault() method faster: > > http://cr.openjdk.java.net/~plevart/jdk9-dev

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 wrote: > Hi again, > > Here's another optimization to be reviewed that has been discussed a while > ago (just rebased from webrev

Re: Additional method on Stream

of filter method to Stream > when one can do the above. > > 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 wrote: > >> This is a request for an additional met

Additional method on Stream

This is a request for an additional method on java.util.stream.Stream. Having written quite a bit of code in Java 8 now, one annoyance keeps on coming up, filtering and casting the stream. Currently, it is necessary to do this: return input.stream() .filter(Foo.class::isInstance)

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

Hi Stephen, > > 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

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

The code in the webrev changes the behaviour of java.time, so cannot go in. Run this code: TimeZone zone = TimeZone.getDefault(); System.out.println(zone); ZoneId zoneId = ZoneId.systemDefault(); System.out.println(zoneId); TimeZone.setDefault(TimeZone.getTimeZone("Europe/Paris

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 wrote: > Stephen and Roger, > > This is the DTF.appendZoneOrOffsetId() issues we discussed last year. > Somehow the > ball was dropped somewhere :-

Re: JEP 238: Multi-Version JAR Files

On 1 March 2015 at 23:37, Remi Forax 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 to create the

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 wrote: > 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/web

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

On 27 February 2015 at 10:55, Daniel Fuchs 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. Thanks for remin

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

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 with that approach. I don't think I saw an is

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

a.net/~plevart/jdk9-dev/ZoneOffsetTransition.epochSecond/webrev.01/ > > > So is this a worthy improvement? What do you think about the new approach > for optimizing ZoneId.systemDefault() compared to SharedSecrets based: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId

Re: JEP 238: Multi-Version JAR Files

antom). On 25 February 2015 at 16:27, Brian Goetz 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 mappin

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 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

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

On 23 February 2015 at 22:27, Peter Levart 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 just delegating 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 wrote: > On 23/02/15 19:50, Roger Riggs wrote:

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 t

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 wrote: > I totally disagree about "recoverable condition". Instead of thinking > about "recove

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 wrote: > On 18/02/15 12:11, Stephen Colebourne wrote: >> >> In LogRecord, the Javadoc of getInstant(): >> "Get event time." >> could be >&g

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

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 d

Re: JEP 102 Process Updates revised API draft

On 9 February 2015 at 23:44, David M. Lloyd 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 you > went with a raw

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

t/~rriggs/webrev-leap-year-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. >> * >> * A leap-year is a year of a longer le

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

hould clearly be either an exception or reinforce the > value is > specified only within the range of the chronology. > > How about: > > except if the year is out of range the chronology should return a best > effort guess, or false if there is no suitable guess > > Roger

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 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 exampl

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

ogies. > > The assertion 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

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 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 withou

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

On 28 January 2015 at 17:09, Paul Sandoz 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 method encourages p

Re: Explicit Serialization API and Security

On 15 January 2015 at 13:01, Peter Firmstone 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 of java > platform class

Re: Explicit Serialization API and Security

On 12 January 2015 at 11:37, Chris Hegarty 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 each type in the dese

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

On 12 January 2015 at 12:00, Daniel Fuchs 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 micros'? .NET refers

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

On 12 January 2015 at 11:36, Daniel Fuchs 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 serialization stream

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 secu

Re: Explicit Serialization API and Security

On 6 January 2015 at 11:46, Chris Hegarty 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 needed > to create the “

Re: Explicit Serialization API and Security

On 6 January 2015 at 10:25, Chris Hegarty wrote: > On 6 Jan 2015, at 08:31, Stephen Colebourne wrote: >> I've thought on a number of occasions that what I wanted from >> serializable was a merger of readObject and readResolve >> >> private Object readObjectAndReso

Re: Explicit Serialization API and Security

On 6 January 2015 at 07:27, Peter Levart 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 anything more or simplify

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 pro

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 wrote: > On 01/

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

Time-zone distribution service

For those of you not aware, an IETF group is currently defining a time zone distribution service "tzdist": http://tools.ietf.org/html/draft-ietf-tzdist-service-03 It will be worth considering whether this might be of use to Java to provide a mechanism to update time zone data. Readers of this list

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

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

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 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.ne

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 wrote: > On 12/03/2014 10:52, Stephen Colebourne wrote: >> >> This is a request for review of this bug: >> https://bugs.openjdk.j

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

ping On 12 March 2014 12:29, Stephen Colebourne 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 java.time.format.DateTimeF

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

). >> >> I can sponsor the fix when reviewed. >> >> Thanks, Roger >> >> >> 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 >>&g

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

ping On 12 March 2014 10:52, Stephen Colebourne wrote: > 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

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

ping On 12 March 2014 10:48, Stephen Colebourne 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

er, may 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. &g

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 i

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 i

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 = base.wi

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: "@

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

On 26 February 2014 20:54, Martin Buchholz 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 monitor as an ins

Re: Type of Class

t we have a plan to expose one backed by core reflection which > is a more sensible way to express the information you are looking for. > > > On Feb 21, 2014, at 2:27 AM, Stephen Colebourne wrote: > >> On 21 February 2014 08:14, David Holmes wrote: >>>> Would it be

Re: Type of Class

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

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() - isTopLevelCl

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 wrote: > Hi Stephen! > > May I ask you to add some more typo fixes to your patch? > > Sincer

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

On 19 February 2014 11:39, Alan Bateman 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 large

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

e too large to fit in an {@code int} and throw an {@code > UnsupportedTemporalTypeException}. > > David > > > On 19/02/2014 8:54 PM, Stephen Colebourne wrote: >> >> A set of minor wording fixes in Javadoc: >> >> https://gist.github.com/jodastephen/8984256 >> >> Comments welcome. >> Stephen >> >

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 java.time cleanup of javadoc and messages

+1 by me Stephen On 3 February 2014 22:43, roger riggs wrote: > Please review this group of java.time updates: > > 8032749 : Typo in > java.time.Clock > 8032888 : Error message > typo in Tempora

Re: RFR java.time.chrono equals and hashCode

Looks good to me Stephen On 17 Dec 2013 06:48, "roger riggs" 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 inherited during a

Re: RFR java.time serialization

Looks fine AFAICT Stephen On 17 Dec 2013 09:23, "roger riggs" 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 AM, roger rig

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 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, not the

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. Japane

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

On 2 December 2013 19:47, Xueming Shen 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 Does the spec allow it t

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

On 26 November 2013 17:35, Martin Buchholz 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 the names of all

<    1   2   3   4   5   6   >