Like on jdbc java provide an interfaces, I see the interfaces like a contract for implementers (Drivers from multiple vendor) to implement those interfaces with respect to their documented functionality from java.
But on java ee, and based on this answer :
https://stackoverflow.com/posts/7571260/revisions
It's the same case on jave ee, the application servers are vendors and they implement jave ee abstract API, but on jdbc (And I mentioned it just as an example) the interfaces on java.sql package define the contract, but on jave ee(for example HttpServlet class) where is the interface the defines the general rules from java to this class that application server have to implement?
or is there any external agreements among application servers to implement the functionality of java ee classes?
Or java ee doc (like on
https://docs.oracle.com/javaee/7/api/
)
is adopted as an agreement?
Some people will see my question is useless, but I want to know the root of any stuff I want to learn, and my mind is used to answer small deal questions.
There are test suites that the vendor implementations are tested against, which obviously need to pass. The specifications also need to be obeyed to be a valid Java EE implementation. The Javadoc API is not the spec, but rather a side effect of it.
Related
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.
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?
For developing enterprise applications using java, Is providing an API the standard approach for stable contract between developers?
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.
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.
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).
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.
I have been asked to write an API for a high-level OO language of my choosing (I'll be using Java). The API needs to perform specific functions, of course, but they are very basic things that I know I can accomplish.
I'm familiar with the concept of an API for a web application and that's straightforward enough, but what exactly does it mean to write an API for an OO language? In Java's case, does this mean writing a package that can be imported and provides the desired functionality via classes/functions, so I would write a) the package and b) a separate module to test it? (For clarification, I have been provided no information other than "write an API" and "it needs to do X, Y, and Z". Further clarification: I mentioned the web application API concept just to show that I know what an API is. This is not any sort of web API whatsoever.)
There are different definitions depending on the context and who you ask.
Some people call all public types that are exposed by a module an API. By this very broad definition almost every library or package has an API. I think this is a quite common definition but not everyone agrees with it.
At a more abstract level, an API is a kind of contract or specification that defines some functionality. An API is more like a well defined interface of a module or service that is used to separate the public available functionality from it's internal implementation. A good example of this kind of API are the Java EE APIs.
Practically, in Java an API usually consist mostly of Interface types. The functionality is defined by the methods of the interface and by the documentation. The API itself does not need to have any functionality on its own (it can have some basic default classes or helper classes though).
It's up to another class to implement the interface and provide implementations of the defined functionality. Those implementations shouldn't violate the contract which is defined in the documentation.
If a some application wants to use the API, it only accesses the interface and never the implementing classes. This is the principle "Program to an interface, not an implementation". In my opinion this is the most important aspect of APIs and is what separates the API from regular interfaces. It makes the API reusable and enables the internal implementation to change without breaking the API.
Of course to actually use an API, there has to be some kind of mechanism to get an instance of a class that implements the API. Usually it's some kind of factory method or dependency injection.
The packaging usually depends on the API's usage. API as defined by the first definition usually are included in the jar of their library, because it wouldn't make sense to import them alone. If there are multiple implementations of an API then the API should be be packaged separately from the implementations.
Yes, you just need to write the classes need to implement the desired functionality. Make sure whatever functionality is requested can be accessed by some other programmer using your code. (Methods they need to use should be public for example).
I'd say your assumption is correct - yes, you are asked to write "a package that can be imported and provides the desired functionality via classes/functions."
Then again, I've never written an API. I was trying to imagine an "offline" one, but the examples that come to mind are mostly referred to as SDKs.
Anyway, this is what Wikipedia has to say on the subject:
API in object-oriented languages
In its simplest form, an object API is a description of how objects work in a given object-oriented language – usually it is expressed as a set of classes with an associated list of class methods.
For example, in the Java language, if the class Scanner is to be used (a class that reads input from the user in text-based programs), it is required to import the java.util.Scanner library, so objects of type Scanner can be used by invoking some of the class' methods
import java.util.Scanner;
public class Test {
public static void main(String[] args) {
System.out.println("Enter your name:");
Scanner inputScanner = new Scanner(System.in);
String name = inputScanner.nextLine();
System.out.println("Your name is " + name + ".");
inputScanner.close();
}
}
In the example above, methods nextLine() and close() are part of the API for the Scanner class, and hence are described in the documentation for that API.
So what I read here is, in OO languages, you can think of any class as being kind of an API for something. Swift is an API for building UIs, and the entire JDK itself is an API for building software for anything that can run the Java runtime environment.
In such [object-oriented] languages, the API is still distributed as a library. For example, the Java language libraries include a set of APIs that are provided in the form of the JDK used by the developers to build new Java programs. The JDK includes the documentation of the API in JavaDoc notation.
Also note that...
An API is usually related to a software library: the API describes and prescribes the expected behavior while the library is an actual implementation of this set of rules. A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.
So basically, whoever told you "it needs to do X and Y" described an API for you (using natural language), and you're supposed to write its implementation - a library, in an object-oriented one. (And years later, some other developer may be writing a new library implementing your API, described by the JavaDoc documentation your produce.)
So yeah, your deliverable is a package that can be imported and used in someone else's Java code.
In an environment with both .Net and Java code, it seems that one way to consolidate the two is to use (or at least look at) common interface files in order to share a high level understanding of the business logic in an organization.
Java and .Net are different from a technical perspective, but by sharing interfaces they can focus on common business logic, while leveraging the advantages of OOP.
Is it common in any sense for an organization to implement an architecture based on having interfaces that are applied to both .Net and Java code and would it be possible to create (or does one exist) a syntax converter for interface code, so they can be easily shared by both frameworks? Or are these two frameworks so completely different that it would be counterproductive to share interfaces?
See IKVM:
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET Framework. It includes the following components:
A Java Virtual Machine implemented in .NET
A .NET implementation of the Java class libraries
Tools that enable Java and .NET interoperability
IKVM makes it possible to develop .NET applications that use Java API's. Here's how to proceed:
IKVM comes with an implementation of the Java class libraries in .NET. To use those API's, simply add a reference to IKVM.OpenJDK.ClassLibrary.dll to your Mono / .NET IDE project.
To use other Java API's, you can take one of the following approaches:
Convert the Java API to .NET CIL using ikvmc. This produces a .NET dll that you can reference in your project.
Use the Java reflection API's to dynamically load and execute the Java bytecode using the IKVM bytecode interpreter. For example, your application can load Java bytecode over a network connection and execute it dynamically.
http://www.ikvm.net/
I'm a beginner in Java EE technologies. I wonder what the difference is between the jstl-api jar and the jstl-impl jar.
Why are the API and implementation separated? Does it mean there are other implementations available?
The API and implementation are separated, because Java EE works with a standardized specification.
The API is part of that specification, and contains a set of mostly interfaces to which everybody that participated in creating said specification agreed. In theory everyone can make an implementation that implements the published standardized API and behaves as described in the associated specification document. You are allowed to call your implementation "certified" when it passes the so-called TCK (Technical Compliance Kit).
It's a stated goal of this specification system to encourage competition, while at the same protected users form being locked-in to any specific implementation.
JSTL in particular is part of the JSP spec, which has been developed under JSR 245. If you would like to make your own implementation, you'd begin with reading the spec document.
Could you point me to any tutorials that explain how to write our own impl for jstl?
There are as far as I know no specific tutorials for creating your own implementation of whatever Java EE specification. It's in nearly all cases pretty much an expert job, and a job which is typically only carried out by a select few organizations or individuals. This kind of material doesn't really lend itself to tutorial-like write ups, although David Blevins (of TomEE fame) has given us the occasional glimpse in the work that is approximately involved with this.
jstl-api contains the interfaces that need to be implemented. The jstl-impl contains the standard or default implementation of those implementations. Why do you need both? because if you want the standard or default functionality you use the jstl-impl, but if you want to implement your own behaviour, you can override the methods of the interfaces in jstl-api. That's what a API means: Application Programming Interface. Best regards.
i've bought a book "learning the java SE 6 platform". i wonder what the word platform really means. cause isn't it just a bunch of classes that i can use. the JDK 1.6 node in Netbeans under Libraries.
And what is API? isn´t it the same thing as platform. But doesnt library mean the same thing..a bunch of classes with some superclasses and so on?
The term "platform" is used to denote any collection of software, services and resources that, within a specific context, are considered a given so they can be used as building blocks for application software (or to build a higher level platform on top of that - something considered a platform in another context)
API is an acronym for application programming interface. This usually means the collection of calling conventions (function signatures and the like) that can be used by an application (the program you are writing) for perusing functionality residing inside a library or a platform.
An API is not the same as a library - the term Interface conveys that it only specifies what you can call, and how that behaves. The actual library that implements the interface can decide for itself how it delivers the specified functionality.
A good example of an API is for example the JDBC API - this is the standard way for java programs to communicate with databases. Each database vendor has its own protocol for connecting to the database, binding variables and such to database commands, but the JDBC API abstracts all that and defines a common ground what allows all java programs to use the same set of functions to talk to - ideally - any database. It is the database vendor's job to actually provide a driver, that is, implement a library that is in accordance with the API and knows how it can fulfill its tasks for that particular database system. So in this case you have many driver libraries (each vendor has their own, sometimes multiple ones) but they all deliver their functionality through the same set of functions, classes etc. specified by the API (in this case, the JDBC API - see http://java.sun.com/j2se/1.5.0/docs/api/java/sql/package-summary.html
Sometimes, an API is so extensive that it is considered a platform, but the term platform is more general, a platform does not need to be an API. For example, the collection of standard UNIX utilities like ls, grep, cd etc. can be considered a platform, but not so much an API.
The Java platform consists (roughly) of the following:
The Java programming language
The Java API
The Java Virtual Machine
There's a quite a bit of details in the Wikipedia article on Java (software platform).
The API, or application programming interface, alone provides the classes that come with the Java platform. For example, when one says the "Java API", one would probably be referring to the class libraries which come with the Java SE platform.
Just for the sake of providing links, here are the official documentation for each part of the Java platform:
The Java programming language - The Java Language Specification
The Java SE API - Java Platform, Standard Edition 6 API Specification
The Java Virtual Machine - The Java Virtual Machine Specification
API - is a Application Programming Interface - this is a set of classes for use.
Platform is a whole bundle - API with runtime and additional applications like compiler, ect.
Yeah platform is more of a general term that can mean different things in different contexts. Think of a gaming platform like the XBox. In this case Microsoft provides a "platform" for developers to make games, and for people to play games on.
In the case of J2EE (enterprise Java), the term platform to me means a solution for developers to build enterprise applications. Its more than a set of classes as you pointed out. For example there are plenty of specifications such as JPA (for persistence), EJB etc. In these cases the Java developers have laid out a specification for other vendors to implement. I think of platform as a base that provides a variety of services on which to build something greater.
An API is a more technical a precise term. It stands for Application Programming Interface. An API is the interface that we developers use when using other people's software. Think of a Java String class. It has a length() method. All Jave developers know that this method exists for the String class, and it is thus part of the Java API.