Hello all
Le 15/04/14 18:14, Mike Duigou a écrit :
I have updated the webrev with what I hope is the final form:
http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/
The first changes in the javadoc contains {@code #keys keys} and
{@code #elements elements}. I presume that you mean
I had a random look at the Webrev for TreeModelEvent.java and saw the
following new code:
sb.append(Integer.toString(childIndices[counter]))
Wouldn't the following be slightly more efficient?
sb.append(childIndices[counter])
since Integer.toString(int) creates a temporary char[] array
Hi Brian
Le 23/09/14 00:34, Brian Burkhalter a écrit :
I created an alternate webrev using compile-time constants per your
suggestion:
http://cr.openjdk.java.net/~bpb/4477961/webrev.01/
On a very minor formatting detail, the change in StrictMath has a
misplaced empty line (before the
Hello all
I noticed that AbstractStringBuilder.indexOf(String, int) is implemented
as below:
public int indexOf(String str, int fromIndex) {
return String.indexOf(value, 0, count,
str.toCharArray(), 0, str.length(),
fromIndex);
}
The call to
Le 15/05/13 10:05, David Holmes a écrit :
There is a huge difference between blowing away a complete process
with kill and having a single thread starting to propagate an async
exception, unwinding its stack and executing finally blocks with
completely broken state invariants.
Given the
Hello all
I apologize if this question was already debated previously. I just wonder:
since JDK 7 defines an Object.requireNonNull(…) method for explicit checks of
argument value, does the Project-Coin expert group has considered the addition
of an explicit NullArgumentException extends
Hello all
I realize that this is a Java2D bug, but given that it is a simple
equals(Object)/hashCode() implementation issue maybe this list is still relevant...
AffineTransform.hashCode() method is inconsistent with equals(Object) when some
'double' values are 0.0 values of opposite sign.
Hello Phil
Le 09/11/11 18:37, Phil Race a écrit :
Please do register on 2d-dev and propose the 2D changes there.
Registration done, I will post in a few minutes.
The hashcode change
definitely needs discussion, I think there may be views on the NaN comparison
as my
understanding is that
Le 10/11/11 16:24, Joe Darcy a écrit :
The Float and Double changes look fine. I don't know why the constructors
were coded up that way;
Maybe because the Float(String) / Double(String) constructors were coded in Java
1.0, while the parseFloat(String) / parseDouble(String) methods were added
Hello all
On December 1, 2010, darcy committed a slight performance improvement to the
StrictMath.min/max methods with floating point arguments (commit 8aabca72877c).
The calls to the doubleToLongBits(double) method were replaced by calls to the
doubleToRawLongBits(double) method, and
Hello Joe
Le 22/11/11 04:20, Joe Darcy a écrit :
3) In if statements, replaced:
(a == 0.0d) (Double.doubleToLongBits(a) == negativeZeroDoubleBits)
by
(Double.doubleToLongBits(a) == negativeZeroDoubleBits)
since the later implies the former.
The performance properties of the two versions of
Hello all
Some widely-used exceptions which were defined in the old Java 1.0 days have
strange or obsolete javadoc @see tags:
http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalArgumentException.html
IllegalArgumentException declares @see Thread#setPriority(int). Why is
Le 12/04/12 10:57, Benedict Elliott Smith a écrit :
I think in this case it is reasonable to leave it to the user to ensure
that the input remains consistent for the duration of the call. It can be
documented if necessary, but as I say I think all imperative methods come
with that caveat by
If String.substring(int, int) now performs a copy of the underlying
char[] array and if there is no String.subSequence(int, int) providing
the old functionality, maybe the following implications should be
investigated?
StringBuilder.append(...)
Since, in order to avoid a
Le 26/06/12 20:10, Mike Duigou a écrit :
StringBuilder.append(string.substring(lower, upper));
by:
StringBuilder.append(string, lower, upper);
This would seem to be a good refactoring regardless of the substring
implementation as it avoids creation of a temporary object.
The
Le 29/01/15 04:43, Mandy Chung a écrit :
Throwing UOE is intentional so that applications depending on existing
behavior will be modified not to use this deprecated method. Making
it a no-op makes it harder to diagnose for applications depending on
the finalizers to be invoked on exit to
Le 27/02/15 16:47, Florian Weimer a écrit :
Maybe I misunderstood the multi-version JAR files proposal, but I
thought that the assumption there is that there are actual *source*
files which use newer features of the platform.
I really don't think this tooling support will provide sufficient
Hello all
java.util.ServiceLoader does not seem to support usage of a second
Iterator in the middle of a previous iteration. The attached Java file
provides two simple tests with a ServiceLoader iterating over two
elements. The first test creates two iterators and invokes their
hasNext() / next()
Le 24/02/15 09:09, Alan Bateman a écrit :
Right, it has never supported multiple iterators but as it's an
Iterable then it should unless specified otherwise. So I think this is
a bug (although one could argue that the usage is unusual, almost a
mis-use).
One use case is that in a
Hello Peter
Le 24/02/15 13:49, Peter Levart a écrit :
You could synchronize on the entire loop and just copy over the
service objects to another collection (say ArrayList).
Right, but I would like to keep the laziness instantiation behaviour.
If you really must combine laziness of
Le 06/03/2018 à 05:48, A Z a écrit :
> Citation about problems with Java floating point:
> https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
This paper is about complex numbers, operation overloading, handling of
NaN, /etc./ I don't think that they are making an argument for decimal
Le 08/01/2019 à 19:55, Hans Boehm a écrit :
> The IEEE standard does say that for quiet NaNs, the value (or one of them)
> "should" be preserved by most operations on the quiet NaN. I have not heard
> of implementations violating this for anything other than the "quiet" bit.
> Thus I don't
I’m deriving Java interfaces from the UML of ISO 19111 international
standard, and a though come to my mind. This is not a request for
changing anything in the Java language now, I’m just wondering if this
is something worth to be considered for the future. This proposal would
require javac to
Hello Rémi
Le 18/09/2018 à 00:28, fo...@univ-mlv.fr a écrit :
> - theoretically, the covariance is defined in term of sub-typing,
> trying to widen it's definition may have unintended consequences that
> need studying.
>
Agree that it would require studying. But we have a general guidance,
which
Hello Rémi
Thanks for your reply.
Le 17/09/2018 à 00:54, Remi Forax a écrit :
> The Java spec limit covariance to subtyping relationship only (there
> is no covariance between primitive types, or between a primitive type
> and it's corresponding wrapper), so you can not use Java to implement
>
Hello
Le 03/11/2020 à 21:30, fo...@univ-mlv.fr a écrit :
You know that you can not change the implementation of
Collectors.toList(), and you also know that if there is a method
Stream.toList(), people will replace the calls to
.collect(Collectors.toList()) by a call to Stream.toList() for
Le 06/11/2020 à 19:00, Alan Snyder a écrit :
(…snip…) But a question that deserves ongoing review is whether Java
should support immutable collections using a separate type hierarchy
(…snip…).
Maybe an alternative way (admittedly more difficult) to have immutable
collections without
On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов
wrote:
>> Non-static classes hold a link to their parent classes, which in many cases
>> can be avoided.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8261880: Remove
Hello A.Z
As far as I know, the difference in output that you observed between
Java and C/C++ is not caused by a difference in floating-point
computation, but in a difference in the way numbers are rounded by the
"printf" command. Java has a policy of showing all significant digits,
while C
Hello A.Z.
As Raffaello said, Java arithmetic does not have any more problem than
C/C++ when using IEEE 754. The "proof" of contrary is only an illusion
due to the rounding behavior of C/C++ output routines, as demonstrated
by Raffaello's code. Maybe some C/C++ code use Intel extended
Le 08/05/2022 à 10:56, Andrew Haley a écrit :
Some targets (x86, in particular) have intrinsics (log, trig) that are
faster than StrictMath and also more accurate. StrictMath is not about
accuracy, but cross-architecture down-to-the-last bit reproducibility.
Whether we still need that
Le 08/05/2022 à 14:15, Victor Williams Stafusa da Silva a écrit :
Was that using Java 17+, which included JEP 306 delivered?
No, but my understanding is that JEP 306 does not apply to Math versus
StrictMath behavior. In my understanding, the strictfp keyword was only
about the use of
32 matches
Mail list logo
