Re: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
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 On 08/19/2013 05:33 PM, Alan Bateman wrote: On 19/08/2013 13:56, Miroslav Kos wrote: Hi Alan, yes, this is true for rngom library - we downgraded it to the version which has been approved to be used as a 3rd party library. Licences are unchanged from the ones in the library; is there somebody who could approve these are ok? IANAL and without some understanding or legal help then it's impossible to approve changes that remove copyright headers from what seems to be 3rd party code. All I can suggest is to get this checked. -Alan.
hg: jdk8/tl/jdk: 8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine
Changeset: 53ea4b5cef9b Author:sla Date: 2013-08-20 08:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53ea4b5cef9b 8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine Reviewed-by: erikj, sspitsyn ! makefiles/CompileNativeLibraries.gmk + makefiles/mapfiles/libattach/reorder-windows-x86 + makefiles/mapfiles/libattach/reorder-windows-x86_64 ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c
Re: Simple RFR: 8203311 Clean up profile-includes.txt
On 20/08/2013 00:33, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/8023311/webrev/ Patch inlined below This is a trivial cleanup following on from an earlier change under 8017570. JFR was moved from profile compact3 to the full JRE but not all the variables in profile-includes.txt were updated as needed. jfr.jar needed to removed from the profile3 jar list and added to the jre jar list. This has no impact on the actual build artifacts - JFR was, and remains, in the full JRE only. This looks okay to me, I can't quite tell why this wasn't done as part of JDK- 8017570 as it's not hard to miss. -Alan.
Re: Simple RFR: 8203311 Clean up profile-includes.txt
On 20/08/2013 5:02 PM, Alan Bateman wrote: On 20/08/2013 00:33, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/8023311/webrev/ Patch inlined below This is a trivial cleanup following on from an earlier change under 8017570. JFR was moved from profile compact3 to the full JRE but not all the variables in profile-includes.txt were updated as needed. jfr.jar needed to removed from the profile3 jar list and added to the jre jar list. This has no impact on the actual build artifacts - JFR was, and remains, in the full JRE only. This looks okay to me, I can't quite tell why this wasn't done as part of JDK- 8017570 as it's not hard to miss. Thanks Alan. I can't recall why I didn't review it either. :) David -Alan.
hg: jdk8/tl/jdk: 8023311: Clean up profile-includes.txt
Changeset: e17da8b09f5e Author:dholmes Date: 2013-08-20 03:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e17da8b09f5e 8023311: Clean up profile-includes.txt Reviewed-by: alanb ! makefiles/profile-includes.txt
Re: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review
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? -Alan
Re: RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
On 08/19/2013 07:07 AM, Paul Sandoz wrote: Hi, This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom: http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/ A couple of extra @since's crept in. See below. I have yet to define a common interface e.g. RandomGenerator After scrapping this idea twice now already for JDK8 time frame, I think leave it for JDK9. ... diff ThreadLocalRandom.java~ ThreadLocalRandom.java 316d315 * @since 1.8 331d329 * @since 1.8 370d367 * @since 1.8 425d421 * @since 1.8 470d465 * @since 1.8 482d476 * @since 1.8
8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed. One of the next steps needs to be to remove the definitions of the test targets from the make file as it can't currently be shared between the Makefile and direct jtreg usage. To that end, I'd like to push a TEST.groups file to define the corresponding jtreg groups. For the most part the proposal is to start up with a mostly 1-1 mapping for the existing test targets. In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named core, svc and desktop. This makes it really easy to run selections of the test suite, for example jtreg options :core :svc will run all the core area and serviceability tests. One other thing to mention is that David Holmes will arrive soon with additional groups to add selection of tests that are appropriate for the compact Profiles, maybe JRE vs. JDK too. The webrev with the proposed changes is here, it's very simple: http://cr.openjdk.java.net/~alanb/8023351/webrev/ A few things to note (as there are a few small changes from the normal test targets): 1. I've moved the management and java.lang.instrument tests out of the jdk_lang group. Once the make file targets are updated then these can be re-included if needed but logically they should be separated. 2. I have not moved the JSR-292 tests or stream tests, they remain in jdk_lang and jdk_util for now. They can easily be changed if there is good reason. 3. I've kept security1, security2 and security3 for now but these are unbalanced in execution time and ideally should all be in one group. Once we get to the point that concurrency is dialed up by default then that might be the right time to do that. 4. To my knowledge, the client teams do not use the make files and I don't know anyone that used the jdk_awt, etc. make targets. For now, I've just re-worked those targets (eliminating the beans1, beans2, beans3 that have not been needed since we moved the execution mode out of the make file). I'm sure someone in the AWT or 2D area could come up with cleaner definitions but as they aren't used then it shouldn't matter for now. -Alan
Please ignore: TEST without signing using OpenPGP (signed messages appear to be blocked)
Paul.
Re: RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
[resending unsigned, sorry if a dup arrives later on] On Aug 20, 2013, at 1:46 PM, Doug Lea d...@cs.oswego.edu wrote: On 08/19/2013 07:07 AM, Paul Sandoz wrote: Hi, This patch updates Random and ThreadLocalRandom to have functional consistency (for the most part) across Random, ThreadLocalRandom and SplittableRandom: http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/ A couple of extra @since's crept in. See below. According to the spec diff new overriding methods are added to TLR: http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/java/util/concurrent/ThreadLocalRandom.html http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/java/util/Random.html Is that sufficient motivation to add @since to such methods on TLR? I have yet to define a common interface e.g. RandomGenerator After scrapping this idea twice now already for JDK8 time frame, I think leave it for JDK9. OK. I like the idea of an interface but i am concerned we don't have enough time to flesh out the contract. Personally i would prefer to manage this webrev minus an interface, otherwise i fear we will never get the patch in! Paul.
Re: Enum.valueOf(String)
Jon, it's not a problem with the method docs, per se. The issue is about how the generation isn't documented. My questioning started because I was using several enums without javadoc available, but I did have the source available, and couldn't figure out how the method came to be. Since I've asked, everyone knew (but me!) it was a generated method, but I couldn't divine that knowledge. My recommendation is to add an @implNote on Enum.valueOf(Class, String) so that people know each subclass will get a generated method that behaves similarly. What do you think? On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict pbened...@apache.org wrote: I have been working with classes that don't have javadoc attachments. The problem was I couldn't find the method in the source nor was the method part of the Enum class. So where did it materialize from? Now I know the answer: the compiler generates it. I really think this knowledge should be added to the Enum javadoc class. I had to go on quite a goose hunt to find this fact. Paul On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman alan.bate...@oracle.comwrote: On 18/08/2013 05:07, Paul Benedict wrote: I think the generated method needs to be listed in the class javadoc at least. I presume it throws an exception too (like the other valueOf) if the String can't be resolved to a constant, but no user is going to discover this fact through the documentation. Have you checked the generated avadoc for your enum? The valueOf(String) should be there and specified to throw IAE or NPE. -Alan -- Cheers, Paul -- Cheers, Paul
Re: RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom
[resending unsigned, sorry if a dup arrives later on] On Aug 19, 2013, at 9:17 PM, Mike Duigou mike.dui...@oracle.com wrote: - documentation of bound should mention that it is exclusive rather than relying on the return documentation. I have updated both webrevs and the spec diff to be consistent when referring to ranges: http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/webrev/ http://cr.openjdk.java.net/~psandoz/tl/JDK-8020292-SplittableRandom/webrev/ http://cr.openjdk.java.net/~psandoz/tl/JDK-8023155-Random-TLR-SR-sync/specdiff/overview-summary.html (SplittableRandom is also updated to include some blurb on not being cryptographically secure.) Paul.
hg: jdk8/tl/langtools: 7182350: Regression in wording of unchecked warning message
Changeset: 55da6b3a6940 Author:kizune Date: 2013-08-20 17:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55da6b3a6940 7182350: Regression in wording of unchecked warning message Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/6758789/T6758789b.out + test/tools/javac/7182350/T7182350.java + test/tools/javac/7182350/T7182350.out ! test/tools/javac/generics/7015430/T7015430_1.out ! test/tools/javac/generics/7015430/T7015430_2.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/inference/7177306/T7177306a.out
Re: Enum.valueOf(String)
Paul, Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, Enum Body Declarations, beginning at the line In addition, if E is the name of an enum type, then that type has the following implicitly declared static methods: -- Jon On 08/20/2013 06:27 AM, Paul Benedict wrote: Jon, it's not a problem with the method docs, per se. The issue is about how the generation isn't documented. My questioning started because I was using several enums without javadoc available, but I did have the source available, and couldn't figure out how the method came to be. Since I've asked, everyone knew (but me!) it was a generated method, but I couldn't divine that knowledge. My recommendation is to add an @implNote on Enum.valueOf(Class, String) so that people know each subclass will get a generated method that behaves similarly. What do you think? On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict pbened...@apache.org mailto:pbened...@apache.org wrote: I have been working with classes that don't have javadoc attachments. The problem was I couldn't find the method in the source nor was the method part of the Enum class. So where did it materialize from? Now I know the answer: the compiler generates it. I really think this knowledge should be added to the Enum javadoc class. I had to go on quite a goose hunt to find this fact. Paul On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote: On 18/08/2013 05:07, Paul Benedict wrote: I think the generated method needs to be listed in the class javadoc at least. I presume it throws an exception too (like the other valueOf) if the String can't be resolved to a constant, but no user is going to discover this fact through the documentation. Have you checked the generated avadoc for your enum? The valueOf(String) should be there and specified to throw IAE or NPE. -Alan -- Cheers, Paul -- Cheers, Paul
Re: Enum.valueOf(String)
So are you recommending not to alter the Javadoc of Enum to mention this fact? Going to the JLS is great for compiler developers, but it's not the first place for the end user. On Tue, Aug 20, 2013 at 8:48 AM, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: Paul, Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, Enum Body Declarations, beginning at the line In addition, if E is the name of an enum type, then that type has the following implicitly declared static methods: -- Jon On 08/20/2013 06:27 AM, Paul Benedict wrote: Jon, it's not a problem with the method docs, per se. The issue is about how the generation isn't documented. My questioning started because I was using several enums without javadoc available, but I did have the source available, and couldn't figure out how the method came to be. Since I've asked, everyone knew (but me!) it was a generated method, but I couldn't divine that knowledge. My recommendation is to add an @implNote on Enum.valueOf(Class, String) so that people know each subclass will get a generated method that behaves similarly. What do you think? On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict pbened...@apache.orgwrote: I have been working with classes that don't have javadoc attachments. The problem was I couldn't find the method in the source nor was the method part of the Enum class. So where did it materialize from? Now I know the answer: the compiler generates it. I really think this knowledge should be added to the Enum javadoc class. I had to go on quite a goose hunt to find this fact. Paul On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman alan.bate...@oracle.comwrote: On 18/08/2013 05:07, Paul Benedict wrote: I think the generated method needs to be listed in the class javadoc at least. I presume it throws an exception too (like the other valueOf) if the String can't be resolved to a constant, but no user is going to discover this fact through the documentation. Have you checked the generated avadoc for your enum? The valueOf(String) should be there and specified to throw IAE or NPE. -Alan -- Cheers, Paul -- Cheers, Paul -- Cheers, Paul
Re: RFR (M) CR 8023234: StampedLock serializes readers on writer unlock
Thanks Martin!
New webrev:
http://cr.openjdk.java.net/~shade/8023234/webrev.01/
On 08/20/2013 03:06 AM, Martin Buchholz wrote:
Thanks. Looks good.
Style suggestions for the test:
+while(!isDone !isInterrupted()) {
SPC after keywords.
Fixed.
I think it's more readable to use CountDownLatch instead of
CyclicBarrier for writerHasLock, because of asymmetric API.
Doers call countDown(), waiters call await().
Nope, we need: a) *reusable* primitive, CDL is one-shot, unfortunately;
b) we need symmetric block, writer should also block on barrier until
both readers arrive; this makes test much more reliable.
-Aleksey.
Re: Enum.valueOf(String)
Well, I presume other learning materials for Java (tutorials, ... for dummies, etc) will explain the existence of these methods as part of the language feature that is enums. Quite where the bytecodes for the methods comes from is implementation detail that should not need to be documented in end-user docs. Interestingly, though, is that the javadoc for Enum.valueOf *does* have something close to the text you want: http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String) Note that for a particular enum type T, the implicitly declared public static T valueOf(String) method on that enum may be used instead of this method to map from a name to the corresponding enum constant. All the constants of an enum type can be obtained by calling the implicit public static T[] values() method of that type. -- Jon On 08/20/2013 07:29 AM, Paul Benedict wrote: So are you recommending not to alter the Javadoc of Enum to mention this fact? Going to the JLS is great for compiler developers, but it's not the first place for the end user. On Tue, Aug 20, 2013 at 8:48 AM, Jonathan Gibbons jonathan.gibb...@oracle.com mailto:jonathan.gibb...@oracle.com wrote: Paul, Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, Enum Body Declarations, beginning at the line In addition, if E is the name of an enum type, then that type has the following implicitly declared static methods: -- Jon On 08/20/2013 06:27 AM, Paul Benedict wrote: Jon, it's not a problem with the method docs, per se. The issue is about how the generation isn't documented. My questioning started because I was using several enums without javadoc available, but I did have the source available, and couldn't figure out how the method came to be. Since I've asked, everyone knew (but me!) it was a generated method, but I couldn't divine that knowledge. My recommendation is to add an @implNote on Enum.valueOf(Class, String) so that people know each subclass will get a generated method that behaves similarly. What do you think? On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict pbened...@apache.org mailto:pbened...@apache.org wrote: I have been working with classes that don't have javadoc attachments. The problem was I couldn't find the method in the source nor was the method part of the Enum class. So where did it materialize from? Now I know the answer: the compiler generates it. I really think this knowledge should be added to the Enum javadoc class. I had to go on quite a goose hunt to find this fact. Paul On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote: On 18/08/2013 05:07, Paul Benedict wrote: I think the generated method needs to be listed in the class javadoc at least. I presume it throws an exception too (like the other valueOf) if the String can't be resolved to a constant, but no user is going to discover this fact through the documentation. Have you checked the generated avadoc for your enum? The valueOf(String) should be there and specified to throw IAE or NPE. -Alan -- Cheers, Paul -- Cheers, Paul -- Cheers, Paul
hg: jdk8/tl/jdk: 8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently
Changeset: 961cdea684b5 Author:sla Date: 2013-08-20 16:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/961cdea684b5 8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently Reviewed-by: alanb ! test/com/sun/jdi/sde/TemperatureTableTest.java
hg: jdk8/tl/langtools: 8019243: AnnotationTypeMismatchException instead of MirroredTypeException
Changeset: e811fb09a1dc Author:jfranck Date: 2013-08-20 17:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e811fb09a1dc 8019243: AnnotationTypeMismatchException instead of MirroredTypeException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java + test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java + test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java + test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.out
RFR 8023367 Collections.emptyList().sort((Comparator)null) throws NPE
Hi,
Please see below for a simple fix to stop throwing an NPE on
Collections.emptyList().sort(null);
Paul.
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126
diff -r 3647aab7b1d5 src/share/classes/java/util/Collections.java
--- a/src/share/classes/java/util/Collections.java Tue Aug 06 14:26:34
2013 +0100
+++ b/src/share/classes/java/util/Collections.java Tue Aug 20 17:38:16
2013 +0200
@@ -4508,7 +4508,6 @@
}
@Override
public void sort(Comparator? super E c) {
-Objects.requireNonNull(c);
}
// Override default methods in Collection
diff -r 3647aab7b1d5 test/java/util/Collection/ListDefaults.java
--- a/test/java/util/Collection/ListDefaults.java Tue Aug 06 14:26:34
2013 +0100
+++ b/test/java/util/Collection/ListDefaults.java Tue Aug 20 17:38:16
2013 +0200
@@ -49,6 +49,7 @@
/**
* @test
+ * @bug 8023367
* @library testlibrary
* @build CollectionAsserts CollectionSupplier
* @run testng ListDefaults
@@ -100,6 +101,7 @@
@DataProvider(name=listProvider, parallel=true)
public static Object[][] listCases() {
final ListObject[] cases = new LinkedList();
+cases.add(new Object[] { Collections.emptyList() });
cases.add(new Object[] { new ArrayList() });
cases.add(new Object[] { new LinkedList() });
cases.add(new Object[] { new Vector() });
@@ -128,6 +130,11 @@
list.removeIf(null);
fail(expected NPE not thrown);
} catch (NullPointerException npe) {}
+try {
+list.sort(null);
+} catch (Throwable t) {
+fail(Exception not expected: + t);
+}
}
@Test
Re: RFR [7129312] BufferedInputStream calculates negative array size with large streams and mark
Thank you Alan! The update to BufferedInputStream looks okay to me. I guess we don't actually need to check the size in the constructor, OOME will be thrown anyway. Usually constants are in uppercase and maybe we should just do this while we are here (so this means rename defaultBufferSize too). Removed the unnecessary check and renamed the constants. I'm in two minds about the test as reserving 4GB of heap is going to be a problem on some systems (32-bit mostly). 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/ Sincerely yours, Ivan -Alan.
Re: RFR 8023367 Collections.emptyList().sort((Comparator)null) throws NPE
On 20/08/2013 16:39, Paul Sandoz wrote: Hi, Please see below for a simple fix to stop throwing an NPE on Collections.emptyList().sort(null); Paul. Looks okay to me. -Alan
Re: RFR 8023367 Collections.emptyList().sort((Comparator)null) throws NPE
Looks OK to me.
On Aug 20 2013, at 08:39 , Paul Sandoz wrote:
Hi,
Please see below for a simple fix to stop throwing an NPE on
Collections.emptyList().sort(null);
Paul.
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67e00b862126
diff -r 3647aab7b1d5 src/share/classes/java/util/Collections.java
--- a/src/share/classes/java/util/Collections.javaTue Aug 06 14:26:34
2013 +0100
+++ b/src/share/classes/java/util/Collections.javaTue Aug 20 17:38:16
2013 +0200
@@ -4508,7 +4508,6 @@
}
@Override
public void sort(Comparator? super E c) {
-Objects.requireNonNull(c);
}
// Override default methods in Collection
diff -r 3647aab7b1d5 test/java/util/Collection/ListDefaults.java
--- a/test/java/util/Collection/ListDefaults.java Tue Aug 06 14:26:34
2013 +0100
+++ b/test/java/util/Collection/ListDefaults.java Tue Aug 20 17:38:16
2013 +0200
@@ -49,6 +49,7 @@
/**
* @test
+ * @bug 8023367
* @library testlibrary
* @build CollectionAsserts CollectionSupplier
* @run testng ListDefaults
@@ -100,6 +101,7 @@
@DataProvider(name=listProvider, parallel=true)
public static Object[][] listCases() {
final ListObject[] cases = new LinkedList();
+cases.add(new Object[] { Collections.emptyList() });
cases.add(new Object[] { new ArrayList() });
cases.add(new Object[] { new LinkedList() });
cases.add(new Object[] { new Vector() });
@@ -128,6 +130,11 @@
list.removeIf(null);
fail(expected NPE not thrown);
} catch (NullPointerException npe) {}
+try {
+list.sort(null);
+} catch (Throwable t) {
+fail(Exception not expected: + t);
+}
}
@Test
Re: 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
I think this look OK Alan Best Lance On Aug 20, 2013, at 8:13 AM, Alan Bateman wrote: For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed. One of the next steps needs to be to remove the definitions of the test targets from the make file as it can't currently be shared between the Makefile and direct jtreg usage. To that end, I'd like to push a TEST.groups file to define the corresponding jtreg groups. For the most part the proposal is to start up with a mostly 1-1 mapping for the existing test targets. In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named core, svc and desktop. This makes it really easy to run selections of the test suite, for example jtreg options :core :svc will run all the core area and serviceability tests. One other thing to mention is that David Holmes will arrive soon with additional groups to add selection of tests that are appropriate for the compact Profiles, maybe JRE vs. JDK too. The webrev with the proposed changes is here, it's very simple: http://cr.openjdk.java.net/~alanb/8023351/webrev/ A few things to note (as there are a few small changes from the normal test targets): 1. I've moved the management and java.lang.instrument tests out of the jdk_lang group. Once the make file targets are updated then these can be re-included if needed but logically they should be separated. 2. I have not moved the JSR-292 tests or stream tests, they remain in jdk_lang and jdk_util for now. They can easily be changed if there is good reason. 3. I've kept security1, security2 and security3 for now but these are unbalanced in execution time and ideally should all be in one group. Once we get to the point that concurrency is dialed up by default then that might be the right time to do that. 4. To my knowledge, the client teams do not use the make files and I don't know anyone that used the jdk_awt, etc. make targets. For now, I've just re-worked those targets (eliminating the beans1, beans2, beans3 that have not been needed since we moved the execution mode out of the make file). I'm sure someone in the AWT or 2D area could come up with cleaner definitions but as they aren't used then it shouldn't matter for now. -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
hg: jdk8/tl/jdk: 8023367: Collections.emptyList().sort((Comparator)null) throws NPE
Changeset: c17d6543b30f Author:psandoz Date: 2013-08-20 17:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c17d6543b30f 8023367: Collections.emptyList().sort((Comparator)null) throws NPE Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Collections.java ! test/java/util/Collection/ListDefaults.java
Test for java.sql.DriverManager
Hi, not sure about mailing group, but here is a test i wrote https://gist.github.com/artkoshelev/6256684. Review please and add it to testbase. Artem
hg: jdk8/tl/jdk: 8023250: Update JavaScript code in JDK for changes in iteration over Java arrays
Changeset: 1ccc7bbee0bb Author:attila Date: 2013-08-20 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ccc7bbee0bb 8023250: Update JavaScript code in JDK for changes in iteration over Java arrays Reviewed-by: sundar, sla ! src/share/classes/com/sun/tools/hat/resources/hat.js
Re: 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
Looks very good! On Aug 20 2013, at 05:13 , Alan Bateman wrote: For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed. One of the next steps needs to be to remove the definitions of the test targets from the make file as it can't currently be shared between the Makefile and direct jtreg usage. I'm eager to wield the axe again once this is change is integrated to remove the directory specifications from the test/Makefile (and hopefully soon from jprt.properties as well). :-) To that end, I'd like to push a TEST.groups file to define the corresponding jtreg groups. For the most part the proposal is to start up with a mostly 1-1 mapping for the existing test targets. Once we have A/B runs that show the same tests are run we can consider refactoring the organization. (For example, I would like to see at least a portion of sun/misc move from jdk_lang to jdk_util). In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named core, svc and desktop. This makes it really easy to run selections of the test suite, for example jtreg options :core :svc will run all the core area and serviceability tests. One other thing to mention is that David Holmes will arrive soon with additional groups to add selection of tests that are appropriate for the compact Profiles, maybe JRE vs. JDK too. The webrev with the proposed changes is here, it's very simple: http://cr.openjdk.java.net/~alanb/8023351/webrev/ A few things to note (as there are a few small changes from the normal test targets): 1. I've moved the management and java.lang.instrument tests out of the jdk_lang group. Once the make file targets are updated then these can be re-included if needed but logically they should be separated. 2. I have not moved the JSR-292 tests or stream tests, they remain in jdk_lang and jdk_util for now. They can easily be changed if there is good reason. Probably they will get their own sub-groups but may or may not remain in the super-groups. 3. I've kept security1, security2 and security3 for now but these are unbalanced in execution time and ideally should all be in one group. Once we get to the point that concurrency is dialed up by default then that might be the right time to do that. I am glad to see you defined the jdk_security super-group. This allows us to abstract these details. 4. To my knowledge, the client teams do not use the make files and I don't know anyone that used the jdk_awt, etc. make targets. For now, I've just re-worked those targets (eliminating the beans1, beans2, beans3 that have not been needed since we moved the execution mode out of the make file). I'm sure someone in the AWT or 2D area could come up with cleaner definitions but as they aren't used then it shouldn't matter for now. -Alan
RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
Hello all; This is a proposal to deprecate (Any votes for outright removal?) two classes in the private sun.misc package. These are ancient vestigial classes who's usage has long been eliminated in the JDK in favour of java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int start, int end, Comparator). http://cr.openjdk.java.net/~mduigou/JDK-8023395/0/webrev/ Mike
RFR: 8023306 : (xs) Add replace() implementations to TreeMap
Hello all; This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map. webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/ Cheers, Mike
Re: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
+1 On Aug 20, 2013, at 11:07 AM, Mike Duigou wrote: Any votes for outright removal?
Re: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
On 08/20/2013 11:07 AM, Mike Duigou wrote: Hello all; This is a proposal to deprecate (Any votes for outright removal?) Yes; take them out! -Joe
Re: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
+1 On Aug 20, 2013, at 11:11 AM, Mike Duigou wrote: This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map. webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/
Re: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
Paul Sandoz pointed out (again) that I let synchronized slip back into the split out patch. http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/ Corrects this error. Mike On Aug 20 2013, at 11:11 , Mike Duigou wrote: Hello all; This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map. webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/ Cheers, Mike
Re: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
On 08/20/2013 07:54 PM, Mike Duigou wrote: Paul Sandoz pointed out (again) that I let synchronized slip back into the split out patch. http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/ Yes, the sycn free versions look better. -Chris. Corrects this error. Mike On Aug 20 2013, at 11:11 , Mike Duigou wrote: Hello all; This is a small changeset I have split out from the mostly unrelated JDK-8021591. This changeset adds Map.replace(key,value) and Map.replace(key,oldValue,newValue) implementations to TreeMap that are more efficient that that provided by the defaults in Map. webrev: http://cr.openjdk.java.net/~mduigou/JDK-8023306/0/webrev/ Cheers, Mike
Re: RFR: 8023306 : (xs) Add replace() implementations to TreeMap
On 20/08/2013 19:54, Mike Duigou wrote: Paul Sandoz pointed out (again) that I let synchronized slip back into the split out patch. http://cr.openjdk.java.net/~mduigou/JDK-8023306/1/webrev/ Corrects this error. Mike Looks okay to me, I guess I would Entry e rather than p but that's just a personal preference. -Alan
Re: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
On 20/08/2013 19:07, Mike Duigou wrote: Hello all; This is a proposal to deprecate (Any votes for outright removal?) No objection to deprecating it but I assume anyone compiling against it is seeing a warning already (because it's a JDK internal class). We've historically being cautious about removing classes from sun.misc (as we know there is code that ignores the warnings). So I would at least do a quick check to see if there is anything obvious using it. One other thing is that this isn't the only orphan in sun.misc. Some time ago I created JDK-6852936 with a list of classes that aren't used. I wasn't brave enough at the time to try to remove them. -Alan two classes in the private sun.misc package. These are ancient vestigial classes who's usage has long been eliminated in the JDK in favour of java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int start, int end, Comparator). http://cr.openjdk.java.net/~mduigou/JDK-8023395/0/webrev/
Re: Enum.valueOf(String)
Eamonn, See http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String) Note that for a particular enum type T, the implicitly declared public static T valueOf(String) method on that enum may be used instead of this method to map from a name to the corresponding enum constant. All the constants of an enum type can be obtained by calling the implicit public static T[] values() method of that type. -- Jon On 08/20/2013 11:00 AM, Eamonn McManus wrote: As I mentioned earlier in the thread, it's kind of user-hostile for the Enum javadoc to send the user to the JLS instead of just saying, even briefly, what the methods are. Even more so since it doesn't actually link to the relevant section of the JLS or in fact to the JLS at all. This is not a complaint that the information isn't documented, just that it is too hard to find. Imagine how much work I have to do if I can't remember the name of the method to convert from a string to an enum constant in a new enum I'm writing, and it doesn't occur to me to pick some other random enum and look at its javadoc. Éamonn 2013/8/20 Jonathan Gibbons jonathan.gibb...@oracle.com: Paul, Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2, Enum Body Declarations, beginning at the line In addition, if E is the name of an enum type, then that type has the following implicitly declared static methods: -- Jon On 08/20/2013 06:27 AM, Paul Benedict wrote: Jon, it's not a problem with the method docs, per se. The issue is about how the generation isn't documented. My questioning started because I was using several enums without javadoc available, but I did have the source available, and couldn't figure out how the method came to be. Since I've asked, everyone knew (but me!) it was a generated method, but I couldn't divine that knowledge. My recommendation is to add an @implNote on Enum.valueOf(Class, String) so that people know each subclass will get a generated method that behaves similarly. What do you think? On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict pbened...@apache.org mailto:pbened...@apache.org wrote: I have been working with classes that don't have javadoc attachments. The problem was I couldn't find the method in the source nor was the method part of the Enum class. So where did it materialize from? Now I know the answer: the compiler generates it. I really think this knowledge should be added to the Enum javadoc class. I had to go on quite a goose hunt to find this fact. Paul On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote: On 18/08/2013 05:07, Paul Benedict wrote: I think the generated method needs to be listed in the class javadoc at least. I presume it throws an exception too (like the other valueOf) if the String can't be resolved to a constant, but no user is going to discover this fact through the documentation. Have you checked the generated avadoc for your enum? The valueOf(String) should be there and specified to throw IAE or NPE. -Alan -- Cheers, Paul -- Cheers, Paul
Re: RFR: 8016846: Pattern.splitAsStream tests required
On 07/24/2013 09:14 AM, Alan Bateman wrote: On 16/07/2013 12:05, Henry Jen wrote: Hi, Please review the webrev at, http://cr.openjdk.java.net/~henryjen/tl/8016846/0/webrev/ The test is mostly contributed by Ben Evans. Cheers, Henry It looks okay to me, just a concern that the tests for the regex API are normally in test/java/util/regex. We are using stream test framework on this to verify all style of stream works, with that we will need to have library on bootclasspath, and that current prevent us from put it in test/java/util/regex because of jtreg limitation. If no object, I'll push this at its current location. We can revisit this when jtreg support is available. The other alternative is that we refactor the test to test only split, and leave out the various style of stream checking. While we lose the sanity check, but I don't think we lose much as the form of iterator converted into stream and operated should have been covered in other stream tests. Let me know if we think it's important enough to refactor the test. Cheers, Henry
Re: Enum.valueOf(String)
It might occur to me to look at valueOf(Class, String) if I was
looking for a method to convert a string to an enum constant, but I
don't think it would occur to me to look there if I was looking for a
method to get all the values of an enum. I'm sure plenty of people end
up using MyEnum.class.getEnumConstants() because that *is* linked to
from the class javadoc. Perhaps a {@link} from the class javadoc to
the valueOf(Class, String) method would be sufficient, like this:
* More information about enums, including descriptions of the
* implicitly declared methods synthesized by the compiler, can be
* found in section 8.9 of
* citeThe Javatrade; Language Specification/cite. See also
* the description in {@link #valueOf valueOf}.
Additionally, Class.getEnumConstants() could mention the simpler
alternative if the class is known at compile time.
Éamonn
2013/8/20 Jonathan Gibbons jonathan.gibb...@oracle.com:
Eamonn,
See
http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html#valueOf(java.lang.Class,%20java.lang.String)
Note that for a particular enum type T, the implicitly declared public
static T valueOf(String) method on that enum may be used instead of this
method to map from a name to the corresponding enum constant. All the
constants of an enum type can be obtained by calling the implicit public
static T[] values() method of that type.
-- Jon
On 08/20/2013 11:00 AM, Eamonn McManus wrote:
As I mentioned earlier in the thread, it's kind of user-hostile for
the Enum javadoc to send the user to the JLS instead of just saying,
even briefly, what the methods are. Even more so since it doesn't
actually link to the relevant section of the JLS or in fact to the JLS
at all. This is not a complaint that the information isn't documented,
just that it is too hard to find. Imagine how much work I have to do
if I can't remember the name of the method to convert from a string to
an enum constant in a new enum I'm writing, and it doesn't occur to me
to pick some other random enum and look at its javadoc.
Éamonn
2013/8/20 Jonathan Gibbons jonathan.gibb...@oracle.com:
Paul,
Enums are well covered in JLS 7, section 8.9. In particular, see 8.9.2,
Enum
Body Declarations, beginning at the line
In addition, if E is the name of an enum type, then that type has the
following implicitly declared static methods:
-- Jon
On 08/20/2013 06:27 AM, Paul Benedict wrote:
Jon, it's not a problem with the method docs, per se. The issue is about
how the generation isn't documented. My questioning started because I
was
using several enums without javadoc available, but I did have the source
available, and couldn't figure out how the method came to be. Since I've
asked, everyone knew (but me!) it was a generated method, but I couldn't
divine that knowledge.
My recommendation is to add an @implNote on Enum.valueOf(Class, String)
so
that people know each subclass will get a generated method that behaves
similarly. What do you think?
On Mon, Aug 19, 2013 at 9:23 AM, Paul Benedict pbened...@apache.org
mailto:pbened...@apache.org wrote:
I have been working with classes that don't have javadoc
attachments. The problem was I couldn't find the method in the
source nor was the method part of the Enum class. So where did it
materialize from? Now I know the answer: the compiler generates it.
I really think this knowledge should be added to the Enum javadoc
class. I had to go on quite a goose hunt to find this fact.
Paul
On Mon, Aug 19, 2013 at 3:32 AM, Alan Bateman
alan.bate...@oracle.com mailto:alan.bate...@oracle.com wrote:
On 18/08/2013 05:07, Paul Benedict wrote:
I think the generated method needs to be listed in the
class javadoc at
least. I presume it throws an exception too (like the
other valueOf) if the
String can't be resolved to a constant, but no user is
going to discover
this fact through the documentation.
Have you checked the generated avadoc for your enum? The
valueOf(String) should be there and specified to throw IAE or
NPE.
-Alan
-- Cheers,
Paul
--
Cheers,
Paul
hg: jdk8/tl/langtools: 8011043: Warn about use of 1.5 and earlier source and target values
Changeset: 58da1296c6b3 Author:darcy Date: 2013-08-20 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58da1296c6b3 8011043: Warn about use of 1.5 and earlier source and target values Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javadoc/Start.java + test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java
Re: RFR : 8023395 : (xs) Deprecate sun.misc.Sort and sun.misc.Compare
FWIW. From the maven artifacts I looked at last year (essentially ran jdeps), there is only one reference to these 2 sun.misc classes: http://grepcode.com/file/repo1.maven.org/maven2/net.sf.ingenias/iaf/1.3/ingenias/jade/EventPanelLogger.java Mandy On 8/20/2013 12:33 PM, Alan Bateman wrote: On 20/08/2013 19:07, Mike Duigou wrote: Hello all; This is a proposal to deprecate (Any votes for outright removal?) No objection to deprecating it but I assume anyone compiling against it is seeing a warning already (because it's a JDK internal class). We've historically being cautious about removing classes from sun.misc (as we know there is code that ignores the warnings). So I would at least do a quick check to see if there is anything obvious using it. One other thing is that this isn't the only orphan in sun.misc. Some time ago I created JDK-6852936 with a list of classes that aren't used. I wasn't brave enough at the time to try to remove them. -Alan two classes in the private sun.misc package. These are ancient vestigial classes who's usage has long been eliminated in the JDK in favour of java.util.Arrays.sort(T[], Comparator) and java.util.Arrays.sort(T[], int start, int end, Comparator). http://cr.openjdk.java.net/~mduigou/JDK-8023395/0/webrev/
Re: Enum.valueOf(String)
On 08/20/2013 04:09 PM, Eamonn McManus wrote: It might occur to me to look at valueOf(Class, String) if I was looking for a method to convert a string to an enum constant, but I don't think it would occur to me to look there if I was looking for a method to get all the values of an enum. I'm sure plenty of people end up using MyEnum.class.getEnumConstants() because that *is* linked to from the class javadoc. As a counter-argument, using an IDE's auto-complete makes it really really easy to discover the values() method. In fact, it never even occurred to me that there is an MyEnum.class.getEnumConstants() method that would do the same. Cheers, Omair
Re: RFR [7129312] BufferedInputStream calculates negative array size with large streams and mark
Just check with JPRT, the test passes on both 64 and 32 bit platforms. Was meant: I've just checked with JPRT, and the test passes on both 64 and 32 bit platforms. Sincerely yours, Ivan
Re: RFR: 8016846: Pattern.splitAsStream tests required
On 08/20/2013 12:58 PM, Jonathan Gibbons wrote: Henry, I think you should sort out the issues you are having with jtreg. It is not yet clear to me that this is a jtreg issue as much as a test or library issue. Thanks Jon for the help on jtreg issue, the test can be easily fixed by adding an extra @build tag. The new webrev is at http://cr.openjdk.java.net/~henryjen/tl/8016846/1/webrev Cheers, Henry -- Jon On 08/20/2013 12:48 PM, Henry Jen wrote: On 07/24/2013 09:14 AM, Alan Bateman wrote: On 16/07/2013 12:05, Henry Jen wrote: Hi, Please review the webrev at, http://cr.openjdk.java.net/~henryjen/tl/8016846/0/webrev/ The test is mostly contributed by Ben Evans. Cheers, Henry It looks okay to me, just a concern that the tests for the regex API are normally in test/java/util/regex. We are using stream test framework on this to verify all style of stream works, with that we will need to have library on bootclasspath, and that current prevent us from put it in test/java/util/regex because of jtreg limitation. If no object, I'll push this at its current location. We can revisit this when jtreg support is available. The other alternative is that we refactor the test to test only split, and leave out the various style of stream checking. While we lose the sanity check, but I don't think we lose much as the form of iterator converted into stream and operated should have been covered in other stream tests. Let me know if we think it's important enough to refactor the test. Cheers, Henry
hg: jdk8/tl/langtools: 8020663: Restructure some properties to facilitate better translation
Changeset: a76dc1b4c299 Author:jjg Date: 2013-08-20 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76dc1b4c299 8020663: Restructure some properties to facilitate better translation Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
hg: jdk8/tl/langtools: 7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8
Changeset: 0f88e3d3d250 Author:ksrini Date: 2013-08-20 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f88e3d3d250 7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8 Reviewed-by: jjg ! test/tools/javac/processing/model/testgetallmembers/Main.java
Re: 8020292: j.u.SplittableRandom
On Aug 20 2013, at 04:57 , Paul Sandoz wrote: [resending unsigned, sorry if a dup arrives later on] On Aug 19, 2013, at 9:04 PM, Mike Duigou mike.dui...@oracle.com wrote: Looks pretty good. Two points concern me: - Every source of non-crypto quality randoms should explicitly document that it should not be used for generating keys or other crypto purposes. There is mention that the seeding is insecure in the implementation docs but more explicit mention in the public docs is needed. (And some fool somewhere will *still* use it for crypto...) Good point. - Additional seed material might be desirable for seeder. I worry about how many of the actual bits are random. If no local host address is available the seed might be fairly predictable. In the murmur3 implementation I included also System.identityHashCode(String.class), System.identityHashCode(System.class), System.identityHashCode(Thread.currentThread()), Thread.currentThread().getId() and Runtime.getRuntime().freeMemory(). Mixing multiply with XOR operations also helps to spread the random bits out. Perhaps just call mix64 on each component and XOR against previous? Are you concerned that the values passed to mix64 may be of low entropy? i.e. that small differences in input (such as counting numbers) do not result in large enough differences in the output. I suppose it might be possible to switch from MurmurHash3 to using Stafford's Mix13 constants or a combination to avoid any potential correlations. However, given that there is further mixing going on for the values and gamma generation perhaps it is not so important? It was more that seeder is initialized with a potentially predictable value. currentTimeMillis probably has only a couple of bits of entropy (and on a webserver it is probably observable), maybe a dozen bits for nanoTime. Those random bits are likely in the same range of bits (around bits 5-15). If getLocalHostAddress() returns a loopback address then we've seeded the shared state with only a few bits of randomness. (Also, since the local host address is directly visible it could be reversed out by an attacker). The suggestion of using mix64 was mostly to take best advantage of the entropy available. Plus, more bits would be better. Imagine an attack where the attacker looked for newly launched instances of a clustered webserver. It would not be too hard to reduce the search space for the initial value of it's SplittableRandom seeder to less than 2^16 possibilities. Whether this is useful would depend upon the application being run on that webserver but it seems insufficient to me though. Mike
hg: jdk8/tl/langtools: 8022080: javadoc generates invalid HTML in Turkish locale
Changeset: 79e341614c50 Author:jjg Date: 2013-08-20 14:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79e341614c50 8022080: javadoc generates invalid HTML in Turkish locale Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java
hg: jdk8/tl/langtools: 8013887: In class use, some tables are randomly unsorted
Changeset: 720992953d43 Author:jjg Date: 2013-08-20 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/720992953d43 8013887: In class use, some tables are randomly unsorted Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
RFR: JDK-8023430 - Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details
Hi, MaxPathLength.java testcase failed intermittently. And File.mkdirs() does not throw any exceptions when it fails, which makes it even harder for the diagnosis. As Alan suggested, I'd like to change it to Files.createDirectories to get detailed exceptions once a failure happens. Thanks! webrev: http://cr.openjdk.java.net/~dxu/8023430/webrev/ bug: http://bugs.sun.com/view_bug.do?bug_id=8023430 -Dan
Re: 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile
On Aug 20 2013, at 05:13 , Alan Bateman wrote: For some time now we have been chipping away at the make files that are used to run the jdk tests. Mike has his wielded his axe on several occasions recently to remove logic and rules that are no longer needed. I've started to sharpen my axe preparing the follow-on changes to Makefiles In addition to groups for the normal test target then I also propose to add higher level groups that partition the entire test suite into three groups named core, svc and desktop. This makes it really easy to run selections of the test suite, for example jtreg options :core :svc will run all the core area and serviceability tests. The root repo test targets currently trigger off the repo name in order to know which repo/test/Makefile to run. ie. jdk_util triggers running the jdk/test/Makefile. Would it be possible to retain the repo prefix for the meta group names? ie. jdk_core jdk_svc and jdk_desktop? The other possibility is to move the TEST.ROOT and TEST.groups files for all tests to the root repo. This would have the advantage that we could define groups like smoketest that would span repos. Mike
hg: jdk8/tl: 8023433: Improve 'make help'
Changeset: c8da1b6a9762 Author:mduigou Date: 2013-08-20 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8da1b6a9762 8023433: Improve 'make help' Reviewed-by: tbell ! NewMakefile.gmk
