You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2017/02/24 18:07:08 UTC
Undeprecating MessageSupplier
In log4j-api, the interface MessageSupplier has been deprecated ever since
we realized that we didn't need it and could just use Supplier<Message> for
lambda support. However, now that I've actually tried to use this in my own
Java 8 project, I noticed that by default, the following will call the
deprecated method:
logger.info(() -> new MapMessage(convertForLogging(fields)));
However, if I cast it, it'll call the non-deprecated form:
logger.info((Supplier<Message>) () -> new
MapMessage(convertForLogging(fields)));
This isn't ideal. I propose we simply undeprecate MessageSupplier as it's
the more specific form that javac will use by default anyways. We should
note that it won't be available in a hypothetical 3.0 API, but I'd imagine
that hypothetical API would just use Java 8's Supplier functional interface
instead as well.
--
Matt Sicker <bo...@gmail.com>
Re: Undeprecating MessageSupplier
Posted by Remko Popma <re...@gmail.com>.
Thanks Matt!
On Sat, Feb 25, 2017 at 2:47 PM, Matt Sicker <bo...@gmail.com> wrote:
> Changed in https://issues.apache.org/jira/browse/LOG4J2-1823
>
> On 24 February 2017 at 12:58, Remko Popma <re...@gmail.com> wrote:
>
>> +1 I'm fine with undeprecating MessageSupplier.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>> On Feb 24, 2017, at 19:07, Matt Sicker <bo...@gmail.com> wrote:
>>
>> In log4j-api, the interface MessageSupplier has been deprecated ever
>> since we realized that we didn't need it and could just use
>> Supplier<Message> for lambda support. However, now that I've actually tried
>> to use this in my own Java 8 project, I noticed that by default, the
>> following will call the deprecated method:
>>
>> logger.info(() -> new MapMessage(convertForLogging(fields)));
>>
>> However, if I cast it, it'll call the non-deprecated form:
>>
>> logger.info((Supplier<Message>) () -> new MapMessage(convertForLogging(f
>> ields)));
>>
>> This isn't ideal. I propose we simply undeprecate MessageSupplier as it's
>> the more specific form that javac will use by default anyways. We should
>> note that it won't be available in a hypothetical 3.0 API, but I'd imagine
>> that hypothetical API would just use Java 8's Supplier functional interface
>> instead as well.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Undeprecating MessageSupplier
Posted by Matt Sicker <bo...@gmail.com>.
Changed in https://issues.apache.org/jira/browse/LOG4J2-1823
On 24 February 2017 at 12:58, Remko Popma <re...@gmail.com> wrote:
> +1 I'm fine with undeprecating MessageSupplier.
>
> Remko
>
> Sent from my iPhone
>
> On Feb 24, 2017, at 19:07, Matt Sicker <bo...@gmail.com> wrote:
>
> In log4j-api, the interface MessageSupplier has been deprecated ever since
> we realized that we didn't need it and could just use Supplier<Message> for
> lambda support. However, now that I've actually tried to use this in my own
> Java 8 project, I noticed that by default, the following will call the
> deprecated method:
>
> logger.info(() -> new MapMessage(convertForLogging(fields)));
>
> However, if I cast it, it'll call the non-deprecated form:
>
> logger.info((Supplier<Message>) () -> new MapMessage(convertForLogging(
> fields)));
>
> This isn't ideal. I propose we simply undeprecate MessageSupplier as it's
> the more specific form that javac will use by default anyways. We should
> note that it won't be available in a hypothetical 3.0 API, but I'd imagine
> that hypothetical API would just use Java 8's Supplier functional interface
> instead as well.
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Undeprecating MessageSupplier
Posted by Remko Popma <re...@gmail.com>.
+1 I'm fine with undeprecating MessageSupplier.
Remko
Sent from my iPhone
> On Feb 24, 2017, at 19:07, Matt Sicker <bo...@gmail.com> wrote:
>
> In log4j-api, the interface MessageSupplier has been deprecated ever since we realized that we didn't need it and could just use Supplier<Message> for lambda support. However, now that I've actually tried to use this in my own Java 8 project, I noticed that by default, the following will call the deprecated method:
>
> logger.info(() -> new MapMessage(convertForLogging(fields)));
>
> However, if I cast it, it'll call the non-deprecated form:
>
> logger.info((Supplier<Message>) () -> new MapMessage(convertForLogging(fields)));
>
> This isn't ideal. I propose we simply undeprecate MessageSupplier as it's the more specific form that javac will use by default anyways. We should note that it won't be available in a hypothetical 3.0 API, but I'd imagine that hypothetical API would just use Java 8's Supplier functional interface instead as well.
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Undeprecating MessageSupplier
Posted by Gary Gregory <ga...@gmail.com>.
Makes sense. We should make we Javadoc all that.
On Feb 24, 2017 10:07 AM, "Matt Sicker" <bo...@gmail.com> wrote:
> In log4j-api, the interface MessageSupplier has been deprecated ever since
> we realized that we didn't need it and could just use Supplier<Message> for
> lambda support. However, now that I've actually tried to use this in my own
> Java 8 project, I noticed that by default, the following will call the
> deprecated method:
>
> logger.info(() -> new MapMessage(convertForLogging(fields)));
>
> However, if I cast it, it'll call the non-deprecated form:
>
> logger.info((Supplier<Message>) () -> new MapMessage(convertForLogging(
> fields)));
>
> This isn't ideal. I propose we simply undeprecate MessageSupplier as it's
> the more specific form that javac will use by default anyways. We should
> note that it won't be available in a hypothetical 3.0 API, but I'd imagine
> that hypothetical API would just use Java 8's Supplier functional interface
> instead as well.
>
> --
> Matt Sicker <bo...@gmail.com>
>