Where should @Service annotation be kept? Interface or Implementation?

Basically annotations like @Service, @Repository, @Component, etc. they all serve the same purpose:

auto-detection when using annotation-based configuration and classpath scanning.

From my experience I am always using @Service annotation on the interfaces or abstract classes and annotations like @Component and @Repository for their implementation. @Component annotation I am using on those classes which serves basic purposes, simple Spring beans, nothing more. @Repository annotation I am using in the DAO layer, for e.g. if I have to communicate to the database, have some transactions, etc.

So I would suggest to annotate your interface with the @Service and other layers depending on the functionality.

I used @Component, @Service, @Controller and @Repository annotations only on the implementation classes and not on the interface. But @Autowired annotation with Interfaces still worked for me. If there's only one implementation of your interface Spring component scan automatically finds it with just @Autowired annotation. In case you have multiple implementations, you will need to use the @Qualifier annotation along with @Autowired to inject the correct implementation at the injection point.

1. @Service on Interfaces

@Service public interface AuthenticationService { boolean authenticate(String username, String password); } 

Normally, that's fine, but there's a drawback. By putting Spring's @Service on interfaces, we create an extra dependency and couple our interfaces with an outside library.

Next, to test the autodetection of our new service beans, let's create an implementation of our AuthenticationService:

public class InMemoryAuthenticationService implements AuthenticationService { @Override public boolean authenticate(String username, String password) { //... } } 

We should pay attention that our new implementation, InMemoryAuthenticationService, doesn't have the @Service annotation on it. We left @Service only on the interface, AuthenticationService.

So, let's run our Spring context with the help of a basic Spring Boot setup:

@SpringBootApplication public class AuthApplication { @Autowired private AuthenticationService authService; public static void main(String[] args) { SpringApplication.run(AuthApplication.class, args); } } 

When we run our app, we may get the infamous NoSuchBeanDefinitionException, and the Spring context fails to start.

Therefore, placing @Service on interfaces isn't enough for the auto-detection of Spring components.

2. @Service on Abstract Classes

Using the @Service annotation on abstract classes isn't common.

We'll start by defining an abstract class from scratch and putting the @Service annotation on it:

@Service public abstract class AbstractAuthenticationService { public boolean authenticate(String username, String password) { return false; } } 

Next, we extend AbstractAuthenticationService to create a concrete implementation without annotating it:

public class LdapAuthenticationService extends AbstractAuthenticationService { @Override public boolean authenticate(String username, String password) { //... } } 

Accordingly, we also update our AuthApplication, to inject the new service class:

@SpringBootApplication public class AuthApplication { @Autowired private AbstractAuthenticationService authService; public static void main(String[] args) { SpringApplication.run(AuthApplication.class, args); } } 

After we run our AuthApplication, the Spring context doesn't start. It ends up with the same NoSuchBeanDefinitionException exception again.

So, using @Service annotation on abstract classes doesn't have any effect in Spring.

3. @Service on Concrete Classes

Contrary to what we've seen above, it's quite a common practice to annotate the implementation classes instead of abstract classes or interfaces.

In this way, our goal is mostly to tell Spring this class is going to be a @Component and mark it with a special stereotype, which is @Service in our case.

Therefore, Spring will autodetect those classes from the classpath and automatically define them as managed beans.

So, let's put @Service on our concrete service classes this time around. We'll have one class that implements our interface and a second that extends the abstract class that we defined previously:

@Service public class InMemoryAuthenticationService implements AuthenticationService { @Override public boolean authenticate(String username, String password) { //... } } @Service public class LdapAuthenticationService extends AbstractAuthenticationService { @Override public boolean authenticate(String username, String password) { //... } } 

We should take notice here that our AbstractAuthenticationService doesn't implement the AuthenticationService here. Hence, we can test them independently.

Finally, we add both of our service classes into the AuthApplication and give it a try:

@SpringBootApplication public class AuthApplication { @Autowired private AuthenticationService inMemoryAuthService; @Autowired private AbstractAuthenticationService ldapAuthService; public static void main(String[] args) { SpringApplication.run(AuthApplication.class, args); } } 

Our final test gives us a successful result, and the Spring context boots up with no exceptions. Both of the services are automatically registered as beans.

You might have a look at this page for the other explanations.

Pros of putting annotation on @Service is that it gives a hint that it is a service. I don't know if any implementing class will by default inherit this annoation.

Con side is that you are coupling your interface with a specific framework i.e. Spring, by using spring specific annotation. As interfaces are supposed to be decoupled from implementation, I would not suggest using any framework specific Annotations or object part of your interface.

I would put @Service on your class but put the name of the interface as a parameter to the annotation e.g.

interface ServiceOne {} @Service("ServiceOne") class ServiceOneImpl implements ServiceOne{} 

By doing that you get all the benefits and can still inject the interface but get the class

@Autowired private ServiceOne serviceOne; 

So your interface is not tied to spring framework and you can change the class at any time and not have to update all your injection points.

So if I wanted to change the implementation class I could just annotate the new class and remove from the first but that's all that is required to be changed. If you inject the class you could have a lot of work when ever you want to change the impl class.

One benefit of spring is to easily switch Service (or other) implementation. For this, you need to annotate on the interface and declare variable like this :

@Autowired private MyInterface myVariable; 

and not :

@Autowired private MyClassImplementationWhichImplementsMyInterface myVariable; 

Like the first case, you can activate which implementation to inject from the moment it is unique (only one class implements the interface). In the second case, you need to refactor all your code (the new class implementation has another name). As a consequence, the annotation needs to be on the interface as much as possible. Furthermore, JDK proxies are well suited for this : they are created and instantiated at application startup because runtime type is known by advance, contrary to CGlib proxies.

interface MyService {} @Service class MyServiceImpl implements MyService{} @Autowired private MyService myService; 

My testing result on spring-boot 2.7.4 is:

Adding @Service ONLY to interface doesn't create spring bean named MyService. It will error on Autowired.

@Service will need to be added to implementation class to create bean com.*.service.impl.MyServiceImpl $$EnhancerBySpringCGLIB$$9140ae19 Spring will wire it to private MyService myService;