CFR - updated 8001667: Comparator combinators and extension methods

2013-03-05 Thread Henry Jen
Hi, Another update to reflect functional interface renames involved in the API, and a bug fix for a regression found earlier. CCC had been approved. Can we get it reviewed and pushed? [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.4/webrev Cheers, Henry

Re: Early review on NIO Stream APIs

2013-02-08 Thread Henry Jen
On 02/08/2013 04:09 AM, Ulf Zibis wrote: Am 08.02.2013 01:15, schrieb Henry Jen: In Files.lines(...): After returned from this method, if an I/O error occurs reading ... should be: After returned from this method, if an I/O error occurs while reading ... In Files.walk(...): ... a given

Early review on NIO Stream APIs

2013-02-07 Thread Henry Jen
Hi, While lambda still finalizing the final API for Stream, there are a couple of streamifaction APIs in nio area, which I would like to start circling around to get early feedbacks. Those APIs return a CloseableStream, other than that, there is not much directly connection to Stream definition.

Re: Early review on NIO Stream APIs

2013-02-07 Thread Henry Jen
. PathMatcher doesn't accept the file attributes though, but that's a problem for most Path-based APIs - path alone often isn't enough and app has to look up attributes in a separate step. Zhong Yu On Thu, Feb 7, 2013 at 6:15 PM, Henry Jen henry@oracle.com wrote: Hi, While lambda

CFR - updated 8001667: Comparator combinators and extension methods

2013-02-05 Thread Henry Jen
Hi, This is an update on previous reviewed version, there are two new method introduced for Comparators to convert a Comparator into a BinaryOperator and corresponding test cases. As there is one new class, java.util.Comparators for 8001667, so we need to have makefile change, thus involve

Re: RFR 2: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-28 Thread Henry Jen
Jason, If I understand you correctly, there are two main concerns, 1. You want to encourage MessageFormat style logging, consider the other way is an anti-pattern. 2. The construction of message could be further eliminated when a filter is involved. Here is what I thought, For 1, the new API

Re: RFR 2: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-28 Thread Henry Jen
On Dec 28, 2012, at 4:11 PM, Henry Jen henry@oracle.com wrote: Next version I'll enable defer message construction until Logger filter check. On a second thought and after more reading into logging code in JDK, it seems like Filter is mostly applied to Handler instead of Logger, thus

Re: RFR 2: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-27 Thread Henry Jen
As stated in the beginning of the review thread, the reason we don't have Supplier version for other API is that a formatter is involved and can achieve same laziness easily. The key is MessageFormatter can take arguments, which will be used to generate the output. As there is no directly

Re: RFR 2: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-26 Thread Henry Jen
On 12/22/2012 07:30 AM, Jason Mehrens wrote: The msg argument in most cases is a string literal because it is either a resource bundle key or a MessageFormat literal. The established best practice is to convert on the fly construction of messages to use the MessageFormat syle logging. This

Re: RFR: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-21 Thread Henry Jen
... Regards, Peter On 12/21/2012 07:28 AM, Henry Jen wrote: Hi, This patch adds a couple APIs to java.util.logging.Logger so that construction of log messages only occurs when it is actually to be logged by using SupplierString instead of String. Since the idea is to avoid unnecessary

RFR 2: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-21 Thread Henry Jen
Hi, Update patch with review feedback, - JavaDoc update for benefit and gotcha. - logEx/logpEx is not log/logp with SupplierString as last argument. As a matter of fact, all API with SupplierString takes it as last argument. - No more doLog(Level, SupplierString, BlockLogRecord) helper for

RFR: JDK-8005263: Logging APIs takes SupplierString for message

2012-12-20 Thread Henry Jen
Hi, This patch adds a couple APIs to java.util.logging.Logger so that construction of log messages only occurs when it is actually to be logged by using SupplierString instead of String. Since the idea is to avoid unnecessary construction of log messages, thus APIs imply formatting are not

Re: Request for Review: CR#8001667, second attempt

2012-12-07 Thread Henry Jen
On Dec 7, 2012, at 1:09 AM, Peter Levart peter.lev...@gmail.com wrote: Hi Henry, I don't know what the plans are about moving the static methods in Comparators to the Comparator interface when static interface methods are enabled, but if that is planned, there will be a clash between

Request for Review: CR#8001667, second attempt

2012-12-05 Thread Henry Jen
Hi, This update reflect changes based on feedbacks for last version, the changes are - rename reverse() to reverseOrder() - rename Comparator.compose to Comparator.thenComparing - add 4 Comparator.thenComparing methods take [Int|Long|Double]Function to enable fluent syntax like this example,

Request for Review: CR#8001667: Comparators class and Comparator extension method

2012-11-13 Thread Henry Jen
Hi, This is a change set regarding Comparator already in lambda repo, it depends on the CR#8001634, particularly the Function SAMs. It implements proposed extension methods on Comparator (reverse and compose) as well as static combinator methods in Comparators for things like turning a T -

<    1   2   3   4