Hi Mike,
I suppose there could also be implementations of removeIf that always throw UOE
regardless of whether an element matched or not i.e. those that override just
to throw UOE.
So perhaps:
* @throws UnsupportedOperationException if elements cannot be removed
* from this
On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
I added a webrev
http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
a bit easier for this review.
Notes:
- change C-style int v[] declarations to Java-ish int[] v.
- catching SQLException should probably return false
On 09/15/2013 08:32 PM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
+1.
-Aleksey.
On 15/09/2013 17:32, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
Now that the hash seed functionality, which utilized ThreadLocalRandom, has been removed
from Hashtable and WeakHashMap we can update TLR to use the same seed initialization
Thanks for the input.
On Sep 16, 2013, at 4:58 AM, Aleksey Shipilev wrote:
On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote:
I added a webrev
http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be
a bit easier for this review.
Notes:
- change C-style int v[]
On 09/16/2013 03:12 PM, Lance Andersen - Oracle wrote:
Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/
Thumbs up.
-Aleksey.
On 09/16/2013 05:35 AM, Alan Bateman wrote:
On 15/09/2013 17:32, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
Now that the hash seed functionality, which utilized ThreadLocalRandom, has
been removed from Hashtable and WeakHashMap we can update TLR
On 09/16/2013 01:32 PM, Doug Lea wrote:
On 09/16/2013 05:35 AM, Alan Bateman wrote:
On 15/09/2013 17:32, Paul Sandoz wrote:
Hi,
http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/
Now that the hash seed functionality, which utilized
ThreadLocalRandom, has
been removed from
On 09/16/2013 02:46 PM, Peter Levart wrote:
The InetAddress.getLocalHost() might throw SecurityException in some
configurations (SecurityManager.checkConnect(localHostName, -1)). So
perhaps, the call should be wrapped by AccessController.doPrivileged(...).
Correction: SecurityException is not
Changeset: 4ce8148ffc4f
Author:jlahoda
Date: 2013-09-16 14:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4ce8148ffc4f
8021112: Spurious unchecked warning reported by javac
6480588: No way to suppress deprecation warnings when implementing deprecated
interface
On 09/16/2013 08:46 AM, Peter Levart wrote:
What worries me is that InetAddress.getLocalHost() involves name
service look-up. It depends on configuration, but on my computer, it takes about
5s to evaluate the hostname - IP mapping the first time the program is run.
NetworkInterface also has
Hi Peter,
Nice observation about name resolving.
On my MacBook, if i switch off the wifi, then 7 addresses are returned 4 for
the en0 and 3 for lo0. Seems overkill to use all of them and the
sub-interefaces, if any. I agree with Doug, selecting the first interface's MAC
address is probably
Changeset: 38378024a332
Author:sundar
Date: 2013-09-16 15:08 +0530
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/38378024a332
8024847: Java.to should accept mirror and external JSObjects as array-like
objects as well
Reviewed-by: hannesw, attila, lagergren
!
Hi Doug,
Perhaps it would be conservative to find the first non-loopback interface, if
any, just in case the first one in the enumeration is a loopback (which will
return a null byte array)?
e.g.:
while (ifcs.hasMoreElements()) {
byte[] bs =
On 16/09/2013 15:00, Paul Sandoz wrote:
Hi Peter,
Nice observation about name resolving.
On my MacBook, if i switch off the wifi, then 7 addresses are returned 4 for
the en0 and 3 for lo0. Seems overkill to use all of them and the
sub-interefaces, if any. I agree with Doug, selecting the
On 09/16/2013 03:54 PM, Doug Lea wrote:
On 09/16/2013 08:46 AM, Peter Levart wrote:
What worries me is that InetAddress.getLocalHost() involves name
service look-up. It depends on configuration, but on my computer, it
takes about
5s to evaluate the hostname - IP mapping the first time the
On 09/16/2013 04:25 PM, Alan Bateman wrote:
On 16/09/2013 15:00, Paul Sandoz wrote:
Hi Peter,
Nice observation about name resolving.
On my MacBook, if i switch off the wifi, then 7 addresses are
returned 4 for the en0 and 3 for lo0. Seems overkill to use all of
them and the sub-interefaces,
On Sep 16, 2013, at 10:50 AM, Doug Lea d...@cs.oswego.edu wrote:
try {
EnumerationNetworkInterface ifcs =
NetworkInterface.getNetworkInterfaces();
boolean retry = false; // retry once if getHardwareAddress is null
while
Hi,
could you please review the following webrev which contains the changes
needed in the 'jdk' repository in order to build the OpenJDK on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/8024265_jdk/
With this change and 8024854: Basic changes and files to build the class
library on AIX
Hi Doug,
This seems reasonable for majority of environments.
Regards, Peter
On 09/16/2013 04:50 PM, Doug Lea wrote:
On 09/16/2013 10:39 AM, Peter Levart wrote:
So perhaps the right strategy would be to get the hardware address of
the 1st
interface that has it, but don't bother to search
On some platforms, Windows, tunneling interfaces report a very bad mac
address, e.g. 00-00-00-00-00-00-00-E0. I wonder if it is worth skipping
all isVirtual() nifs?
-Chris.
On 16/09/2013 16:06, Peter Levart wrote:
Hi Doug,
This seems reasonable for majority of environments.
Regards, Peter
On 09/16/2013 09:02 PM, Doug Lea wrote:
(This might stand as a record for the most expert attention
spent on the least important issue ever in JDK :-)!
+1.
-Aleksey.
Changeset: 86aa8e7503e9
Author:henryjen
Date: 2013-09-16 10:28 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86aa8e7503e9
8024874: Copy-paste typo in the spec for j.u.Comparator.thenComparing(Function,
Comparator)
Reviewed-by: mduigou
!
Thanks for those interesting measurements, Sergey.
As you point out, the 8024761 changes are be more broadly beneficial to most
292 users, such as Nashorn and JRuby.
So I'm glad to hear they hit near the mark of the specialized tweak. We can
keep your tweak in our back pocket in case we need
On 09/16/2013 11:39 AM, Chris Hegarty wrote:
On some platforms, Windows, tunneling interfaces report a very bad mac
address, e.g. 00-00-00-00-00-00-00-E0. I wonder if it is worth skipping all
isVirtual() nifs?
Good idea. This makes it impossible to also take advantage of Guy's
Hi,
could you please review the following webrev which contains the basic
changes and files needed in the 'jdk' repository in order to build the
OpenJDK on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/8024854
This change together with 8024265: Enable new build on AIX (jdk
On 16/09/2013 18:37, Volker Simonis wrote:
Hi,
could you please review the following webrev which contains the basic
changes and files needed in the 'jdk' repository in order to build the
OpenJDK on AIX:
http://cr.openjdk.java.net/~simonis/webrevs/8024854
Hi Volker,
You'll probably need
On Sep 16, 2013, at 1:02 PM, Doug Lea d...@cs.oswego.edu wrote:
On 09/16/2013 11:39 AM, Chris Hegarty wrote:
On some platforms, Windows, tunneling interfaces report a very bad mac
address, e.g. 00-00-00-00-00-00-00-E0. I wonder if it is worth skipping all
isVirtual() nifs?
Good idea.
delete the typo
+ * @param characteristics Characteristics of the this spliterator's source
A top-level Spliterator should not report CONCURRENT and SIZED
=
A top-level Spliterator should not report both CONCURRENT and SIZED
I think the docs for SIZED can make it clearer that it is an
I'm only doing superficial review, but Looks Good To Me!
On Sep 16, 2013, at 8:27 PM, Martin Buchholz marti...@google.com wrote:
delete the typo
+ * @param characteristics Characteristics of the this spliterator's
source
A top-level Spliterator should not report CONCURRENT and SIZED
=
A top-level Spliterator should not report both
I think this is a reasonable compromise (and will be what I use for the other
cases).
Thanks!
Mike
On Sep 16 2013, at 01:13 , Paul Sandoz wrote:
Hi Mike,
I suppose there could also be implementations of removeIf that always throw
UOE regardless of whether an element matched or not i.e.
I pulled the class files into byte array constants, as a temporary
measure until a viable method for testing bad class files is developed.
The webrev has been refreshed. The class files will be taken out before
I push.
http://cr.openjdk.java.net/~emc/8020981/
On 09/13/13 20:48, Joe Darcy
Resending this to more lists as requested by Alan Bateman with the kind
request to anybody to review the parts for which he feels responsible:)
For those not up to date, this change is part of the ongoing PowerPC/AIX
Porting Project:
http://openjdk.java.net/projects/ppc-aix-port
On Mon, Sep 16, 2013 at 12:13 PM, Paul Sandoz paul.san...@oracle.comwrote:
I think the docs for SIZED can make it clearer that it is an error for
the size to change while the spliterator is in progress. One can imagine
CONCURRENT data structures whose SIZE does not change. An iterator
Volker,
You need different bug ID for these JDK changes.
8024265 (top level changes) is already fixed:
https://bugs.openjdk.java.net/browse/JDK-8024265
I created new one for you:
https://bugs.openjdk.java.net/browse/JDK-8024900
Thanks,
Vladimir
On 9/16/13 8:20 AM, Volker Simonis wrote:
Looks fine; cheers,
-Joe
On 9/16/2013 3:49 PM, Mike Duigou wrote:
Ping!
(still need a reviewer on this)
Mike
On Sep 4 2013, at 11:44 , Mike Duigou wrote:
Hello all;
I have updated the proposed changeset for this issue. I have moved the note to
the interface documentation for Collection
On 09/16/2013 02:11 PM, Guy Steele wrote:
Okay, as long as we're obsessing: the code defends against the hardware
address being longer than 8 bytes.
This was to protect ourselves from the impact of this code being used in some
alternative universe in which hardware addresses are not always
On Sep 13, 2013, at 7:02 PM, Dmitry Nadezhin wrote:
I agree with 1100 for this review (JDK7).
OK. I will post an approval request to 7u-dev for the patch as-is.
I think that we shouldn't change from 1100 to 768 in JDK8 because this is a
small performance enhancement.
This will save time
Ping!
(still need a reviewer on this)
Mike
On Sep 4 2013, at 11:44 , Mike Duigou wrote:
Hello all;
I have updated the proposed changeset for this issue. I have moved the note
to the interface documentation for Collection and Map and made it more
general:
Some collection operations
Hello all;
This is a cross-repo patch which disables building and enabling of the
alt-rt.jar file. The alt-rt.jar file has been used with the -XX:+AggressiveOpts
option (which will be remaining for other optimizations). This jar file
formerly contained (closed-source) versions of several JDK
Looks good. Both.
I assume you will send webrev for closed changes.
Thanks,
Vladimir
PS: RIP jbb2005 ;)
On 9/16/13 5:16 PM, Mike Duigou wrote:
Hello all;
This is a cross-repo patch which disables building and enabling of the
alt-rt.jar file. The alt-rt.jar file has been used with the
The algorithmic change (string cache) is acceptable, although it will tend to
increase footprint somewhat. We can tweak that later if necessary. There are
probably only a small number of such strings, so maybe a small leaky map would
do the trick as well. What you propose is fine.
But,
Reviewed both hotspot and jdk changes.
Thumbs up and good riddance! :)
How do you propose to handle the coordination of the push?
Thanks,
David
On 17/09/2013 10:16 AM, Mike Duigou wrote:
Hello all;
This is a cross-repo patch which disables building and enabling of the
alt-rt.jar file. The
On Sep 16 2013, at 19:37 , David Holmes wrote:
Reviewed both hotspot and jdk changes.
Thumbs up and good riddance! :)
How do you propose to handle the coordination of the push?
The hotspot and jdk changes can go in any order. I plan to push them sequential
after cross platform test
On Sep 17, 2013, at 1:22 AM, Doug Lea d...@cs.oswego.edu wrote:
On 09/16/2013 02:11 PM, Guy Steele wrote:
Okay, as long as we're obsessing: the code defends against the hardware
address being longer than 8 bytes.
This was to protect ourselves from the impact of this code being used in some
On Sep 16, 2013, at 9:49 PM, Mike Duigou mike.dui...@oracle.com wrote:
I think this is a reasonable compromise (and will be what I use for the other
cases).
OK, +1 from me.
Paul.
Thanks!
Mike
On Sep 16 2013, at 01:13 , Paul Sandoz wrote:
Hi Mike,
I suppose there could also
47 matches
Mail list logo
