Hi, Joe and All
This is a test bug on 9-repo-jigsaw, jaxp tests failed due to internal class
access.
To fix this bug, I made the following changes:
1. moved the tests which test internal APIs to separate directory and added
@modules for them
2. for other tests which don't intend to test
On 14/05/2015 14:40, Andrew Haley wrote:
:
Fix:
http://cr.openjdk.java.net/~aph/8079459-3-jdk/
Testcase:
http://cr.openjdk.java.net/~aph/8079459-3-hs/
This looks good to me. We'll need to address the splitting of the tests
between two repos at some point.
-Alan.
On 15/05/15 08:41, Alan Bateman wrote:
his looks good to me. We'll need to address the splitting of the tests
between two repos at some point.
Well, we did discuss it at the time. It wasn't clear what was
being tested, the VM or the class library, and in the end the
answer was both. In the
I have provided Paul with an updated patch:
* The test has been updated using data provider and reduce as much repetition
as possible.
* The GS copyright notice from the main JDK patch. However we retain it on our
test cases as we developed ourselves. In our previous contributions where we
Hi Roger,
On 05/14/2015 03:44 PM, Roger Riggs wrote:
Hi Peter,
On 5/14/15 8:19 AM, Peter Levart wrote:
Hi Roger,
The new API using Optional(s) looks fine. In particular for the
ProcessHandle returning methods. They now either return
StreamProcessHandle or OptionalProcessHandle.
At some
After private discussion with Paul, here's an update:
http://cr.openjdk.java.net/~vlivanov/8079205/webrev.03
Renamed CallSite$Context to MethodHandleNatives$Context.
Best regards,
Vladimir Ivanov
On 5/14/15 3:18 PM, Vladimir Ivanov wrote:
Small update in JDK code (webrev updated in place):
Hi Roger,
On 05/15/2015 12:35 PM, Peter Levart wrote:
public class AsyncCompletableFuture ... {
/**
* Returns a new CompletionStage that, when this stage completes
* normally, completes with the given replacementResult.
*
* @param replacementResult the successful
On May 15, 2015, at 3:20 PM, Vitaly Davidovich vita...@gmail.com wrote:
Paul,
I don't think you're missing anything obvious (unless I am as well :)). What
you wrote is basically what I meant by creating static helper method in
Brett's own code that does exactly what you wrote. The
On May 15, 2015, at 9:41 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 14/05/2015 14:40, Andrew Haley wrote:
:
Fix:
http://cr.openjdk.java.net/~aph/8079459-3-jdk/
Testcase:
http://cr.openjdk.java.net/~aph/8079459-3-hs/
This looks good to me.
Saem here,
Paul.
On 13/05/2015 12:51, Claes Redestad wrote:
Hi,
9-b33 introduced a sustained regression in SPECjvm2008
xml.transform on a number of our test setups.
JDK-8058643 removed the check on value.length 0, which
means repeated calls to .hashCode() now do a store of the
calculated value (0) to the hash
On May 14, 2015, at 8:17 AM, Brett Bernstein brett.bernst...@gmail.com wrote:
I believe the linked sequence of messages refer to the addition of a
PriorityQueue constructor only taking a Comparator which was does appear in
Java 1.8. Did you have a link to something regarding the a
On 2015-05-15 15:23, Alan Bateman wrote:
On 13/05/2015 12:51, Claes Redestad wrote:
Hi,
9-b33 introduced a sustained regression in SPECjvm2008
xml.transform on a number of our test setups.
JDK-8058643 removed the check on value.length 0, which
means repeated calls to .hashCode() now do a
Hi everybody,
this is review request for: 8072839: JAX-B Plugability Layer: using
java.util.ServiceLoader
The JAX-B API changed a little bit - proprietary ServiceLoader-like code
has been replaced by java.util.ServiceLoader. This change is required by
Jigsaw, old configuration way still
On May 15, 2015, at 11:48 AM, Chan, Sunny sunny.c...@gs.com wrote:
I have provided Paul with an updated patch:
Here it is:
http://cr.openjdk.java.net/~psandoz/tmp/gs/sort/webrev.1/
In DualPivotQuicksort
63 /**
64 * The maximum length of run in merge sort.
65 */
66
Hi Frank,
Seems OK
Best
Lance
On May 15, 2015, at 5:48 AM, Frank Yuan frank.y...@oracle.com wrote:
Hi, Joe and All
This is a test bug on 9-repo-jigsaw, jaxp tests failed due to internal class
access.
To fix this bug, I made the following changes:
1. moved the tests which
I don't think you're taking the load factor into account.
https://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/collect/Maps.java?r=f8144b4df7eec5f1c9e6942d8d5ef734a8767fd9#110
You want to check (via reflection) that the size of the backing array is
unchanged if you
Hi Peter,
Some comments below...
On 5/14/15 3:50 AM, Peter Levart wrote:
Hi Derek,
On 05/13/2015 10:34 PM, Derek White wrote:
Hi Peter,
I don't have smoking gun evidence that your change introduces a bug,
but I have some concerns...
I did have a concern too, ...
On 5/12/15 6:05 PM,
Hello!
When constructing the map, the expected size is specified to be 256, but
then 510 elements are inserted.
A new whitebox test is provided, so the next time the number of entries
grows, the expected size will not be forgotten.
Would you please help review this fix?
BUGURL:
So, I'm pretty dubious, mostly because of the risks mentioned in the JEP.
If you need a flag-check and two code paths for every String method, that's
going to make the String class more slow and bloated, and make it very
difficult for the JIT compiler to do its job inlining and intrinsifying
calls
Hi all,
Please review this small API enhancement to add a default method asIterator()
to Enumeration that converts it into an Iterator.
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8072726/webrev.0/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8072726
Thanks,
On 16.05.2015 2:18, Martin Buchholz wrote:
I don't think you're taking the load factor into account.
Hm. You're right, HashMap's constructor expects the capacity as the
argument.
I was confused by IdentityHashMap, whose constructor expects the maximum
number of elements to be inserted.
Hi Dmitry, Peter,
I should read my email more frequently - I missed Dmitry's last webrev
email.
My comments on a preference for volatile over Unsafe are not a strong
objection to using Unsafe fences. I just don't have enough experience
with Unsafe fences yet to agree that this use is
On Thu, May 14, 2015 at 6:44 AM, Roger Riggs roger.ri...@oracle.com wrote:
At some point in the development of this API, the implementation
introduced the AsyncExecutor to execute synchronous continuations of the
onExit() returned CompletableFuture(s). What was the main motivation for
this
Yes, this is very subtle, and Brett mentioned it (albeit somewhat obliquely) in
an email on jdk9-dev: [1]
If someone needs to make a
heap and their data is Comparable, the corresponding constructor gives a
O(n) runtime. If their data uses a Comparator, the corresponding runtime
(using addAll)
Whoops, I believe you're right -- I completely overlooked that as well :(
On Fri, May 15, 2015 at 12:40 PM, Paul Sandoz paul.san...@oracle.com
wrote:
On May 15, 2015, at 6:15 PM, Louis Wasserman lowas...@google.com wrote:
http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm
I know injected fields are somewhat hacky, but there are a couple of conditions
here which would motivate their use:
1. The field is of a type not known to Java. Usually, and in this case, it is
a C pointer to some metadata.
We can make space for it with a Java long, but that is a size
Hi Frank,
The patch looks good. I'll check it in later today.
Thanks,
Joe
On 5/15/2015 8:35 AM, Lance Andersen wrote:
Hi Frank,
Seems OK
Best
Lance
On May 15, 2015, at 5:48 AM, Frank Yuan frank.y...@oracle.com
mailto:frank.y...@oracle.com wrote:
Hi, Joe and All
This is a test bug on
Go ahead and push.
(Optimizing test runs is pretty important long term)
On Thu, May 14, 2015 at 1:47 PM, Stuart Marks stuart.ma...@oracle.com
wrote:
On 5/14/15 1:22 AM, Daniel Fuchs wrote:
I'm curious: have you tried with using a lambda instead? changing:
394 static void check(String
Hi Brent,
1163 @Override
1164 public EnumerationObject keys() {
1165 return map.keys();
1166 }
I wonder if you should use:
public EnumerationObject keys() {
return Collections.enumeration(map.keySet());
}
instead.
ConcurrentHashMap.keys() returns an Enumeration which
Everybody,
Please review updated version.
http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.06/
JDK part provided by Peter Levart, so all credentials belongs to him.
-Dmitry
On 2015-05-14 23:35, Peter Levart wrote:
On 05/14/2015 10:11 PM, Peter Levart wrote:
Hi Dmitry,
On 5/13/15 8:53 AM, Mandy Chung wrote:
On May 12, 2015, at 2:26 PM, Peter Levart peter.lev...@gmail.com
wrote:
On 05/12/2015 10:49 PM, Mandy Chung wrote:
But I think it should be pretty safe to make the
java.util.Properties object override all Hashtable methods and
delegate to internal CMH so
On May 15, 2015, at 6:15 PM, Louis Wasserman lowas...@google.com wrote:
http://lcm.csa.iisc.ernet.in/dsa/node139.html suggests an algorithm for
heapifying an unsorted array in O(n), corroborated elsewhere at
http://courses.csail.mit.edu/6.006/fall10/handouts/recitation10-8.pdf .
Any
I was initially confused by this because it seems to attribute the
algorithmic difference to Comparable vs Comparator, which doesn't make any
sense
That's exactly what threw me off as well, but I didn't bother checking
(doh!). Anyway, I think the upside is we're all in agreement now that
Hello,
Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8080422
Just some HTML markup fix.
The affected packages should (probably) not be visible in the new
modular system, but nevertheless...
34 matches
Mail list logo
