[slf4j-dev] [JIRA] (SLF4J-471) CharSequence and varargs

[QOS.CH (JIRA)]

    [ https://jira.qos.ch/browse/SLF4J-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19960#comment-19960 ] 

Foo Far commented on SLF4J-471:
-------------------------------

[The CharSequence interface|https://docs.oracle.com/javase/8/docs/api/java/lang/CharSequence.html] is implemented by both String (which cannot be easily preallocated) and nio CharBuffer (which can).

Java String cannot be easily preallocated because it is strictly immutable.

The CharSequence could be implemented by a class with only private mutability, that allocates at time 1, and initializes via a factory method at time 2.

> 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)