Yep, that's definitely one of the candidates for a solution. Sent from my iPhone
> On 2016/02/16, at 9:43, Gary Gregory <garydgreg...@gmail.com> wrote: > > Which is one of the reasons I proposed "level logging". I'm on my phone so I > can't do more that say there is a branch and Jira for my proposal. You only > add a method once, not once per level. Then you say logger.alevel.log(...). > > Gary > >> On Feb 15, 2016 3:47 PM, "Remko Popma" <remko.po...@gmail.com> wrote: >> A word of caution: the Logger API already has 209 method (and I think a few >> just got added). This will explode if we just add "var-arg unrolling" >> methods for 1 param, 2 params, 3 params, ... (up to how many?) Especially >> if we want to also prevent auto boxing in all possible combinations of the >> primitive types boolean, long and double. >> >> There may be other ways to accomplish this. Let's think about this a bit >> longer. I'll add a Jira for this in the no-GC epic. >> >> Sent from my iPhone >> >>> On 2016/02/16, at 1:59, Matt Sicker <boa...@gmail.com> wrote: >>> >>> Considering the garbage-free epic, this sounds like a good idea to bake in >>> from the start. >>> >>>> On 15 February 2016 at 10:39, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> Hi All: >>>> >>>> My my custom flow logger, I avoid auto-boxing on traceExit() calls by >>>> having primitive versions of the APIs. We could do the same and avoid >>>> auto-boxing unless a logger's level is enabled. >>>> >>>> This generates a lot less garbage when, for example, we flow trace our >>>> JDBC APIs and get 50m rows and 50 columns per row. >>>> >>>> Thoughts? >>>> >>>> Gary >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>> Java Persistence with Hibernate, Second Edition >>>> JUnit in Action, Second Edition >>>> Spring Batch in Action >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com>
