Fine by me (not an official reviewer)
Stephen
On 14 October 2013 15:34, roger riggs roger.ri...@oracle.com wrote:
Hi,
The java.time.chrono.Chronology should be split into an interface for
Chronology
and an AbstractChronology class that is the base for implementing a
Chronology.
A number
.
the end() will be invoked by the finalizer.
It might be reasonable to simply have a pair of static utility methods
byte[] Deflater.deflate(byte[]);
byte[] Inflater.deflate(byte[]);
For the casual/simple/easy use scenario.
Sherman
On 10/08/2013 03:24 AM, Stephen Colebourne wrote:
I've
for the mentioned update of effective chrono?
Thanks, Roger
On 9/22/2013 10:27 AM, Stephen Colebourne wrote:
The patch only changes the text of one of the two appendValueReduced
methods. The patch does not handle week based years or provide for
users to add their own year fields. It also does
My patch still looks fine to me :-)
Stephen
On 2 October 2013 16:19, roger riggs roger.ri...@oracle.com wrote:
Please review this fix for parsing two digit years in an Chronology.
The webrev includes Stephen's proposed alternate method that provides
a ChronoLocalDate as the base date.
I would agree that methods work best here although we do use constants
in other places (such as DTFormatter where it emphasises the
immutability)
I want to keep the Temporal prefix. Removing it from the static
classes does shorten code, but no other pluralized helper class
changes the name (eg.
The change looks fine AFAICT. I would prefer to see the new serial
package test classes have names that end in Serialization, eg
TCKLocalDateSerialization, but if that does not happen it is not the
end of the world.
Stephen
On 18 September 2013 22:31, roger riggs roger.ri...@oracle.com wrote:
A
I coded the methods I was thinking of on the plane to SFO:
https://gist.github.com/jodastephen/6659515
If there is still interest for JDK8 perhaps a group could work on
tidying this up at the codegarten.
Stephen
On 12 July 2013 00:49, Stephen Colebourne scolebou...@joda.org wrote:
On 12
The patch only changes the text of one of the two appendValueReduced
methods. The patch does not handle week based years or provide for
users to add their own year fields. It also does not handle
formatting.
After much thinking, I think the right solution is to add a new
appendValueReduced method
FWIW, I'm surprised that these methods don't exist. I've not hit the
problem myself but I know I'd curse if I discovered their absence.
Stephen
On 21 Sep 2013 08:35, Marcin Wiśnicki mwisni...@gmail.com wrote:
Third party serialization libraries and other tools need to know the
type of EnumSet
I'd be more comfortable with them moving to the non-TCK area. But if
they have to be deleted, so be it.
Stephen
On 12 September 2013 15:14, roger riggs roger.ri...@oracle.com wrote:
Hi,
Testing of java.time has found a problematic test on compact 1 and 2.
The test relies on localization data
On 12 September 2013 14:49, roger riggs roger.ri...@oracle.com wrote:
Some classes have had transient added, while others haven't. For
example LocalDate doesn't use transient. Since the instance fields are
never directly serialized, but do appear in the serialized form,
perhaps they should be
HijrahChronology mixes final transient and transient final. They
should be consistently one way or the other files should be checked,
and I think there is an official coding standard for this).
Some classes have had transient added, while others haven't. For
example LocalDate doesn't use
I lke the idea, but the wording feels a little opaque as the result is
typically StackOverflow.
Also, I prefer a style with the @apiNote on a line of its own, rather
like a heading. It makes the documentation easier to read in source
code, and has no effect on the output Javadoc.
@apiNote
If the
Thanks for getting these in.
Stephen
On 10 August 2013 02:26, Mike Duigou mike.dui...@oracle.com wrote:
Looks good to me. I am glad we were able to get this back into Java 8.
Mike
On Aug 9 2013, at 17:39 , Brian Burkhalter wrote:
Please review at your convenience:
Issue
Fine by me
On 14 August 2013 20:48, roger riggs roger.ri...@oracle.com wrote:
The issue 8019185: Inconsistency between JapaneseEra start dates and
java.util.JapaneseImperialDate
Observes a minor discrepancy between the java.util.Calendar Japanese
implementation
and the java.time JapaneseEra.
Looks fine to me
Stephen
On 12 August 2013 19:03, roger riggs roger.ri...@oracle.com wrote:
Please review test fixes related to changes of Hijrah localization data.
[1] 8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing
[2] 8022766:
On 25 July 2013 21:46, Jonathan Gibbons jonathan.gibb...@oracle.com wrote:
First, as was pointed out earlier[1] in the original thread, the HTML 4 spec
does not mention the existence of self-closing elements, and in that
message,
David makes a good point that br is defined to not have an end
On 26 July 2013 13:58, David M. Lloyd david.ll...@redhat.com wrote:
On 07/26/2013 04:39 AM, Stephen Colebourne wrote:
Its websites and
browsers that define what should be accepted as HTML, not standards.
This is the craziest thing I've read all week.
What percentage of the worlds websites
On 26 July 2013 14:49, David M. Lloyd david.ll...@redhat.com wrote:
You took one step outside of logic, in my opinion. Yes, the spec is a
guide, in practice. But to use that to justify not even trying to conform
or not encouraging people to conform is crazy. Without the spec, the HTML
world
On 26 July 2013 14:44, roger riggs roger.ri...@oracle.com wrote:
The html subset that appears in javadoc comments does not exist in isolation
or in a full browser context.
It is deliberately limited and structured to work within a documentation
framework
defined by javadoc and supported by
Its complicated, see for example:
http://stackoverflow.com/questions/3558119/are-self-closing-tags-valid-in-html5
The key point here is not whether its in the standard or not, but what
people actually *do*.
There is no doubt in my mind that br / br space slash is very common
indeed. Its
On 12 July 2013 00:04, Mike Duigou mike.dui...@oracle.com wrote:
Implementation would ideally be via new dedicated immutable classes,
however space could be saved by simply reusing the existing classes.
I would prefer to use existing Collections implementations. Primarily because
they have
Just to note that I am supportive of this bug fix (compared to the
previous proposal)
Stephen
On 3 July 2013 19:09, Brian Burkhalter brian.burkhal...@oracle.com wrote:
On Jul 3, 2013, at 10:47 AM, Brian Burkhalter wrote:
I'll update this only to change the one public method and to modify its
Sending this on to core-libs-dev to try to get a response ;-)
Stephen
On 24 June 2013 16:14, Stephen Colebourne scolebou...@joda.org wrote:
One point lambdaification that I haven't seen mentioned is addition
static factory methods for the main collection interfaces. (Strictly,
this proposal
Like others, I would prefer isNotNull() to notNull(). Mainly for
consistency, but also for dicoverability is IDE autocomplete (as the
methods would then be next to one another)
Stephen
On 30 April 2013 23:45, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
Another changeset coming from
On 19 June 2013 08:08, Peter Levart peter.lev...@gmail.com wrote:
I'd also like to suggest something. You have made lots of tests that cover
the functionality of new default methods in Map and other collections
interfaces which prove the correctness of behaviour when used with
implementations
The standard JDK bug tracker should be used to keep track of these.
For info, Oracle is in control of integration of JSR-310 into other
APIs, not JSR-310.
Stephen
On 17 June 2013 09:40, Nick Williams
nicholas+open...@nicholaswilliams.net wrote:
On Jun 15, 2013, at 1:34 PM, Nick Williams
On 17 June 2013 12:40, Alan Bateman alan.bate...@oracle.com wrote:
On 17/06/2013 11:05, Nick Williams wrote:
Thanks. I have filed two different bugs for these two different problems.
Here they are:
8016743: java.text.MessageFormat does not support java.time.* types
8016742: JAXB does not
I'd humbly suggest that a sneakyThrow would be a very desirable
addition to the public JDK API.
Stephen
On 25 May 2013 12:35, Alan Bateman alan.bate...@oracle.com wrote:
On 24/05/2013 19:14, Martin Buchholz wrote:
:
Alan, you're telling everyone there's no need for Thread.stop, but you are
I would suggest a new line at the end of each file.
Plus there is some very stylised formatting in terms of making things
align vertically that I wouldn't do personally, and seem to waste a
lot of screen space. Plus a single line which should be three lines.
public void close() { closed = true; }
As far as I can tell, there are three different styles being used for
public modifiers in interfaces now:
1) no use of public
2) use of public only on default methods
3) use of pubilc on default and abstract methods
(I can't recall seeing any static methods on interfaces outside of JSR-310 yet)
While I disagree with the choice made (one of Java's strengths is a
little bit of extra verbosity), I am happy if it is consistent. Based
on the links I provided, clearly Project Lambda has a long way to go
to meet that consistency, so it clearly hasn't been a firm
recommendation up until now.
On 19 February 2013 06:58, Joe Darcy joe.da...@oracle.com wrote:
diff -r bcde0486261e
src/share/classes/java/time/format/DateTimeFormatterBuilder.java
--- a/src/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon
Feb 18 08:14:18 2013 +
+++
On 19 February 2013 10:27, Weijun Wang weijun.w...@oracle.com wrote:
I'm using LinkedList to maintain a history
Don't use LinkedList. Multiple benchmarks down the years have shown it
is almost always worse than ArrayList.
Stephen
and the elements are ordered by
their timestamps. Every now
Thanks for continuing to look at this with Brian
I also had this response on twitter - my most hated Java bug, top 1
https://twitter.com/temerev/status/300204751931453440
Stephen
On 15 February 2013 05:54, Joe Darcy joe.da...@oracle.com wrote:
On 02/08/2013 02:37 PM, Stephen Colebourne wrote
On 8 February 2013 11:00, Florian Weimer fwei...@redhat.com wrote:
8007392: JSR 310: DateTime API Updates
Webrev:
http://cr.openjdk.java.net/~sherman/8007392/
http://cr.openjdk.java.net/~sherman/8007392/javadoc
I don't think you mention that the reference to ISO 8601 actually refers to
On 8 February 2013 00:23, Remi Forax fo...@univ-mlv.fr wrote:
I wonder if it's not better to declare enum constants of DayOfWeek (and
Month) in an order that is not the usual week/month order to make clear that
ordinal() doesn't work as expected.
By example they can be declared in alphabetical
implemented that
way for about 9 years.
-Joe
Bruce
On 7/02/2013 12:16 p.m., Stephen Colebourne wrote:
On 5 February 2013 09:09, Paul Sandoz paul.san...@oracle.com wrote:
This is one of those unfortunate cases where a bug can become a
feature.
I *really* don't see how.
The method name
On 7 February 2013 07:32, Bruce Chapman brucechap...@paradise.net.nz wrote:
Stephen, In your case(s) would the workaround fail to work if the bug was
fixed?
No. The workaround would handle the fixed implementation just fine.
And all workarounds would ultimately be similar to mine.
On 5 February 2013 22:16, Joe Darcy joe.da...@oracle.com wrote:
This review is both to cover the addition of @FunctionalInterface to the
types above and also to query if the annotation should be included in any of
the other types below under the same bug. The sub-areas I have not
annotated
On 5 February 2013 09:09, Paul Sandoz paul.san...@oracle.com wrote:
This is one of those unfortunate cases where a bug can become a feature.
I *really* don't see how.
The method name is absolutely clear about its purpose. Strip trailing
zeros. Anyone relying on it not stripping zeroes for zero
On 4 February 2013 18:09, Brian Burkhalter brian.burkhal...@oracle.com wrote:
While stripTrailingZeros() should perhaps for purity of specification always
return BigDecimal.ZERO for anything which is numerically equal to zero, the
present behavior of this method has been extant for some
On 4 February 2013 19:31, Joe Darcy joe.da...@oracle.com wrote:
The stripTrailingZeros method has acted in this surprising way since the
IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped
in 2004.
This situation is analogous to when the specification and behavior
I would encourage null checking to be done first, rather than
sometimes getting StringIndexOutOfBoundsException for a null input.
Reasoning about the JDK methods is much easier that way around.
Stephen
On 9 January 2013 23:09, Mike Duigou mike.dui...@oracle.com wrote:
AbstractStringBuilder
On 27 November 2012 02:12, Mike Duigou mike.dui...@oracle.com wrote:
In the original patch which added the basic lambda functional interfaces,
CR#8001634 [1], none of the interfaces extended other interfaces. The reason
was primarily that the javac compiler did not, at the time that 8001634
On 27 November 2012 17:32, Mike Duigou mike.dui...@oracle.com wrote:
It is vitally important to get this kind of formatting/style correct.
Developers the world over will be copying what the style is in these
classes.
I totally agree that we should be consistent but I don't believe that
On 14 November 2012 04:09, Henry Jen henry@oracle.com wrote:
This is a change set regarding Comparator already in lambda repo, it
depends on the CR#8001634, particularly the Function SAMs.
It implements proposed extension methods on Comparator
(reverse and compose) as well as static
On 13 November 2012 19:05, Mike Duigou mike.dui...@oracle.com wrote:
- Mapper.map becomes Function.apply
- Factory.make becomes Supplier.get
- Specializations of Supplier for int, long, double
- Reorder type variables to put result last
- Fixes many javadoc and stylistic comments.
What
The class level javadoc is quite short. It also has hyperlinks in the
first sentence, which means that they are visible in package level
javadoc. Consider having no hyperlinks in the first sentence, and
expanding a little on what base 64 is.
There are lots of other public base 64 implementations
On 10 October 2012 15:22, Roger Riggs roger.ri...@oracle.com wrote:
A reviewer is needed for:
6282196 There should be Math.mod(number, modulo) methods
The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
Just to note that floorMod(long, int) is not present. This is often
useful as
On 22 August 2012 10:46, Alan Bateman alan.bate...@oracle.com wrote:
On 21/08/2012 21:45, Jim Gish wrote:
Please review http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/
http://cr.openjdk.java.net/%7Ejgish/6984084-jdk8-StringRepeat/
This started in lambda, making changes to both
On 06/12/2012 07:40 AM, David Holmes wrote:
On 12/06/2012 7:59 AM, Jim Gish wrote:
My personal feeling is that pre-conditions should be explicitly checked
for and be spec'd.
This is very, very common in the core libraries. Rather than document
every single method where a null parameter
Can you explain why the mod implementation differs from that in JSR-310?
https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/MathUtils.java#L401
The code ((a % b) + b) % b; is short and involves no branches, which
should aid performance and inlining. Is this to do with
Thanks for the explanation, I don't think that the change in floorDiv
behaviour will cause JSR-310 a problem
Stephen
On 22 February 2012 16:21, Roger Riggs roger.ri...@oracle.com wrote:
On 02/22/2012 09:37 AM, Stephen Colebourne wrote:
Can you explain why the mod implementation differs from
On 11 February 2012 17:31, Roger Riggs roger.ri...@oracle.com wrote:
Updated the webrev for CR6708398:
http://cr.openjdk.java.net/~rriggs/6708398.2
- Added a paragraph to the class javadoc for Math and StrictMath to
introduce the exact arithmetic methods and their uses.
-
On 6 February 2012 21:15, Roger Riggs roger.ri...@oracle.com wrote:
Separately but related, there are missing methods in BigInteger,
longValueExact() and intValueExact()
BigInteger provides a bitLength method than be tested to see if the result
would overflow. That's a better API than an
On 6 February 2012 21:16, Roger Riggs roger.ri...@oracle.com wrote:
* Removed the negateExact methods since they don't pull their weight
in the API,
simple tests for MIN_VALUE and MAX_VALUE can be done by the
developer more efficiently.
Sorry, but I can't agree with this. Developers
I prefer the method naming safeAdd/safeNegate/safeMultiply (I think
they are a lot clearer), but can live with the ones proposed (which
are somewhat linked to BigInteger/BigDecimal).
I would like to see source code comments explaining why the algorithm
works in the final version in OpenJDK. Thats
On 3 February 2012 17:52, Eamonn McManus eam...@mcmanus.net wrote:
I agree with Stephen Colebourne that brief implementation comments would be
useful. But I disagree with his proposed further methods in Math
(increment, decrement, int+long variants), which I don't think would pull
their weight
This message is forwarded from Apache Commons, where a question was
raised as to whether the change in behaviour of year formatting in JDK
7 was deliberate:
Stephen
-- Forwarded message --
From: Jörg Schaible joerg.schai...@gmx.de
Date: 12 July 2011 18:56
Subject: Re: [lang] RC4
On 26 May 2011 03:27, David Holmes david.hol...@oracle.com wrote:
It hadn't occurred to me before but the more precise rethrow semantics are
basically making the same invalid assumption about where checked exceptions
can be thrown. Before if you catch Throwable and want to rethrow then you
As I said before, removing this method is the best option now. Get it
right in v8.
Stephen
On 27 January 2011 05:05, mark.reinh...@oracle.com wrote:
Executive summary: requireNonNull is the preferred name.
Date: Tue, 25 Jan 2011 18:33:47 -0500
From: brian.go...@oracle.com
On 17 January 2011 05:26, Brian Goetz brian.go...@oracle.com wrote:
My aversion to checkNonNull naming pattern comes from experience. Long,
long ago in a code base far, far away I wrote a big set of unit tests
using this pattern. Coming back to it months later I had to read the
code very
There are a number of strands to this thread
1) Null useful or not.
There are arguments on both sides here, and developers are divided.
Personally, I use null every single day to use not known or not
required, such as in a search request:
/**
* The set of exchange object identifiers, null
While I support Kevin´s summary, having a public implementation of
Map.Entry in java.util would be very useful. (Along with making other
private classes public - unmodifiable iterator is one IIRC)
Stephen
On 30 March 2010 13:54, Kevin Bourrillion kev...@google.com wrote:
Pair is only a partial,
(I´m writing from a slow connection in a national park in Chile)
I meant a decortator for an iterator that wraps the original making it
immutable.
Stephen
On 30 March 2010 16:55, Martin Buchholz marti...@google.com wrote:
On Tue, Mar 30, 2010 at 13:39, Stephen Colebourne scolebou...@joda.org
ListPeriodField periods
private final transient int hashCode
private Object readResolve() throws java.io.ObjectStreamException {
return new MyImmutableClass(name, duration, firstPeriod); //you can
define a private constructor if required
}
On Sat, Jan 30, 2010 at 7:44 PM, Stephen Colebourne
13:35, Alan Bateman alan.bate...@sun.com wrote:
Stephen Colebourne wrote:
I thought I'd raise an issue with serialization that I've had a problem
with more than once. Perhaps there is an obvious easy solution, but I can't
see it (I can see hard workarounds...)
In JSR-310 we have lots
I thought I'd raise an issue with serialization that I've had a problem
with more than once. Perhaps there is an obvious easy solution, but I
can't see it (I can see hard workarounds...)
In JSR-310 we have lots of immutable classes. One of these stores four
fields:
private final String
2009/11/16 David Holmes - Sun Microsystems david.hol...@sun.com:
In this specific case, the question was why include it when you can
use a?b:c. Well, I've seen resistance by developers to that language
feature, and I know some places outright block it in coding standards.
For many, a method
Martin Buchholz wrote:
On Wed, Nov 11, 2009 at 10:10, Ulf Zibis ulf.zi...@gmx.de
mailto:ulf.zi...@gmx.de wrote:
At least, IMO, fileSeparator() and pathSeparator() would belong to
java.io.File or java.nio.file.FileSystem.
Those would have been better names,
but at this point they are not
2009/11/10 Mark Reinhold m...@sun.com:
Yet ... how much of a problem is this outside of the JDK itself and,
more generally, for new code rather than old?
If there are n (for n = 43) problematic uses in the JDK then we could
just fix those without defining any new public API. For new code we
Not wishing to confuse the debate, but perhaps the correct place for
this is a static Strings class, that parallels Objects.
We all know that there are lots of possible methods for such a class,
but even if JDK7 had just a few, that would be a good start.
Joe, would you be prepared to sponsor a
This isn't one I've seen much use for.
It would also be possible to write it as a decorating wrapper for a
map, rather than as a static utility method.
Stephen
2009/10/25 assembling signals assembling.sign...@yandex.ru:
Hello!
I am thinking about a new method getSafe(...) for the
All,
While I agree that the nonNull methods below are useful and should be in
the JDK, I question whether they should be on j.u.Objects.
I believe that there is a whole category of methods to pre-validate the
arguments of a method, such as Commons Lang Validate, or Google Prevalidate.
Joseph D. Darcy wrote:
If such a validation class is added to the platform, the nonNull
methods can be moved there. Until then, they can live in Objects.
At first glance, such an approach makes perfect sense. However, we
should really stop and question whether it is right or not.
One point
...@sun.com:
David Holmes - Sun Microsystems wrote:
Stephen Colebourne said the following on 10/07/09 18:10:
BTW, I don't accept the argument that one and only one way to do
something is part of the JDK.
While the JDK is far from a model example of providing one way to do
something
Paul Benedict wrote:
If you want Objects.toString() to provide value, consider mimicking
the functionality from Apache Commons:
http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/ObjectUtils.html
My biggest complaint about String.valueOf(Object) is that it will
actually return null
Joe Darcy wrote:
What other utility methods would have broad enough use and applicability
to go into a common java.util class?
Joe,
You've asked for a call for ideas, but not given any indication of
process. Are you going to evaluate everything that comes in and pick the
best a la Coin? Or
I've been reviewing the Javadoc for the JDK 7 Currency class changes.
http://download.java.net/jdk7/docs/api/java/util/Currency.html
The updates appear to allow users the ability to override the built in
currency data, as indicated in the class javadoc:
Users can supersede the Java runtime
I was actually interested in the thrust of the original question, let me
rephrase it.
If you wanted to code from scratch a JVM, but not include the rest of
the Java SE platform (such as the .class files), what would you need to
include? Is Object.class mandatory for a pure JVM? Anything else?
2009/6/8 Doug Lea d...@cs.oswego.edu:
It is possible to use a look-aside strategy for tiny
HashMaps. I think one of the Apache commons maps
does this.
FYI - Commons Collections Flat3Map:
http://commons.apache.org/collections/api-3.2/org/apache/commons/collections/map/Flat3Map.html
Stephen
There is some talk of adding a group of new methods to low level
classes: http://smallwig.blogspot.com/2007/11/minor-api-fixes-for-jdk-7.html
Personally, I would like to see this extended to become a simple JSR
where ideas such as ltrim/rtrim and so on can be evaluated properly.
ie. take each
401 - 483 of 483 matches
Mail list logo
