[slf4j-dev] [JIRA] (SLF4J-471) CharSequence and varargs
QOS.CH (JIRA)
noreply-jira at qos.ch
Mon Sep 2 10:58:00 CEST 2019
[ https://jira.qos.ch/browse/SLF4J-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19958#comment-19958 ]
Ceki Gülcü commented on SLF4J-471:
----------------------------------
As you are aware, SFL4J 2.0 introduced a fluent API. Since the API is still in alpha phase, we could replace the String message/format parameter with a CharSequence with no consequences.
However, can you please explain why CharSequence is any better than String with regards to pre-allocation? Any references?
> CharSequence and varargs
> ------------------------
>
> Key: SLF4J-471
> URL: https://jira.qos.ch/browse/SLF4J-471
> Project: SLF4J
> Issue Type: Improvement
> Components: Core API
> Reporter: Foo Far
> Assignee: SLF4J developers list
>
> Could sl4fj provide an interface that enables avoiding all object allocation?
> This is important for low latency applications, which only allocate objects at startup, in order to prevent even minor collection pauses.
> The actual zero-garbage implementation could come later. It would be nice if the slf4j api itself did not have any such impediments. So e.g. users could pass some preallocated string-like object which implements CharSequence, instead of a concrete String, which cannot be allocated ahead of time. There could also be overloaded methods for relatively few parameters (say up to ten), for users that want to avoid the array allocation involved in the java variable argument feature. Of course it'd be positive to have logback implementation so that those actually work, even if they initially work with allocations.
> For the sake of backwards compatibility, this could be a new java interface. Perhaps a superinterface with the varargs replacements as default methods, to avoid breaking anybody who might be implementing the original interface.
--
This message was sent by Atlassian JIRA
(v7.3.1#73012)
More information about the slf4j-dev
mailing list