[java] Confused about using APIs

Started by
4 comments, last by CaptainJester 19 years, 7 months ago
Hi, Well I've bought 2 books for Java so far and downloaded a few E-Books but one thing I don't understand is how I can use third party APIs, for example, I have downloaded an API which allows combatibility with MS Excel but I don't know what I can do with it. It's in a folder called APIs in my SDK Folder, how can I tell the compiler to use this API whilst compiling? Thanks in Advance TomX
Advertisement
An API or Application Program(ming) Interface is a kind of like a car. You put in the key, turn it, change gears, push the pedal a bit and your car moves. There is much going on behind the scenes, but even with out knowing how all those small individual componets work, you can still drive your car :] The api wraps all of those confusing things into simple easy to use functions. An api usually comes with a header file and a library. The header shows what can use in the form of function prototypes. The library contains the complicted implementation of these prototypes. To get an api to work, your going to need to show your compiler the prototypes and the implementation. You do this by including the header file into your source code, and by linking the library to your compiler. Each compiler is a bit different, but never do anything drastically different. Just include the header file like you would any other. To link the library you need to go to your project settings and look for the specfic tab or section on linking files. You can also search your compilers documentation.
I study day and night, memorizing the game.
How you configure the compiler to link/include with the API is totally dependent on the compiler. In an IDE like MSVC, you would definately find some kind of 'Project Options' that allows you to set that. For a command-line compiler, it is either in a .ini file or you pass it as an argument ("gcc -i /include", I hope I got that right...). I'm not sure about the Java compiler though...

xorjesus's explanation is very good - you use the API to perform a task with more simplicity. For example, say I made an API for your MS Excel thingy. You could either do it yourself or use my API. If you did it yourself, then you would be writing lots and lots of unstable and possibly even incorrect code. Most APIs are pretty much guaranteed to do their basic task correctly (even if a few glitches appear higher up) - OpenGL/DirectX draw graphics, DevIL loads images, and the Excel API would load Excel documents (and would provide an easy to use, convenient function to do it, i.e. 'loadExcelDocument( "doc.xls" )' ). Some APIs can even use other APIs, which are commonly called 'wrappers' - for example, a graphics engine. The engine might provide a scene graph, many special techniques, etc. but must use OpenGL/DirectX to do the drawing.

If you don't get it, feel free to ask!
- fyhuang [ site ]
This is where classpath comes in. You set your classpath to point to the jar file that contains the API. You also need to set the classpath to point to the current directory so it will also pick up your own classes as well. If you are using an IDE you need to find a spot to include external libraries. Here is what your classpath might look like:
classpath=.;c:\Java\API\newapi.jar

You can also set the classpath with a command line switch for the javac(compiler) and java(vm) commands.
"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]
1. Classpath is out-dated (although very much still in existence); it caused so many problems in the past that Sun has faffed around trying to get rid of it, or hide it, or simply wondering what the heck to do with it. These days it still exists, but is less overt than it used to be. It is also supplemented by some siblings (e.g. the sourcepath...and I'm trying to get them to add a compilepath too). In general, try to avoid mucking with it... a really good IDE will let you, but will have easier wizards/setup to achieve the same stuff with less hassle.

Oh, and there is now more than one classpath in your typical JVM, just to confuse matters. And there are various later add-ons that pervert the classpath in interesting ways.

2. Use eclipse as your IDE ;D, and you just need to:

If it's a ZIP or GZ file, just unzip it, and inside (somewhere) you'll find a JAR file, which is the all-important part.

a. go to the Properties dialgo for your current proejct
b. go to the build-path section
c. find the tab with a button "add external JARs"
d. click that button, browse to the JAR file that you downloaded, and select it.
e. Magic. All works fine.

If your API wasn't supplied as a JAR...find a new API. Unless it's a native lib, in which case things can get stickier and you should have more detailed install docs come with it.

(sorry for plugging eclipse; there are other good IDE's too, but the only ones that are clearly superior, as opposed to "partly better, partly worse" aren't free)

redmilamber
Classpath is still used in this case too. Eclipse just hides it from you, so it makes it easier. It is better to learn about classpaths than to avoid them. Especially if you want to automate the build with Ant.
"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]

This topic is closed to new replies.

Advertisement