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
