Re: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair
Hi Mike, I am probably going over old ground here... Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry, or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? The defaults on Map could state they are not suitable for maps that can be concurrently modified, if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? Paul. On Oct 4, 2013, at 5:35 AM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. Mike
Re: JDK 8 RFR 8016252: More defensive HashSet.readObject
On 10/07/2013 10:03 PM, Brian Burkhalter wrote: On Oct 7, 2013, at 1:43 PM, Brian Burkhalter wrote: On second thought an exception really should be thrown on negative size; will update. http://cr.openjdk.java.net/~bpb/8016252.2/ updated including a not-very-exciting and perhaps unnecessary test. This looks much better. loadfactor and size validation look good, and in line with the original suggestion in the bug. For the initial capacity what was originally suggested was to use a similar technique to that of HashMap.readObject ( to ensure that the table never needs to be rehashed during load, and ends up being at least 25% full). Snippet from the bug: int capacity = (int)Math.min(size * Math.min(1 / loadFactor, 4.0f), HashMap.MAXIMUM_CAPACITY); I'm curious why you have not taken that suggestion? What you have looks ok, but it does reply on reasonable capacity and loadfactor values. I have not looked in any detail at the test, but the file should start with the copyright/header, and not the import statements. -Chris. Brian
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 10/08/2013 06:04 AM, Mandy Chung wrote: On 10/7/2013 9:45 PM, David Holmes wrote: Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. I do plan to push them separately meaning that the jdk change will wait until the hotspot change is integrated. I think the hotspot integration is weekly. I am not a HSX committer :( Since I have your attention, can you sponsor my hotspot change? For such small hotspot changes it seems overly restrictive to have to push then through a hotspot integration forest. We have a perfectly good hotspot repo in tl, why not use it? -Chris. Mandy David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Re: Review Request for 8025799: Restore sun.reflect.Reflection.getCallerClass(int)
On 8/10/2013 7:18 PM, Chris Hegarty wrote: On 10/08/2013 06:04 AM, Mandy Chung wrote: On 10/7/2013 9:45 PM, David Holmes wrote: Hi Mandy, Note that unless you push both hotspot and jdk changes through the same forest you will need separate bugs for each part. You will also need a HSX committer to do the hotspot push. I do plan to push them separately meaning that the jdk change will wait until the hotspot change is integrated. I think the hotspot integration is weekly. I am not a HSX committer :( Since I have your attention, can you sponsor my hotspot change? For such small hotspot changes it seems overly restrictive to have to push then through a hotspot integration forest. We have a perfectly good hotspot repo in tl, why not use it? Even if tl forest was used it still has to be pushed by a hsx committer and via JPRT. Until we have some definitive processes in place (current ones are ad-hoc) pushing the hotspot changes first is a simple but un-timely approach. Otherwise additional coordination is needed regardless of whether you use hsx forest or tl forest to push from. David - -Chris. Mandy David On 7/10/2013 6:24 PM, Mandy Chung wrote: JDK 8 was feature complete in June and there just isn't sufficient time remaining to get agreement and feedback on an API to examine the caller frames. To that end, I propose to restore the old unsupported Reflection.getCallerClass(int) and that we will look to define a standard API for JDK 9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8025799/ It remains to be an unsupported API and JDK should not use this method and it's not annotated with @CallerSensitive. I considered detecting if this method is called by a system class (loaded by null loader) and throw an error. I decided to minimize the compatibility risk in case if there is any existing code added to the bootclasspath depending on this private API. Thanks Mandy
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On 08/10/2013 00:00, Brian Burkhalter wrote: Resuming this discussion … Thanks for the previous comments. My feeling at this point is to do one of two things: A) defer to something after JDK 8, or B) on EAI_AGAIN do not retry but set the cause of the UAE to new SomeException(gai_strerror(error)) where SomeException could be for example Exception, RuntimeException, or IOException. Comments? Throwing UHE with a useful message or cause would be best, so option B. However, I don't think it is critical for jdk8 as it's not a new issue (at least I think UHE has always been thrown with just the hostname, never the reason if it is known). So if there isn't time to be confident with the patch then it should be okay to move this out to 9. -Alan.
Re: Debug builds
Hi Gili, the mail threads you mention in your mail refer to debugging symbols in the native VM implementation (i.e. libjvm.so) and not to debug symbols in the java classes in rt.jar. Regards, Volker On Mon, Oct 7, 2013 at 7:45 PM, cowwoc cow...@bbs.darktech.org wrote: On 07/10/2013 1:35 PM, Steven Schlansker wrote: On Oct 7, 2013, at 8:30 AM, cowwoc cow...@bbs.darktech.org wrote: Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's not clear why that was. Also, out of curiosity, what is the overhead of the full debug symbols (versus what we ship now)? Couldn't we ship a full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? +1 on shipping debug builds with the JDK, that would be very helpful for those of us who are stupid^Wcurious enough to step-debug into JDK classes. I have personally wasted countless days/weeks/months debugging problems that would have been solved much quicker by having full debug symbols. Furthermore, as you can see at http://mail.openjdk.java.net/** pipermail/build-dev/2012-**October/006892.htmlhttp://mail.openjdk.java.net/pipermail/build-dev/2012-October/006892.htmlthe GNU/Linux world also ships with full debug symbols by default. I'd like to take this opportunity to follow-up on http://mail.openjdk.java.net/**pipermail/build-dev/2012-** October/006881.htmlhttp://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html. I am confused because this post seems to be saying that Oracle JDK 7 ships full debug symbols, but in my experience this is not the case. It would be good to get some answers from someone in the know. Thanks, Gili
hg: jdk8/tl/jdk: 8025136: SplittableRandom enchancements
Changeset: b90dcd1a71bf Author:psandoz Date: 2013-10-08 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90dcd1a71bf 8025136: SplittableRandom enchancements Reviewed-by: psandoz, martin Contributed-by: Doug Lea d...@cs.oswego.edu, Guy Steele guy.ste...@oracle.com ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
Re: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE
On 04/10/2013 21:58, Brian Burkhalter wrote: : An updated webrev which I hope adequately addresses the expressed concerns may be found at: http://cr.openjdk.java.net/~bpb/7179567.2/ This looks much better. If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. My previous comment on @throws vs. @exception was just to keep things consistent as this is old code and would look odd for a method to use both. Our preference is to switch to @throws whenever the opportunity arises. The comment was also on the alignment/style. Take URLCLassLoader(URL[], ClassLoader) for example, the existing SecurityException has its description aligned under SecurityException whereas the new NullPointerException wraps around. So my overall comment here was to avoid mixing styles (it doesn't matter too much which style is used, just keep it consistent for future maintainers). In the test then it might be better to change the @summary line to only include the second paragraph (the bug summary is not interesting, especially when it references a test that is not in OpenJDK). -Alan.
hg: jdk8/tl/jdk: 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers
Changeset: 95bb56c61276 Author:alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java
Re: [7u-dev] Request for review of backport 7147084
Alan, Rob, Martin, Would you please help review the backport? I see you were the reviewers for the master fix. I need a review for the backport, since the patch couldn't get applied cleanly. Here are the changes I had to make: - I had to manually replace Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle it automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Thanks in advance, Ivan On 25.09.2013 17:50, Ivan Gerasimov wrote: Hello! May I please have a review for a backport of the fix for 7147084 to jdk7u-dev? This webrev does not include fix 8007454 anymore, as it has already been pushed. http://cr.openjdk.java.net/~igerasim/7147084/1/webrev/ Thanks in advance, Ivan Gerasimov Original Message Subject: Re: [7u-dev] Request for approval for CRs 8007454, 7147084 Date: Tue, 24 Sep 2013 10:29:04 +0100 From: Seán Coffey sean.cof...@oracle.com To: Ivan Gerasimov ivan.gerasi...@oracle.com CC: jdk7u-...@openjdk.java.net On 24/09/2013 10:25, Ivan Gerasimov wrote: Thanks Seán! Then I'll ask for an approval to backport 8007454, which is applied cleanly. Consider both bugs fixes approved. You could use this mail thread to review the 7147084 changes if you want. They're innocent enough. Alan or someone else should be able to review. regards, Sean. And once it is pushed, I'll initiate a review for 7147084 with adjustments. Sincerely, Ivan On 24.09.2013 12:59, Seán Coffey wrote: Approved for jdk7u-dev but you'll need a review first due to the adjustments needed in the backport. Hopefully, you'll be resolving these issues with 2 different changesets. It's been the trend in the past and helps keep changesets more aligned to those in JDK 8. regards, Sean. On 24/09/2013 09:08, Ivan Gerasimov wrote: Sending to the correct ML -- Hello! We have a request to backport fix for 7147084. First, it depends on the fix for 8007454, so the webrev includes it too. Second, the fix had to be adjusted a bit. - I had to manually replaced Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Combined webrev: http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/ BUGS: http://bugs.sun.com/view_bug.do?bug_id=7147084 http://bugs.sun.com/view_bug.do?bug_id=8007454 JDK8 Changesets: 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d Reviews for jdk8 fix: 7147084: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html 8007454: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html I had set up a JPRT job, which completed successfully. All the .*jdk_lang.* test passed. Sincerely yours, Ivan Gerasimov
RFR 8020061: Clarify reporting characteristics between splits
Hi,
The following patch is a minor clarification to the documentation of
Spliterator.characteristics():
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169
Paul.
--- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04
2013 +0200
+++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27
2013 +0200
@@ -414,12 +414,18 @@ public interface SpliteratorT {
* #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED},
* {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT},
* {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on
- * a given spliterator should always return the same result.
+ * a given spliterator, prior to or in-between calls to {@code trySplit},
+ * should always return the same result.
*
* pIf a Spliterator reports an inconsistent set of
* characteristics (either those returned from a single invocation
* or across multiple invocations), no guarantees can be made
* about any computation using this Spliterator.
+ *
+ * @apiNote The characteristics of a given spliterator before splitting
+ * may differ from the characteristics after splitting. For specific
+ * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED}
+ * and {@link #CONCURRENT}.
*
* @return a representation of characteristics
*/
Re: RFR 8020061: Clarify reporting characteristics between splits
Sorry Paul, I know the apiNote says for examples see ... but would you
mind providing an example. I'm scratching my head.
-Chris.
On 10/08/2013 12:42 PM, Paul Sandoz wrote:
Hi,
The following patch is a minor clarification to the documentation of
Spliterator.characteristics():
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169
Paul.
--- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04
2013 +0200
+++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27
2013 +0200
@@ -414,12 +414,18 @@ public interface SpliteratorT {
* #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED},
* {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT},
* {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on
- * a given spliterator should always return the same result.
+ * a given spliterator, prior to or in-between calls to {@code trySplit},
+ * should always return the same result.
*
* pIf a Spliterator reports an inconsistent set of
* characteristics (either those returned from a single invocation
* or across multiple invocations), no guarantees can be made
* about any computation using this Spliterator.
+ *
+ * @apiNote The characteristics of a given spliterator before splitting
+ * may differ from the characteristics after splitting. For specific
+ * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED}
+ * and {@link #CONCURRENT}.
*
* @return a representation of characteristics
*/
Re: RFR 8020061: Clarify reporting characteristics between splits
On Oct 8, 2013, at 3:02 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Sorry Paul, I know the apiNote says for examples see ... but would you mind
providing an example. I'm scratching my head.
* @apiNote Most Spliterators for Collections, that cover all elements of a
* {@code Collection} report this characteristic. Sub-spliterators, such as
* those for {@link HashSet}, that cover a sub-set of elements and
* approximate their reported size do not.
*/
public static final int SIZED = 0x0040;
SetInteger s = new HashSet(Arrays.asList(1, 2, 3, 4));
SpliteratorInteger split1 = s.spliterator();
System.out.println(split1.hasCharacteristics(Spliterator.SIZED));
SpliteratorInteger split2 = split1.trySplit();
System.out.println(split1.hasCharacteristics(Spliterator.SIZED));
System.out.println(split2.hasCharacteristics(Spliterator.SIZED));
Paul.
-Chris.
On 10/08/2013 12:42 PM, Paul Sandoz wrote:
Hi,
The following patch is a minor clarification to the documentation of
Spliterator.characteristics():
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169
Paul.
--- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04
2013 +0200
+++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27
2013 +0200
@@ -414,12 +414,18 @@ public interface SpliteratorT {
* #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED},
* {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT},
* {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on
- * a given spliterator should always return the same result.
+ * a given spliterator, prior to or in-between calls to {@code
trySplit},
+ * should always return the same result.
*
* pIf a Spliterator reports an inconsistent set of
* characteristics (either those returned from a single invocation
* or across multiple invocations), no guarantees can be made
* about any computation using this Spliterator.
+ *
+ * @apiNote The characteristics of a given spliterator before splitting
+ * may differ from the characteristics after splitting. For specific
+ * examples see the characteristic values {@link #SIZED}, {@link
#SUBSIZED}
+ * and {@link #CONCURRENT}.
*
* @return a representation of characteristics
*/
RFR JDK-7183985: (ann) Class.getAnnotation() throws an ArrayStoreException when the annotation class not present
Hi,
Please review the fix for bug JDK-7183985, bug:
https://bugs.openjdk.java.net/browse/JDK-7183985
webrev:
http://cr.openjdk.java.net/~jlahoda/7183985/webrev.00/
The problem, as I understand it, is as follows. Consider this code:
-
@WithArray({E.class})
class O {
}
@Retention(RetentionPolicy.RUNTIME)
@interface WithArray {
Class?[] value();
}
class E { }
-
The code is compiled and is being inspected by reflection at runtime.
Assume the type E is not available at that time. At that
point calling:
O.class.getAnnotations();
or:
O.class.getAnnotation(WithArray.class);
will lead to:
java.lang.ArrayStoreException:
sun.reflect.annotation.TypeNotPresentExceptionProxy
The proposed fix is to throw TypeNotPresentException only when the
WithArray.value() method is invoked on the instance of the annotation
returned from O.class.getAnnotation(WithArray.class).
Something similar happens for enum constants missing at runtime (will
throw EnumConstantNotPresentException after the patch when queried).
There is also a somewhat related case when an annotation type is missing:
-
@WithArray({@E})
class O {
}
@Retention(RetentionPolicy.RUNTIME)
@interface WithArray {
Class?[] value();
}
@interface E { }
-
If E is missing at runtime, calling O.getAnnotations() leads to:
java.lang.NoClassDefFoundError: [Ltest/E;
After this fix, the O.getAnnotations() won't throw the exception, and
the resulting array won't contain the WithArray annotation.
Does this sound like a reasonable direction/patch?
Thanks,
Jan
Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation
On 10/08/2013 12:36 AM, Peter Levart wrote: That said, this is a 13 year old issue that hasn't come up very often (to my knowledge anyway, perhaps because those making heavy use of direct buffers are pooling buffers rather than allocating and unreferencing). In additional we are close to the end of JDK 8 (ZBB is in 2.5 weeks time) and technically we have been in ramp down (meaning P1-P3 only) since mid-July. Ok then, I'll finish this nevertheless and then it can sit and wait for JDK9. Sounds like a good plan, with the backport to JDK 8 update. Thanks for taking this over, Peter. I reassigned the JDK-6857566 to you. Once you ready with the final patch, put the link here, I have two guys (Hazelcast and Netty) who are up to assist us with reviews and testing. This issue seems to grind their gears. ;) -Aleksey.
Re: Debug builds
Hi Volker, Thanks for the clarification. I have been able to ascertain that adding full debug symbols to rt.jar would grow the file by 12MB (uncompressed, probably much smaller after you run PACK200). The debugging symbols for native code probably cost a lot more than that. Any idea on why rt.jar does not contain full debug symbols in the JDK? If I open a bug report for this, is anyone willing to push this through the system? Thanks, Gili On 08/10/2013 6:03 AM, Volker Simonis wrote: Hi Gili, the mail threads you mention in your mail refer to debugging symbols in the native VM implementation (i.e. libjvm.so) and not to debug symbols in the java classes in rt.jar. Regards, Volker On Mon, Oct 7, 2013 at 7:45 PM, cowwoc cow...@bbs.darktech.org mailto:cow...@bbs.darktech.org wrote: On 07/10/2013 1:35 PM, Steven Schlansker wrote: On Oct 7, 2013, at 8:30 AM, cowwoc cow...@bbs.darktech.org mailto:cow...@bbs.darktech.org wrote: Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's not clear why that was. Also, out of curiosity, what is the overhead of the full debug symbols (versus what we ship now)? Couldn't we ship a full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? +1 on shipping debug builds with the JDK, that would be very helpful for those of us who are stupid^Wcurious enough to step-debug into JDK classes. I have personally wasted countless days/weeks/months debugging problems that would have been solved much quicker by having full debug symbols. Furthermore, as you can see at http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006892.html the GNU/Linux world also ships with full debug symbols by default. I'd like to take this opportunity to follow-up on http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html. I am confused because this post seems to be saying that Oracle JDK 7 ships full debug symbols, but in my experience this is not the case. It would be good to get some answers from someone in the know. Thanks, Gili
Re: RFR 8020061: Clarify reporting characteristics between splits
Thanks Paul. In which case, the spec clarifications seem fine.
-Chris.
On 10/08/2013 02:10 PM, Paul Sandoz wrote:
On Oct 8, 2013, at 3:02 PM, Chris Hegarty chris.hega...@oracle.com wrote:
Sorry Paul, I know the apiNote says for examples see ... but would you mind
providing an example. I'm scratching my head.
* @apiNote Most Spliterators for Collections, that cover all elements of a
* {@code Collection} report this characteristic. Sub-spliterators, such as
* those for {@link HashSet}, that cover a sub-set of elements and
* approximate their reported size do not.
*/
public static final int SIZED = 0x0040;
SetInteger s = new HashSet(Arrays.asList(1, 2, 3, 4));
SpliteratorInteger split1 = s.spliterator();
System.out.println(split1.hasCharacteristics(Spliterator.SIZED));
SpliteratorInteger split2 = split1.trySplit();
System.out.println(split1.hasCharacteristics(Spliterator.SIZED));
System.out.println(split2.hasCharacteristics(Spliterator.SIZED));
Paul.
-Chris.
On 10/08/2013 12:42 PM, Paul Sandoz wrote:
Hi,
The following patch is a minor clarification to the documentation of
Spliterator.characteristics():
http://hg.openjdk.java.net/lambda/lambda/jdk/rev/653d17f35169
Paul.
--- a/src/share/classes/java/util/Spliterator.java Tue Oct 01 12:10:04
2013 +0200
+++ b/src/share/classes/java/util/Spliterator.java Tue Oct 08 13:36:27
2013 +0200
@@ -414,12 +414,18 @@ public interface SpliteratorT {
* #ORDERED}, {@link #DISTINCT}, {@link #SORTED}, {@link #SIZED},
* {@link #NONNULL}, {@link #IMMUTABLE}, {@link #CONCURRENT},
* {@link #SUBSIZED}. Repeated calls to {@code characteristics()} on
- * a given spliterator should always return the same result.
+ * a given spliterator, prior to or in-between calls to {@code trySplit},
+ * should always return the same result.
*
* pIf a Spliterator reports an inconsistent set of
* characteristics (either those returned from a single invocation
* or across multiple invocations), no guarantees can be made
* about any computation using this Spliterator.
+ *
+ * @apiNote The characteristics of a given spliterator before splitting
+ * may differ from the characteristics after splitting. For specific
+ * examples see the characteristic values {@link #SIZED}, {@link #SUBSIZED}
+ * and {@link #CONCURRENT}.
*
* @return a representation of characteristics
*/
hg: jdk8/tl/nashorn: 6 new changesets
Changeset: 6345d08fd5de Author:hannesw Date: 2013-10-08 11:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/6345d08fd5de 8025213: Assignment marks variable as defined too early Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025213.js + test/script/basic/JDK-8025213.js.EXPECTED Changeset: 8c326f8c6799 Author:sundar Date: 2013-10-08 13:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8c326f8c6799 8026033: Switch should load expression even when there are no cases in it Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8026033.js + test/script/basic/JDK-8026033.js.EXPECTED Changeset: 025e2ff9e91b Author:hannesw Date: 2013-10-08 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/025e2ff9e91b 8025965: Specialized functions with same weight replace each other in TreeSet Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/CompiledFunction.java Changeset: 19dba6637f20 Author:sundar Date: 2013-10-08 14:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/19dba6637f20 8026039: future strict names are allowed as function name and argument name of a strict function Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/error/JDK-8026039.js + test/script/error/JDK-8026039.js.EXPECTED Changeset: c9921761903b Author:hannesw Date: 2013-10-08 15:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/c9921761903b 8026042: FoldConstants need to guard against ArrayLiteralNode Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + test/script/basic/JDK-8026042.js + test/script/basic/JDK-8026042.js.EXPECTED Changeset: 346ba5b8a488 Author:sundar Date: 2013-10-08 16:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/346ba5b8a488 8026048: Function constructor should convert arguments to String before performing any syntax checks Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeFunction.java + test/script/basic/JDK-8026048.js
Re: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE
On 10/08/2013 12:08 PM, Alan Bateman wrote: On 04/10/2013 21:58, Brian Burkhalter wrote: : An updated webrev which I hope adequately addresses the expressed concerns may be found at: http://cr.openjdk.java.net/~bpb/7179567.2/ This looks much better. Yes, this is much nicer. I'd be tempted to write another private constructor, taking all args, and checking params with checkForNullURLs before invoking, similar to ThreadGroup [1] L117, for example. But that is just clean up to remove some duplication. No need to do this. If I read the code correctly then the long standing behavior of URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to return the empty collection in order to match the super type (SecureClassLoader). I can't think of anything that would break so this is probably okay, just maybe a bit surprising. Agreed. My previous comment on @throws vs. @exception was just to keep things consistent as this is old code and would look odd for a method to use both. Our preference is to switch to @throws whenever the opportunity arises. The comment was also on the alignment/style. Take URLCLassLoader(URL[], ClassLoader) for example, the existing SecurityException has its description aligned under SecurityException whereas the new NullPointerException wraps around. So my overall comment here was to avoid mixing styles (it doesn't matter too much which style is used, just keep it consistent for future maintainers). Right, these classes are prime for stylistic clean up early in 9. For now, keep things locally consistent ( even if that is old style ). -Chris. [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/9f57d2774603/src/share/classes/java/lang/ThreadGroup.java In the test then it might be better to change the @summary line to only include the second paragraph (the bug summary is not interesting, especially when it references a test that is not in OpenJDK). -Alan.
hg: jdk8/tl/jaxp: 2 new changesets
Changeset: dbecbb685503 Author:mfang Date: 2013-10-08 09:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dbecbb685503 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: joehw, yhuang ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java ! src/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java ! src/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java + src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_pt_BR.java ! src/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java !
RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources.
Hi, Please find below a fix for: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. https://bugs.openjdk.java.net/browse/JDK-8024704 This is a clarification of the implementation of the ServiceLoader.iterator() method, as well as non normative advice for ClassLoader subclasses overriding getResource() or getResources() to consider overriding the other method in order to keep them consistent with each other. http://cr.openjdk.java.net/~dfuchs/webrev_8024704/webrev.00/ best regards, -- daniel
Re: Debug builds
Alex clarified the difference between FULL_DEBUG_SYMBOLS and DEBUG_CLASSFILES below (thank you!) Based upon this, I am asking Oracle to ship DEBUG_CLASSFILES=true as part of the public JDK. Can someone from Oracle please comment on this? Thanks, Gili Original Message Subject:Re: Debug builds Date: Tue, 08 Oct 2013 21:09:11 +0400 From: Alex Kasko alex.kasko.li...@gmail.com To: cowwoc cow...@bbs.darktech.org Hi, I wrote email to the list but decided to send it to you offlist instead (because it's your thread about debug).Feel free to forward it (or its parts) to the list if you want. On 10/08/2013 06:52 PM, cowwoc wrote: Hi Volker, Thanks for the clarification. I have been able to ascertain that adding full debug symbols to rt.jar would grow the file by 12MB (uncompressed, probably much smaller after you run PACK200). I'll try to clarify the question concerning debugging terminology. Please correct me if I am wrong. This is all about jdk7. Full debug symbols build switch: FULL_DEBUG_SYMBOLS=1 It adds '.diz' files with zipped debug symbols for all native binaries. Classfiles' debug symbols build switch: DEBUG_CLASSFILES=true It adds debug symbols to compiled java classes in rt.jar and others. Full debug symbols and classfiles' debug symbols are completely independent of each other. Information about full debug symbols in Oracle builds is not clear because of this email - http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html According to it promoted builds must have FDS. At the same time openjdk7 build that was released on java.net on the promoted url - http://download.java.net/openjdk/jdk7/promoted/b146/jcp_bcl/ does not have FDS. Builds on java.com do not have FDS too but they are not the part of OpenJDK so maybe it's incorrect to ask about them here. I think initial question was about classfiles' debug symbols. The debugging symbols for native code probably cost a lot more than that. Any idea on why rt.jar does not contain full debug symbols in the JDK? If I open a bug report for this, is anyone willing to push this through the system? Thanks, Gili On 08/10/2013 6:03 AM, Volker Simonis wrote: Hi Gili, the mail threads you mention in your mail refer to debugging symbols in the native VM implementation (i.e. libjvm.so) and not to debug symbols in the java classes in rt.jar. Regards, Volker On Mon, Oct 7, 2013 at 7:45 PM, cowwoc cow...@bbs.darktech.org mailto:cow...@bbs.darktech.org wrote: On 07/10/2013 1:35 PM, Steven Schlansker wrote: On Oct 7, 2013, at 8:30 AM, cowwoc cow...@bbs.darktech.org mailto:cow...@bbs.darktech.org wrote: Hi, Where did the old debug builds of rt.jar go (meaning, rt.jar with full debug symbols, even for local variables)? I scanned the mailing list for a related discussion but couldn't find anything. It looks like somewhere down the line a decision was made to remove these builds, but it's not clear why that was. Also, out of curiosity, what is the overhead of the full debug symbols (versus what we ship now)? Couldn't we ship a full-debug rt.jar with the JDK and ship the smaller rt.jar with the JRE? +1 on shipping debug builds with the JDK, that would be very helpful for those of us who are stupid^Wcurious enough to step-debug into JDK classes. I have personally wasted countless days/weeks/months debugging problems that would have been solved much quicker by having full debug symbols. Furthermore, as you can see at http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006892.html the GNU/Linux world also ships with full debug symbols by default. I'd like to take this opportunity to follow-up on http://mail.openjdk.java.net/pipermail/build-dev/2012-October/006881.html. I am confused because this post seems to be saying that Oracle JDK 7 ships full debug symbols, but in my experience this is not the case. It would be good to get some answers from someone in the know. Thanks, Gili -- Regards, Alex Kasko
RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path
Hi, This is a backport request towards 7u-dev repository on bug JDK-8025128 that I fixed several days ago. It is going to keep the method, File.createTempFile(), backward compatible. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ -Dan
Re: Debug builds
On 10/8/13 8:17 PM, cowwoc wrote: Alex clarified the difference between FULL_DEBUG_SYMBOLS and DEBUG_CLASSFILES below (thank you!) Based upon this, I am asking Oracle to ship DEBUG_CLASSFILES=true as part of the public JDK. Can someone from Oracle please comment on this? Not an OpenJDK issue - forums.oracle.com may be a better place for that. cheers, dalibor topic -- Oracle http://www.oracle.com Dalibor Topic | Principal Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment
Re: Debug builds
On 08/10/2013 3:25 PM, Dalibor Topic wrote: On 10/8/13 8:52 PM, cowwoc wrote: Dalibor, I don't think anyone from Oracle reads those forums or has the authority to make this change. Isn't there a better way for me to bring this up? Well, you could file a bug report instead, if you believe that to be a defect. But keep in mind that https://bugs.openjdk.java.net/browse/JDK-7133254 already exists, so unless you have a different angle on it, it may be better to just track this bug for changes, if any. cheers, dalibor topic Ah! I didn't know this issue existed. Okay, I'll keep my eye open for changes. (I wish the bug tracker was open to the public because I can't Watch the issue without an account). Thanks, Gili
Re: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path
Looks fine to me Dan but I'm not a official reviewer. regards, Sean. On 08/10/2013 19:24, Dan Xu wrote: Hi, This is a backport request towards 7u-dev repository on bug JDK-8025128 that I fixed several days ago. It is going to keep the method, File.createTempFile(), backward compatible. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ -Dan
Re: [7u-dev] Request for review of backport 7147084
Alan, Rob, Martin, Would you please help review the backport? I see you were the reviewers for the master fix. I need a review for the backport, since the patch couldn't get applied cleanly. Here are the changes I had to make: - I had to manually replace Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle it automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Thanks in advance, Ivan On 25.09.2013 17:50, Ivan Gerasimov wrote: Hello! May I please have a review for a backport of the fix for 7147084 to jdk7u-dev? This webrev does not include fix 8007454 anymore, as it has already been pushed. http://cr.openjdk.java.net/~igerasim/7147084/1/webrev/ Thanks in advance, Ivan Gerasimov Original Message Subject: Re: [7u-dev] Request for approval for CRs 8007454, 7147084 Date: Tue, 24 Sep 2013 10:29:04 +0100 From: Seán Coffey sean.cof...@oracle.com To: Ivan Gerasimov ivan.gerasi...@oracle.com CC: jdk7u-...@openjdk.java.net On 24/09/2013 10:25, Ivan Gerasimov wrote: Thanks Seán! Then I'll ask for an approval to backport 8007454, which is applied cleanly. Consider both bugs fixes approved. You could use this mail thread to review the 7147084 changes if you want. They're innocent enough. Alan or someone else should be able to review. regards, Sean. And once it is pushed, I'll initiate a review for 7147084 with adjustments. Sincerely, Ivan On 24.09.2013 12:59, Seán Coffey wrote: Approved for jdk7u-dev but you'll need a review first due to the adjustments needed in the backport. Hopefully, you'll be resolving these issues with 2 different changesets. It's been the trend in the past and helps keep changesets more aligned to those in JDK 8. regards, Sean. On 24/09/2013 09:08, Ivan Gerasimov wrote: Sending to the correct ML -- Hello! We have a request to backport fix for 7147084. First, it depends on the fix for 8007454, so the webrev includes it too. Second, the fix had to be adjusted a bit. - I had to manually replaced Java_java_lang_ProcessImpl_create() function body with the new version, as 'hg patch' could not handle automatically. - I had to replace wide-char strings to regular char*, in all the calls to win32Error() function. Combined webrev: http://cr.openjdk.java.net/~igerasim/7147084/0/webrev/ BUGS: http://bugs.sun.com/view_bug.do?bug_id=7147084 http://bugs.sun.com/view_bug.do?bug_id=8007454 JDK8 Changesets: 7147084: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c4f1081a0fa 8007454: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2b308cc82d Reviews for jdk8 fix: 7147084: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019604.html 8007454: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014602.html I had set up a JPRT job, which completed successfully. All the .*jdk_lang.* test passed. Sincerely yours, Ivan Gerasimov
Re: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path
On 08/10/2013 19:24, Dan Xu wrote: Hi, This is a backport request towards 7u-dev repository on bug JDK-8025128 that I fixed several days ago. It is going to keep the method, File.createTempFile(), backward compatible. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ -Dan This looks like it's the same patch that is in jdk8 so it doesn't need to be reviewed again. Instead you just need to send an approval request to the jdk7u-dev list to request approval to push it there. The approval template page [1] has the list of things that need to be included in the request. One other thing to point out is that you don't have committer role on jdk7u so you are going to need a sponsor. I'm sure Seán or one of the other maintainers will help on this. -Alan [1] http://openjdk.java.net/projects/jdk7u/approval-template.html
Re: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path
Yes - no problem pushing the changeset for Dan once the approval request is logged and approved. regards, Sean. On 08/10/2013 20:43, Alan Bateman wrote: On 08/10/2013 19:24, Dan Xu wrote: Hi, This is a backport request towards 7u-dev repository on bug JDK-8025128 that I fixed several days ago. It is going to keep the method, File.createTempFile(), backward compatible. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ -Dan This looks like it's the same patch that is in jdk8 so it doesn't need to be reviewed again. Instead you just need to send an approval request to the jdk7u-dev list to request approval to push it there. The approval template page [1] has the list of things that need to be included in the request. One other thing to point out is that you don't have committer role on jdk7u so you are going to need a sponsor. I'm sure Seán or one of the other maintainers will help on this. -Alan [1] http://openjdk.java.net/projects/jdk7u/approval-template.html
Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation
On 07/10/2013 21:36, Peter Levart wrote: : Ask not what reference handler can do for you, ask what you can do for reference handler! ;-) Indeed. : } I get: sleep(1) takes 1079078 ns sleep(2) takes 2058245 ns sleep(3) takes 3060258 ns sleep(4) takes 4060121 ns sleep(5) takes 5061263 ns sleep(6) takes 6063189 ns sleep(7) takes 7075132 ns sleep(8) takes 8071381 ns sleep(9) takes 9062244 ns ... ...which seems pretty accurate. Okay although I must admit that I didn't expect to see any difference up to 5 or 10ms (but it is of course highly platform/config specific). : A related piece of work is the FileChannel map implementation where there is a gc + retry if mmap fails. This could be changed to have a similar back-off/retry. I see. Would it make sense to do it in same patch or separately. This too, will need JavaLangRefAccess.tryHandlePendingReference(), I think, since it similarly ties unmap0 to a Cleaner referencing MappedByteBuffer. The tryMap0 would just be a call to map0 with catching of OOME and returning true/false, right? Do you happen to know what defines the limit of how many bytes or blocks can be mapped at one time? Is this some parameter for VM or is this just plain OS limit? It's okay to separate this into a separate patch, I was really just pointing out that we file mappings is another case where this could help. There isn't a limit for this in the JDK so it does depend on the OS. A tryMap as you suggest should be okay, alternatively we could change the native method to return 0 for the ENOMEM case. : Ok then, I'll finish this nevertheless and then it can sit and wait for JDK9. I don't know when a jdk9 project will be proposed but I expect so very soon because we will all be holding onto patches after the ZBB date. -Alan.
Re: RFR 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses iterator position
I've beefed up the test case, as suggested by Alan and Paul. It tries
removing at the start, middle, and end of the iteration.
FWIW, all but one of the test scenarios pass even without the fix. The
failing case is:
checkDescItrRmMid(m.keySet(), m.navigableKeySet().descendingIterator());
(that is, remove an element from the middle of the iteration, the
specific case of this bug).
So most of the new tests are of code that is already correct, but IMO it
doesn't hurt to make sure it stays correct. :)
http://cr.openjdk.java.net/~bchristi/8024709/webrev.01/
Thanks,
-Brent
On 10/4/13 1:51 AM, Paul Sandoz wrote:
On Oct 4, 2013, at 7:28 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 03/10/2013 16:31, Brent Christian wrote:
Please review my fix for 8024709 : TreeMap.DescendingKeyIterator 'remove' confuses
iterator position
There are two possible code paths for performing a descending iteration over
the elements in a TreeMep, depending on how the iteration is setup.
For instance,
treemap.descendingKeySet().iterator();
will use a
TreeMap.NavigableSubMap.DescendingSubMapIterator
This code correctly handles Iterator.remove().
On the other hand,
treemap.navigableKeySet().descendingIterator();
will use a
TreeMap.DescendingKeyIterator.
This code does not correctly handle remove(), and results in a confused
iterator.
TreeMap.DescendingKeyIterator should override remove() with code
similar to that in TreeMap.NavigableSubMap.SubMapIterator.removeDescending().
Bug report:
https://bugs.openjdk.java.net/browse/JDK-8024709
Webrev:
http://cr.openjdk.java.net/~bchristi/8024709/webrev.00/
The remove looks right to me and next() should return the predecessor that is
already set.
Looks ok to me too.
The test looks okay (although you might want to align the parameters to
checkDescendingIteratorRemove), I just wonder if you would be worth generating
additional cases to exercise this code a bit more.
One could write a general test without having to pass in expicit values and if
so i suspect it is better to pass in the ascending collection and descending
iterator (since the toArray could be implemented using an iterator):
T void checkTraverse2Remove1Traverse1(CollectionT aC, IteratorT dIt) {
T[] values = (T) aC.toArray();
int n = values.length -1;
equalNext(dIt, values[n--]);
equalNext(dIt, values[n--]);
it.remove();
equalNext(dIt, values[n]);
}
Might also be useful to have a test that removes the last traversed element.
Paul.
Re: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks
On Oct 4, 2013, at 1:33 AM, Paul Sandoz wrote: On Oct 4, 2013, at 9:18 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 10/04/2013 03:34 AM, Brian Burkhalter wrote: Here is an alternative solution:http://cr.openjdk.java.net/~bpb/7189139.2/. Seems OK with me, Same here. Based on previous comments by Aleksey and Paul I created this test http://cr.openjdk.java.net/~bpb/7189139/PrimeTest.java and ran it with the list of primes supplied by Aleksey, N=6000, and certainty=100. This is the output: --- Primes: /Users/bpb/Desktop/primes-50M.txt N = 6000 certainty = 100 3562115 probable primes out of 3562115 candidates Prime test = true Not-prime test = true Test succeeded! --- An updated webrev which differs only in having a correct Hg header is here: http://cr.openjdk.java.net/~bpb/7189139/webrev.2/ If this looks good to go, would a Reviewer please issue an approval? Thanks, Brian
Re: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources.
On 08/10/2013 18:19, Daniel Fuchs wrote: Hi, Please find below a fix for: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. https://bugs.openjdk.java.net/browse/JDK-8024704 This is a clarification of the implementation of the ServiceLoader.iterator() method, as well as non normative advice for ClassLoader subclasses overriding getResource() or getResources() to consider overriding the other method in order to keep them consistent with each other. http://cr.openjdk.java.net/~dfuchs/webrev_8024704/webrev.00/ As background to others, the motive for this one stems from a small compatibility issue that arose with the JAXP changes to use ServiceLoader (it was previous foraging for service configuration files itself). The compatibility issue arises with ClassLoader implementations where getResource and getResources are inconsistent, and in the JAXP case uncovered a server that located an unexpected XML parser. Daniel - in the @apiNote on getResource it reads the implementations ensure where it should be the implementation ensures or implementations should ensure. Otherwise the wording looks okay to me. Conventions haven't been established yet but I would think that @apiNote is a case where you can use the full line. -Alan.
Re: RFR: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources.
As a mostly ;-) silent observer on this list I just wanted to say Thank You to everyone for continuing the diligent work to fix issues like this. I've seen a host of really useful small improvements go in recently (and docs definitely count as well) - it doesn't go unnoticed! Cheers, Martijn On 8 October 2013 21:06, Alan Bateman alan.bate...@oracle.com wrote: On 08/10/2013 18:19, Daniel Fuchs wrote: Hi, Please find below a fix for: 8024704: Improve API documentation of ClassLoader and ServiceLoader with respect to enumeration of resources. https://bugs.openjdk.java.**net/browse/JDK-8024704https://bugs.openjdk.java.net/browse/JDK-8024704 This is a clarification of the implementation of the ServiceLoader.iterator() method, as well as non normative advice for ClassLoader subclasses overriding getResource() or getResources() to consider overriding the other method in order to keep them consistent with each other. http://cr.openjdk.java.net/~**dfuchs/webrev_8024704/webrev.**00/http://cr.openjdk.java.net/~dfuchs/webrev_8024704/webrev.00/ As background to others, the motive for this one stems from a small compatibility issue that arose with the JAXP changes to use ServiceLoader (it was previous foraging for service configuration files itself). The compatibility issue arises with ClassLoader implementations where getResource and getResources are inconsistent, and in the JAXP case uncovered a server that located an unexpected XML parser. Daniel - in the @apiNote on getResource it reads the implementations ensure where it should be the implementation ensures or implementations should ensure. Otherwise the wording looks okay to me. Conventions haven't been established yet but I would think that @apiNote is a case where you can use the full line. -Alan.
Re: Deflater enhancements
The 100 in sample really means a big enough buffer here for simple use case,
not
necessarily means a fixed size' buffer. Sure there is always room for doc
improvement,
especially given this is the API has been there for decade.
Deflater/Inflater.end() is for explicitly/proactively release of the memory
resource
held by the deflater/inflater, it does not have impact to the
deflating/inflating result.
the end() will be invoked by the finalizer.
It might be reasonable to simply have a pair of static utility methods
byte[] Deflater.deflate(byte[]);
byte[] Inflater.deflate(byte[]);
For the casual/simple/easy use scenario.
Sherman
On 10/08/2013 03:24 AM, Stephen Colebourne wrote:
I've been trying to use Deflater today and found it rather tricky. Two
thoughts...
1) The class level Javadoc specifies a fixed size byte array of 100.
http://download.java.net/jdk8/docs/api/java/util/zip/Deflater.html
From what I can tell from other searching and basic common sense, this
cannot be right as the output size could well be bigger than 100.
However, there is no real information in the Deflater class as to how
the class is supposed to be used. I don't believe that kind of broken
example is helpful.
The best I found was
http://java.dzone.com/articles/how-compress-and-uncompress
which proposed a loop:
Deflater deflater = new Deflater();
deflater.setInput(data);
ByteArrayOutputStream outputStream = new ByteArrayOutputStream(data.length);
deflater.finish();
byte[] buffer = new byte[1024];
while (!deflater.finished()) {
int count = deflater.deflate(buffer); // returns the generated code... index
outputStream.write(buffer, 0, count);
}
outputStream.close();
byte[] output = outputStream.toByteArray();
Neither example call deflater.end(), which I believe to be a mistake as well.
Is my analysis correct? Should I raise a bug for better documentation?
(this appears to affect Inflater as well)
2) Even with the Javadoc change, the API is still far too complex.
As a user, all I want is something like:
byte[] compressed = Deflater.deflate(input, options...)
and similar for Inflater.
(I actually want to compress a String, and an override to handle that
would be useful as well)
Any thoughts on adding a convenience method to make the API a lot
easier? Can I raise a bug for that?
Stephen
Re: JDK 8 RFR 8016252: More defensive HashSet.readObject
On Oct 8, 2013, at 1:51 AM, Chris Hegarty wrote: This looks much better. loadfactor and size validation look good, and in line with the original suggestion in the bug. For the initial capacity what was originally suggested was to use a similar technique to that of HashMap.readObject ( to ensure that the table never needs to be rehashed during load, and ends up being at least 25% full). Snippet from the bug: int capacity = (int)Math.min(size * Math.min(1 / loadFactor, 4.0f), HashMap.MAXIMUM_CAPACITY); I'm curious why you have not taken that suggestion? What you have looks ok, but it does reply on reasonable capacity and loadfactor values. I saw that suggestion. I was trying insofar as possible to use the field values as serialized. After reading your comments above however I think that the suggestion is better. I have updated the webrev accordingly http://cr.openjdk.java.net/~bpb/8016252/webrev.3/ Note that this is a new URL. I have not looked in any detail at the test, but the file should start with the copyright/header, and not the import statements. Fixed - thanks. On Oct 8, 2013, at 2:14 AM, Alan Bateman wrote: This looks better, the checks on loadFactor and size look okay. I don't know all the history on this bug but it looks like the goal was partly to avoid resizing when deserializing. This means the capacity could match HashMap. To be consistent with the size check then we could throw an exception if the capacity is negative (interesting case for tests and malware only). Negative capacity check added in the updated webrev.3. I skimmed over the test but it doesn't appear to exercise anything new. If you want to exercise the checks then it would require deserializing from a byte stream that results in bad loadFactor, size and capacity values. It might not be worth it of course. No, it does not exercise anything new. I actually did try inserting random garbage into the written-out byte stream, but without knowing where to do so to affect the fields of interest it is rather useless and causes totally unpredictable results. I don't know that this test really needs to be included with the patch. Thanks, Brian
Re: RFR: JDK-8026061 - File.createTempFile fails if prefix is absolute path
Sean and Alan, Thanks for the instructions. I just sent out the request to jdk7u-dev mailing list. -Dan On Tue 08 Oct 2013 12:49:08 PM PDT, Seán Coffey wrote: Yes - no problem pushing the changeset for Dan once the approval request is logged and approved. regards, Sean. On 08/10/2013 20:43, Alan Bateman wrote: On 08/10/2013 19:24, Dan Xu wrote: Hi, This is a backport request towards 7u-dev repository on bug JDK-8025128 that I fixed several days ago. It is going to keep the method, File.createTempFile(), backward compatible. Please help review it. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-8026061 Webrev: http://cr.openjdk.java.net/~dxu/8026061/webrev/ -Dan This looks like it's the same patch that is in jdk8 so it doesn't need to be reviewed again. Instead you just need to send an approval request to the jdk7u-dev list to request approval to push it there. The approval template page [1] has the list of things that need to be included in the request. One other thing to point out is that you don't have committer role on jdk7u so you are going to need a sponsor. I'm sure Seán or one of the other maintainers will help on this. -Alan [1] http://openjdk.java.net/projects/jdk7u/approval-template.html
Re: JDK 8 RFR 7179567: JCK8 tests: api/java_net/URLClassLoader/index.html#Ctor3 failed with NPE
I have posted an updated webrev
http://cr.openjdk.java.net/~bpb/7179567/webrev.3/ which I hope addresses all
the concerns expressed below.
Please see also my comments in line.
Once this looks acceptable I can do the CCC request.
Thanks,
Brian
On Oct 7, 2013, at 9:28 PM, David Holmes wrote:
Aside: I'm confused about the relationship of this bug and JDK-6445180 - are
they not duplicates? Seems to me this one should have been closed as a dup
when it was reported.
I think you are correct. I can adjust this once the webrev is approved.
On 5/10/2013 6:58 AM, Brian Burkhalter wrote:
On Oct 3, 2013, at 5:38 PM, Brian Burkhalter wrote:
On Oct 3, 2013, at 5:35 PM, Alan Bateman wrote:
On 03/10/2013 16:10, Brian Burkhalter wrote:
Please review and comment at your convenience.
Issue:https://bugs.openjdk.java.net/browse/JDK-7179567
Webrev: http://cr.openjdk.java.net/~bpb/7179567/
An updated webrev which I hope adequately addresses the expressed concerns
may be found at:
http://cr.openjdk.java.net/~bpb/7179567.2/
URLClassLoader.java: please delete the commented out line:
+ //Objects.requireNonNull(urls);
I already fixed that but had not updated the webrev.
SecureClassLoader.java:
186 * @throws SecurityException if the {@code ClassLoader} instance is
not
187 * initialized.
should read this classloader instance as it refers to the current instance.
Also this may be bringing the spec into line with the implementation but
initialization here is purely an implementation detail not part of the
specification for this class so it should not be mentioned explicitly - and
this change still needs a CCC (which might help determine exactly what should
be said here - I'm unclear how you can try to call getPermissions if this is
uninitialized as it would need 'this' to escape from the constructor - which
perhaps it can do via a third-party security manager?).
I've removed this @throws clause.
NoCallStackClassLoader.java: the comment is far too verbose, we don't write
such explanatory kinds of comments for this kind of thing (else the code
would be overrun with commentary!).
Shortened.
Aside: if you are a JDK Author you don't need a Contributed-by line in the
commit comments.
Removed.
On Oct 8, 2013, at 4:08 AM, Alan Bateman wrote:
This looks much better.
If I read the code correctly then the long standing behavior of
URLClassLoader.getPermissions(null) was to throw a NPE, now it is changed to
return the empty collection in order to match the super type
(SecureClassLoader). I can't think of anything that would break so this is
probably okay, just maybe a bit surprising.
My previous comment on @throws vs. @exception was just to keep things
consistent as this is old code and would look odd for a method to use both.
Our preference is to switch to @throws whenever the opportunity arises. The
comment was also on the alignment/style. Take URLCLassLoader(URL[],
ClassLoader) for example, the existing SecurityException has its description
aligned under SecurityException whereas the new NullPointerException wraps
around. So my overall comment here was to avoid mixing styles (it doesn't
matter too much which style is used, just keep it consistent for future
maintainers).
In the test then it might be better to change the @summary line to only
include the second paragraph (the bug summary is not interesting, especially
when it references a test that is not in OpenJDK).
Updated.
On Oct 8, 2013, at 8:53 AM, Chris Hegarty wrote:
Yes, this is much nicer.
I'd be tempted to write another private constructor, taking all args, and
checking params with checkForNullURLs before invoking, similar to ThreadGroup
[1] L117, for example. But that is just clean up to remove some duplication.
No need to do this.
If I read the code correctly then the long standing behavior of
URLClassLoader.getPermissions(null) was to throw a NPE, now it is
changed to return the empty collection in order to match the super type
(SecureClassLoader). I can't think of anything that would break so this
is probably okay, just maybe a bit surprising.
Agreed.
My previous comment on @throws vs. @exception was just to keep things
consistent as this is old code and would look odd for a method to use
both. Our preference is to switch to @throws whenever the opportunity
arises. The comment was also on the alignment/style. Take
URLCLassLoader(URL[], ClassLoader) for example, the existing
SecurityException has its description aligned under SecurityException
whereas the new NullPointerException wraps around. So my overall comment
here was to avoid mixing styles (it doesn't matter too much which style
is used, just keep it consistent for future maintainers).
Right, these classes are prime for stylistic clean up early in 9. For now,
keep things locally consistent ( even if that is old style ).
-Chris.
[1]
hg: jdk8/tl/jdk: 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs
Changeset: f1e31376f419 Author:robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c
Re: RFR: 8024688: j.u.Map.merge doesn't work as specified if contains key:null pair
On Oct 8 2013, at 01:27 , Paul Sandoz wrote: Hi Mike, I am probably going over old ground here... Not a problem, I don't think this particular aspect has received as much attention as it probably should Given that there is ConcurrentMap is there any point in having the defaults on Map detect concurrent modification and barf, or retry The retry behaviour in particular doesn't seem to be appropriate for the general Map defaults. The concurrent modification detection at this point is mostly a result of (supposed) invariant checks failing. or neither of the previous two e.g. putIfAbsent, computeIfPresent and replace respectively i.e. there seems to be inconsistent behaviour here. Right, the behaviour is not consistent across all of the Map methods. Some do a better job than others of detecting concurrent modification. Would it not be better to separate concerns of serial and concurrent access in the defaults of Map and ConcurrentMap? Yes, The defaults on Map could state they are not suitable for maps that can be concurrently modified, They probably should do so. if that is required extend from ConcurrentMap. If function values passed to methods modify the Map then undefined behaviour will result. (I am also wondering if there are currently edge cases e.g. if a function value modifies the source then the re-try loop will never terminate.) Yes, there are cases where this can happen. I realize that is separate from the null behaviour, but perhaps this separate will help clarify null behaviour? For the ConcurrentMap implementations I've written the defaults to explicitly assume that null values are not supported (there's @implNote documentation of this assumption) Mike Paul. On Oct 4, 2013, at 5:35 AM, Mike Duigou mike.dui...@oracle.com wrote: Hello all; This is a changeset which improves the consistency of several Map.merge implementations for handling of null values. The existing unit tests hadn't considered several cases where the result of the remapper was not the same as the value. I've restructured the merge tests to be more thorough and systematic this revealed a couple of problems. http://cr.openjdk.java.net/~mduigou/JDK-8024688/0/webrev/ Like several of the previous patches, this one introduces an alternative default for ConcurrentMap to work around issues involving null values where the handling in the general Map default would be incorrect. Mike
Review request for 8026027: Level.parse should return the custom Level instance instead of the mirrored Level
This fixes Level.parse to return the custom Level instance. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8026027/webrev.00/ When a custom Level is created, a mirrored level instance (containing the same value as the custom Level) is created and used by the logging implementation. Only the custom level should be added to the known level list from which Level.parse will look up. Thanks Mandy
Re: JDK 8 code review request for JDK-8025913 - Rename jdk.Supported to jdk.Exported
On 10/04/2013 10:30 AM, mark.reinh...@oracle.com wrote:
2013/10/3 16:43 -0700, joe.da...@oracle.com:
Per previous discussions on the mailing list, we've decided to rename
the annotation type jdk.Supported to jdk.Exported.
...
Looks good to me.
One question, though: Is it intended that one use of this annotation
can be overridden by another at a deeper lexical level? For example:
@Supported
public class X {
@Supported(false)
public static class Y {
}
}
I would say that is most likely a logical error to have inconsistent
exported-ness on a top-level and its nested types, but it is an
extra-linguistic correctness issue for the semantics we want to impose
on this annotation.
Conceivably, such an inconsistency could arise if for some reason a
nested type was slated for removal in the future but the containing type
was not.
Equivalently, imagine @Supported in a package-info.java file and
@Supported(false) on a type within that package.
At the package level, I'd say the package-info file should have the
prevailing exported-ness of the types in that package, but sometimes
there are a few bad types and the rest should stay.
If so then it'd be helpful to mention this possibility in the
specification.
I'll add some guidance on these points.
Thanks,
-Joe
JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation
Hello,
Please review the patch below which addresses
JDK-8024354 Explicitly permit DoubleStream.sum()/average()
implementations to use higher precision summation
Thanks,
-Joe
diff -r f1e31376f419
src/share/classes/java/util/DoubleSummaryStatistics.java
--- a/src/share/classes/java/util/DoubleSummaryStatistics.java Wed Oct
09 00:10:02 2013 +0100
+++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Tue Oct
08 18:54:55 2013 -0700
@@ -118,6 +118,11 @@
* value is a {@code NaN} or the sum is at any point a {@code NaN}
then the
* sum will be {@code NaN}.
*
+ * @implNote This method may be implemented using compensated
+ * summation or other technique to reduce the error bound in the
+ * numerical sum compared to a simple summation of {@code double}
+ * values.
+ *
* @return the sum of values, or zero if none
*/
public final double getSum() {
@@ -161,6 +166,10 @@
* value is a {@code NaN} or the sum is at any point a {@code NaN}
then the
* average will be {@code NaN}.
*
+ * @implNote This method may be implemented using compensated
+ * summation or other technique to reduce the error bound in the
+ * numerical sum used to compute the average.
+ *
* @return the arithmetic mean of values, or zero if none
*/
public final double getAverage() {
Re: JDK 8 code review request forJDK-8024354: Explicitly permit DoubleStream.sum()/average() implementations to use higher precision summation
This seems to contradict the main documentation for these methods. Perhaps
instead we should remove the The average returned can vary depending upon the
order in which values are recorded. This is due to accumulated rounding error
in addition of values of differing magnitudes. Values sorted by increasing
absolute magnitude tend to yield more accurate results. into an @implNote?
I also suspect that having this documentation only in DoubleSummaryStatistics
may be too hidden away. Perhaps similar docs on DoubleStream sum() and
average() methods as well?
Mike
On Oct 8 2013, at 18:56 , Joe Darcy wrote:
Hello,
Please review the patch below which addresses
JDK-8024354 Explicitly permit DoubleStream.sum()/average()
implementations to use higher precision summation
Thanks,
-Joe
diff -r f1e31376f419 src/share/classes/java/util/DoubleSummaryStatistics.java
--- a/src/share/classes/java/util/DoubleSummaryStatistics.java Wed Oct 09
00:10:02 2013 +0100
+++ b/src/share/classes/java/util/DoubleSummaryStatistics.java Tue Oct 08
18:54:55 2013 -0700
@@ -118,6 +118,11 @@
* value is a {@code NaN} or the sum is at any point a {@code NaN} then
the
* sum will be {@code NaN}.
*
+ * @implNote This method may be implemented using compensated
+ * summation or other technique to reduce the error bound in the
+ * numerical sum compared to a simple summation of {@code double}
+ * values.
+ *
* @return the sum of values, or zero if none
*/
public final double getSum() {
@@ -161,6 +166,10 @@
* value is a {@code NaN} or the sum is at any point a {@code NaN} then
the
* average will be {@code NaN}.
*
+ * @implNote This method may be implemented using compensated
+ * summation or other technique to reduce the error bound in the
+ * numerical sum used to compute the average.
+ *
* @return the arithmetic mean of values, or zero if none
*/
public final double getAverage() {
RFR: 8025910 : (s) rename substream(long) - skip and substream(long, long) - slice
Hello all; Based upon feedback from the JavaOne Hands-On-Lab and other sources the 335 EG has decided to rename the two substream methods in the Streams interfaces to skip and slice. Webrev: http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/webrev/ and the specdiff: http://cr.openjdk.java.net/~mduigou/JDK-8025910/0/specdiff/overview-summary.html Thanks, Mike
RFR: 8023524: Mechanism to dump generated lambda classes / log lambda code generation
Hi, Please review updated webrev at http://cr.openjdk.java.net/~henryjen/ccc/8023524/6/webrev In this update, - Check the specified directory once, disable dumping if it is invalid. This address the comment of unnecessary complexity, as this is a debug feature and most likely developer would like to restart. - minimum doPrivilege permission - Install security manager in test to verify doPrivilege Cheers, Henry
