Bateman alan.bate...@oracle.com wrote:
On 16/10/2013 21:22, Mike Duigou wrote:
Hello all;
With the imminent promotion of JTReg 4.1b07 it's possible to finally
consider completing this changeset!
http://cr.openjdk.java.net/~mduigou/JDK-8015068/2/webrev/
This updated webrev includes
and fix it in the next round. (which redoes configure time detection of jtreg
and eliminates JT_HOME entirely).
Mike
Thanks,
David
On 6/11/2013 4:13 AM, Mike Duigou wrote:
One final set of changes was required based upon cross platform testing.
The revised webrev which passes cross
the jtreg executable is found.
http://cr.openjdk.java.net/~mduigou/JDK-8015068/4/webrev/
Mike
On Nov 5 2013, at 10:13 , Mike Duigou mike.dui...@oracle.com wrote:
One final set of changes was required based upon cross platform testing.
The revised webrev which passes cross platform testing on all
Thank you for the review!
On Nov 6 2013, at 09:11 , Alan Bateman alan.bate...@oracle.com wrote:
On 06/11/2013 03:51, Mike Duigou wrote:
I have updated the webrev to backout the changes to how JT_HOME is set. This
will be addressed in the next set of changes (8020779
https
Changeset: 9c30cbc316e9
Author:mduigou
Date: 2013-11-05 19:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c30cbc316e9
8021309: replace test/Makefile jdk_* targets with jtreg groups
8015068: Use jtreg -exclude for handling problemList.txt exclusions
Reviewed-by: jjg,
Hello all;
With JDK-8015068 only very recently pushed it's time for the next set of jtreg
test/Makfile changes. These changes improve the configure script detection of
jtreg and improve the handling of the specification variables in the jdk and
langtools test/Makefiles. This changeset is also
patterns for test/Makefile which are
still being used.
It will be a week or two before I try to finalize this changeset.
Thanks,
Mike
/Erik
On 2013-11-06 21:40, Mike Duigou wrote:
Hello all;
With JDK-8015068 only very recently pushed it's time for the next set of
jtreg test/Makfile changes
Hi Robert;
As mentioned in another thread with Steven Schlansker there is a patch in
progress with similar goals. I will look at your patch and see how much overlap
there is and merge in any relevant parts. This improvement won't make it into
Java 8 but will be implemented early in the Java 9
Hi Steven;
We were able to get some parts of your UUID patch into Java 8 but I
unfortunately didn't get time to get all the pieces in before the Java 8
rampdown began. I was hoping to get the parsing part in next as it seemed to
have a bigger payoff than the remaining toString() changes. These
- Collectors averagingDouble could use the same @implNote as in DoublePipeline.
- DoublePipeline implementation could document the usage of the double array
indices.
- @summary in test.
- I agree with Paul that refactoring as a testNG test would be nice.
- I wondered at the mechanism for
It could still be added in a future rev. setValue was less compelling and
obviously correct than Iterator.remove(). I had a version of Map.Entry earlier
on which provided provided setValue() along defaults for the required
implementations of hashCode() and equals(). The spec for these later two
On Nov 20 2013, at 16:31 , Remi Forax fo...@univ-mlv.fr wrote:
Hi mike,
On 11/21/2013 12:07 AM, Mike Duigou wrote:
It could still be added in a future rev.
yes, I've post that here as a remainder for the future generation :)
setValue was less compelling and obviously correct than
We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this issue.
I've posted a webrev here:
http://cr.openjdk.java.net/~mduigou/JDK-8029055/0/webrev/
There is an identical change in ConcurrentMap's merge().
Mike
On Nov 22 2013, at 16:01 , Henry Jen henry@oracle.com wrote:
implementations should refuse null value param
I have updated the webrev.
http://cr.openjdk.java.net/~mduigou/JDK-8029055/1/webrev/
Thanks,
Mike
Thanks,
David
On 23/11/2013 10:25 AM, Mike Duigou wrote:
We'll be using https://bugs.openjdk.java.net/browse/JDK-8029055 for this
issue.
I've
of what the improvements would be? The bug doesn't currently
capture what will be changed/improved.
Thanks,
-Joe
On 11/25/2013 09:57 AM, Mike Duigou wrote:
Looks good
Mike
On Nov 22 2013, at 23:06 , Joe Darcy joe.da...@oracle.com wrote:
Hello Mike and Paul,
Thanks for reviewing
Looks fine to me.
Mike
On Nov 27 2013, at 03:02 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
https://bugs.openjdk.java.net/browse/JDK-8029164
http://cr.openjdk.java.net/~psandoz/tl/JDK-8029164-thenCompose-async/webrev/
This fixes an issue with CompletableFuture.thenCompose.
If
Approved.
On Dec 3 2013, at 09:49 , Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review the patch before which addresses a handful of doclint issues in
javax.script.
Thanks,
-Joe
diff -r c11553506228 src/share/classes/javax/script/ScriptEngineFactory.java
---
The changes look OK.
The needs of mutable CharSequences to isolate the subsequence changes seems
adequately handled in the mutable classes.
Mike
On Dec 3 2013, at 10:15 , Stuart Marks stuart.ma...@oracle.com wrote:
Hi all,
Please review this small change to the subSequence() method specs
8029483: BufferedReader.lines() javadoc typo should be fixed
So that we can at least fix the javadoc by jdk8 release if not the
characteristic.
Cheers,
Henry
On 12/03/2013 10:52 AM, Mike Duigou wrote:
Looks good to me.
Mike
On Dec 3 2013, at 10:36 , Henry Jen henry
Hello all;
There's been a discussion on the lambda spec experts list
(http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a
notice to the Optional classes about implications of their likely future as
values. This discussion recently completed so now there's a doc patch to
the complexity. It kind of goes against the null is fully supported as a
value.
- merge where the existing mapping has a null value should not pass
the null to the function
This is the same as treating it as absent.
Stephen
On 26 November 2013 04:32, Mike Duigou mike.dui...@oracle.com
Looks fine.
On Dec 3 2013, at 17:40 , Stuart Marks stuart.ma...@oracle.com wrote:
Hi all,
Please review the following small javadoc change. The StringJoiner doc for a
couple methods uses i.e. in the first sentence, which screws up the javadoc
logic that pulls the first sentence into the
. That phrase is used at the beginning of the last paragraph of the
HTML doc, and it makes much more sense to me than unpredictable effects.
I prefer results to effects as well.
Mike
s'marks
On 12/3/13 2:21 PM, Mike Duigou wrote:
Hello all;
There's been a discussion on the lambda
Changeset: 2aae624bb833
Author:briangoetz
Date: 2013-12-03 21:22 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aae624bb833
8028816: Add value-type notice to Optional* classes
Reviewed-by: mduigou, smarks
Contributed-by: bitterf...@gmail.com
+
On Dec 6 2013, at 02:07 , Chris Hegarty chris.hega...@oracle.com wrote:
On 06/12/13 08:38, Paul Sandoz wrote:
On Dec 5, 2013, at 9:29 PM, Doug Lea d...@cs.oswego.edu wrote:
On 12/05/2013 03:18 PM, Brent Christian wrote:
I'm curious about why this was done:
*** 4452,4462
Hello all;
https://bugs.openjdk.java.net/browse/JDK-8029696
Michael McMahon noticed that some links to the anchor #NonInterference were not
using the correct name for the anchor. He prepared a patch which I reviewed,
tested. I also checked to make sure there were no other broken instances.
Hello all. I have updated the webrev with a final correction from Brian Goetz,
the @throws NPE didn't reflect that it was thrown unconditionally if value is
null.
http://cr.openjdk.java.net/~mduigou/JDK-8029055/2/webrev/
Mike
On Nov 25 2013, at 20:32 , Mike Duigou mike.dui...@oracle.com
On Dec 9 2013, at 11:49 , Martin Buchholz marti...@google.com wrote:
On Wed, Apr 17, 2013 at 4:51 PM, Mike Duigou mike.dui...@oracle.com wrote:
@apiNote : Non-normative notes about the API. Usually used for examples.
@implSpec : Describes required behaviour of conforming implementations
On Dec 9 2013, at 17:50 , Martin Buchholz marti...@google.com wrote:
Current ConcurrentMap.forEach
http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/ConcurrentMap.html#replaceAll-java.util.function.BiFunction-
has two different specs for the default method:
sense to rewrite get() in terms of getOrDefault() to reduce
duplication?
Thanks
Sent from my phone
On Dec 9, 2013 10:40 PM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
I've posted a webrev for review which corrects the problem and adds
appropriate tests.
http
On Dec 10 2013, at 01:06 , Paul Sandoz paul.san...@oracle.com wrote:
On Dec 10, 2013, at 5:14 AM, Martin Buchholz marti...@google.com wrote:
Hmmm... it was time that I studied Map.forEach I see you convert to
ISE to CME ...
(Synchronized maps (like Hashtable) do not implement
the total number of accesses.
Mike
On Dec 10 2013, at 01:52 , Paul Sandoz paul.san...@oracle.com wrote:
On Dec 10, 2013, at 10:47 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Dec 10, 2013, at 5:37 AM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
I've posted a webrev
Hello all;
This is a documentation only fix for a bug reported by Michael McMahon. The
reduce methods of the primitive streams classes currently reference an apply
method rather than the appropriate applyAsInt, applyAsLong or applyAsDouble
methods.
Changeset: 1298e476729c
Author:michaelm
Date: 2013-12-11 15:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1298e476729c
8029944: Primitive Stream reduce method documentation pseudo code misidentifies
apply method
Reviewed-by: mduigou
Contributed-by:
Hello all;
In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent
would generate a spurious access event for keys mapped to null when the
function returned null. This patch corrects that behaviour.
http://cr.openjdk.java.net/~mduigou/JDK-8030016/0/webrev/
The actual
Changeset: a7ed72627c3f
Author:mduigou
Date: 2013-12-13 13:34 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ed72627c3f
8029055: Map.merge implementations should refuse null value param
Reviewed-by: briangoetz, dl
! src/share/classes/java/util/HashMap.java
!
Hello all;
These two changesets were committed to JDK 8 forest. I wish to commit the same
changes to JDK 9.
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26028cb56c68
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ed72627c3f
Mike
If the changeset is the same, which it should be, then proceed.
Mike
On Dec 13 2013, at 16:19 , Brian Burkhalter brian.burkhal...@oracle.com wrote:
The patch in questions was already approved in this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/023611.html
so
Sandoz paul.san...@oracle.com wrote:
On Dec 11, 2013, at 1:27 AM, Mike Duigou mike.dui...@oracle.com wrote:
I have added tests and documentation for the other methods.
http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/
The documentation for some of the methods is ambiguous about how
Noted. Thank you.
Mike
On Dec 17 2013, at 05:51 , Paul Sandoz paul.san...@oracle.com wrote:
On Dec 17, 2013, at 4:42 AM, Mike Duigou mike.dui...@oracle.com wrote:
I've updated the documentation per Paul's suggestions. Specifically, in
addition to the existing put() and get() methods
Changeset: 8e133b86b9f8
Author:mduigou
Date: 2013-12-17 09:36 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e133b86b9f8
8029795: LinkedHashMap.getOrDefault() doesn't update access order.
Reviewed-by: psandoz
! src/share/classes/java/util/LinkedHashMap.java
!
These look good to me.
On Dec 19 2013, at 06:51 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
Here are some patches that migrate some code to use more up to date language
features. I will create a bug later on after feedback.
This is motivated from Brian's patches to lang tools.
+1
Mike
On Dec 20 2013, at 10:29 , Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review the patch below to fix
JDK-8030785: Missing since 1.8 javadoc for
java.lang.reflect.Method:getParameterCount
The Executable type was added in 8 so none of the method in Executable should
Approved. These changes are a reasonable solution and, as you say, we can
improve it further in future releases.
Mike
On Dec 22 2013, at 06:54 , Joe Darcy joe.da...@oracle.com wrote:
Hello,
Testing (eventually) revealed that changing the streams floating point sum
and average algorithms
If you navigate through
http://cr.openjdk.java.net/~chegar/8031142/specdiff/java/util/package-summary.html
it shows just the relevant diffs. It appears that the specdiff was generated
without an explicit --includes option which results in all the extra chaff.
Mike
On Jan 6 2014, at 09:05 ,
Coming in late but this looks like a very good change to me as well.
Mike
On Jan 2 2014, at 23:06 , Chris Hegarty chris.hega...@oracle.com wrote:
On 3 Jan 2014, at 02:14, Martin Buchholz marti...@google.com wrote:
OK, as you wish - this change is clear progress!
Thanks Martin.
I
Entirely reasonable. Approved.
Mike
On Jan 6 2014, at 13:41 , Joe Darcy joe.da...@oracle.com wrote:
Hello,
Please review the patch below to add a @SuppressWarning(serial) to
java.lang.Enum to resolve a lint warning in the core libraries.
Thanks,
-Joe
---
The implementation looks good. I would move construction of the listIterator to
before the toArray() for detection of concurrent modification (growing of the
list).
I believe we should fix this for 8 if possible.
Mike
On Jan 10 2014, at 03:21 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
On Jan 10 2014, at 05:42 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
Some tweaks to the Stream forEachOrdered operation:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/
The first tweak is to size the CHM used in ForEachOrderedTask, this avoids
On Jan 10 2014, at 10:09 , Chris Hegarty chris.hega...@oracle.com wrote:
On 10 Jan 2014, at 18:05, Dan Xu dan...@oracle.com wrote:
Hi Roger,
My macro is a little different from yours, which compares with -1 instead of
NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which
The docs changes look good to me.
Mike
On Jan 13 2014, at 05:39 , Paul Sandoz paul.san...@oracle.com wrote:
On Jan 10, 2014, at 3:01 PM, Alan Bateman alan.bate...@oracle.com wrote:
The implementation changes look good. I agree that the javadoc needs
changing as it's otherwise misleading as
Very helpful. Thank you for adding the comments.
Mike
On Jan 16 2014, at 03:26 , Paul Sandoz paul.san...@oracle.com wrote:
On Jan 10, 2014, at 2:42 PM, Paul Sandoz paul.san...@oracle.com wrote:
I have also removed the inconsistently applied synchronized block. Either we
apply it
On Jan 20 2014, at 07:18 , Paul Sandoz paul.san...@oracle.com wrote:
On Jan 20, 2014, at 3:18 PM, Chris Hegarty chris.hega...@oracle.com wrote:
It is good to clarify that the streams are closed.
I find the following updated wording a little odd, If a mapped stream is
{@code null} then
On Jan 26 2014, at 17:12 , Philip Hodges philip.hod...@bluewin.ch wrote:
Please please please drop StringJoiner from Java 1.8 before it is too late.
It is well past too late. The API has been frozen since August for all but
the most exceptional cases.
At first I thought they were cool. Then
Hello all;
This is a bit of cleanup I did back during Java 8 that got deferred due to it's
late arrival during the development cycle. I've updated it for Java 9.
http://cr.openjdk.java.net/~mduigou/JDK-8022854/0/webrev/
This change improves the implementation of System.setProperties(null)
On Jan 31 2014, at 11:50 , Martin Buchholz marti...@google.com wrote:
Jason,
Thanks for pointing that out. I'm sure I have seen those bugs before (when
I owned them!) but had suppressed the memory.
I'm currently the assignee for this bug.
I probably didn't try fixing them because there is
Seems like good changes.
ObjectStreamClass.java::
- Why not have getClassSignature() return an interned string? (that's if
interning is actually essential. Are we sure it's not just overhead?)
On Jan 31 2014, at 10:46 , Chris Hegarty chris.hega...@oracle.com wrote:
Forwarding to correct
On Jan 31 2014, at 15:09 , Jason Mehrens jason_mehr...@hotmail.com wrote:
Martin, Mike,
Totally agree with everything that has been said on this. Leaving it
'unresolved' or 'closed as will not fix' won't bother me.
Mike has it listed as a 'doc clarification only' so my suggestion
The condition that is causing the problem is not a collection containing null,
which is allowed, but that the provided collection c is itself null.
The problem was is a consequence of the following implementation:
IteratorE iterator = iterator();
while(iterator.hasNext()) {
I would prefer to leave the implementation as is and amend the documentation.
The difference in behaviour between the overloads seems OK since it will still
be valid for the Supplier to return null. The String overload reasonably allows
null since the Throwable(String) constructor allows null
On Feb 10 2014, at 04:33 , Doug Lea d...@cs.oswego.edu wrote:
Among the constraints on solution is that several of these
methods compile down to no-ops on many common platforms.
This is interpreted as a benefit. However, if the are no-ops only for the most
common platform (x86) then we are
This looks fine.
On Feb 11 2014, at 15:42 , Phil Race philip.r...@oracle.com wrote:
Here's a JDk8u webrev : -http://cr.openjdk.java.net/~prr/8031737.8u/
-phil.
On 2/11/14 2:28 PM, Phil Race wrote:
So since hg export/import doesn't apply cleanly and the dependency
chain seems, long and
Hello all;
This changeset consists of two small performance improvements for ArrayList.
Both are related to the lazy initialization introduced in JDK-8011200.
The first change is in the ArrayList(int capacity) constructor and forces lazy
initialization if the requested capacity is zero. It's
On Feb 24 2014, at 06:37 , roger riggs roger.ri...@oracle.com wrote:
Hi Ivan,
The code is correct as written but there might be some creep in the end time
due to the sampling of System.nanoTime.
I would be inclined to calculate the final time of the timeout once
and then compare simply
!
On 24.02.2014 22:26, Mike Duigou wrote:
On Feb 24 2014, at 06:37 , roger riggs roger.ri...@oracle.com wrote:
Hi Ivan,
The code is correct as written but there might be some creep in the end
time due to the sampling of System.nanoTime.
I would be inclined to calculate the final time
Or a suppressed exception.
Mike
On Feb 25 2014, at 06:14 , Roger Riggs roger.ri...@oracle.com wrote:
In some cases, I would expect that the exception being overridden
would/should become the 'cause' of the new exception so it is not cleared
but chained. Does JNI support that?
On the
On Mar 1 2014, at 06:07 , Yasumasa Suenaga y...@ysfactory.dip.jp wrote:
Hi David,
1. Generating debug symbols in the binaries (via gcc -g or whatever)
2. Generating debuginfo files (zipped or not) (FDS)
3. Stripping debug symbols from the binaries (strip-policy)
It may be that we don't
On Mar 4 2014, at 07:13 , Peter Levart peter.lev...@gmail.com wrote:
On 03/04/2014 01:14 AM, Brian Burkhalter wrote:
- add AtomicReferenceFieldUpdater-type constant for stringCache
initialization
Hi Brian,
By using volatile read and CAS, there's still a chance that multiple
On Mar 11 2014, at 01:05 , Sergey Kuksenko sergey.kukse...@oracle.com wrote:
Brian, Mike.
Could you explain what is the problem with the old caching?
Concern over heap pollution with extra string copies was the motivation to
ensure that only a single cached instance was ever returned.
Hello all;
The test java/util/Arrays/Correct.java (yeah, great name...) has failed
intermittently in nightly testing. Unfortunately the currently committed
version does not provide much information on the failure condition. This
changeset is a renovation of the test to hopefully provide
(i)==nullnbsp;:nbsp;o.equals(get(i)))},
Corrected. Thank you.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/
Mike
On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com wrote:
I've actually always used scp. :-)
Since I accepted all of your changes as suggested
no longer working?
On Tue, Mar 11, 2014 at 4:34 PM, Mike Duigou mike.dui...@oracle.com wrote:
On Feb 21 2014, at 14:56 , Martin Buchholz marti...@google.com wrote:
You should do tt - code conversion separately, and do it pervasively
across the entire JDK.
From your lips to God's ears I
branches in the common
case. Instead,
if (initialCapacity 0) this.elementData = new Object[initialCapacity];
else if (initialCapacity == 0) this.elementData = EMPTY_ELEMENTDATA;
else barf
Corrected.
Thanks as always for the feedback.
Mike
On Fri, Feb 21, 2014 at 2:41 PM, Mike
.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/
Mike
On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com
wrote:
I've actually always used scp. :-)
Since I accepted all of your changes as suggested and had no other
changes I
Looks good to me. There are some additional optimization opportunities but they
can certainly wait.
Mike
On Mar 14 2014, at 05:04 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
Looks good to me. There are some additional optimization opportunities but they
can certainly wait.
Mike
On Mar 14 2014, at 05:04 , Paul Sandoz paul.san...@oracle.com wrote:
Hi,
This patch overrides some default methods with more optimal ones for the
Arrays.asList implementation:
On Mar 14 2014, at 05:14 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
On 14.03.2014 16:02, David Holmes wrote:
Ivan,
On 14/03/2014 9:19 PM, Ivan Gerasimov wrote:
Thanks Peter for the comments.
On 14.03.2014 14:53, Peter Levart wrote:
On 03/14/2014 08:05 AM, Ivan Gerasimov wrote:
Looks good.
On Mar 18 2014, at 11:37 , Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Sorry, here's the link:
http://cr.openjdk.java.net/~igerasim/8014066/4/webrev/
On 18.03.2014 22:28, Ivan Gerasimov wrote:
Hello!
Would you please take a look at the next iteration of webrev?
I
Definitely a useful macro.
I too would prefer a name like TO_JBOOLEAN since it reveals the result type.
Also all uppercase to identify it as a macro. If we are paranoid and want to
reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps.
I would also define the macro as:
#define
I
On Mar 19 2014, at 15:01 , Brian Burkhalter brian.burkhal...@oracle.com wrote:
On Mar 14, 2014, at 7:17 AM, Brian Burkhalter brian.burkhal...@oracle.com
wrote:
On Mar 14, 2014, at 3:39 AM, Peter Levart wrote:
But in general it would be better to just use ThreadLocalRandom.current()
called JNU_CHECK_NULL to reduce collision
chances
and to make it clearer where it comes from ..
-phil.
On 3/19/2014 12:49 PM, Mike Duigou wrote:
Definitely a useful macro.
I too would prefer a name like TO_JBOOLEAN since it reveals the result
type. Also all uppercase to identify
On Mar 24 2014, at 12:25 , Martin Buchholz marti...@google.com wrote:
On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart peter.lev...@gmail.com wrote:
On 03/24/2014 06:52 PM, Martin Buchholz wrote:
On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart peter.lev...@gmail.com wrote:
What
Hello all;
Recently HotSpot gained additional support for transactional memory,
https://bugs.openjdk.java.net/browse/JDK-8031320. This patch is a libraries
followon to that change. RTM and other transactional memory implementations
benefit from clustering writes towards the end of the
The issue is that the comparison is done upon the signed most significant and
least significant long values.
At minimum UUIDs should be compared as if they were 128-bit unsigned values.
Beyond that, version (which is a type not a version) 1 and 2 UUIDs (time
based and DCE), should have a more
, Paul Sandoz paul.san...@oracle.com wrote:
On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote:
I also note that UUID does not currently support version 5, SHA-1, which it
should.
I am hoping to do other performance work on UUID within the scope of Java
9. Adding
On Apr 8 2014, at 01:03 , Paul Sandoz paul.san...@oracle.com wrote:
On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote:
The issue is that the comparison is done upon the signed most significant
and least significant long values.
At minimum UUIDs should be compared
On Apr 10 2014, at 03:21 , Chris Hegarty chris.hega...@oracle.com wrote:
On 10 Apr 2014, at 11:03, Ulf Zibis ulf.zi...@cosoco.de wrote:
Hi Chris,
Am 10.04.2014 11:04, schrieb Chris Hegarty:
Trivially, you could ( but of not have to ) use
java.nio.charset.StandardCharsets.ISO_8859_1 to
Shouldn't we be using the platform default character set rather than iso8859-1?
This change will change the charset used for all platforms not using iso885901
as their default.
It is certainly odd that sun.misc.CharacterEncoder(byte) and
sun.misc.CharacterDecoder(String) are not symmetrical
one keep it symmetrical without forcing a particular encoding?
Brian
On Apr 10, 2014, at 10:54 AM, Mike Duigou mike.dui...@oracle.com wrote:
Shouldn't we be using the platform default character set rather than
iso8859-1?
This change will change the charset used for all platforms
On Apr 10 2014, at 11:08 , Chris Hegarty chris.hega...@oracle.com wrote:
On 10 Apr 2014, at 18:40, Mike Duigou mike.dui...@oracle.com wrote:
On Apr 10 2014, at 03:21 , Chris Hegarty chris.hega...@oracle.com wrote:
On 10 Apr 2014, at 11:03, Ulf Zibis ulf.zi...@cosoco.de wrote:
Hi
Hello all;
This is a simple cleanup changeset that removes redundant initialization of
fields to null from a number of collection classes. These field initializations
may seem cheap but they do have a cost:
- For volatile fields there is a measurable cost on some benchmarks for these
extra
at 12:22 PM, Mike Duigou mike.dui...@oracle.com wrote:
Hello all;
This is a simple cleanup changeset that removes redundant initialization of
fields to null from a number of collection classes. These field
initializations may seem cheap but they do have a cost:
- For volatile fields
documentation value (suggesting that the
constructor will not assign a value; null is a valid value). How about
fixing javac instead?
On Fri, Apr 11, 2014 at 12:22 PM, Mike Duigou mike.dui...@oracle.com
wrote:
Hello all;
This is a simple cleanup changeset that removes redundant
On Apr 14 2014, at 18:25 , Martin Buchholz marti...@google.com wrote:
I'll retreat to being neutral on the overall idea.
In general, it *is* a best software engineering practice to do all the
reading and computing before doing all the writing at the end.
You'll break anyone who does the
Yes. This has been corrected.
Mike
On Apr 16 2014, at 08:19 , Martin Desruisseaux
martin.desruisse...@geomatys.fr wrote:
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
. Thank you.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/
Mike
On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com
wrote:
I've actually always used scp. :-)
Since I accepted all of your changes as suggested and had no other
)))},
Corrected. Thank you.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/2/webrev/
Mike
On Tue, Mar 11, 2014 at 5:20 PM, Mike Duigou mike.dui...@oracle.com
wrote:
I've actually always used scp. :-)
Since I accepted all of your changes as suggested
Hello all;
Revisiting this issue again at long last I have updated the proposed changeset
based upon Jason Mehren's most recent feedback.
http://cr.openjdk.java.net/~mduigou/JDK-8035584/4/webrev/
This version reverts the prior changes to toArray().
Mike
At long last I got back to this issue and discovered that there are some
lurking issues with property reinitialization. I've created a couple of bugs
for some of the shortcomings I discovered. None of these are caused by this
changeset. I would like to hold off completing this issue until we
, which is a data
race
+public boolean addAll(int index, Collection? extends E c) {
if (index 0 || index elementCount)
throw new ArrayIndexOutOfBoundsException(index);
On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou mike.dui...@oracle.com wrote:
Yes. This has
1 - 100 of 822 matches
Mail list logo
