Why separate the API definition and implementation JARs

Question

For jstl tags, an API javax.servlet.jsp.jstl-api-1.2.1.jar & implementation javax.servlet.jsp.jstl-1.2.1.jar are provided.

For servlets, an API in servlet-api.jar & implementation jar from tomcat or GlassFish are provided.

For collections, API like java.util.List & corresponding implementations like java.util.ArrayList & java.util.LinkedList are provided.

IDE Netbeans is another example.

1. Implementation jar includes both the API(mostly interfaces) and its implementation, What are the advantages in providing a solution with an API JAR and their corresponding implementations(a separate JAR), for programmers/developers to use?

2. For developing enterprise applications using java, Is providing an API the standard approach for stable contract between developers?

Answer 1

I have advocated separating the API from its implementation in my Practical API Design book. At that time I valued the simple library as well as modular library approaches. We used them both successfully when designing NetBeans Platform APIs. I usually felt uneasy when it came to vendor library style - a common approach used in Java EE world.

Later I realized the optimal solution depends on the desired degree of proximity (see my detailed explanation). In short, it depends how closely the API author is related to the one who implements the API. Is it the same person? Is it a group that sit down and agreed on a specification? Are they different, but we expect way more users of the library than those who implement it? Or do we expect almost every user to implement (something in) the library? The answer to this question then leads to:

• None to many
• One to many
• Few to many
• Many to many

Proximity classification. Each of them can be handy in some situations. However, my all time favorite is many to many approach with full featured modular library design.