[jira] [Commented] (LOG4J2-1629) Support for primitive values in StringMap

["Matt Sicker (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15540551#comment-15540551 ] 

Matt Sicker commented on LOG4J2-1629:
-------------------------------------

Can't you make a {{LongBiConsumer}} version instead of adding another parameter? Or would that not make sense in this use case?

> Support for primitive values in StringMap
> -----------------------------------------
>
>                 Key: LOG4J2-1629
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1629
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.7
>            Reporter: Remko Popma
>            Assignee: Remko Popma
>             Fix For: 2.7
>
>
> For some applications like financial trading systems, highly interactive games or numerical computation-heavy scientific applications, a large portion of data is stored in primitives. Applications like this sometimes need to set such values in the logging context (e.g., order ID, algo strategy instance ID, etc) and would prefer to avoid the overhead of boxing/unboxing these primitives. 
> Building on top of the work done for LOG4J2-1447 and LOG4J2-1349, this ticket proposes to add the following methods to the ThreadContextMap2, StringMap and ReadOnlyStringMap interfaces:
> {code}
> // ReadOnlyStringMap and ThreadContextMap2 additional methods 
> long getLong(String key);
> boolean containsLong(String key);
> /** The value {@link #getLong()} should return if the map
>  * doesn't have a long value for the specified key.
>  */
> long getDefaultLong();
> void setDefaultLong(long defaultValue);
> // StringMap additional method (also in ThreadContextMap2)
> void putLong(String key, long value);
> {code}
> The semantics remain the same as a normal map: there is at most one value for a key. Putting a value with the same key replaces the old value with that key, regardless of whether the old value was an Object or a primitive.
> An API supporting only primitive long values is sufficient because all primitives can be represented as a 64 bit long. For example, a double can be converted to a long and back with the {{Double.doubleToLongBits(double)}} method and its reverse. Applications can decorate the Log4j interfaces with custom facades that provide separate methods for different primitive types if required.
> For iteration, the BiConsumer and TriConsumer's {{accept}} method will take an additional {{long}} parameter:
> {code}
> public interface BiConsumer<K, V> {
>     /**
>      * Performs the operation given the specified arguments.
>      * @param key the first input argument
>      * @param objectValue the second input argument as an Object of type
>      *               {@code V}, or {@code null} if the value is a primitive long
>      * @param longValue the second input argument as a primitive long, or
>      *              a default value if the underlying value is not a primitive value
>      */
>     void accept(K key, V objectValue, long longValue);
> }
> {code}
> It would be good if we can include these methods in the 2.7 release. ThreadContextMap2 and the StringMap interfaces are new so at this stage we don't need to be concerned with backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org