Changeset: e59d7f0f36f7
Author:ewang
Date: 2013-05-28 22:22 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e59d7f0f36f7
8009258: TEST_BUG:java/io/pathNames/GeneralWin32.java fails intermittently
Reviewed-by: dxu, alanb
Contributed-by: yiming.w...@oracle.com
! test/java/io/pa
On Tue, May 28, 2013 at 9:00 PM, David Holmes wrote:
> Martin,
>
>
> On 29/05/2013 5:53 AM, Martin Buchholz wrote:
>
>> Is atomicity part of the contract of ConcurrentMap.getOrDefault?
>> Currently, it doesn't say.
>> Actually, there are two possible guarantees it could make - whether the
>> def
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
idiom from elsewhere in the JDK. Perh
On 29/05/2013 7:33 AM, Martin Buchholz wrote:
On Mon, May 27, 2013 at 12:10 AM, David Holmes mailto:david.hol...@oracle.com>> wrote:
FutureTask.java: the indentation of the changed code is all wrong.
That must be an artifact of the webrev generation (ignoring lines with
only whitespace chan
Martin,
On 29/05/2013 5:53 AM, Martin Buchholz wrote:
Is atomicity part of the contract of ConcurrentMap.getOrDefault?
Currently, it doesn't say.
Actually, there are two possible guarantees it could make - whether the
default implementation ConcurrentMap.getOrDefault is atomic (when the map
do
Looks good to me.
---
While you're moving code around, you could fix the typo below and change
method comments to javadoc style ('*' => '**'')
accidnetly
and
One historical reason for this class of bugs was the historic support for
Windows98 family, which made it much harder to switch to the correct "W"
Unicode APIs. Today Windows98 is no longer supported, so some things may
appear easy or at least easier.
On Thu, May 23, 2013 at 6:59 AM, Salter, Tho
On 29/05/2013 7:26 AM, Aleksey Shipilev wrote:
On 05/29/2013 12:38 AM, Martin Buchholz wrote:
however, remain in force for all
+ * superclass and subclass instances
"remain in force for superclass instances" doesn't make sense to me. Do
you mean "remain in force when fields are inherited in s
>> You can still generate a ISE inside readObject by performing "new
>> XPathException(new Exception()).initCause(null)" in the old code and then
>> reading that in the new patch. In the new code that line would fail fast.
>
> So what should the result of this be given that the original exception
On Tue, May 28, 2013 at 6:43 PM, David Holmes wrote:
> On 29/05/2013 11:23 AM, Martin Buchholz wrote:
>
>> [+compiler-dev]
>>
>>
>> On Wed, May 15, 2013 at 1:05 AM, David Holmes **
>> wrote:
>>
>> On 15/05/2013 3:16 PM, Martin Buchholz wrote:
>>>
>>>
General purpose library code sometim
Looks good to me.
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() issue.
Thanks!
John
On 05/26/2013 11:03 PM, David Holmes wrote:
I concur with Martin on all counts.
Confus
On 29/05/2013 11:23 AM, Martin Buchholz wrote:
[+compiler-dev]
On Wed, May 15, 2013 at 1:05 AM, David Holmes wrote:
On 15/05/2013 3:16 PM, Martin Buchholz wrote:
General purpose library code sometimes would like to rethrow an
exception that was previously caught.
How should it do that?
On 28/05/2013 11:41 PM, Jason Mehrens wrote:
Alan, David,
thank you for comments - I also agree with all of them. And as a result v3:
http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/
I think this looks better. I assume that since the super.getCause() is
null that there is no need to handle
On 28/05/2013 11:08 PM, Remi Forax wrote:
On 05/28/2013 02:48 PM, David Holmes wrote:
Sorry it didn't register that getName() already returns a String -
hence the toString() is redundant - but minimally so.
David
The second call to toString() also performs an implicit nullcheck
(elementName c
[+compiler-dev]
On Wed, May 15, 2013 at 1:05 AM, David Holmes wrote:
> On 15/05/2013 3:16 PM, Martin Buchholz wrote:
>
>>
>>
>> General purpose library code sometimes would like to rethrow an
>> exception that was previously caught.
>> How should it do that?
>>
>
> Umm catch it and throw it. If
On 05/24/2013 07:07 AM, Alan Bateman wrote:
On 24/05/2013 05:19, Eric Wang wrote:
Hi Dan & All,
I have updated the test based on your comments, Can you please review
the fix? Thanks!
http://cr.openjdk.java.net/~ewang/8009258/webrev.02/
I think this is okay. Dan is going to sponsor this one.
On Tue, May 28, 2013 at 2:26 PM, Aleksey Shipilev <
aleksey.shipi...@oracle.com> wrote:
> On 05/29/2013 12:38 AM, Martin Buchholz wrote:
>
> > We don't use closing html tags for things like in javadoc.
>
> Ok, JDK 8 doclint does not like self-closing entities, and leaving
> unterminated seems do
Hi Aleksej,
Please note that in jdk8 repo, we've added jdk/test/javax/xml/jaxp to
hold all new tests for jaxp. All of the existing tests will be migrated
to this place in the future. In your case, the new test can be created
under a new folder jdk/test/javax/xml/jaxp/XPath/8009579. Daniel's
The JSR 206 spec did not have such requirement, but the RIs of JSR
206/173 still support JDK5. We stopped supporting JDK 1.4 in 2009 in
order to move up to features introduced in JDK5. It may be time to
consider again. However, even if we do, I think we should move up to
JDK6. It may be too
On Mon, May 27, 2013 at 12:10 AM, David Holmes wrote:
>
> FutureTask.java: the indentation of the changed code is all wrong.
>
That must be an artifact of the webrev generation (ignoring lines with only
whitespace changes?). I don't think the actual code is mis-formatted.
On 05/29/2013 12:38 AM, Martin Buchholz wrote:
> Tricky stuff!
You bet! Thanks for the review! I'll wait for more reviews, and update
the webrev.
> We don't use closing html tags for things like in javadoc.
Ok, JDK 8 doclint does not like self-closing entities, and leaving
unterminated seems d
On Fri, May 24, 2013 at 8:17 PM, Mike Duigou wrote:
>
> - It was surprising (and somewhat disappointing) to see changes like the
> following in various places. Is iterator creation that expensive? I'd hate
> to have to go back to using old style for loops everywhere.
>
> -List> futures =
On Mon, May 27, 2013 at 12:10 AM, David Holmes wrote:
>
> atomic/package-info.java: the URL updates (to oracle.com) have been
> regressed to java.sun.com :(
>
>
Doug's CVS has been updated to link to the jdk7 edition of the jls. This
improves on the version in openjdk proper by removing stale ref
Changeset: b99d56d1aa3f
Author:naoto
Date: 2013-05-28 14:02 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b99d56d1aa3f
6251788: (rb) PropertyResourceBundle doesn't document exceptions
Reviewed-by: okutsu
! src/share/classes/java/util/PropertyResourceBundle.java
Tricky stuff!
---
We don't use closing html tags for things like in javadoc.
---
+ * in concurrent contexts in which each instance of the annotated
+ * object is often accessed by a different thread.
Hmmm... makes it sound like it applies even if each instance is
thread-confined (in a differ
On 5/28/13 3:09 AM, Doug Lea wrote:
To better enable and simplify future improvements, could you
do this -- nest the tree classes within HashMap?
Done.
Also, a note on spliterators: I had added these in the
least disruptive way (knowing that major changes were coming)
by checking exact class
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(); }
I'm not sure mappingCount is the best name, but all names will be
confusing. Using the name "length()" at least has an
Vaguely related, looking at Map.getOrDefault:
---
Whitspace is wonky - we want more whitespace before the '*', less after.
/**
* Returns the value to which the specified key is mapped,
* or {@code defaultValue} if this map contains no mapping
* for the key.
---
The @param fo
Hi David,
On 05/28/2013 04:11 AM, David Holmes wrote:
> Okay I have some suggested rewordings below and a couple of grammatical
> corrections.
Thank you! The updated webrev is here:
http://cr.openjdk.java.net/~shade/8014966/webrev.02/
Changes from the David's version:
* added the provisionin
On 27.05.2013 10:40, Alan Bateman wrote:
On 26/05/2013 12:04, Philippe Marschall wrote:
Hi
It would be nice if javax.xml.stream.XMLStreamReader and
javax.xml.stream.XMLStreamWriter could be made to extend
java.lang.AutoCloseable so that they can be used in a
try-with-resouces statement. The s
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 see the advantage to exposing the ConcurrentHashMap.Ke
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 issues reported in JDK-8013827 and
JDK-8
Changeset: 7fa2d1dcb8f6
Author:sherman
Date: 2013-05-28 10:42 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa2d1dcb8f6
8001750: CharsetDecoder.replacement should not be changeable except via
replaceWith method
Summary: to make defensive copy for set/get replacement byte a
Thanks. Looks good!
On Tue, May 28, 2013 at 6:07 AM, John Zavgren wrote:
> Greetings:
>
> I fixed the comment line... to correct the "nul", "NULL", "NUL" issue and
> I disambiguated the readlink() issue.
>
> Thanks!
> John
>
>
> On 05/26/2013 11:03 PM, David Holmes wrote:
>
>> I concur with Mart
Hello everyone my name is Otávio Santana and I do part of some Java user
groups in Brazil, including SouJava.
I know it is not an error, but an optimization.
I have studying about OpenJDK and I hope help you.
How I am a beginner in OpenJDK, I only can help with simple things like
refactoring and
Hi Petr,
Hello, Kumar.
Thank you for the review.
Is there a regression test for this somewhere ?
It's quite hard to create a regression test for this issue, as we would need
SWT for such test and we do not have any tests which use SWT currently.
I have tried to make a test without SWT using
Changeset: d042cba65eab
Author:vromero
Date: 2013-05-28 17:39 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d042cba65eab
8012333: javac, ClassFile should have a read(Path) method
Reviewed-by: jjg
! src/share/classes/com/sun/tools/classfile/ClassFile.java
Changeset: b16a8b4ae6b4
Author:robm
Date: 2013-05-28 16:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b16a8b4ae6b4
7038105: File.isHidden() should return true for pagefile.sys and hiberfil.sys
Reviewed-by: alanb
! src/windows/native/java/io/WinNTFileSystem_md.c
! test/ja
Changeset: 7d7bfce34a79
Author:dsamersoff
Date: 2013-05-28 18:46 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7bfce34a79
8014420: Default JDP address does not match the one assigned by IANA
Summary: JDP protocol defaults changed to IANA assigned values
Reviewed-by: dholme
Jason,
You are absolutely right and my fault that I didn't tested the
compatibility of new/old versions.
I have tested it with JDK 8(without fix) as a serializer and JDK 8
(with fix) as deserializer. The behavior was as you expected. Thanks for
catching it.
I'll wait for other comments before
Changeset: 7d9fab5d86cd
Author:jbachorik
Date: 2013-05-28 15:57 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d9fab5d86cd
8005472:
com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh
failed on windows
Reviewed-by: chegar, smarks, dfuchs
! test/Pro
> Alan, David,
> thank you for comments - I also agree with all of them. And as a result v3:
> http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/
> >> I think this looks better. I assume that since the super.getCause() is
> >> null that there is no need to handle IllegalStateException now.
You
On 05/28/2013 02:48 PM, David Holmes wrote:
Sorry it didn't register that getName() already returns a String -
hence the toString() is redundant - but minimally so.
David
The second call to toString() also performs an implicit nullcheck
(elementName can not be null).
So if we have to fix som
Greetings:
I fixed the comment line... to correct the "nul", "NULL", "NUL" issue
and I disambiguated the readlink() issue.
Thanks!
John
On 05/26/2013 11:03 PM, David Holmes wrote:
I concur with Martin on all counts.
Confusing NUL and NULL is also a pet peeve of mine :)
David
On 25/05/2013
Sorry it didn't register that getName() already returns a String - hence
the toString() is redundant - but minimally so.
David
On 28/05/2013 9:15 PM, David Holmes wrote:
Please see my reply under your original subject line.
This is not a bug.
David
On 28/05/2013 7:37 PM, Otávio Gonçalves de
Alan, David,
thank you for comments - I also agree with all of them. And as a result v3:
http://cr.openjdk.java.net/~dmeetry/8009581/webrev.3/
Aleksej
On 05/27/2013 06:57 AM, David Holmes wrote:
On 26/05/2013 1:41 AM, Alan Bateman wrote:
On 25/05/2013 09:37, Aleksej Efimov wrote:
David, Jason
Changeset: c6df5b20f9eb
Author:vromero
Date: 2013-05-28 12:46 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c6df5b20f9eb
6970173: Debug pointer at bad position
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/comp/Lower.java
+ test/tools/javac/T6970173
Please see my reply under your original subject line.
This is not a bug.
David
On 28/05/2013 7:37 PM, Otávio Gonçalves de Santana wrote:
diff --git
a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
b/src/share/classes/java/lang/annotation/IncompleteAnnotationException
On 28/05/2013 7:27 PM, Alan Bateman wrote:
On 28/05/2013 10:15, Otávio Gonçalves de Santana wrote:
diff --git
a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
---
a/src/share/classes/java/l
Thank you Doug, this addresses my concerns.
On 05/28/2013 11:29 AM, Doug Lea wrote:
On 05/27/13 10:30, Chris Hegarty wrote:
1) CHM no longer extends AbstractMap. I guess this should not be a
problem in the real world, and I guess users would not be too
surprised by instanceof checks.
On 05/27/13 10:30, Chris Hegarty wrote:
1) CHM no longer extends AbstractMap. I guess this should not be a
problem in the real world, and I guess users would not be too
surprised by instanceof checks. Just worth highlighting the change
for compatibility.
Yes, thanks. It was a bad
On 05/23/13 15:02, Brent Christian wrote:
On 5/23/13 5:20 AM, Doug Lea wrote:
* Given that balanced trees are not used in WeakHashMap
or Hashtable, I wonder why the TreeNode etc classes are
not just nested inside HashMap (usable from subclass LinkedHashMap).
To better enable and simplify futur
diff --git
a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
b/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
---
a/src/share/classes/java/lang/annotation/IncompleteAnnotationException.java
+++
b/src/share/classes/java/lang/annotation/IncompleteA
Thank you Paul, got it.
-Chris.
On 05/28/2013 10:00 AM, Paul Sandoz wrote:
Hi Chris,
On May 27, 2013, at 4:30 PM, Chris Hegarty wrote:
2) KeySetView.spliterator()
I guess the API should also report CONCURRENT, NONNULL & SUBSIZED?
And the implementation should return SIZED too?
3) Va
Hi Chris,
On May 27, 2013, at 4:30 PM, Chris Hegarty wrote:
> 2) KeySetView.spliterator()
>
> I guess the API should also report CONCURRENT, NONNULL & SUBSIZED?
> And the implementation should return SIZED too?
>
> 3) Value/EntrySpliterator.spliterator() should return SIZED?
>
The CHM sp
On May 27, 2013, at 3:05 PM, Doug Lea wrote:
>>
>> - The default for getOrDefault() in ConcurrentMap shouldn't be removed.
>>
>> - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not
>> normally order preserving.
>>
>
> Thanks! Both the results of my not rechecking vs lambda
On 5/28/2013 3:50 PM, Alan Bateman wrote:
> On 28/05/2013 02:31, Xuelei Fan wrote:
>> Ping again, any one available to review this changeset?
> It's good to fix up FindBugs warnings and I think these changes are okay.
>
> Can the @SuppressWarnings("unchecked") be removed from
> GenericURLContext.r
On 28/05/2013 02:31, Xuelei Fan wrote:
Ping again, any one available to review this changeset?
It's good to fix up FindBugs warnings and I think these changes are okay.
Can the @SuppressWarnings("unchecked") be removed from
GenericURLContext.removeFromEnvironment now?
-Alan
58 matches
Mail list logo
