[
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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
