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
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
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.
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
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
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.
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
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
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
+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
A set of minor wording fixes in Javadoc:
https://gist.github.com/jodastephen/8984256
Comments welcome.
Stephen
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
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
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()
-
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() ||
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
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
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:
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 =
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
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
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
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
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
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
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
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
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
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 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
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 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
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
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 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
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 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 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
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 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
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.
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; }
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
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
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
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
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
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
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
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 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
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:
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.
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
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
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'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
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 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
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
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 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
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
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
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
/~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
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
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
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
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
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
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
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 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
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
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
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
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.
-
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 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
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
1 - 100 of 483 matches
Mail list logo
