My first thought was that it certainly makes sense for Groovy to use this
internally, but perhaps less to expose this to applications.
The raw System.Logger API is very limited.
However, if Groovy can provide convenience methods (like info, trace,
debug, warn) then it may be attractive for applications to be able to use
logging in their application without introducing an external dependency by
coding to an API like SLF4J or the Log4j2 API.
On Fri, May 1, 2020 at 9:01 PM Paul King <pa...@asert.com.au> wrote:
>
> Hi,
>
> I was wondering whether adding something like a @PlatformLog AST transform
> would be useful. Has anyone had experience using platform logging[1] yet?
>
> I have an early spike to give a flavour of what it could look like[2]. See
> also the Jira issue[3].
> Basically, usage would look like this:
>
> ////////////////
> import groovy.util.logging.*
> import static java.lang.System.Logger.Level.INFO
>
> @PlatformLog
> class Foo {
> def method() {
> log.log INFO, 'Foobar'
> }
> }
>
> new Foo().method()
> ////////////////
>
> I see the real value in JEP 264 is when we move to a JDK9+ minimum
> required version. Then we can switch over to platform logging for all of
> Groovy's internal logging. But a @PlatformLog transform would be about
> exposing it for users of Groovy too. I imagine we'd provide a way to enable
> info, trace, debug, warn style methods too. Perhaps using DGM methods.
>
> Any thoughts?
>
> Thanks, Paul.
>
> [1] https://openjdk.java.net/jeps/264
> [2] https://github.com/apache/groovy/pull/1237
> [3] https://issues.apache.org/jira/browse/GROOVY-9534
>
>
