In 1991, Sun Microsystems (specifically, James Gosling) answered a long standing question. The Java programming language, at the time called Oak, was established and released to cut development times into small fractions of what they used to be. The word was “write once, run anywhere”, which for the most part was true. A program could be compiled on one machine, and run on any that supported the same virtual machine.
Don’t get me wrong; Oak was a disaster for efficiency. However, it proved that virtual-machine based productive software wasn’t just an idea, it was actually possible. That was huge. So, Oak became Java (a word already very familiar to programmers), and Sun got to work on expanding the API and improving the compiler. Honestly, Java 1.0 was also crap; but it was very exciting crap. Java 2, in my humble opinion, was where it really took off.
During this time (Oak to now), a lot of features were added. Just-in-time compiling, regular expressions, enumerations, recently lambda expressions, and most importantly a gazillion bazillion classes were added to the JDK. All kinds of solutions to what became a very broad class of problems, shortening development time quite a bit for programmers. Surprisingly the internet, and the population of Java programmers, grew faster than Sun could keep up with. It had the added pressure of improving the compiler, too; which didn’t help.
As a response to this frustrating lag, the Open Source community (you may picture it in a hero cape) took off and created a vast assortment of additional libraries. Many of them, such as LWJGL and JOAL, were domain-specific; some of them weren’t. Apache Commons was the first big guy to come in. It’s actually a collection of libraries, the most important of which (at least for me) was the math (now Math3) library. It offered tried and tested methods for handling complex numbers, Fourier transforms, tuples, and all sorts of awesome stuff. That meant that the people, previously using the vanilla JDK, didn’t have to write it themselves. That saved a boatload of time.
Later, Google came up with Guava, their own contribution to the community (fully compatible with Apache Commons). Guava had neat features like bidirectional maps, and very handy byte conversion methods. Much like Apache Commons, it’s expanding all the time.
In olden days (1990s), it was often necessary to have the entire library as a local resource. That means on-disk. This could be an issue, when you only needed a few methods out of something as large as Math3. It is an enormous library, with a lot of binary data. Then came Apache Maven. I don’t intend to describe how to use Maven manually here, it isn’t something I’m an expert at, and it often isn’t necessary; but there are plenty of wonderful tutorials on the internet. I’m going to describe how to use it quickly.
Maven allowed for the inclusion of libraries from a URL, without the need to download the entire library to disk. As more and more computers were online 24/7, this became increasingly feasible. Through a feature of the Maven build tool, a file called pom.xml, the features of the project could be described, and lazily received as needed. The “POM” in pom.xml stands for “Project Object Model”, which is very accurate.
So How Can I Use Maven to Import these Libraries?
My IDE of choice is Eclipse (which is not to say that there aren’t other good ones out there). There’s almost always a utility native to your environment, which should work similarly to this. Eclipse has a plugin which handles Maven directly. To get it, go to the Help menu, and select “Eclipse Marketplace”. Under the Eclipse.org marketplace, look up the keyword “Maven”. You will probably have quite a few “m2e” entries, the central one usually starts with “Maven Integration for Eclipse…”, the rest generally depends on your Eclipse version.
Install it, and restart Eclipse. Next up, assuming that your project already exists, you need to create a Maven project out of it. Right-click it, select “Configure…”, and click “Convert to Maven Project”. (If it nags you about the group ID or the artifact ID, it’s because of a naïve algorithm for generating the identifiers from the project name; just remove any spaces and funny characters and try again. The details of what these identifiers are are better left to more detailed tutorials on Maven.) It will set up your Eclipse project as a Maven project as well, specifically, an M2Eclipse project.
You will have a new file called “pom.xml” located in your project directory. There are other ways to do this, but the dependency information is typically provided in raw XML and copy/pasting it is usually fastest. Enter XML mode on the document (currently by clicking the last lower tab, labelled “pom.xml”), and find the end of the “<build>” entries.
Right below the “</build>” tag, enter “<dependencies>”. Eclipse will often fill in the terminating tag for you. Between these two, you may enter the dependency information typically found on the web for the library you are using; such as, for LWJGL:
<dependency> <groupId>org.lwjgl.lwjgl</groupId> <artifactId>lwjgl</artifactId> <version>2.8.4</version> </dependency>
Or, for Apache Commons Math3:
<dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-math3</artifactId> <version>3.0</version> </dependency>
Or for Google Guava:
<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>12.0</version> </dependency>
Then, clean your project by going to the Project menu and clicking on the “Clean” option. It’s generally good to recompile a project completely and from the ground, often called cleaning, after making a major change to its dependencies; this is often done automatically, but not always. You’ll now note that you can import any of the packages in Guava, Commons, or whichever library you have imported, without having to download the entire API.
How Does This Change Things?
The JDK is not a small library as it is, it’s actually quite enormous; but if you have ever found yourself struggling to write an extension of a collection or a math utility that could be used in a wide variety of projects, those efforts will now be fewer and further between. You may check the javadocs for these APIs as readily as the javadocs for the JDK, and need not worry about increasing the disk footprint of your development environment or (much worse) your project.