CODEWITHSUNDEEP
javaapijpaapi-design
overexchange
overexchange

Reputation: 1

Why separate the API definition and implementation JARs

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?

Upvotes: 4

Views: 1690

Answers (4)

Madhu
Madhu

Reputation: 119

In programming using an implementation, you might need the API specification (interfaces, abstract classes etc) too. 

Interface obj = new ClassImpletingInterface();

which could also be done as

ClassImpletingInterface obj = new ClassImpletingInterface();

If your program used only the latter, you might get away having just the implementation jar that didn't include the API package. As far as possible, one should use the former for better maintainability etc. Now the question of why can't the API package just be bundled into the implementation jar - one API one jar. Might sound simple, but may not be desirable. You might prefer to use the javax.servelet.jsp.jstl-api package obtained from the authentic source; not bundled in com.newbie.servlet-0.0.1.jar. There can be legal aspects that prevent such bundling. Further, an implementation not necessarily provide functionality for the complete specification. Your imports for an API could come from two different implementations as different parts, and they could be for different release levels of the specification. In that case, perhaps rare, each bundling a different release level of API may cause trouble because jar search within a directory is not completely defined. So, bundling of API and implementation into separate jars is cleaner.

Upvotes: 0

Jaroslav Tulach
Jaroslav Tulach

Reputation: 528

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.

Upvotes: 3

Matt Timmermans
Matt Timmermans

Reputation: 59164

1) If you put the API in a different jar, then you can let it be used by clients that can't access the implementation. For example:

  • You can exclude the implementation from the compile-time classpath of clients, to ensure that clients of the API don't require any particular implementation.

  • You can exclude the implementation from the run-time classpath of API clients (either via ClassLoaders like servlets do or separate JVMs), so that clients can't depend on any particular implementation, and so that they can use libraries that would conflict with the ones that the implementation uses.

2) Not really individual developers, but it's common to use a strategy like that to avoid conflicts and unwanted dependencies between different development teams.

Upvotes: 2

Raedwald
Raedwald

Reputation: 48654

This is because only the API is standardised, and multiple implementations are possible, and the API is an incomplete specification. In the case of servlets, in addition to the servlets API, which your Web App uses, there is the web application server (Tomcat or Glassfish). The application server is a large program, with many other features and APIs. For a Web Application, your servlets are not "the program"; the application server is. It is not that your servlets delegate to the server, the server delegates to your code (in a WAR).

Upvotes: 0

Related Questions