Re: 7099119: Remove unused dlinfo local variable in launcher code
On 29/11/2012 07:17, Shi Jun wrote: Hi all, Previously 7099119 is fixed in the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this change is lost during the Mac port merging changes 7113349 and 7146424. Hereby I raise this thread again. Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ Previous discuss thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html I don't know this slipped it, perhaps it was due to the refactoring. In any case your change looks fine. -Alan
Re: Code review request 8004134: More ProblemList.txt updates (11/2012)
On 29/11/2012 07:02, Amy Lu wrote: We have a few test failures on nightly testing, they are failing for known issues and should be excluded until issue is resolved. Please review: https://dl.dropbox.com/u/5812451/yl153753/8004134/webrev.00/index.html Thanks, Amy This looks okay to me. Stuart - do you mind sponsoring this? -Alan.
RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final
Hi, Submitted the original issue found by Peter Levart [1] as CR 8004141. Peter had suggested the trivial change [2] to fix this. Please review. Thanks, Aleksey. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html [2] http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html
Re: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final
Looks fine to me Aleksey. Let me know if you need a sponsor to get this into jdk8. -Chris. On 11/29/2012 11:05 AM, Aleksey Shipilev wrote: Hi, Submitted the original issue found by Peter Levart [1] as CR 8004141. Peter had suggested the trivial change [2] to fix this. Please review. Thanks, Aleksey. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html [2] http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html
Re: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final
I do, since I do not have the commit rights into OpenJDK repos. Thanks! -Aleksey. On 11/29/2012 03:19 PM, Chris Hegarty wrote: Looks fine to me Aleksey. Let me know if you need a sponsor to get this into jdk8. -Chris. On 11/29/2012 11:05 AM, Aleksey Shipilev wrote: Hi, Submitted the original issue found by Peter Levart [1] as CR 8004141. Peter had suggested the trivial change [2] to fix this. Please review. Thanks, Aleksey. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html [2] http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html
Re: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final
On 29/11/2012 11:05, Aleksey Shipilev wrote: Hi, Submitted the original issue found by Peter Levart [1] as CR 8004141. Peter had suggested the trivial change [2] to fix this. Please review. Thanks, Aleksey. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html [2] http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html It looks fine, are you looking for a sponsor? -Alan
Re: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final
On 11/29/2012 03:22 PM, Alan Bateman wrote: It looks fine, are you looking for a sponsor? Thanks. Chris had already volunteered for this. -Aleksey.
Re: RFR: 8003380 - Compiler warnings in logging test code
and pushed...
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b829a5a46ee
-Chris.
On 11/28/2012 06:51 PM, Jim Gish wrote:
Since we don't yet have a resolution on this, I modified the test code
in question to remove the @SuppressWarnings(unused) and actually
removed the unused references (and retested, of course).
Please review
http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/
http://cr.openjdk.java.net/%7Ejgish/Bug8003380-logging-test-warnings/
and if ok, Chris, could you please go ahead and push the changes?
thanks,
Jim
On 11/28/2012 01:27 PM, Jim Gish wrote:
Here's the list of @suppresswarnings values that are recognized by
Eclipse Juno:
Excluding warnings using @SuppressWarnings
Since Java 5.0, you can disable compilation warnings relative to a
subset of a compilation unit using
the|java.lang.SuppressWarning|annotation.
@SuppressWarning(unused) public void foo() {
String s;
}
Without the annotation, the compiler would complain that the local
variable|s|is never used. With the annotation, the compiler silently
ignores this warning locally to the|foo|method. This enables to keep
the warnings in other locations of the same compilation unit or the
same project.
The list of tokens that can be used inside
a|SuppressWarnings|annotation is:
* allto suppress all warnings
* boxingto suppress warnings relative to boxing/unboxing operations
* castto suppress warnings relative to cast operations
* dep-annto suppress warnings relative to deprecated annotation
* deprecationto suppress warnings relative to deprecation
* fallthroughto suppress warnings relative to missing breaks in switch
statements
* finallyto suppress warnings relative to finally block that don't
return
* hidingto suppress warnings relative to locals that hide variable
* incomplete-switchto suppress warnings relative to missing entries in
a switch statement (enum case)
* javadocto suppress warnings relative to javadoc warnings
* nlsto suppress warnings relative to non-nls string literals
* nullto suppress warnings relative to null analysis
* rawtypesto suppress warnings relative to usage of raw types
* resourceto suppress warnings relative to usage of resources of type
Closeable
* restrictionto suppress warnings relative to usage of discouraged or
forbidden references
* serialto suppress warnings relative to missing serialVersionUID
field for a serializable class
* static-accessto suppress warnings relative to incorrect static access
* static-methodto suppress warnings relative to methods that could be
declared as static
* superto suppress warnings relative to overriding a method without
super invocations
* synthetic-accessto suppress warnings relative to unoptimized access
from inner classes
* sync-overrideto suppress warnings because of missing synchronize
when overriding a synchronized method
* uncheckedto suppress warnings relative to unchecked operations
* unqualified-field-accessto suppress warnings relative to field
access unqualified
* unusedto suppress warnings relative to unused code and dead code
(From
http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm)
Jim
On 11/16/2012 10:02 PM, Stuart Marks wrote:
On 11/16/12 6:39 PM, Stuart Marks wrote:
The background is that the words that can be supplied to
@SuppressWarnings
reside in an uncontrolled namespace. The JLS [1] defines only
unchecked and
any others are compiler-specific. The set of words accepted here by
javac is
the same as the words defined for -Xlint.
[1]
http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5
Whoops, the JLS defines deprecation as well (as Alan pointed out in
another thread the other day). But the rest of the point stands.
s'marks
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. -Chris.
hg: jdk8/tl/jdk: 8004141: UnsafeStaticFieldAccessorImpl#base should be final
Changeset: d91e6cb1da41 Author:shade Date: 2012-11-29 17:03 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.lev...@gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: bf6ceb6b8f80
Author:mduigou
Date: 2012-11-29 14:07 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf6ceb6b8f80
7175464: entrySetView field is never updated in NavigableSubMap
Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed
to cache the entrySetView.
Reviewed-by: alanb, psandoz
! src/share/classes/java/util/TreeMap.java
Changeset: 75cb07a7b622
Author:mduigou
Date: 2012-11-29 14:09 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75cb07a7b622
6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary
allocation
Summary: It is not necessary to extract the value array with toCharArray. The
value array can now be used directly.
Reviewed-by: alanb
! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/String.java
hg: jdk8/tl: 8004131: move jdi tests out of core testset
Changeset: ab1ab9b148dd Author:smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ab1ab9b148dd 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties
Re: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by couldn't get file lock
Apologies for the extreme delay. I added the bug id, and checked that setting the userRoot=. will result in the JTwork/scratch directory being used to store the preferences. I think we had concluded that othervm is the correct choice for running a test when setting the -Djava.util.prefs.userRoot property. Updated webrev: http://cr.openjdk.java.net/~khazra/7197662/webrev.01/ Note that the -Djava.util.prefs.userRoot property is only honored by Linux/Solaris implementations. Windows and Mac OS will continue to use the user's home directory, or the default location that the respective platform uses to store preferences. Thanks, Kurchi On 9/21/12 11:49 AM, Kurchi Hazra wrote: On 21.09.2012 02:03, Chris Hegarty wrote: On 21/09/12 01:12, Dan Xu wrote: Kurchi, Can you append bug number 7197662 to @bug field in each test so that it is easy to check its history? Yes, this is always a good idea. Sure, I missed adding the bug id. For your changes, I wonder why you choose to run these tests in othervm mode. Thanks! The tests need to run in othervm mode as they are now setting a system property. We don't want this system property to inadvertently effect other tests, if a batch are being run in samevm or agentvm. Right, I looked at some examples in jdk/src/test of tests which set system properties, and this is what they were doing. http://openjdk.java.net/jtreg/tag-spec.txt also hints toward the same. Assuming that '.' means the scratch directory when jtreg is running, then I'm fine with these changes. That is a good question, and while I assumed it will, the Mac code is clearly doing other things. I am afraid I need to investigate this for all platforms and see what others do, and whether we need to make additional changes in the Mac source code to correct its behavior. I will get back with a newer webrev soon. Thanks! - Kurchi -Chris. -Dan On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote: Hi, The tests in java/util/prefs creates new nodes under the user's home directory. This causes the tests to start out with pre-existing preferences and sometimes leads to interference between the tests. This fix is to change the userRoot property for each of these tests so these tests create nodes only under the current directory. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197662 Webrev: http://cr.openjdk.java.net/~khazra/7197662/webrev.00/ Thanks, - Kurchi
Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces
On 30/11/2012 12:44 AM, Chris Hegarty wrote: On 11/29/2012 05:50 AM, David Holmes wrote: ... I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The default simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David -Chris.
Re: 7099119: Remove unused dlinfo local variable in launcher code
On 11/29/2012 6:40 PM, Alan Bateman wrote: On 29/11/2012 07:17, Shi Jun wrote: Hi all, Previously 7099119 is fixed in the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this change is lost during the Mac port merging changes 7113349 and 7146424. Hereby I raise this thread again. Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ Previous discuss thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html I don't know this slipped it, perhaps it was due to the refactoring. In any case your change looks fine. -Alan Thanks, Alan. Hi Jonathan, Could you help to push the change? -- Regards, Shi Jun Zhang
hg: jdk8/tl/jdk: 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo
Changeset: 55f8ddc2f9c6 Author:sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java
