hg: jdk8/tl/jdk: 8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails
Changeset: a0896634ab46 Author:sla Date: 2013-08-22 08:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0896634ab46 8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails Reviewed-by: ysr ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java
Re: RFR: JDK-8023430 - Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details
On 21/08/2013 22:06, Dan Xu wrote: : Thanks, Alan. I have updated my webrev at, http://cr.openjdk.java.net/~dxu/8023430/webrev.01/. Please take a look! This looks okay now. -Alan
Re: RFR: 8022445: fix RMISocketFactory example to avoid using localhost
Stuart,
I think I would have picked the more common IPv4 loopback address,
127.0.0.1, but what you have is fine.
-Chris.
On 08/22/2013 01:58 AM, Stuart Marks wrote:
Hi all,
Please review this small documentation change to the example I added to
RMISocketFactory a couple weeks ago [1]. This change fixes a problem
that Bernd Eckenfels pointed out [2] where the interface returned by
getLoopbackAddress() might not match the interface that localhost
resolves to.
Patch appended below.
Thanks,
s'marks
[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2013-August/008346.html
# HG changeset patch
# User smarks
# Date 1377131500 25200
# Node ID fac7907d8c0b4358b9994b04562b722f533db3ac
# Parent 1ccc7bbee0bb4d4d0f472374f2cc544cb07d1336
8022445: fix RMISocketFactory example to avoid using localhost
Reviewed-by: XXX
diff -r 1ccc7bbee0bb -r fac7907d8c0b
src/share/classes/java/rmi/server/RMISocketFactory.java
--- a/src/share/classes/java/rmi/server/RMISocketFactory.javaTue Aug
20 11:15:08 2013 +0200
+++ b/src/share/classes/java/rmi/server/RMISocketFactory.javaWed Aug
21 17:31:40 2013 -0700
@@ -50,13 +50,13 @@
* @implNote
* pYou can use the {@code RMISocketFactory} class to create a
server socket that
* is bound to a specific address, restricting the origin of requests.
For example,
- * the following code implements a socket factory that binds server
sockets to the
+ * the following code implements a socket factory that binds server
sockets to the IPv6
* loopback address. This restricts RMI to processing requests only
from the local host.
*
* pre{@code
* class LoopbackSocketFactory extends RMISocketFactory {
* public ServerSocket createServerSocket(int port) throws
IOException {
- * return new ServerSocket(port, 5,
InetAddress.getLoopbackAddress());
+ * return new ServerSocket(port, 5,
InetAddress.getByName(::1));
* }
*
* public Socket createSocket(String host, int port) throws
IOException {
@@ -72,8 +72,8 @@
* }/pre
*
* Set the {@code java.rmi.server.hostname} system property
- * to a host name (typically {@code localhost}) that resolves to the
loopback
- * interface to ensure that the generated stubs use the right network
interface.
+ * to {@code ::1} to ensure that the generated stubs connect to the right
+ * network interface.
*
* @author Ann Wollrath
* @author Peter Jones
Re: RFR: 8022445: fix RMISocketFactory example to avoid using localhost
On 22/08/2013 01:58, Stuart Marks wrote: Hi all, Please review this small documentation change to the example I added to RMISocketFactory a couple weeks ago [1]. This change fixes a problem that Bernd Eckenfels pointed out [2] where the interface returned by getLoopbackAddress() might not match the interface that localhost resolves to. We don't have support for IPv4-only or IPv6-only listeners (at least not with stream oriented sockets, there is support for protocol specific datagram sockets but that doesn't apply here). So I'm curious about the original comments and whether there are configurations or loopback address plumbing where getLoopbackAddress doesn't do the right thing? -Alan
hg: jdk8/tl/langtools: 8022316: Generic throws, overriding and method reference
Changeset: 7a4717f3ea7b Author:vromero Date: 2013-08-22 10:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a4717f3ea7b 8022316: Generic throws, overriding and method reference Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out
Re: RFR: Remove tests from ProblemList.txt
On 22/08/2013 12:20 AM, Staffan Larsen wrote: I've had a look at these two old bugs: http://bugs.sun.com/view_bug.do?bug_id=7020857 http://bugs.sun.com/view_bug.do?bug_id=6909804 They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively. I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs. How have they been running if they are in the ProblemList ??? David I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems. I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff. Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -336,12 +336,6 @@ # Filed 6653793 com/sun/jdi/RedefineCrossEvent.java generic-all -# Filed 6987312 -com/sun/jdi/DoubleAgentTest.javageneric-all - -# Filed 7020857 -com/sun/jdi/FieldWatchpoints.java generic-all - # Filed 6402201 com/sun/jdi/ProcessAttachTest.shgeneric-all
Re: RFR: Remove tests from ProblemList.txt
On 22 aug 2013, at 13:32, David Holmes david.hol...@oracle.com wrote: On 22/08/2013 12:20 AM, Staffan Larsen wrote: I've had a look at these two old bugs: http://bugs.sun.com/view_bug.do?bug_id=7020857 http://bugs.sun.com/view_bug.do?bug_id=6909804 They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively. I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs. How have they been running if they are in the ProblemList ??? Good question and I wish I understood. From aurora history it looks like some promotion testing runs still included the tests. /Staffan
Re: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black)
On Aug 21, 2013, at 6:47 PM, Paul Sandoz paul.san...@oracle.com wrote: I updated the webrev and replaced TreeBinSplitBackToEntries.java with: http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html Another tweak to ensure untreeify is tested on resize (use the same URL above). I think at this point the tests are in reasonable shape and are on a par with previous tests. Paul.
hg: jdk8/tl/langtools: 8023112: javac should not use lazy constant evaluation approach for method references
Changeset: 25aaff78d754 Author:vromero Date: 2013-08-22 13:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25aaff78d754 8023112: javac should not use lazy constant evaluation approach for method references Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java
Re: RFR: Remove tests from ProblemList.txt
On 8/22/13 5:32 AM, David Holmes wrote: On 22/08/2013 12:20 AM, Staffan Larsen wrote: I've had a look at these two old bugs: http://bugs.sun.com/view_bug.do?bug_id=7020857 http://bugs.sun.com/view_bug.do?bug_id=6909804 They are both listed in ProblemList.txt and reported as intermittent failures in 2011 and 2009 respectively. I've been searching our test history for instances of these failures, but cannot find anything for the last year (didn't look further back). I can see that the tests have been running and I can see other failures in the tests (environment issues mostly) but not the failures reported in the bugs. How have they been running if they are in the ProblemList ??? VM/SQE nightly doesn't use the ProblemList. Dan David I have been doing reruns on linux x86-64 and window x86-64. 1000 iterations did not reproduce the problems. I would thus like to close the bugs and remove the tests from ProblemList.txt. Below is the proposed diff. Thanks, /Staffan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -336,12 +336,6 @@ # Filed 6653793 com/sun/jdi/RedefineCrossEvent.java generic-all -# Filed 6987312 -com/sun/jdi/DoubleAgentTest.java generic-all - -# Filed 7020857 -com/sun/jdi/FieldWatchpoints.java generic-all - # Filed 6402201 com/sun/jdi/ProcessAttachTest.sh generic-all
Re: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black)
On 22/08/2013 13:01, Paul Sandoz wrote: On Aug 21, 2013, at 6:47 PM, Paul Sandozpaul.san...@oracle.com wrote: I updated the webrev and replaced TreeBinSplitBackToEntries.java with: http://cr.openjdk.java.net/~psandoz/tl/JDK-8023463-Linked-HashMap-bin-and-tree/webrev/test/java/util/Map/MapBinToFromTreeTest.java.html Another tweak to ensure untreeify is tested on resize (use the same URL above). I think at this point the tests are in reasonable shape and are on a par with previous tests. I skimmed over the test updates and they looks good to me (and more checks that the original MapBinToFromTreeTest). -Alan.
Re: RFR: 8022445: fix RMISocketFactory example to avoid using localhost
On 22/08/2013 13:48, Bernd Eckenfels wrote: getLoopbackAddress is either ::1 or 127.0.0.1 (depending on the stack preferemces) and InetAddress.getByName(localhost) is also one of both (but not necesarily the same, unfortunately). This happened to me in the past, so I wanted to make sure that asumption does not show up in sample code of JavaDocs. Thanks for improving this! You're right, this method is returning a specific address. In that case, I think Chris's point about using the familiar (IPv4) is probably the way to go when changing this. -Alan.
Re: RFR [7129312] BufferedInputStream calculates negative array size with large streams and mark
Thank you Alan! Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/7129312/3/webrev/ http://cr.openjdk.java.net/%7Eigerasim/7129312/2/webrev/ On 21.08.2013 13:28, Alan Bateman wrote: On 20/08/2013 17:01, Ivan Gerasimov wrote: Yes, you're right! I've updated the test to be a shell script + Java application. If java reported 'Invalid maximum heap size', the test is skipped. Just check with JPRT, the test passes on both 64 and 32 bit platforms. Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/7129312/2/webrev/ http://cr.openjdk.java.net/%7Eigerasim/7129312/2/webrev/ The updated change to BufferedInputStream looks good. On the test then I agree with the approach to skip on 32-bit but I think we should avoid introduce more shell tests. Have you looked at jdk.testlibrary.ProcessTools to launch the test after checking that we are 64-bit? That's a good alternative to shell scripting, I like it. Sincerely yours, Ivan -Alan.
Re: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
On 08/20/2013 11:04 AM, Alan Bateman wrote: On 20/08/2013 07:23, Miroslav Kos wrote: Hi everybody, I prepared a new changeset containing no copyright changes so we can get further: http://cr.openjdk.java.net/~mkos/8022885/webrev.01/ We will discuss rngom changes separately and if necessary, it will be updated with a new integration. Miran Thanks for the dropping this, that make things easier. There are still a bunch updates to copyright dates in files that don't have other changes, they seem harmless and I only assume they have crept in with whatever is used to create the source bundle to push to OpenJDK. Chris - are you going to sponsor this? Yes, I can sponsor this. -Chris. -Alan
Please review fix for 8011944 : Sort fails with ArrayIndexOutOfBoundsException
Please review the fix for: JDK-8011944[1] : Sort fails with ArrayIndexOutOfBoundsException The pending run stack size is estimated based on the input size. The worst case sequence of inputs exceeds the current allocation and an exception occurs. Increasing the allocation of the pending run stack addresses the issue. This was present in the original contribution of Timsort and ComparableTimSort. Webrev[2]: http://cr.openjdk.java.net/~rriggs/webrev-timsort-8011944/ Thanks, Roger [1] http://bugs.sun.com/view_bug.do?bug_id=8011944 [2] http://cr.openjdk.java.net/~rriggs/webrev-timsort-8011944/
hg: jdk8/tl/jdk: 8023587: Fix lone remaining doclint issue in java.util.regex
Changeset: b7c4094be729 Author:darcy Date: 2013-08-22 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7c4094be729 8023587: Fix lone remaining doclint issue in java.util.regex Reviewed-by: jjg ! src/share/classes/java/util/regex/Pattern.java
hg: jdk8/tl/langtools: 8020745: Suspicious MethodParameters attribute generated for local classes capturing local variables
Changeset: 1ab22e60a738 Author:emc Date: 2013-08-22 12:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1ab22e60a738 8020745: Suspicious MethodParameters attribute generated for local classes capturing local variables Summary: Corrected an error in a previous patch that caused captured locals to be added to the beginning, not the end of a parameter list. Reviewed-by: jjg, mcimadamore, ksrini, abuckley ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java - test/tools/javac/8015701/AnonymousParameters.java + test/tools/javac/MethodParameters/CaptureTest.java
hg: jdk8/tl/jdk: 8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details
Changeset: 8a7d9cc2f41c Author:dxu Date: 2013-08-22 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a7d9cc2f41c 8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details Reviewed-by: alanb ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java
JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses double checked locking
JDK 8 Reviewers:
The proposed patch is here:
http://cr.openjdk.java.net/~bpb/6470700/
JTREG tests pass and JMH benchmarking shows a very slight performance
improvement versus the extant code.
Thanks,
Brian
On Aug 21, 2013, at 7:23 PM, Mike Duigou wrote:
On Aug 21 2013, at 17:01 , David M. Lloyd wrote:
On 8/21/13 5:37 PM, Brian Burkhalter wrote:
With respect to this issue
http://bugs.sun.com/view_bug.do?bug_id=6470700
the code of concern from java.lang.Math is
701private static Random randomNumberGenerator;
702
703private static synchronized Random initRNG() {
704Random rnd = randomNumberGenerator;
705return (rnd == null) ? (randomNumberGenerator = new Random()) :
rnd;
706 }
731public static double random() {
732Random rnd = randomNumberGenerator;
733if (rnd == null) rnd = initRNG();
734return rnd.nextDouble();
735}
where the class variable randomNumberGenerator is not used anywhere else
in the class. The complaint is that this is an instance of the broken
double-checked locking pattern. While at first glance this might appear to
be the case, it does not seem so to me. It looks more like an attempt to
avoid calling a synchronized method if randomNumberGenerator has already
been initialized.
A more typical pattern would be
private static Random randomNumberGenerator;
private static synchronized Random getRNG() {
if (randomNumberGenerator == null) {
randomNumberGenerator = new Random();
}
return randomNumberGenerator;
}
public static double random() {
return getRNG().nextDouble();
}
Comments, please.
I don't think you'd want to introduce the overhead of synchronization here.
It may be better in this case to use this kind of lazy init pattern:
static final class Holder {
static final Random RNG = new Random();
}
public static double random() {
return Holder.RNG.nextDouble();
}
--
- DML
David's suggestion seems very reasonable.
Mike
Re: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses double checked locking
On 22/08/2013 20:41, Brian Burkhalter wrote: JDK 8 Reviewers: The proposed patch is here: http://cr.openjdk.java.net/~bpb/6470700/ JTREG tests pass and JMH benchmarking shows a very slight performance improvement versus the extant code. It looks okay to me although the downside of this idiom is yet another class (which I assume can private btw). -Alan
Re: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses double checked locking
You are correct: it should be private - I'll fix that. Thanks, Brian On Aug 22, 2013, at 12:46 PM, Alan Bateman wrote: It looks okay to me although the downside of this idiom is yet another class (which I assume can private btw).
hg: jdk8/tl/langtools: 8022173: Relax some warnings in doclint
Changeset: b77381d99056 Author:jjg Date: 2013-08-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b77381d99056 8022173: Relax some warnings in doclint Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/ListTagsTest.java ! test/tools/doclint/html/OtherTagsTest.java ! test/tools/doclint/html/OtherTagsTest.out ! test/tools/doclint/html/TableTagsTest.java
Re: JDK 8 RFR 6470700: Math.random() / Math.initRNG() uses double checked locking
On 08/22/2013 08:46 PM, Alan Bateman wrote: On 22/08/2013 20:41, Brian Burkhalter wrote: JDK 8 Reviewers: The proposed patch is here: http://cr.openjdk.java.net/~bpb/6470700/ JTREG tests pass and JMH benchmarking shows a very slight performance improvement versus the extant code. It looks okay to me although the downside of this idiom is yet another class (which I assume can private btw). +1 -Chris. -Alan
hg: jdk8/tl/jdk: 8022721: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition
Changeset: 2281a7f79738 Author:plevart Date: 2013-08-20 14:13 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738 8022721: AnnotationTypeDeadlockTest.java throws java.lang.IllegalStateException: unexpected condition Reviewed-by: alanb, jfranck ! test/java/lang/annotation/AnnotationType/AnnotationTypeDeadlockTest.java
Re: RFR: 8022445: fix RMISocketFactory example to avoid using localhost
On 8/22/13 6:48 AM, Alan Bateman wrote: On 22/08/2013 13:48, Bernd Eckenfels wrote: getLoopbackAddress is either ::1 or 127.0.0.1 (depending on the stack preferemces) and InetAddress.getByName(localhost) is also one of both (but not necesarily the same, unfortunately). This happened to me in the past, so I wanted to make sure that asumption does not show up in sample code of JavaDocs. Thanks for improving this! You're right, this method is returning a specific address. In that case, I think Chris's point about using the familiar (IPv4) is probably the way to go when changing this. Thanks for looking at this. I had initially used the IPv6 address since it's more forward-looking, but after reading the comments and after further reflection I'll change it to use an IPv4 loopback address. s'marks
hg: jdk8/tl/jdk: 8022445: fix RMISocketFactory example to avoid using localhost
Changeset: 7496ec8bab76 Author:smarks Date: 2013-08-22 15:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7496ec8bab76 8022445: fix RMISocketFactory example to avoid using localhost Reviewed-by: chegar, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java
Re: RFR: 8022343: j.l.Class.getAnnotatedSuperclass() doesn't return null in some cases
Hi Joel,
The new version is better, but for the testing in question I would
prefer to see something even simpler like:
public static void main(String[] args) throws Exception {
int failed = 0;
Class?[] testData = {/* list of class literals*/}
for (Class? toTest: testData) {
Object res = toTest.getAnnotatedSuperclass();
if (res != null) {
failed++;
System.out.println(toTest + .getAnnotatedSuperclass()
returns:
+ res + , was non-null);
}
}
if (failed != 0)
throw new RuntimeException(Test failed, check log for
details);
}
-Joe
On 8/21/2013 5:04 AM, Joel Borggrén-Franck wrote:
Hi Joe, Paul
I rewrote the test in Paul's style without using testNG.
http://cr.openjdk.java.net/~jfranck/8022343/webrev.01/
Please review.
cheers
/Joel
On 2013-08-19, Joe Darcy wrote:
Hi Joel,
I agree the code looks fine.
However, I concur with the general sentiment of Paul test advice
without advocating using testng for this task.
A loop over a Class?[] initialized with the kinds of values of
interest would seem to be better structured to me and allow for
better exception handing, etc.
-Joe
On 08/19/2013 01:34 AM, Paul Sandoz wrote:
Hi Joel,
The fix looks OK.
Not suggesting you do the following, unless you really want to, but the test is
an example of where TestNG data providers are useful, since all cases will be
tested and reported for pass or failure, rather than in this case the first
failure will cause other checks (if any) not to be tested and in addition will
not report which check failed (one needs to look at the stack trace).
Not tested:
@DataProvider(name = class)
private static Object[][] getClasses() {
// Using the stream API because i can :-)
// Arguably simpler in this case to use new Object[][] { {} }
return Stream.of(
Object.class,
If.class,
Object[].class,
void.class,
int.class).
map(e - new Object[] { e }).
toArray(Object[][]::new);
}
@Test(dataProvider = class)
public void testAnnotatedSuperClassIsNull(Class c) {
assertNull(c.getAnnotatedSuperclass())
}
Paul.
On Aug 16, 2013, at 2:17 PM, Joel Borggren-Franck joel.fra...@oracle.com
wrote:
Hi
Please review this small fix for a type annotation reflection issue.
The javadoc spec for Class.getAnnotatedSuperclass says:
* If this Class represents either the Object class, an interface type, an
* array type, a primitive type, or void, the return value is null.
The patch fixes this.
Webrev at: http://cr.openjdk.java.net/~jfranck/8022343/webrew.00/
Patch also included it at the end of this mail.
cheers
/Joel
diff -r b07b19182e40 src/share/classes/java/lang/Class.java
--- a/src/share/classes/java/lang/Class.javaThu Aug 15 15:04:59 2013 +0100
+++ b/src/share/classes/java/lang/Class.javaFri Aug 16 13:20:31 2013 +0200
@@ -3338,8 +3338,16 @@
* @since 1.8
*/
public AnnotatedType getAnnotatedSuperclass() {
- return
TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(),
getConstantPool(), this);
-}
+if(this == Object.class ||
+isInterface() ||
+isArray() ||
+isPrimitive() ||
+this == Void.TYPE) {
+return null;
+}
+
+return
TypeAnnotationParser.buildAnnotatedSuperclass(getRawTypeAnnotations(),
getConstantPool(), this);
+}
/**
* Returns an array of AnnotatedType objects that represent the use of
types to
diff -r b07b19182e40 test/java/lang/annotation/TypeAnnotationReflection.java
--- a/test/java/lang/annotation/TypeAnnotationReflection.java Thu Aug 15
15:04:59 2013 +0100
+++ b/test/java/lang/annotation/TypeAnnotationReflection.java Fri Aug 16
13:20:31 2013 +0200
@@ -23,7 +23,7 @@
/*
* @test
- * @bug 8004698 8007073
+ * @bug 8004698 8007073 8022343
* @summary Unit test for type annotations
*/
@@ -58,7 +58,7 @@
}
private static void testSuper() throws Exception {
-check(Object.class.getAnnotatedSuperclass().getAnnotations().length ==
0);
+check(Object.class.getAnnotatedSuperclass() == null);
check(Class.class.getAnnotatedSuperclass().getAnnotations().length ==
0);
AnnotatedType a;
diff -r b07b19182e40
test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/test/java/lang/annotation/typeAnnotations/GetAnnotatedSuperclass.java
Fri Aug 16 13:20:31 2013 +0200
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you
RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
Hello everybody! The method ProcessBuilder#inheritIO() is reported to not have any effect on Windows platform. The same story is with redirectOutput/Input/Error(Redirect.INHERIT) methods. As the result, standard in/out/err aren't inherited. It turn out that the culprit is the CREATE_NO_WINDOW flag passed to CreateProcessW(). MS doc says about this flag: The process is a console application that is being run without a console window. CREATE_NO_WINDOW flag was added with the fix for http://bugs.sun.com/view_bug.do?bug_id=4244515 to suppress a console window on a newly created process, when it is created from a program launched with javaw.exe. Thus, I left this flag only for cases when the program doesn't have a console associated with it. Would you please help review a fix for this problem? BUGURL: http://bugs.sun.com/view_bug.do?bug_id=8023130 WEBREV: http://cr.openjdk.java.net/~igerasim/8023130/0/webrev/ Sincerely yours, Ivan Gerasimov
RFR: 8023528: Rename Comparator combinators to disambiguate overloading methods
Hi, Please review a relative simple webrev[1] that basically simply renaming Comparator methods. The reason behind the renaming can be found at this email thread[2]. The specdiff is also available here[3]. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/ [2] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html [3] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html
Re: RFR: 8023528: Rename Comparator combinators to disambiguate overloading methods
Hi Henry, Changes look good. It's also good to see some now-extra casts and type witnesses removed. It somewhat makes up for the longer, non-overloaded method names. Note, corrected email thread[2] link: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-August/002206.html s'marks On 8/22/13 8:21 PM, Henry Jen wrote: Hi, Please review a relative simple webrev[1] that basically simply renaming Comparator methods. The reason behind the renaming can be found at this email thread[2]. The specdiff is also available here[3]. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/webrev/ [2] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-expert/2013-August/002206.html [3] http://cr.openjdk.java.net/~henryjen/ccc/8023528/0/specdiff/overview-summary.html
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 7b6211cd8d76 Author:egahlin Date: 2013-08-21 17:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b6211cd8d76 6417649: -interval=0 is accepted and jconsole doesn't update window content at all Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/JConsole.java Changeset: 77a32e5df365 Author:egahlin Date: 2013-08-21 17:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a32e5df365 6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties
