Re: class SplittableRandom
Hi Doug, I confess I'm not an expert in PRNGs, but I'll try to ask a hopefully no-nonsense question anyway. SplittableRandom seems to be a kind of PR-PRNG-G - a PseudoRandom-PseudoRandomGenerator-Generator. In a sense that it's split() method returns an instance that represents a PRNG which produces numbers of a different sequence than it's parent (it has it's own distinct gamma). So not only does a child SplittableRandom instance return numbers from different part of same sequence as parent, but from a different sequence altogether. While it is not obvious from the javadocs, repeatable invocations of split() performed on the same instance, return SplittableRandom instances that represent the same PRNG (same gamma), just initialized with different seeds. Is this important to know? Regards, Peter On 07/10/2013 09:13 PM, Doug Lea wrote: [Note: I'm also posting this on the concurrency-interest list.] We expect that using random numbers in parallel Stream computations will be common. (We know it is common in parallel computing in general.) But we had left support for it in an unsatisfactory state. If you want to create a stream of random numbers to drive a parallel computation, you'd choose among two options, neither of them providing what you probably want: (1) Use a stream based on a single shared java.util.Random object, in which case your program will encounter stunning slowdowns when run with many cores; or (2) Use a stream based on ThreadLocalRandom, which avoids contention, but gives you no control over the use or properties of the per-thread singleton Random object. While the ThreadLocalRandom option is great for many purposes, you wouldn't want to use it in, say, a high-quality Monte Carlo simulation. Enter Guy Steele. Guy has been working on an algorithm that addresses exactly the substantial range of uses not otherwise supported: It is, in essence, the Random number generator analog of a Spliterator. Class SplittableRandom supports method split() that creates a sub-generator that when used in parallel with the original, maintains its statistical properties. When Brian Goetz and I heard that this was nearing completion, we entered drop-everything mode to explore whether it could be added now in time for JDK8. We conclude that it should. We've been helping with JDK-ifying the basic algorithm, integrating java.util.Stream support, etc, to enable addition as class java.util.SplittableRandom. Just to be on the cautious side though, we are for the moment treating this in the same way we treat jsr166n candidates for potential OpenJDK integration. The initial version is available at http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/SplittableRandom.java?view=log With API docs at: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/SplittableRandom.html This post serves as a request for comment, with shorter than usual turnaround (a couple of days) before considering a request to integrate into OpenJDK 8. So, please take a look. Here are answers to some likely questions: Q: How much faster is it than java.util.Random? A: In sequential usages, usually at least twice as fast for long and double methods; usually only slightly faster for int methods. In parallel usages, SplittableRandom is almost arbitrarily faster. The very first simple parallel Stream program I wrote (to generate and sum nextLong()'s) ran 2900 times faster than the java.util.Random equivalent on a 32-way machine. Q: When can/should I use it instead of java.util.Random? A: Whenever you are not sharing one across Threads. Instances of SplittableRandom are not thread-safe. They are designed to be split, not shared, across threads. When class SplittableRandom applies (or you can rework your program to make it apply), it is usually a better choice. Not only is it usually faster, it also has better statistical independence and uniformity properties. Q: When can/should I use it instead of java.util.concurrent.ThreadLocalRandom? A: When you are doing structured fork/join computations, so you can explicitly split one rather than relying on the per-thread singleton instance. Q: Why is this in java.util, not java.util.concurrent? A: Because, like java.util.Spliterator, SplittableRandom is a tool for arranging isolated parallel computations that don't entail any concurrency control themselves. Q: Why isn't SplittableRandom a subclass of Random? A: Class Random requires thread-safety in its spec. It would be nonsensical for SplittableRandom to comply. Q: Why don't you at least come up with a new interface that defines methods shared with java.util.Random? A: We spent a couple of days exploring this. We think it could and probably should be done, but not now. Method names and specs of SplittableRandom are chosen to make it possible. But we encountered enough short-term obstacles to conclude that this is an unwise move for JDK8. Among the issues are that we'd need to adjust some specs
Re: RFR: 8017513: Support for closeable streams
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools that a MHCR instance that definitely hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is that you don't
want to give up the last reference to a closeable resource without
calling close()—and not leak references which out-live the call to
close(). This is definitely not a property of the type of the resource,
so I don't see why the MayHoldCloseableResource interface is needed (or
can confer relevant information). The HoldsResource annotation could be
useful, but based on the current documentation, it's not clear if it is
actually intended to express the data flow property.
--
Florian Weimer / Red Hat Product Security Team
problems with sun.reflect.Reflection.getCallerClass(int)
Hi all, I started a thread about this already on the mlvm list, but since I get no responses there I am going to ask here as well. Plus I have an actual problem with openjdk 7u25 related to this it seems. First the u25 problem. According to https://jira.codehaus.org/browse/GROOVY-6246 openjdk 1.7.0_25 freezes with 100% CPU load in this code: https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java#L105 This is surely not the nicest piece of code and all that, but that is not the point. The point is that this worked in openjdk 1.7.0_9 and does not in openjdk 1.7.0_25. Where it does work is in the oracle jdk 1.7.0_25. Btw: it is too bad there are no .tar.gz packages of the openjdk builds available. Assuming the diagnosis is right, this should help pinpointing the problem. Has there been any changes already to that method? Of course Reflection.getCallerClass(int) is a bigger problem for us. It was announced, that in u40 of jdk 1.7.0 this method will be no longer operational, unless you use a jvm switch. This is quite troublesome for us, but at least there is some way. In jdk 1.8 this method is supposed to disappear without replacement. There seems then to be the getCallerClass() method, which ignores frames from reflection (I strongly hope for you guys that lambda and indy are included here), but this will not rescue us at all. We have almost always a frame of our own appearing in a first call in Groovy. And there is no way to avoid that (not even in indy). That means for us, that any functionality depending on this cannot be called from a Groovy program anymore. We already replace RessourceBundle.getBundle(String) to let it discover the right loader. But after the change this will not help. Transporting the not always available caller class from the callsite into the method is for current versions of Groovy (and all versions of Groovy are influenced here) We are currently investigating if we can find a workaround for @Grab (http://groovy.codehaus.org/Grape) in some cases. There won't be one for all cases of course. What I would like to hear is a statement if this is taken as serious or if it will be ignored. From the mlvm list I have so far the impression, that it will be ignored. bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org
hg: jdk8/tl/jdk: 8019826: Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE
Changeset: a46982a212e0 Author:jbachorik Date: 2013-07-11 09:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a46982a212e0 8019826: Test com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java fails with NPE Reviewed-by: sjiang, dholmes, mchung ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java
Re: problems with sun.reflect.Reflection.getCallerClass(int)
Hi Jochen, On 7/11/2013 4:21 PM, Jochen Theodorou wrote: Hi all, I started a thread about this already on the mlvm list, but since I get no responses there I am going to ask here as well. Plus I have an actual problem with openjdk 7u25 related to this it seems. First the u25 problem. According to https://jira.codehaus.org/browse/GROOVY-6246 openjdk 1.7.0_25 freezes with 100% CPU load in this code: https://github.com/groovy/groovy-core/blob/master/src/main/org/codehaus/groovy/reflection/ReflectionUtils.java#L105 This is surely not the nicest piece of code and all that, but that is not the point. The point is that this worked in openjdk 1.7.0_9 and does not in openjdk 1.7.0_25. Where it does work is in the oracle jdk 1.7.0_25. Btw: it is too bad there are no .tar.gz packages of the openjdk builds available. Assuming the diagnosis is right, this should help pinpointing the problem. Has there been any changes already to that method? There is a regression in 7u25 that is fixed in 7u40: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016814 The workaround is to call it with depth+1 when running in 7u25. I will reply the second part next (currently OOTO). Mandy Of course Reflection.getCallerClass(int) is a bigger problem for us. It was announced, that in u40 of jdk 1.7.0 this method will be no longer operational, unless you use a jvm switch. This is quite troublesome for us, but at least there is some way. In jdk 1.8 this method is supposed to disappear without replacement. There seems then to be the getCallerClass() method, which ignores frames from reflection (I strongly hope for you guys that lambda and indy are included here), but this will not rescue us at all. We have almost always a frame of our own appearing in a first call in Groovy. And there is no way to avoid that (not even in indy). That means for us, that any functionality depending on this cannot be called from a Groovy program anymore. We already replace RessourceBundle.getBundle(String) to let it discover the right loader. But after the change this will not help. Transporting the not always available caller class from the callsite into the method is for current versions of Groovy (and all versions of Groovy are influenced here) We are currently investigating if we can find a workaround for @Grab (http://groovy.codehaus.org/Grape) in some cases. There won't be one for all cases of course. What I would like to hear is a statement if this is taken as serious or if it will be ignored. From the mlvm list I have so far the impression, that it will be ignored. bye Jochen
Re: Review request: JDK-7147084 (process) appA hangs when read output stream of appB which starts appC that runs forever (v.1)
Rob, Could you help me with bug review. It stay in review pool too long. Nobody like to look into the native code. Here is the long problem solution description: https://jbs.oracle.com/bugs/browse/JDK-7147084?focusedCommentId=13322689page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13322689 Discussion thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016753.html Bug description: https://jbs.oracle.com/bugs/browse/JDK-7147084 http://bugs.sun.com/view_bug.do?bug_id=7147084 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7147084/webrev.01/ Summary for v1 changes: -- The set of handles that need to restore the inherit flag was extended by child process IOE handles. That was done to avoid greedy sibling problem for the file handles. The file handles are closed outside the synchronized block. -- Greedy sibling problem is covered by the [test/java/lang/ProcessBuilder/SiblingIOEHandle.java] test. -- The fact that the set of current process standard IOE handles and the set of child process IOE handles can intersect was taken into account. -- The [test/java/lang/ProcessBuilder/InheritIOEHandle.java] was changed in accordance with Martin's concern. Regards, -uta On 7/5/2013 5:59 PM, Alan Bateman wrote: On 05/07/2013 09:37, Alexey Utkin wrote: Hi Alan, I know that your stack is overflowed, that is just ping. Regards, -uta Sorry Alexey, I just have not had time to fully digest this one and understand the performance/correctness trade-off. Also I've been desperately trying to get through a list of things before going on vacation this week (for 2 weeks). Rob - since you are interested in ProcessBuilder and Runtime.exec then could you take a pass over Alexey's change on core-libs-dev. This one fixes a long standing issue on Windows. I will get make time to help review when I get back. -Alan
CompletableFuture updates and CompletionStage
Last fall, when putting together class CompletableFuture, and when many issues surrounding lambdas and Streams were still up in the air, we postponed dealing with the question of how to extract out an interface that would support usages by those who need the fluent completion-style capabilities, but under different policies or mechanisms that cannot otherwise be captured using a single class. The lack of an interface was a serious problem because the variation among policies and methods beyond the base fluent methods is so wide and conflicting that some potential users wrote off CompletableFuture as unusable -- some need method X, some cannot allow that same method X, for X dealing with cancellation, blocking, overwrites, etc. We finally last week settled this in an acceptable and simple way, introducing interface CompletionStage, that is nearly just a subset of existing CompletableFuture methods, and adjusting CompletableFuture accordingly, in a way that provides a recipe for creating interoperable CompletionStage implementations that may differ wrt those methods not in the CompletionStage interface. The adjustments are small but still officially require CCC approval. We had to introduce a method form (whenComplete) to deal with exceptional completions that otherwise required use of CompletableFuture-dependent methods. Plus a couple of utilities and some spec rewordings, and an overhaul of CompletableFuture class-level documentation to now reference CompletionStage. After expert-group and concurrency-interest discussions, no one disagrees that this is an improvement. Some people have lingering disagreements about those policy issues, but are more content that there is now a straightforward way of obtaining the ones they want. The updates have also been in lambda repo (although probably not used much) for about a week. Paul Sandoz has volunteered to coordinate the CCC and webrev and will post the details. (Thanks Paul for adding this to your already overcomitted workload!) -Doug
hg: jdk8/tl/jdk: 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl
Changeset: 05b164788aab Author:psandoz Date: 2013-07-11 13:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05b164788aab 8019484: Sync j.u.c.ConcurrentHashMap from 166 to tl Reviewed-by: martin Contributed-by: Doug Lea d...@cs.oswego.edu ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
RFR 8020921 was Re: CompletableFuture updates and CompletionStage
Hi, Doug's explanation provides an excellent hook to hang the RFR off: http://cr.openjdk.java.net/~psandoz/tl/JDK-8020291-completion-stage/specdiff/overview-summary.html http://cr.openjdk.java.net/~psandoz/tl/JDK-8020291-completion-stage/webrev/ Paul. On Jul 11, 2013, at 12:29 PM, Doug Lea d...@cs.oswego.edu wrote: Last fall, when putting together class CompletableFuture, and when many issues surrounding lambdas and Streams were still up in the air, we postponed dealing with the question of how to extract out an interface that would support usages by those who need the fluent completion-style capabilities, but under different policies or mechanisms that cannot otherwise be captured using a single class. The lack of an interface was a serious problem because the variation among policies and methods beyond the base fluent methods is so wide and conflicting that some potential users wrote off CompletableFuture as unusable -- some need method X, some cannot allow that same method X, for X dealing with cancellation, blocking, overwrites, etc. We finally last week settled this in an acceptable and simple way, introducing interface CompletionStage, that is nearly just a subset of existing CompletableFuture methods, and adjusting CompletableFuture accordingly, in a way that provides a recipe for creating interoperable CompletionStage implementations that may differ wrt those methods not in the CompletionStage interface. The adjustments are small but still officially require CCC approval. We had to introduce a method form (whenComplete) to deal with exceptional completions that otherwise required use of CompletableFuture-dependent methods. Plus a couple of utilities and some spec rewordings, and an overhaul of CompletableFuture class-level documentation to now reference CompletionStage. After expert-group and concurrency-interest discussions, no one disagrees that this is an improvement. Some people have lingering disagreements about those policy issues, but are more content that there is now a straightforward way of obtaining the ones they want. The updates have also been in lambda repo (although probably not used much) for about a week. Paul Sandoz has volunteered to coordinate the CCC and webrev and will post the details. (Thanks Paul for adding this to your already overcomitted workload!) -Doug
Review request for 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error
Bug: http://bugs.sun.com/view_bug.do?bug_id=7187144 Please review http://cr.openjdk.java.net/~sundar/7187144/ Thanks -Sundar
Re: class SplittableRandom
On 07/11/13 03:36, Peter Levart wrote: Hi Doug, I confess I'm not an expert in PRNGs, but I'll try to ask a hopefully no-nonsense question anyway. SplittableRandom seems to be a kind of PR-PRNG-G - a PseudoRandom-PseudoRandomGenerator-Generator. In a sense that it's split() method returns an instance that represents a PRNG which produces numbers of a different sequence than it's parent (it has it's own distinct gamma). So not only does a child SplittableRandom instance return numbers from different part of same sequence as parent, but from a different sequence altogether. While it is not obvious from the javadocs, repeatable invocations of split() performed on the same instance, return SplittableRandom instances that represent the same PRNG (same gamma), just initialized with different seeds. Is this important to know? I don't think it's important to know the mechanics as a user of the class. In fact uses aren't even *allowed* to know them -- we are careful in the API specs not to promise anything except good statistical RNG properties. But your description is mostly accurate: Each instance seeds its split-off instances. The main algorithmic challenge is to find a version of this scheme that has good RNG properties -- both analytically good, and empirically good via DieHarder tests. SplittableRandom's algorithm does, and is simpler and faster than any others we know of. While I'm at it, here are a few follow-ups about SplittableRandom vs ThreadLocalRandom. There's no simple one is better than the other argument. They differ in multiple ways: * SplittableRandom has better statistical properties. Among them: The base algorithm in java.util.Random, shared by ThreadLocalRandom (as well as similar versions used in C rand48 and elswehere) is known to have some weaknesses (it does not pass DieHarder). In particular, lower bits of consecutive values are less independent than higher bits. (I've been contemplating re-exploring alternatives in TLR, but the options are more limited because it is a subclass of Random. Which made sense at the time I did it, but ...) * Ignoring memory contention etc, ThreadLocalRandom is generally faster for nextInt, but slower for long and double methods. * SplittableRandom applies nicely in structured parallelism contexts (for/join, spliterators, etc). ThreadLocalRandom applies nicely in most unstructured-async contexts. * The two classes take different approaches to the memory-effects issues that haunt us core-parallel/concurrent component developers. ThreadLocalRandom keeps the state with the thread, which, after lots of help from Aleksey, works great. SplittableRandom keeps the state with the computation, which (we hope/predict) also works great. But neither is always best. Also, a note to those testing either or both: Especially if you are running on a multisocket-multicore, be sure to use either -XX:+UseCondCardMark or -XX:+UseG1GC. Otherwise the memory contention byproducts of garbage collector bookkeeping are likely to overwhelm other memory effects. -Doug
Re: class SplittableRandom
(I've been distracted by other high priority stuff, and only starting to explore SR, sorry for dumb questions below) On 07/11/2013 04:16 PM, Doug Lea wrote: (I've been contemplating re-exploring alternatives in TLR, but the options are more limited because it is a subclass of Random. Which made sense at the time I did it, but ...) What exactly limits us to adopt the PRNG from SR into TLR, thus gaining the same good statistical properties? Does extending Random actually forces us to match the PRNG j.u.Random has? It does not seem likely if we don't control the seed for TLR anyway. -Aleksey.
Re: Review request for 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error
+1 On 2013-07-11, at 9:13 AM, A. Sundararajan sundararajan.athijegannat...@oracle.com wrote: Bug: http://bugs.sun.com/view_bug.do?bug_id=7187144 Please review http://cr.openjdk.java.net/~sundar/7187144/ Thanks -Sundar
Re: Review request for 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error
On 11/07/13 13:26, Jim Laskey (Oracle) wrote: +1 On 2013-07-11, at 9:13 AM, A. Sundararajan sundararajan.athijegannat...@oracle.com wrote: Bug: http://bugs.sun.com/view_bug.do?bug_id=7187144 Please review http://cr.openjdk.java.net/~sundar/7187144/ Thanks -Sundar Looks good Maurizio
hg: jdk8/tl/jdk: 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error
Changeset: dadcfd84d33f Author:sundar Date: 2013-07-11 18:50 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dadcfd84d33f 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error Reviewed-by: mcimadamore, jlaskey, hannesw, attila ! src/share/classes/javax/script/ScriptEngineFactory.java
Re: RFR: 8019799: api/java_util/jar/Pack200 test failed with compactX profiles. (EZ)
Hi David, thanks for reviewing this! On 10/07/2013 6:25 AM, Kumar Srinivasan wrote: Hi, We had earlier added a fail over to the java implementation, for reference: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/1432a6247ac9 The first time the unpacker is called an UnsatisfiedLinkError will be thrown, but subsequent invocations in the same JDK/VM instance, a NoClassDefFoundError will be thrown. This error also needs to be caught and handled. Ugghhh. Presumably we need a test update to catch this? Yes it is tedious to create this test, the test needs to make a copy of the JDK under test and modify it to remove the libunpack.so and call unpack repeatedly. But since we already have a JCK test, I marked the bug noreg-jck since the jck test catches this scenario. Here is the modified webrev: http://cr.openjdk.java.net/~ksrini/8019799/webrev.0/ Looks okay - but no test. It would be better/more-efficient if the presence of the native implementation could be detected once during class initialization. But I won't try to force that on you. :) that is what I started with initially, later Bob and I agreed that testing for libunpack.so will need to be performed by SE always, where libunpack.so is sure to exist. Thanks Kumar Thanks, David Thanks Kumar
hg: jdk8/tl/langtools: 8013404: Unclear spec for target typing with conditional operator (?:)
Changeset: 87a951c88a33 Author:mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out
Re: hg: jdk8/tl/langtools: 8013404: Unclear spec for target typing with conditional operator (?:)
On 07/11/2013 04:37 PM, maurizio.cimadam...@oracle.com wrote: Changeset: 87a951c88a33 Author:mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out may I ask why ? Rémi
Re: hg: jdk8/tl/langtools: 8013404: Unclear spec for target typing with conditional operator (?:)
On 11/07/13 16:11, Remi Forax wrote: On 07/11/2013 04:37 PM, maurizio.cimadam...@oracle.com wrote: Changeset: 87a951c88a33 Author:mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out may I ask why ? Rémi Why what? :-) Maurizio
Re: hg: jdk8/tl/langtools: 8013404: Unclear spec for target typing with conditional operator (?:)
On 07/11/2013 05:45 PM, Maurizio Cimadamore wrote: On 11/07/13 16:11, Remi Forax wrote: On 07/11/2013 04:37 PM, maurizio.cimadam...@oracle.com wrote: Changeset: 87a951c88a33 Author:mcimadamore Date: 2013-07-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/87a951c88a33 8013404: Unclear spec for target typing with conditional operator (?:) Summary: Fix previously ignored test Reviewed-by: jjg, vromero ! test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType36.out may I ask why ? Rémi Why what? :-) Maurizio Why the target typing in ?: has a special case for casting ? Rémi
hg: jdk8/tl/jdk: 8020321: Problem in PKCS11 regression test TestRSAKeyLength
Changeset: 162c015c434a Author:valeriep Date: 2013-07-11 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/162c015c434a 8020321: Problem in PKCS11 regression test TestRSAKeyLength Summary: Corrected the isValidKeyLength array Reviewed-by: xuelei ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java
Re: RFR: 8017513: Support for closeable streams
On 07/10/2013 03:17 PM, Zhong Yu wrote: A few things that require clarification: If we have interface A extends B, C interface B extends MayHoldCloseableResource interface C extends AutoCloseable is A considered definitely holding resource? Not programatically. A is both, from MHCR perspective, it's not without the annotation. If @HoldsResource is applied to a subtype of MayHoldCloseableResource @HoldsResource interface D extends B What does it mean? I would think that means instances of D holds resource. If it mean that D definitely holds resource, is @HoldResource still necessary on methods that return D? Not necessary. Cheers, Henry
Re: class SplittableRandom
Hello.
1) extending Random
Doug Lea wrote:
Q: Why isn't SplittableRandom a subclass of Random?
A: Class Random requires thread-safety in its spec. It would be
nonsensical for SplittableRandom to comply.
Random Javadoc states Instances of java.util.Random are threadsafe.
but ThreadLocalRandom extends Random and is not, so why not consider
that the thread-safety statement only applies to Random.class, and
not to Random subclasses?
2) third alternative
Doug Lea wrote:
If you want to create a stream of random numbers to drive a parallel
computation, you'd choose among two options, neither of them providing
what you probably want: (1) Use a stream based on a single shared
java.util.Random object, in which case your program will encounter
stunning slowdowns when run with many cores; or (2) Use a stream based
on ThreadLocalRandom,
What I would have used (maybe because I'm not an expert!) is something
like this:
new Subtask(new MySequentialRandom(currentTaskRandom.nextLong())).fork()
with nextLong() returning something else than current seed of course,
to avoid ending up with the same sequence of pseudo-random numbers.
In what way would
new Subtask(aSplittableRandom.split()).fork()
be better than that?
The Javadoc for split() says that the values of the returned object
should have the same (i.e. as good?) statistical properties, but wouldn't
it also be the case with a good non-thread-safe Random, like based on
MersenneTwister, which could be seeded with multiple longs?
3) nextDouble()
With this method:
public double nextDouble() {
long bits = (1023L 52) | (nextLong() 12);
return Double.longBitsToDouble(bits) - 1.0;
}
the returned value granularity is only 1/2^52,
i.e. last mantissa bit is always zero.
For example the highest value you can return is
1.9998 - 1.0
i.e.
0.9998
and so
0.
is never returned.
One could use that instead, which doesn't have that problem,
and provides values in [0,1-1/2^53], with 1/2^53 granularity:
public double nextDouble() {
return (this.nextLong() ((1L53)-1)) * (1.0/(1L53));
}
but it can be a bit slower (maybe due to cast of huge longs
into double being slow on some architectures).
If needing speed over accuracy, one can replace nextLong() with
nextInt(), mask with Integer.MAX_VALUE, and 53 with 31.
4) nextGaussian()
Currently there is no nextGaussian():
if added, would it use Random/TLR's algorithm,
or some variation of the Ziggurat method
(which can be about four times faster)?
-Jeff
Re: RFR: 8017513: Support for closeable streams
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools that a MHCR instance that definitely hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is that you don't
want to give up the last reference to a closeable resource without
calling close()—and not leak references which out-live the call to
close(). This is definitely not a property of the type of the resource,
so I don't see why the MayHoldCloseableResource interface is needed (or
can confer relevant information). The HoldsResource annotation could be
useful, but based on the current documentation, it's not clear if it is
actually intended to express the data flow property.
I would suggest you look at EG discussion on this topic. The MHCR is
different from AutoCloseable on the chances of holding critical resources.
Perhaps that suggests the javadoc is not clear enough, I would like to
know what is important and missing.
Cheers,
Henry
hg: jdk8/tl/jdk: 8010285: Enforce the requirement of Management Interfaces being public
Changeset: f3211af79339 Author:jbachorik Date: 2013-07-11 21:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3211af79339 8010285: Enforce the requirement of Management Interfaces being public Reviewed-by: sjiang, dfuchs, mchung ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/package.html ! src/share/classes/sun/management/ManagementFactoryHelper.java + test/javax/management/MBeanServer/MBeanFallbackTest.java + test/javax/management/MBeanServer/MBeanTest.java + test/javax/management/mxbean/MXBeanFallbackTest.java ! test/javax/management/mxbean/MXBeanTest.java + test/javax/management/proxy/JMXProxyFallbackTest.java + test/javax/management/proxy/JMXProxyTest.java
hg: jdk8/tl/jdk: 8019799: api/java_util/jar/Pack200 test failed with compactX profiles.
Changeset: 0bd48087e2dc Author:ksrini Date: 2013-07-11 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0bd48087e2dc 8019799: api/java_util/jar/Pack200 test failed with compactX profiles. Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java
Re: RFR: 8017513: Support for closeable streams
Paul S.'s said the negative of using AutoCloseable is it is no longer
clear whether a stream should be closed or not (6/20). That's true because
the semantics of AutoCloseable indicates you have a resource that requires
closing.
However, the choice to make MayHoldCloseableResource a sub-interface of
AutoClosable should be resisted. It's an inverted design. The Liskov
*substitution
principle *says that sub-interfaces can't loosen the contracts of their
superinterface. If anything, AutoCloseable should be subclass of this new
interface, which MIGHT hold a resource that requires closing. The current
choice is just plainly backwards.
For the above reason stated, and for the fact the interface adds no new
functionality, it's superfluous. If the interface relationship can't be
inverted, then chuck it -- it does nothing anyway. At the least, keep the
annotation.
Paul
On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com wrote:
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools that a MHCR instance that definitely hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is that you don't
want to give up the last reference to a closeable resource without
calling close()—and not leak references which out-live the call to
close(). This is definitely not a property of the type of the resource,
so I don't see why the MayHoldCloseableResource interface is needed (or
can confer relevant information). The HoldsResource annotation could be
useful, but based on the current documentation, it's not clear if it is
actually intended to express the data flow property.
I would suggest you look at EG discussion on this topic. The MHCR is
different from AutoCloseable on the chances of holding critical resources.
Perhaps that suggests the javadoc is not clear enough, I would like to
know what is important and missing.
Cheers,
Henry
--
Cheers,
Paul
Re: class SplittableRandom
On 07/11/13 15:50, Jeff Hain wrote:
Doug Lea wrote:
Q: Why isn't SplittableRandom a subclass of Random?
A: Class Random requires thread-safety in its spec. It would be
nonsensical for SplittableRandom to comply.
Random Javadoc states Instances of java.util.Random are threadsafe.
but ThreadLocalRandom extends Random and is not, so why not consider
that the thread-safety statement only applies to Random.class, and
not to Random subclasses?
ThreadLocalRandoms are (trivially) threadSafe in that you cannot
share them among threads using any sanctioned usage construction.
What I would have used (maybe because I'm not an expert!) is something
like this:
new Subtask(new MySequentialRandom(currentTaskRandom.nextLong())).fork()
One way to think of SplittableRandom is that it makes your idea
behind this code actually work. As it stands, if you were to do
this with java.util.Random, both would generate the same sequence.
The Javadoc for split() says that the values of the returned object
should have the same (i.e. as good?) statistical properties, but wouldn't
it also be the case with a good non-thread-safe Random, like based on
MersenneTwister, which could be seeded with multiple longs?
It might be. It wasn't until a paper in PPoPP last year that
researchers started looking more systematically at the independence
properties of these parent-child generators. And of those we
know something about, SplittableRandom's algorithm seems to
be simplest and fastest. But if a better one comes along,
we can plug it in; nothing in the specs requires the current
implementation.
With this method:
public double nextDouble() {
long bits = (1023L 52) | (nextLong() 12);
return Double.longBitsToDouble(bits) - 1.0;
}
the returned value granularity is only 1/2^52,
Thanks. I'll relay this to a floating-point expert
I know :-) and see whether we can/should improve it.
4) nextGaussian()
Currently there is no nextGaussian():
if added, would it use Random/TLR's algorithm,
or some variation of the Ziggurat method
(which can be about four times faster)?
You've just answered why it is not there, and mostly
answered why it shouldn't be there in any upcoming interface.
There are many algorithms to choose from, that are all
independent of the underlying uniform RNG algorithm.
Plus, there are many more probability distributions
out there. Singling out a particular algorithm/method
for Gaussian stands mostly as an accident of history
in java.util.Random.
-Doug
hg: jdk8/tl/jdk: 8017212: File.createTempFile requires unnecessary read permission
Changeset: 10d2a4b1e576 Author:dxu Date: 2013-07-11 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10d2a4b1e576 8017212: File.createTempFile requires unnecessary read permission Summary: Directly call FileSystem method to check a file existence. Also reviewed by tom.haw...@oracle.com Reviewed-by: alanb ! src/share/classes/java/io/File.java + test/java/io/File/CheckPermission.java ! test/java/io/File/NulFile.java ! test/java/io/File/createTempFile/SpecialTempFile.java
Re: RFR: 8017513: Support for closeable streams
Hi Paul,
I think the MayHoldCloseableResource extends AutoClosable is correct and
AutoClosable extends MayHoldCloseableResource would be wrong.
And exactly because of Liskov:
MayHoldCloseableResource contract says: If you know it holds a
resource, call close(), otherwise you need not call close(), but it's
not wrong to call it anyway - you know whether it holds resource by
looking at @HoldsResource annotation
AutoClosable contract says: It holds a resource, you should call close()
Now imagine code that was written for the AutoClosable contract. Would
it work if you pass it an instance of MayHoldCloseableResource? Allways.
Now imagine generic code that was written for MayHoldCloseableResource
contract and which uses the lookup of @HoldsResource at runtime to
decide whether to call close() or not. Would it work if you pass it an
instance of AutoClosable? Never (since AutoClosable says nothing about
any annotation).
So I argue that MayHoldCloseableResource should be a subtype of
AutoClosable and not the other way around.
(I have not said anything about whether the MayHoldCloseableResource is
actually needed or not.)
Regards, Peter
On 07/11/2013 10:22 PM, Paul Benedict wrote:
Paul S.'s said the negative of using AutoCloseable is it is no longer
clear whether a stream should be closed or not (6/20). That's true because
the semantics of AutoCloseable indicates you have a resource that requires
closing.
However, the choice to make MayHoldCloseableResource a sub-interface of
AutoClosable should be resisted. It's an inverted design. The Liskov
*substitution
principle *says that sub-interfaces can't loosen the contracts of their
superinterface. If anything, AutoCloseable should be subclass of this new
interface, which MIGHT hold a resource that requires closing. The current
choice is just plainly backwards.
For the above reason stated, and for the fact the interface adds no new
functionality, it's superfluous. If the interface relationship can't be
inverted, then chuck it -- it does nothing anyway. At the least, keep the
annotation.
Paul
On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com wrote:
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools that a MHCR instance that definitely hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is that you don't
want to give up the last reference to a closeable resource without
calling close()—and not leak references which out-live the call to
close(). This is definitely not a property of the type of the resource,
so I don't see why the MayHoldCloseableResource interface is needed (or
can confer relevant information). The HoldsResource annotation could be
useful, but based on the current documentation, it's not clear if it is
actually intended to express the data flow property.
I would suggest you look at EG discussion on this topic. The MHCR is
different from AutoCloseable on the chances of holding critical resources.
Perhaps that suggests the javadoc is not clear enough, I would like to
know what is important and missing.
Cheers,
Henry
Re: RFR: 8017513: Support for closeable streams
Hi,
Wouldn't the close() implementation be nil in most cases if there was no
resource.
That kind of method runs very quickly and I would expect the compiler to
inline nothing.
It would be quicker to just call close() than to engage reflection to
determine
if it really did and then decide to call it. Or am I missing some point
about
generating code or in some cases not needing/wanting to close it?
Roger
On 7/11/2013 5:08 PM, Peter Levart wrote:
Hi Paul,
I think the MayHoldCloseableResource extends AutoClosable is correct
and AutoClosable extends MayHoldCloseableResource would be wrong.
And exactly because of Liskov:
MayHoldCloseableResource contract says: If you know it holds a
resource, call close(), otherwise you need not call close(), but it's
not wrong to call it anyway - you know whether it holds resource by
looking at @HoldsResource annotation
AutoClosable contract says: It holds a resource, you should call
close()
Now imagine code that was written for the AutoClosable contract. Would
it work if you pass it an instance of MayHoldCloseableResource? Allways.
Now imagine generic code that was written for MayHoldCloseableResource
contract and which uses the lookup of @HoldsResource at runtime to
decide whether to call close() or not. Would it work if you pass it an
instance of AutoClosable? Never (since AutoClosable says nothing about
any annotation).
So I argue that MayHoldCloseableResource should be a subtype of
AutoClosable and not the other way around.
(I have not said anything about whether the MayHoldCloseableResource
is actually needed or not.)
Regards, Peter
On 07/11/2013 10:22 PM, Paul Benedict wrote:
Paul S.'s said the negative of using AutoCloseable is it is no longer
clear whether a stream should be closed or not (6/20). That's true
because
the semantics of AutoCloseable indicates you have a resource that
requires
closing.
However, the choice to make MayHoldCloseableResource a sub-interface of
AutoClosable should be resisted. It's an inverted design. The Liskov
*substitution
principle *says that sub-interfaces can't loosen the contracts of their
superinterface. If anything, AutoCloseable should be subclass of this
new
interface, which MIGHT hold a resource that requires closing. The
current
choice is just plainly backwards.
For the above reason stated, and for the fact the interface adds no new
functionality, it's superfluous. If the interface relationship can't be
inverted, then chuck it -- it does nothing anyway. At the least, keep
the
annotation.
Paul
On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com wrote:
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools that a MHCR instance that definitely hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is that you don't
want to give up the last reference to a closeable resource without
calling close()—and not leak references which out-live the call to
close(). This is definitely not a property of the type of the
resource,
so I don't see why the MayHoldCloseableResource interface is needed
(or
can confer relevant information). The HoldsResource annotation
could be
useful, but based on the current documentation, it's not clear if
it is
actually intended to express the data flow property.
I would suggest you look at EG discussion on this topic. The MHCR is
different from AutoCloseable on the chances of holding critical
resources.
Perhaps that suggests the javadoc is not clear enough, I would like to
know what is important and missing.
Cheers,
Henry
Re: class SplittableRandom
Doug Lea wrote: new Subtask(new MySequentialRandom(currentTaskRandom.nextLong())).fork() One way to think of SplittableRandom is that it makes your idea behind this code actually work. As it stands, if you were to do this with java.util.Random, both would generate the same sequence. What I was worrying about is having a new API, for a behavior that could be obtained with an old one, but indeed this new API helps people not screw up as they would tend to if using the old one (and especially its default implementation), and it should be easy to make an adapter extending Random and have existing code use SplittableRandom through it. Also not extending Random saves memory and makes things faster (no method override). Singling out a particular algorithm/method for Gaussian stands mostly as an accident of history in java.util.Random. Yes, that was just in case you were going to make SplittableRandom extend or at least imitate Random at some point, for convenience (like for nextDouble()). -Jeff
Re: Point lambdaification of List/Set/Map
(Just getting back from vacation) This seems like a reasonable idea. There has been some concern about adding defaulted non-static methods to these core interfaces because of potential collisions with existing implementations abut that would not seem to be a concern with static methods. On Jun 26 2013, at 09:47 , Stephen Colebourne wrote: Sending this on to core-libs-dev to try to get a response ;-) Stephen On 24 June 2013 16:14, Stephen Colebourne scolebou...@joda.org wrote: One point lambdaification that I haven't seen mentioned is addition static factory methods for the main collection interfaces. (Strictly, this proposal is not point lambdaification as it does not involve lambdas, but it is very much in the same area). I propose adding these static methods: Collection.empty() Collection.of(T...) List.empty() List.of(T...) Set.empty() Set.of(T...) Map.empty() Map.of(Entry...) Map.Entry.of(K, V) Each of these methods would return immutable implementations. There is a case for extending the methods to Iterator and other collection types, however these are the most important. These follow the designs of Stream static methods IIRC. This library change would remove much of the requirement for the collection literals change discussed in Project Coin. Implementation would ideally be via new dedicated immutable classes, however space could be saved by simply reusing the existing classes. I would prefer to use existing Collections implementations. Primarily because they have already been thoroughly used. Any reason to use new dedicated classes? Is this something we could fit in? (Is resourcing the problem, or the idea?) Patches are *always* welcome and are usually more grease to make things happen than just a squeaky wheel. :-) Without a patch I wouldn't be willing to commit that this RFE would make it into Java 8. Mike thanks Stephen
Re: class SplittableRandom
On 07/11/13 15:50, Jeff Hain wrote:
One could use that instead, which doesn't have that problem,
and provides values in [0,1-1/2^53], with 1/2^53 granularity:
public double nextDouble() {
return (this.nextLong() ((1L53)-1)) * (1.0/(1L53));
}
Thanks very much! We changed to use this approach, which does
indeed seem like the best tradeoff.
-Doug
Re: RFR: 8017513: Support for closeable streams
On Thu, Jul 11, 2013 at 4:08 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi Paul,
I think the MayHoldCloseableResource extends AutoClosable is correct and
AutoClosable extends MayHoldCloseableResource would be wrong.
And exactly because of Liskov:
MayHoldCloseableResource contract says: If you know it holds a resource,
call close(), otherwise you need not call close(), but it's not wrong to
call it anyway - you know whether it holds resource by looking at
@HoldsResource annotation
AutoClosable contract says: It holds a resource, you should call close()
Now imagine code that was written for the AutoClosable contract. Would it
work if you pass it an instance of MayHoldCloseableResource? Allways.
Now imagine generic code that was written for MayHoldCloseableResource
contract and which uses the lookup of @HoldsResource at runtime to decide
How do you lookup an annotation on an _instance_ at runtime? And why
do we even care? Just call close() regardless.
And we can revert the parent/child relation, because the otherwise
specified clause is a panacea.
Zhong Yu
whether to call close() or not. Would it work if you pass it an instance of
AutoClosable? Never (since AutoClosable says nothing about any annotation).
So I argue that MayHoldCloseableResource should be a subtype of AutoClosable
and not the other way around.
(I have not said anything about whether the MayHoldCloseableResource is
actually needed or not.)
Regards, Peter
On 07/11/2013 10:22 PM, Paul Benedict wrote:
Paul S.'s said the negative of using AutoCloseable is it is no longer
clear whether a stream should be closed or not (6/20). That's true
because
the semantics of AutoCloseable indicates you have a resource that requires
closing.
However, the choice to make MayHoldCloseableResource a sub-interface of
AutoClosable should be resisted. It's an inverted design. The Liskov
*substitution
principle *says that sub-interfaces can't loosen the contracts of their
superinterface. If anything, AutoCloseable should be subclass of this new
interface, which MIGHT hold a resource that requires closing. The current
choice is just plainly backwards.
For the above reason stated, and for the fact the interface adds no new
functionality, it's superfluous. If the interface relationship can't be
inverted, then chuck it -- it does nothing anyway. At the least, keep the
annotation.
Paul
On Thu, Jul 11, 2013 at 3:01 PM, Henry Jen henry@oracle.com wrote:
On 07/11/2013 01:13 AM, Florian Weimer wrote:
On 07/10/2013 11:30 PM, Henry Jen wrote:
A new interface, java.util.MayHoldCloseableResource, indicates an
implementation may or may not hold a resource need to be closed.
Why doesn't close() throw Exception?
Because there is really much a developer can do on that situation. The
API simply make it not throw a *checked* exception.
See EG discussion on this topic,
http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002081.html
Annotation {@link HoldsResource} may be used to guide users/static
analysis tools that a MHCR instance that definitely hold a Closeable
resource.
All this looks a bit odd to me. I suppose the idea is that you don't
want to give up the last reference to a closeable resource without
calling close()—and not leak references which out-live the call to
close(). This is definitely not a property of the type of the resource,
so I don't see why the MayHoldCloseableResource interface is needed (or
can confer relevant information). The HoldsResource annotation could be
useful, but based on the current documentation, it's not clear if it is
actually intended to express the data flow property.
I would suggest you look at EG discussion on this topic. The MHCR is
different from AutoCloseable on the chances of holding critical
resources.
Perhaps that suggests the javadoc is not clear enough, I would like to
know what is important and missing.
Cheers,
Henry
Re: Point lambdaification of List/Set/Map
On 12 July 2013 00:04, Mike Duigou mike.dui...@oracle.com wrote: Implementation would ideally be via new dedicated immutable classes, however space could be saved by simply reusing the existing classes. I would prefer to use existing Collections implementations. Primarily because they have already been thoroughly used. Any reason to use new dedicated classes? Google Guava is the model here. It has dedicated immutable classes that are more efficient because they don't have the overhead of an immutable wrapper. If it has to be existing classes, then so be it, but the implementation may suffer as a result. I don't believe it can be changed later, as users may see the implementation class as significant, perhaps via a serialization ID. If it is considered acceptable to change the implementation class in a later release, then I would be happy to accept reusing the existing classes to get this into 8. Is it possible to get an opinion on a later implementation class change? Is this something we could fit in? (Is resourcing the problem, or the idea?) Patches are *always* welcome and are usually more grease to make things happen than just a squeaky wheel. :-) Without a patch I wouldn't be willing to commit that this RFE would make it into Java 8. I may be able to find time to do this. Or I may not. Other list readers might want to chime in here and volunteer. I certainly think it would be a popular addition. Stephen
Re: Point lambdaification of List/Set/Map
On Jun 24, 2013, at 10:14 AM, Stephen Colebourne wrote:
One point lambdaification that I haven't seen mentioned is addition
static factory methods for the main collection interfaces. (Strictly,
this proposal is not point lambdaification as it does not involve
lambdas, but it is very much in the same area).
I propose adding these static methods:
Collection.empty()
Collection.of(T...)
List.empty()
List.of(T...)
Set.empty()
Set.of(T...)
Map.empty()
Map.of(Entry...)
Map.Entry.of(K, V)
Each of these methods would return immutable implementations.
There is a case for extending the methods to Iterator and other
collection types, however these are the most important.
These follow the designs of Stream static methods IIRC.
This library change would remove much of the requirement for the
collection literals change discussed in Project Coin.
In general I really like the idea of these methods and support them, but I
wanted to make something clear. This:
Map.of(Map.Entry.of(hello, value1), Map.Entry.of(world, value2),
Map.Entry.of(foo, value3), Map.Entry.of(bar, value4))
Is NOT a replacement for this:
{ hello : value1, world : value2, foo : value3, bar : value4 }
The former is incredibly more verbose than the latter, and that verbosity is
wholly unnecessary. I still support the addition of these methods, and perhaps
the future Collection Literals are syntactic sugar for them, but it most
certainly does NOT remove much of the requirement for the 'collection
literals' change discussed in Project Coin. Collection literals are still very
much desired and lacking, even with these new methods.
Nick
hg: jdk8/tl/jdk: 7 new changesets
Changeset: f225da733291 Author:valeriep Date: 2013-07-05 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f225da733291 8012637: Adjust CipherInputStream class to work in AEAD/GCM mode Summary: Ensure the Cipher.doFinal() is called only once Reviewed-by: xuelei ! src/share/classes/javax/crypto/CipherInputStream.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java Changeset: 6e2a5637b286 Author:valeriep Date: 2013-07-05 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e2a5637b286 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful Summary: Check equality based on component values instead of encoding which may vary due to optional components Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: f321b78c7009 Author:ascarpino Date: 2013-07-08 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f321b78c7009 6755701: SunJCE DES/DESede SecretKeyFactory.generateSecret throws InvalidKeySpecExc if passed SecretKeySpec Reviewed-by: valeriep, wetmore, xuelei ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java + test/com/sun/crypto/provider/Cipher/DES/DESSecretKeySpec.java Changeset: 869bfa39d923 Author:valeriep Date: 2013-07-08 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/869bfa39d923 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 4fcac826628c Author:valeriep Date: 2013-07-09 15:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fcac826628c Merge Changeset: 7bd2993e03fa Author:valeriep Date: 2013-07-10 18:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd2993e03fa 8020310: JDK-6356530 broke the old build Summary: Add serialVersionUID to AuthProvider and P11Key class. Reviewed-by: xuelei ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: 4c95c032c395 Author:valeriep Date: 2013-07-11 17:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c95c032c395 Merge
Re: Review request for 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error
Looks good to me. Mandy On 7/11/2013 8:13 PM, A. Sundararajan wrote: Bug: http://bugs.sun.com/view_bug.do?bug_id=7187144 Please review http://cr.openjdk.java.net/~sundar/7187144/ Thanks -Sundar
