Its a fair question. Certainly the stream construction you suggest will do the
job; you’re looking for a more compact way to do it. Note that of course you
could write your own static method that encapsulates the stream operation and
you’d be done.
Map.replace/replaceAll are in-place, mutativ
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 the first 10 primes are correctly identified as probably
prime
2 - checking tha
This change proposes to remove granting all permissions for extensions
as the default and implements the principle of least privilege.In JDK 9,
we want to reduce the privileges of as many system classes as possible.
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/
This patch
Hi, Paul.
> Do you want to become an openJDK contributor? I don't see you in the OpenJDK
> census.
>
> If you become a contributor:
>
> http://openjdk.java.net/contribute/
>
> then i can directly accept patches from you and commit them with you as the
> author
I'm sure this is what you meant,
On 04/22/2014 09:53 AM, Peter Levart wrote:
On 04/22/2014 02:48 PM, David M. Lloyd wrote:
On 04/22/2014 04:17 AM, Peter Levart wrote:
On 04/22/2014 12:02 AM, David M. Lloyd wrote:
Um, do we *know* that there is a performance cost to covariantly
overriding these methods? There would seem to be
Sherman,
Is it better to group zipfs in jdk_nio?
Mandy
On 4/22/2014 7:44 AM, Xueming Shen wrote:
Looks good.
On Apr 22, 2014, at 6:05 AM, Lance Andersen wrote:
Here is the diff for this via bug 8041485
hg diff test/Test.groups
diff -r 3aeb306d985c test/TEST.groups
--- a/test/TEST.groups
On 04/22/2014 02:48 PM, David M. Lloyd wrote:
On 04/22/2014 04:17 AM, Peter Levart wrote:
On 04/22/2014 12:02 AM, David M. Lloyd wrote:
Um, do we *know* that there is a performance cost to covariantly
overriding these methods? There would seem to be enough information
to keep them monomorphic,
Looks good.
> On Apr 22, 2014, at 6:05 AM, Lance Andersen wrote:
>
>
> Here is the diff for this via bug 8041485
>
> hg diff test/Test.groups
> diff -r 3aeb306d985c test/TEST.groups
> --- a/test/TEST.groupsTue Apr 22 08:57:01 2014 -0400
> +++ b/test/TEST.groupsTue Apr 22 09:01
Hi Frank,
On Apr 22, 2014, at 12:10 PM, Frank van Heeswijk wrote:
>
> Hello,
>
> First of all, this is the first time I am sending a mail to any java mailing
> list,
Welcome!
> so please correct me if I did something wrong.
>
> I am a regular visitor and answered on stackoverflow (
> http
On 04/22/2014 08:24 AM, Paul Sandoz wrote:
On Apr 22, 2014, at 2:48 PM, David M. Lloyd wrote:
If the methods were final, AFAICT it'd be more like this:
public final ByteBuffer position(int newPosition) {
// iirc super upcall is already bytecoded as invokespecial
invokespecial (Buffer)
On Apr 22, 2014, at 2:48 PM, David M. Lloyd wrote:
>
> If the methods were final, AFAICT it'd be more like this:
>
> public final ByteBuffer position(int newPosition) {
>// iirc super upcall is already bytecoded as invokespecial
>invokespecial (Buffer)Buffer.position(newPosition);
>r
Looks good to me Lance.
-Chris.
On 22 Apr 2014, at 14:05, Lance Andersen wrote:
>
> Here is the diff for this via bug 8041485
>
> hg diff test/Test.groups
> diff -r 3aeb306d985c test/TEST.groups
> --- a/test/TEST.groupsTue Apr 22 08:57:01 2014 -0400
> +++ b/test/TEST.groupsTue
Here is the diff for this via bug 8041485
hg diff test/Test.groups
diff -r 3aeb306d985c test/TEST.groups
--- a/test/TEST.groups Tue Apr 22 08:57:01 2014 -0400
+++ b/test/TEST.groups Tue Apr 22 09:01:26 2014 -0400
@@ -194,7 +194,7 @@
com/sun/jndi \
com/sun/corba \
lib/testlibrary
On 04/22/2014 04:17 AM, Peter Levart wrote:
On 04/22/2014 12:02 AM, David M. Lloyd wrote:
Um, do we *know* that there is a performance cost to covariantly
overriding these methods? There would seem to be enough information
to keep them monomorphic, if the optimizer is smart enough to inline
the
On 22 Apr 2014, at 12:22, Lance Andersen wrote:
> ….
>
> The revised webrev is at http://cr.openjdk.java.net/~lancea/8041331/webrev.01/
Looks good to me Lance.
-Chris.
>
> Best
> Lance
>>
>> Thanks,
>>
>> s'marks
>>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.
Thank for your opinion.
Done this way to keep the pattern.
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/java/lang/invoke/BoundMethodHandle.java
Hello!
If a BitSet has the bit Integer.MAX_VALUE set, then calling toString()
will throw an exception.
The same thing happens if the bit (Integer.MAX_VALUE-1) is set.
Would you please help review the fix for this issue?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8040806
WEBREV: http://c
Hi Otávio,
These look like good finds. I bet there are lots more of them.
IntelliJ reports 284 possible uses in src/share/classes (see the
"'StringBuffer' may be 'StringBuilder'" migration aid), but i have not verified
all those. Perhaps we should do this more systematically over all the Java
Hi Stuart
On Apr 21, 2014, at 9:26 PM, Stuart Marks wrote:
>
>
> On 4/21/14 1:58 PM, Lance Andersen wrote:
>> Need a reviewer for some additional updates of the SQLException tests I
>> pushed on Friday so that they play nicer WRT clean up on windows with some
>> tools.
>>
>> Did some minor r
Hello,
First of all, this is the first time I am sending a mail to any java mailing
list, so please correct me if I did something wrong.
I am a regular visitor and answered on stackoverflow (
http://stackoverflow.com/users/2057294/skiwi ) and noticed that there are quite
a large amount of
On 04/22/2014 12:02 AM, David M. Lloyd wrote:
Um, do we *know* that there is a performance cost to covariantly
overriding these methods? There would seem to be enough information
to keep them monomorphic, if the optimizer is smart enough to inline
the bridge methods and the delegating override
Hi,
> It certainly spawns all kinds of questions that were on the agenda for
> lambda expressions, like:
> - what's the meaning of "this" inside the .{ ... } block?
> - what's the meaning of "break", "continue", "next", "return", (I
> guess it should be the same as with the ordinary lexical
On Apr 22, 2014, at 3:18 AM, Wang Weijun wrote:
> If I copy a file to another I can
>
> try (src = open(ifile); dest = open(ofile)) {
>while (!src.EOF) dest.write(src.read());
> }
>
> but what if there are multiple destinations? Is there something like
>
Not that i am aware of.
A fun
Hi Otávio,
On Apr 21, 2014, at 3:06 PM, Otávio Gonçalves de Santana
wrote:
> Hello everyone, one question.
> Conditions that always returns true, is 'if' necessary?
I can imagine it is a left over from hacking in the fast path. IMHO better to
remove the if and comment the line below to retain
On 04/21/2014 11:51 PM, Richard Warburton wrote:
Hi Peter,
I'm suggesting this alternative, because Buffer methods can stay
final in this case. This is more JIT-friendly. And, if I'm not
mistaken, client code compiled using JDK8 onto which this API
change was backported, would st
On 04/22/2014 04:30 AM, Zhong Yu wrote:
On Mon, Apr 21, 2014 at 7:07 AM, Ulf Zibis wrote:
So to me, this is clearly a language matter, not to solve by tricky
footprint and/or performance lasting code on APIs:
People want a _smart syntax_ for consecutive method invocations on the same
object, th
26 matches
Mail list logo
