@Slf4j in static interface methods, JDK8?

[Fabrizio Giudici]

I've just written this:

@Slf4j
public interface ObjectFactory
{
@Nonnull
public static ObjectFactory getInstance()
{
try
{
// FIXME: use Singleton
return
(ObjectFactory)Class.forName("it.tidalwave.accounting.model.impl.InMemoryObjectFactory").newInstance();
}
catch (ClassNotFoundException e)
{
throw new RuntimeException(e);
}
}

...
}

Lombok refuses to accept @Slf4j with an interface, but in JDK 8 this
should change... right?

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[eric.giese]

A Problem is that even in Java 8 only public members are allowed in interfaces.
Slf4j creates a private field - and normally, log variables really shouldn't be public.

To be even more specific, interfaces should only contain trivial implementations in their static or default methods, or delegate to other classes.
In your usecase, a package-private class in the same file which keeps the implementation save might solve the problem.

[Fabrizio Giudici]

On Mon, 07 Apr 2014 09:32:47 +0200, eric.giese <eric...@googlemail.com>
wrote:

... but precisely for the reason that the implementation is trivial (here
it's just a single line, apparently inflated by a try/catch; in other
cases it's definitely a single line) it makes no sense to introduce
another class. I'd prefer to see an "exceptional" public log field here.



--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[eric.giese]

To me the question is rather: "Is this really a good idea at all?"

Static factory methods or default methods in Interfaces really shouldn't have side-effects at all, so I see no real usecase for logging, but a lot of potential for abuse. In your example above, throwing the Exception up-front is probably clearly superior to just log and discard a problem.

If lombok really introduces this feature, then I would at least recommend to give a warning that the log field cannot be scoped to an appropiate visibility level.

[Fabrizio Giudici]

On Mon, 07 Apr 2014 10:16:55 +0200, eric.giese <eric...@googlemail.com>
wrote:

> To me the question is rather: "Is this really a good idea at all?"
>
> Static factory methods or default methods in Interfaces really shouldn't
> have side-effects at all, so I see no real usecase for logging, but a lot
> of potential for abuse. In your example above, throwing the Exception
> up-front is probably clearly superior to just log and discard a problem.

In my case I don't want to eat the exception - BTW it's prototype code
that will be soon changed. You have a point in saying that if the method
is not that complex and you don't want to log errors, there's probably not
meaning in logging anything. But, for instance for debugging purposes, I'd
like to log that "an instance of Service has been instantiated from class
...". It's not something that I can't live without. I could be persuaded
that it's such a marginal need that Lombok should avoid it.

> If lombok really introduces this feature, then I would at least recommend
> to give a warning that the log field cannot be scoped to an appropiate
> visibility level.

Can Lombok generate extra classes? I was thinking that the log variable
could be placed in a package-visible synthetic wrapper class...