Allowing message field to be null to match SLF4J behavior

[quidryan]

(not really documented in Slf4j)

Quick stab at fixing #11. Comments welcome.

[Mahoney]

Hi,

Thanks for this.

I was trying to follow a philosophy of never storing or exposing null, so always using Optional where a value could be absent, so this fix would break that pattern.

On the other hand this fix is backwards compatible, whereas changing getMessage() on LoggingEvent to return Optional<String> would be a breaking change (though hopefully not a terribly arduous one if people are comparing events using the static helper constructors).

I'll think about what to do; possibly apply this change as a bug fix release to the 1.2 branch and make the breaking change in a 2.0 release.

[nicktindall]

+1

[neeme-praks-sympower]

Any hope of getting this merged and getting a new release of slf4j-test out?

[valfirst]

Please check out https://github.com/valfirst/slf4j-test