[jira] [Comment Edited] (LOG4J2-2735) Make the content of the generated log4j2plugins.dat file repeatable

["Andy Wilkinson (Jira)" <ji...@apache.org>]

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

Andy Wilkinson edited comment on LOG4J2-2735 at 12/13/19 8:08 PM:
------------------------------------------------------------------

Reproducible may have been a better term than repeatable. By reproducible or repeatable I mean that given the same inputs the exact same output will always be produced. This isn't the case at the moment as the ordering of the entries in {{Log4j2Plugins.dat}} may vary. One benefit of being byte-for-byte reproducible is that it allows outputs to be cached and reused, enabling significant savings in build execution time as test execution, downstream compilation etc, can all be avoided if the input is the same as it was from a previously cached execution. As mentioned in the original description, Gradle supports such caching. You can learn more about it [here|https://docs.gradle.org/current/userguide/build_cache.html].

It's good to hear that this hopefully won't be a problem in Log4j 3.0 (although it may be if the contents of the class varies). I'd still be grateful for a fix in a 2.x maintenance release and would be happy to contribute a pull request.


was (Author: awilkinson):
Reproducible may have been a better than repeatable. By reproducible or repeatable I mean that given the same inputs the exact same output will always be produced. This isn't the case at the moment as the ordering of the entries in {{Log4j2Plugins.dat}} may vary. One benefit of being byte-for-byte reproducible is that it allows outputs to be cached and reused, enabling significant savings in build execution time as test execution, downstream compilation etc, can all be avoided if the input is the same as it was from a previously cached execution. As mentioned in the original description, Gradle supports such caching. You can learn more about it [here|https://docs.gradle.org/current/userguide/build_cache.html].

It's good to hear that this hopefully won't be a problem in Log4j 3.0 (although it may be if the contents of the class varies). I'd still be grateful for a fix in a 2.x maintenance release and would be happy to contribute a pull request.

> Make the content of the generated log4j2plugins.dat file repeatable
> -------------------------------------------------------------------
>
>                 Key: LOG4J2-2735
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2735
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Plugins
>    Affects Versions: 2.12.1
>            Reporter: Andy Wilkinson
>            Priority: Major
>
> The content of the generated {{Log4j2Plugins.dat}} does not appear to be repeatable. I noticed the problem as it affects Gradle's build caching. Getting different output from Java compilation for the same inputs causes a cache miss and additional work that should be unnecessary.
> Looking at the code, I believe that the problem is that {{PluginProcessor.process}} works with a {{Set}} of elements and that {{PluginCache}} uses an insertion-order map. If the order of the elements in the {{Set}} changes, they will be inserted into the cache in a different order and then written out in a different order.
> Would it be possible to use {{TreeMap}} s in {{PluginCache}} so that the categories and their entries are written in name order?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)