On Jul 2, 2014, at 9:13 PM, Stuart Marks stuart.ma...@oracle.com wrote:
On 7/2/14 1:25 AM, Paul Sandoz wrote:
Stuart, are you planning to back port your doc fix to 8u-dev? If so we could
do all three in one go.
Hm, it might be a good idea to do so, in case we refresh the published
But it can be confusing to users since they've been using them since JDK 1.5
Related to JDK-8023276[1] where we added two packages to JDK 9
Speaking of which, has it occurred to anyone that it might be confusing to
users that JDK 9 and JDK 1.9 are the same thing? Isn't it time we got rid of
Hi,
I noticed a data race in java.net.URL:
https://bugs.openjdk.java.net/browse/JDK-8049220
I propose the following simple patch:
http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/
Regards, Peter
Hi Peter,
Just a minor subjective issue. I would suggest changing the name of the local
variable 'factory' in java.net.URL.getURLStreamHandler method for something
different. It's a bit hard to read the code since this variable clashes with
the same-name class field.
Thanks,
-Pavel
On 3 Jul
On 07/01/2014 05:31 PM, Stuart Marks wrote:
On 6/30/14 8:17 AM, Henry Jen wrote:
On 06/30/2014 12:18 AM, Alan Bateman wrote:
On 30/06/2014 02:30, Henry Jen wrote:
On 06/20/2014 02:28 PM, Henry Jen wrote:
Please review a trivial webrev for jdk9/corba that do the same @since
tag normalization
Hi,
We know that URL.equals and hashCode are fundamentally broken. But
URL.equals is even more broken than hashCode. Nevertheless, URL.equals
is used explicitly in the following places in JDK:
java.security.CodeSource.matchLocation
java.security.CodeSource.equals
On 03/07/2014 09:43, Peter Levart wrote:
Hi,
I noticed a data race in java.net.URL:
https://bugs.openjdk.java.net/browse/JDK-8049220
I propose the following simple patch:
http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/
A good catch and the change looks good to me. I
Martin's law of expanding capacity:
Always grow by using the form
newCapacity = oldCapacity + oldCapacity n
for some suitable constant n. This will be efficient and more overflow
resistant than the alternative
newCapacity = oldCapacity * (2**n + 1) / (2**n)
Here n == 1.
On Thu, Jul 3,
On 02/07/2014 01:31, Stuart Marks wrote:
There are some strange cases here.
But the high order question is API vs implementation, and I think
@since really is about API.
I don't know if was a conclusion on what to do with some of these but
maybe the simplest is to just remove @since from
Alan, David - thanks for the reviews!
Cheers,
Mikael
On 2014-07-03 05:05, David Holmes wrote:
+1
David
On 3/07/2014 4:29 PM, Alan Bateman wrote:
On 03/07/2014 02:24, Mikael Vidstedt wrote:
Please review -- the jdk_beansX targets were removed as part of moving
from Makefile logic to jtreg
On 07/03/2014 07:59 PM, Martin Buchholz wrote:
On Wed, Jul 2, 2014 at 7:39 AM, Claes Redestad
claes.redes...@oracle.com mailto:claes.redes...@oracle.com wrote:
Hi Peter,
perhaps the synchronized(this)-block in
NameServiceAddresses::get() can be replaced with a ReentrantLock?
Thanks Martin!
On 03.07.2014 21:12, Martin Buchholz wrote:
Martin's law of expanding capacity:
Always grow by using the form
newCapacity = oldCapacity + oldCapacity n
for some suitable constant n. This will be efficient and more
overflow resistant than the alternative
newCapacity =
Hi.
WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/
The while loop in put(...) supposes that there is at least one free slot,
which was the case
before (that could be added as comment).
Now if you try to go past max capacity, instead of getting an
IllegalStateException,
you
Thank you Jeff!
On 03.07.2014 23:07, Jeff Hain wrote:
Hi.
WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/
http://cr.openjdk.java.net/%7Eigerasim/6904367/0/webrev/
The while loop in put(...) supposes that there is at least one free
slot,
which was the case before (that
Hello,
In the course of fixing
JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.*
http://cr.openjdk.java.net/~darcy/8043550.1/
I encountered a build failure in jconsole due to a conflict between a
recent generification in jconsole
8044865: Fix raw and unchecked
http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/
My test now terminates (exception on MAX_CAPACITY-th put).
Maybe where MAX_CAPACITY is defined you could indicate
that you can actually have at most MAX_CAPACITY-1 mappings,
to ensure that the table always contains some null key-spot
(I
I reviewed the jconsole change that looks okay to me.
Mandy
On 7/3/14 12:44 PM, Joe Darcy wrote:
Hello,
In the course of fixing
JDK-8043550: Fix raw and unchecked lint warnings in javax.swing.*
http://cr.openjdk.java.net/~darcy/8043550.1/
I encountered a build failure in jconsole
On 7/3/14 5:03 AM, Paul Sandoz wrote:
On Jul 3, 2014, at 1:05 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Paul, would you please include a few more typo fixes, if it's not too late?
Thanks for doing this, the changes look good.
Unfortunately it's too late for this bug, but i will
Hello,
in Java7 (U51 in this case) I do some testing with print inlining,
and I noticed that all possible executions of
AbstractStringBuilder::append had been inlined (hot) in thise tests.
Opposed to that I see a lot of too big messages for Java 8. I wonder if
this is known/intentional?
(The
Hi Bernd,
Are you testing with tiered compilation on java 8? If so, what happens if
you turn it off?
Thanks
Sent from my phone
On Jul 3, 2014 8:01 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:
Hello,
in Java7 (U51 in this case) I do some testing with print inlining,
and I noticed that
Hi Bernd,
I agree with Vitaly. Tiered compilation may well be the reason you're
seeing different logging -- in other words, your test is probably too short
so that when tiered compilation is turned on, you're only seeing C1's
compilation logs, and C2 compilation hasn't happened yet.
Try turning
Hi Ivan,
I find the change to capacity somewhat obfuscating and I can't see what
the actual bug was.
The recursive call to put after a resize seems very sub-optimal as you
will re-search the map for the non-existent key. Can you not just
recompute the correct indices and do the store?
22 matches
Mail list logo
