Hello Victor,
On 5/29/2013 11:25 PM, Victor Polischuk wrote:
Greetings,
I beg pardon for the previous HTML mail.
Some time ago I wanted to migrate our "commons-lang" enums to "java 5"
enumerations, but I encountered an issue that it cannot be done without discarding generics since
java enums
On Wed, May 29, 2013 at 5:20 PM, Brian Burkhalter <
brian.burkhal...@oracle.com> wrote:
> On May 29, 2013, at 4:57 PM, Martin Buchholz wrote:
>
>
> Use third person in the first sentence of a javadoc - e.g.
> s/Retrieve/Retrieves/.
>
> ---
>
> Don't use the denigrated C style
> char zero[] =
> Ins
Greetings,
I beg pardon for the previous HTML mail.
Some time ago I wanted to migrate our "commons-lang" enums to "java 5"
enumerations, but I encountered an issue that it cannot be done without
discarding generics since java enums do not support them. Let me show an
example:
//--
public
Hi All,
The fix to JDK-8009258 solves the failure in GeneralWin32.java. But the
changes in Line 311, 312 in checkNames() method of General.java file,
lead to the new failure of GeneralSolaris.java testcase. Because it
changes the implicit value of an empty "ask" parameter.
This fix is to rev
Changeset: 90df6756406f
Author:sherman
Date: 2013-05-29 19:50 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90df6756406f
4759491: method ZipEntry.setTime(long) works incorrectly
6303183: Support NTFS and Unix-style timestamps for entries in Zip files
7012856: (zipfs) Newly c
On 5/29/2013 3:44 PM, Brian Burkhalter wrote:
On May 29, 2013, at 2:35 PM, Alan Bateman wrote:
It would be good to do a few experiments with -XX:AutoBoxCacheMax= to
make sure that bad values dp startup to fail, I expect they should.
Yes, bad values do indeed cause startup to fail, for exampl
On May 29, 2013, at 4:57 PM, Martin Buchholz wrote:
> I would like to see the real world-class experts on this scary math stuff
> (Alan Eliasen, Tim Buktu) be made honorary jdk reviewers, just for their area
> of specialization, if that was bureaucratically possible.
I'll leave serious comments
I would like to see the real world-class experts on this scary math stuff
(Alan Eliasen, Tim Buktu) be made honorary jdk reviewers, just for their
area of specialization, if that was bureaucratically possible. Shouldn't
the original authors be cc'ed?
The code is awesome. My thorough review found
On 05/30/2013 12:44 AM, Brian Burkhalter wrote:
On May 29, 2013, at 2:35 PM, Alan Bateman wrote:
It would be good to do a few experiments with -XX:AutoBoxCacheMax= to
make sure that bad values dp startup to fail, I expect they should.
Yes, bad values do indeed cause startup to fail, for examp
Changeset: d685b12b62a4
Author:jjg
Date: 2013-05-29 15:34 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d685b12b62a4
8015641: genstubs needs to cope with static interface methods
Reviewed-by: ksrini
! make/tools/genstubs/GenStubs.java
On May 29, 2013, at 2:35 PM, Alan Bateman wrote:
> It would be good to do a few experiments with -XX:AutoBoxCacheMax= to
> make sure that bad values dp startup to fail, I expect they should.
Yes, bad values do indeed cause startup to fail, for example:
$ java -XX:AutoBoxCacheMax=1024\-Xmx2g Hel
On Wed, May 29, 2013 at 3:17 PM, Xueming Shen wrote:
> Hi Martin,
>
> Somehow most of your comments are "blank lines" in my mailbox, just wonder
> if
> you can send them again. Based on the "hints", I updated those javadoc
> comments
> in ZipUtils to "**".
>
Sorry, my mail program is a bit too in
Hi Martin,
Somehow most of your comments are "blank lines" in my mailbox, just wonder if
you can send them again. Based on the "hints", I updated those javadoc comments
in ZipUtils to "**".
The code has been updated slightly (mainly to not output the extra time stamp if
it already exists in the
On Wed, May 29, 2013 at 7:45 AM, Chris Hegarty wrote:
> decouple it from the other changes going on here. (Says me who wanted to
> resync, in one pass, the complete j.u.c last week!)
>
However it gets done, Chris, thanks very much for taking on the big task of
syncing jsr166.
On 29/05/2013 20:54, Brian Burkhalter wrote:
So if an InternalError were to be used instead, the code would be like:
try {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is I
Updated webrev is here:
http://cr.openjdk.java.net/~bchristi/8005698/webrev.03/
It contains the following changes from Mike's review:
* HashMap.comparableClassFor(): corrected reference to TreeBin docs
* fixed @run tag in InPlaceOpsCollisions.java
* Hashtable & HashMap: hashSeed made final, in
So if an InternalError were to be used instead, the code would be like:
try {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i
Looks good enough to me for a non-public API. I expect more contentious
arguments if this is ever made public, since the problems remain very
tricky. Only a VM that monitors memory "hot spots" can really get this
right ... but the VM we have is already named "hotspot" ...
On 29/05/2013 19:49, Brian Burkhalter wrote:
:
Problem is that the String in the NumberFormatException in this case does not
contain the reason, only the offending String. The parseInt() would need to be
changed accordingly to make this intelligible.
I have no strong preference but it does not
Hi Aleksey,
Thanks for the references. Currently, you are correct, I don't need it.
Has it been considered that highly contended field should not be allocated
in the object itself anyway but in some pool or structure better suited
to its access characteristics? A read-only indirection could pr
On May 29, 2013, at 11:40 AM, Mike Duigou wrote:
> In other cases similar to this an InternalError is thrown. It seems that for
> a property like this which can have a dramatic effect on performance silently
> ignoring bad input may not be the right choice.
>
> java -Djava.lang.Integer.Integer
In other cases similar to this an InternalError is thrown. It seems that for a
property like this which can have a dramatic effect on performance silently
ignoring bad input may not be the right choice.
java -Djava.lang.Integer.IntegerCache.high=foobar
Exception in thread "main" java.lang.Excep
On 5/28/13 9:13 PM, Mike Duigou wrote:
Hashtable/WeakHashMap::
- I assume that the JVM falls over dead if the security manager
doesn't allow access to the property, correct? I hadn't considered
what should happen in the event of a security exception when I
originally copied the GetPropertyAction
Hi Roger,
On 05/29/2013 09:12 PM, roger riggs wrote:
> I'm not sure I quite understand the purpose or semantics of this
> annotation.
That's the early sign you don't need it! :) I'm actually envious.
> Since it is in sun.misc, it may not be so important and is just an
> implementation artifact
http://cr.openjdk.java.net/~bpb/8015395/
Fix is to ignore bad value passed for java.lang.Integer.IntegerCache.high
property and devolve to the default.
Thanks,
Brian
Hi Alexey,
I'm not sure I quite understand the purpose or semantics of this annotation.
Since it is in sun.misc, it may not be so important and is just an
implementation
artifact but does not have enough of a standalone description nor connection
to the other elements.
The description of the a
Hi,
Here is proposal to add one mapping entry into the mapping table for EUC-KR
to add the "newly" added KS X 1001:2002 code point
2-71 (EUC_KR:0xA2E8 Unicode: U+0x327E)
Info regarding this code point
http://www.unicode.org/L2/L2004/04267-n2815.pdf
Here is the mapping change webrev
http://cr.
Changeset: 0bf451c0678d
Author:hannesw
Date: 2013-05-27 12:26 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0bf451c0678d
8015348: RegExp("[") results in StackOverflowError
Reviewed-by: sundar, attila
! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java
+ test/sc
On 29/05/2013 02:50, David Holmes wrote:
Looks good to me.
+1. If you need a sponsor, I can push this for you John.
-Chris.
David
On 28/05/2013 11:07 PM, John Zavgren wrote:
Greetings:
I fixed the comment line... to correct the "nul", "NULL", "NUL" issue
and I disambiguated the readlink(
On 29/05/2013 15:28, Peter Levart wrote:
.
I don't feel strongly about this either, but I think it deserves
possibly its own bug number and consideration. I have removed it from
this review request, and will a file a new bug to track it.
Hi,
Why not using Unsafe (which is already used in
Back to this. (which applies to ConcurrentHashMap, under review).
On 05/24/13 07:18, Doug Lea wrote:
On 05/23/13 16:47, Jeff Hain wrote:
Implementing some RB-tree I found out that
a lot of the null checks from CLR code could be removed from balancing
operations.
Yes and no. Some of those
Looks fine to me Paul.
On 29/05/2013 12:35, Paul Sandoz wrote:
Hi,
Please review these changes to j.u.PrimitiveIterator to ensure the default
forEachRemaining methods consistently throw an NPE when the consumer is null.
I almost produced a webrev for this, but i thought it was just about acce
On 05/29/2013 04:07 PM, Chris Hegarty wrote:
... and the links to the updated spedcdiff / webrev
http://cr.openjdk.java.net/~chegar/8005704/ver.01/specdiff/java/util/concurrent/package-summary.html
http://cr.openjdk.java.net/~chegar/8005704/ver.01/webrev/
-Chris.
On 29/05/2013 15:06, Ch
Understood that it is necessary to have some mechanism to have reproducible
results. The command line system property is by default disabled. Enabling it
has only the effect of setting the hashSeed to a non-zero XOR value for each
instance. Since the randomness is per instance there's no single
Looks fine to me with the space removed as well.
Mike
On May 29 2013, at 06:10 , Paul Sandoz wrote:
>
> On May 29, 2013, at 2:49 PM, Chris Hegarty wrote:
>
>> Looks fine to me Paul.
>>
>> Trivially, there is an extra space which could be removed.
>>
>> "builder__has..."
>>
>
> Thanks, i u
Mike, Doug,
On 28/05/2013 20:07, Mike Duigou wrote:
Hi Chris& Doug;
- I don't feel strongly about the removal of AbstractMap. I don't see this as
very likely to cause problems in real world code though there is probably some
test code somewhere that assigns CHM to an AbstractMap.
I don't f
... and the links to the updated spedcdiff / webrev
http://cr.openjdk.java.net/~chegar/8005704/ver.01/specdiff/java/util/concurrent/package-summary.html
http://cr.openjdk.java.net/~chegar/8005704/ver.01/webrev/
-Chris.
On 29/05/2013 15:06, Chris Hegarty wrote:
Mike, Doug,
On 28/05/2013 20
Changeset: 00ad19610e75
Author:vinnie
Date: 2013-05-29 14:57 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00ad19610e75
7174966: With OCSP enabled on Java 7 get error 'Wrong key usage' with Comodo
certificate
Reviewed-by: xuelei
! src/share/classes/sun/security/provider/ce
On 05/28/13 16:03, Martin Buchholz wrote:
A long-returning size method seems like a framework-level decision. We could
add a default method to Collection.java and Map.java
default long mappingCount() { return size(); }
The lambda EG discussed this, and decided not to do it now,
and to put off
On 05/28/13 15:07, Mike Duigou wrote:
Hi Chris & Doug;
- I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type
particularly for newKeySet(). Why not return Set? The additional methods
don't seem to offer much that's desirable for the newKeySet() case.
Since we don't hav
On May 29, 2013, at 2:49 PM, Chris Hegarty wrote:
> Looks fine to me Paul.
>
> Trivially, there is an extra space which could be removed.
>
> "builder__has..."
>
Thanks, i updated the patch/lambda repo.
Paul.
Looks good to me.
-Chris.
On 29/05/2013 12:36, Paul Sandoz wrote:
Hi,
Please review this JavaDoc fixe to j.u.Spliterator.getExactSizeIfKnown.
Paul.
# HG changeset patch
# User psandoz
# Date 1369825085 -7200
# Node ID 840469ba82ab8d8238414a5333aa99b8d4035a9b
# Parent 7ded996200218791c885c0a
Looks fine to me.
-Chris.
On 29/05/2013 12:12, Paul Sandoz wrote:
Hi,
Please review these changes to j.u.s. StreamSupport to make it final and
non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry.
Paul.
# HG changeset patch
# User psandoz
# Date 1369825082 -7200
#
Looks fine to me Paul.
Trivially, there is an extra space which could be removed.
"builder__has..."
-Chris.
On 29/05/2013 12:08, Paul Sandoz wrote:
Hi,
Please review these JavaDoc fixes to j.u.s.StreamBuilder.
Paul.
# HG changeset patch
# User psandoz
# Date 1369825073 -7200
# Node ID 30
On 29/05/2013 13:00, Alan Bateman wrote:
On 29/05/2013 12:10, Paul Sandoz wrote:
Hi,
Please review these JavaDoc fixes to j.u.s.{Xxxx}Stream.findFirst.
Paul.
I had to look at the diff twice to spot it :-)
Not bad, it took me three times ;-)
Looks fine to me.
+1
-Chris.
It looks like there's no way to set the random seed from the command line.
That's going to make Heisenbugs even less fun than they already are. Ideally,
if a VM crashes, that random seed could get mentioned somewhere in the crash,
and someone who is debugging might then be able to specify it t
On 29/05/2013 12:10, Paul Sandoz wrote:
Hi,
Please review these JavaDoc fixes to j.u.s.{Xxxx}Stream.findFirst.
Paul.
I had to look at the diff twice to spot it :-)
Looks fine to me.
-Alan.
On 29/05/2013 12:08, Paul Sandoz wrote:
Hi,
Please review these JavaDoc fixes to j.u.s.StreamBuilder.
Paul.
This looks fine to me.
-Alan
On 28/05/2013 19:39, Dan Xu wrote:
Hi All,
When File.createTempFile() is called with some special parameters, it
runs into infiniteloop and hangs. It is because it does not always
mean a file exists when the method, createFileExclusively(), returns
false. This fix is going to solve such issue
On May 29, 2013, at 1:34 PM, Alan Bateman wrote:
> On 29/05/2013 12:12, Paul Sandoz wrote:
>> Hi,
>>
>> Please review these changes to j.u.s. StreamSupport to make it final and
>> non-instantiable, i also tacked on some JavaDoc broken link fixes made by
>> Henry.
>>
>> Paul.
>>
> This looks
Hello,
Why phantom references are not automatically cleared by the garbage collector
as they are enqueued?
Keeping phantom reachable objects in heap has some drawbacks:
1. At least 2 GC are required in order to reclaim them, even in case when
application code pulls references from reference que
Hi,
Please review this JavaDoc fixe to j.u.Spliterator.getExactSizeIfKnown.
Paul.
# HG changeset patch
# User psandoz
# Date 1369825085 -7200
# Node ID 840469ba82ab8d8238414a5333aa99b8d4035a9b
# Parent 7ded996200218791c885c0aae4c474066101c7bd
8014732: Minor spec issue: java.util.Spliterator.get
Hi,
Please review these changes to j.u.PrimitiveIterator to ensure the default
forEachRemaining methods consistently throw an NPE when the consumer is null.
I almost produced a webrev for this, but i thought it was just about acceptable
size-wise and i hope easy to review in textual form. If th
On 29/05/2013 12:12, Paul Sandoz wrote:
Hi,
Please review these changes to j.u.s. StreamSupport to make it final and
non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry.
Paul.
This looks okay to me but just to note that making it final is
technically an API change
Thanks for the review!
On 05/29/2013 04:28 AM, Martin Buchholz wrote:
> Yeah, we have the same problem with javadoc issuing very verbose
> warnings. I've been ignoring/filtering them and hoping they get fixed
> before jdk8 ships.
Ok, reverted back to .
> > + * in concurrent contexts in whic
Hi,
Please review these JavaDoc fixes to j.u.s.StreamBuilder.
Paul.
# HG changeset patch
# User psandoz
# Date 1369825073 -7200
# Node ID 303e9d2aff3cbaf27823b2591f2e8570b77afcce
# Parent bd6d3801347bfd912507d16dc14488f47e94e626
8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder
Su
Hi,
Please review these changes to j.u.s. StreamSupport to make it final and
non-instantiable, i also tacked on some JavaDoc broken link fixes made by Henry.
Paul.
# HG changeset patch
# User psandoz
# Date 1369825082 -7200
# Node ID bfdc1ed75460c9e6869827cf9acabd4b1a5e9d29
# Parent 6be3ce51e6
Hi,
Please review these JavaDoc fixes to j.u.s.{Xxxx}Stream.findFirst.
Paul.
# HG changeset patch
# User psandoz
# Date 1369747350 -7200
# Node ID 6be3ce51e61dbdab6766c74223c076a7b3472be6
# Parent 303e9d2aff3cbaf27823b2591f2e8570b77afcce
8014393: Minor typo in the spec for j.u.stream.Stream.fin
Thank you everyone.
I searched classes with this situation and I find these classes:
- sun.tools.java.MemberDefinition
- sun.rmi.rmic.Main
- sun.tools.jconsole.inspector.Utils
- com.sun.jndi.toolkit.dir.SearchFilter
- javax.swing.text.html.FormView
The diffs is in attachment
O
Changeset: 92e420e9807d
Author:vromero
Date: 2013-05-29 10:56 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e420e9807d
7053059: VerifyError with double Assignment using a Generic Member of a
Superclass
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/java
Changeset: 2b3242a69a44
Author:alanb
Date: 2013-05-29 10:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b3242a69a44
8014928: (fs) Files.readAllBytes() copies content to new array when content
completely read
Reviewed-by: martin
! src/share/classes/java/nio/file/Files.ja
On 29/05/2013 2:29 PM, Martin Buchholz wrote:
On Tue, May 28, 2013 at 9:00 PM, David Holmes mailto:david.hol...@oracle.com>> wrote:
On 29/05/2013 5:53 AM, Martin Buchholz wrote:
Is atomicity part of the contract of ConcurrentMap.getOrDefault?
Currently, it doesn't say.
Greetings,
>
>
Some time ago I wanted to migrate our "commons-lang" enums to "java 5"
enumerations, but I encountered an issue that it cannot be done without
discarding generics since java enums do not support them. Let me show an
example:
>
//--
>
public final class ColorEnum extend
Changeset: bd6d3801347b
Author:sla
Date: 2013-05-29 09:42 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6d3801347b
8015440: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails with
RuntimeException
Summary: Make sure serial gc compacts heap every time
Review
64 matches
Mail list logo
