Hi,
I propose a patch for:
https://bugs.openjdk.java.net/browse/JDK-8040892
Here's the webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/Collectors.duplicateKey/webrev.02/
There has already been a discussion on the lambda-dev about this bug:
http://mail.openjdk.java.net/pipermail/lamb
On Apr 23, 2014, at 1:48 AM, Brian Burkhalter
wrote:
> Hello,
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8026236
> Patch:http://cr.openjdk.java.net/~bpb/8026236/webrev.00/
>
> This test provides a rudimentary verification of isProbablePrime() by:
>
> 1 - checking that
Hi Peter,
IMHO such security manager usage by the test is v. fragile and we should try
and find a safer alternative if possible.
However, there may also be an issue with lambda form code. (About a month ago i
too was looking, internally, at this kind of issue and thought there was a
questionab
Hi Brian,
There seems to be a confusion between "upperBound" and the 1st "n"
primer numbers. You pass "upperBound" as the parameter "n" of the
parsePrimes() method which returns 1st "n" primes from the file (it can
return less primes if the file is smaller).
I suggest doing the following:
-
Hi,
* Yasumasa Suenaga [2014-04-04 10:56]:
> I've succeeded to make binaries which are contained debuginfo as following:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html
> $ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""
>
> I guess that we should run "make" abov
Hi Peter,
The limitation below is precisely what I referred to in my post in particular
with respect to the upper bound of non-primes tested.
Thank you for your observations: I will look into the ideas and repost a
revised patch later.
Regards,
Brian
On Apr 23, 2014, at 7:28 AM, Peter Levart
On 09/04/2014 15:51, Xueming Shen wrote:
> Hi,
>
> Please help review the fix for JDK-8039751.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8039751
> webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/
>
>
> This is the corner case (in 4 bytes sequence) we missed when fixing
diff -r 57c1da89ae1a src/share/classes/java/util/prefs/Base64.java
--- a/src/share/classes/java/util/prefs/Base64.java Wed Apr 16 12:32:36
2014 -0700
+++ b/src/share/classes/java/util/prefs/Base64.java Mon Apr 21 20:20:57
2014 -0300
@@ -57,7 +57,7 @@
int numFullGroups = aLen/3;
in
I would to add for news methods on Iterable, I believe it will helpful for
many Java Developers.
diff -r 3dd165facde7 test/java/util/Iterator/IteratorDefaults.java
--- a/test/java/util/Iterator/IteratorDefaults.java Wed Apr 09 12:26:00
2014 -0700
+++ b/test/java/util/Iterator/IteratorDefaults.j
Hello everyone, one question.
Conditions that always returns true, is 'if' necessary?
I found one.
diff -r 57c1da89ae1a
src/share/classes/java/lang/invoke/BoundMethodHandle.java
--- a/src/share/classes/java/lang/invoke/BoundMethodHandle.java Wed Apr 16
12:32:36 2014 -0700
+++ b/src/share/classes/j
Didn’t we just discuss this like a week ago?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026506.html
On Apr 17, 2014, at 12:30 AM, Otávio Gonçalves de Santana
wrote:
> I would to add for news methods on Iterable, I believe it will helpful for
> many Java Developers.
>
Yes I did a mistake, please ignore.
I sent twice but it had one week as delay.
Sorry
On Apr 23, 2014 2:01 PM, "Brian Goetz" wrote:
> Didn’t we just discuss this like a week ago?
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-April/026506.html
>
>
>
> On Apr 17, 2014, at 12:30 AM,
Just a few comments:
1. When you write a test that uses the jtreg /policy option, the policy
file overrides the system policy file. If the test depends on a standard
extension, then you may get SecurityExceptions unless additional perms
are granted. Thus, there are quite a few tests that defin
On 4/23/2014 1:10 PM, Sean Mullan wrote:
Just a few comments:
1. When you write a test that uses the jtreg /policy option, the
policy file overrides the system policy file. If the test depends on a
standard extension, then you may get SecurityExceptions unless
additional perms are granted. T
After exploring this bug when running my full application, I have a lead on
what seems to be a necessary condition/cause for it, and possibly a way to
create a short reproducible case. The isolated code I posted originally is
not enough.
Here is what I found out. First lets call the process my Jav
On Mar 13 2014, at 08:56 , Jason Mehrens wrote:
> Mike,
>
> The constructor modification looks good. The only other alternative I can
> think would be to use 'c.toArray(EMPTY_ELEMENTDATA)' to avoid creating an
> extra array. I'm guessing that version would not perform as well as your
> cu
On Mar 13 2014, at 09:53 , Martin Buchholz wrote:
> It's time to add general purpose public static final empty arrays to
> Arrays.java for Object, all the primitive types, and perhaps also String,
> instead of local copies scattered around the JDK; then have ArrayList use
> Arrays.EMPTY_OBJEC
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 dec
If a thread is created inside AccessController.doPrivileged(), it
seems to inherit AccessControlContext from the calling thread, is that
the expected/specified behavior?
I'm asking because I tried to solve this problem: A spawned Thread
contains strong references to all call stack class loaders th
On Thu, Apr 24, 2014 at 12:06 AM, Zhong Yu wrote:
> If a thread is created inside AccessController.doPrivileged(), it
> seems to inherit AccessControlContext from the calling thread,
sorry, I was mistaken; there is no such inheritance, the new thread is
indeed privileged.
> is that
> the expecte
21 matches
Mail list logo
