Why Java frameworks do not enforce use of interfaces?

I was just wondering, why there is no interface for a Spring Bean or for a EJB Bean (or for an OSGi service)? I know that there is no need for this because frameworks can use reflection API for calling methods but wouldn't it be less erroneus if interfaces were used instead?

For example, why there is no interface for OSGi component which would look 开发者_开发问答like this:

interface OSGIComponent {
  void activate(BundleContext context);
  ... 
}

In the case of Spring, you don't have to implement a Spring-specific interface to be able to use Spring with your code. This is actually seen as an advantage: it prevents your code being tied to Spring, therefore making it more portable.

That's not to say that you can't implement Spring-specific interfaces. One example that springs to mind (no pun intended) is InitializingBean; this defines a method, afterPropertiesSet(), which gets called (as the name suggests) after Spring has instantiated your bean and set all of its properties.

So there are often framework-specific interfaces and classes that you can use; you have to balance keeping your code portable with making use of the useful stuff that frameworks provide.

You gave the example of an OSGi component that might implement an OSGIComponent interface. Spring does in fact have an interface that your class can implement to be passed a reference to the containing Spring context: ApplicationContextAware. Typically, though, you don't need to make use of these framework-specific interfaces. Your code is generally easier to understand if it just focuses on the actual business logic, rather than details of how the framework is instantiating objects, wiring objects together, and so on.

I was just wondering, why there is no interface for a Spring Bean or for a EJB Bean (or for an OSGi service)?

Before version three, the EJB standard did "enforce use of interfaces". In fact, you had to have at least two, often three interfaces for each bean (Home, Remote and Local). Except the implementation classes didn't implement those interfaces and you had to have an XML deployment descriptor that connected everything together and if anything didn't fit (e.g. because of a typo) you got a completely cryptic runtime error. It was an absolute nightmare, and EJBs have a horrible reputation to this day, even though this mistake was fixed years ago.

I know that there is no need for this because frameworks can use reflection API for calling methods

That makes no sense at all.

but wouldn't it be less erroneus if interfaces were used instead?

Interfaces aren't magic fairy dust that makes code "less erroneous". If you have an API that may have several implementations, you create an interface. Otherwise you don't. That's it.

If the beans have to implement an interface, that interface must be present in the classpath, causing the bean to depend on the dependency injection framework in use (at least prior to the standardization of dependency injection annotations in JSR-330, and now we want backwards compatibility).

However, in Spring, beans may implement an interfaces to interact with the container, for instance InitializingBean and DisposableBean. (source)