Penso sia interessante iniziare la discussione non tanto dall'implementazione di Federico, ma dal questo articolo sul design di Flogger: https://google.github.io/flogger/anatomy.html
Se ho letto bene, una delle principali obiezioni di Simone era su: -----XXX-----XXX----- *paghi l'if (dentro atDebug()), string concatenation, boxing e varargs array* -----XXX-----XXX----- Mi pare flogger ignori completamente l'aspetto della string concatenation (con un implicito "non usarla"), e risolve le ultime due scrivendo scrivendo una bella valanga di metodi: https://github.com/google/flogger/blob/master/api/src/main/java/com/google/common/flogger/LoggingApi.java#L289 Se partiamo da codice come quello descritto da Federico, dove: -----XXX-----XXX----- *Raramente ho visto usare "if (isDebugEnabled())" nel codice delle applicazioni su cui ho lavorato* -----XXX-----XXX----- se usi una "tradizionale" libreria di logging, senza nessun is*Level* Enabled() guard, non avresti comunque gli stessi problemi di "*string concatenation, boxing e varargs array*" ad ogni chiamata? On Tue, Jan 8, 2019 at 2:26 PM Federico Fissore [email protected] [it-torino-java-jug] <[email protected]> wrote: > > > Simone Bordet [email protected] [it-torino-java-jug] ha scritto il > 08/01/19 alle 13:36: > > > > Scusa ma non capisco. > > Fare una libreria di logging che alloca di più e non salva nemmeno il > > costo di if (isXXXEnabled()), che senso ha? > > E nel 99% dei casi di utilizzo non usi neanche la fluency, perché i > > log statements sono del tipo log("format string", params), che è lo > > stesso di SLF4J debug("format string", params) - l'unica fluency che > > usi è atDebug() che però introduce altri problemi (e grossi)... > > > > Non è che voglio smontarti, ma veramente non capisco l'effort, sorry. > > > > L'idea è partita guardando Flogger [0]: api carina, ma perchè inventarsi > un'altra libreria per il logging? > > Introdurre un oggetto intermedio permette di migliorare l'API di slf4j > senza scrivere un'altra libreria di logging e senza dover duplicare il > codice > > Se per esempio volessi aggiungere a slf4j un overload con un terzo > Object alla firma di "debug", dovrei poi fare copia incolla negli altri > 4 metodi. Con questo approccio invece lo fai una volta e vale per tutti. > > Finora comunque l'unico vantaggio è avere la lazy evaluation degli > argomenti > > La dimensione dei problemi è relativa a dove usi slf4j. Raramente ho > visto usare "if (isDebugEnabled())" nel codice delle applicazioni su cui > ho lavorato: è boiler plate code che cerco di evitare loggando quel che > serve, usando solo info e error, warn al massimo. In quei casi quindi la > dimensione del problema è zero. > > [0] https://github.com/google/flogger > > -- Paolo Mossino <[email protected]>
