Spring Beginner Tutorial: Dependency Injection Part 2 – What is a Dependency?

What is Dependency Injection? — Part 2

This is the second in a series of blog posts that I’m putting together for developers who are beginning to work with Spring. This post attempts to describe the fundamentals of what a dependency is.

In order to understand Dependency Injection (sometimes people call it Inversion of Control), we need to understand what dependencies are. Take a look at the Java code below. You can find the full example at my Spring Beginner Tutorial github repo.

I’ve tried to give the simplest example I could think of. In this example we have three classes, ExampleRunner, ClassDependency, and InterfaceDependency. We’ll get into the differences below. ExampleRunner depends on both ClassDependency and InterfaceDependency. In the run method of the ExampleRunner class above, we instantiate both ClassDependency and InterfaceDependency, and then call methods on both of these classes.

What does it mean when we say one class depends on another class?

The reason is simple. We say that one class depends on another because one class needs to call methods (or get information from, etc) on the class it depends on. In order for it to complete its job, it needs or depends on the other class. Without that class, it can’t carry out the work that it expects to do.

What is coupling?

Often, you’ll hear the term ‘coupling’ used in discussions of class dependencies. When one class uses another, we say that they are ‘coupled’. In other words, where you have dependencies, you have coupling, at least in a very basic form.

Types of Dependencies

Since I’ve now covered the basics, let’s dive into the different types of dependencies.

  • Class dependencies
  • Interface dependencies
  • Method dependencies
  • Field dependencies
  • Dependency in method

Class dependencies

Class dependencies are when one class depends on another class. In the example above, ExampleRunner depends on ClassDependency. ClassDependency is a concrete type — i.e. it’s not an interface.

Interface dependencies

ExampleRunner also depends on InterfaceDependency, which, as its name implies, is an interface dependency. InterfaceDependency is an interface. In this example, there is a somewhat hidden dependency in that since we instantiate InterfaceDependencyImpl, ExampleRunner also depends on this class. Later in the tutorial, we’ll get into how Spring helps us remove that dependency, but for now the thing to focus on is that InterfaceDependency is an interface, and the ExampleRunner class calls methods on it through this interface.

Field dependencies

In the example above, ExampleRunner also depends on a field. In this case it’s a field called ‘getField()’ (great name, I know :)). This is called a field dependency in that one class (ExampleRunner in our case) depends on the field of another (getField() on the ClassDependency class). This is what we’ll call a ‘field dependency’.

Dependency in method

Take a look at the dependencyInMethod method. Here, we again depend on ClassDependency. It’s just that, this time, the dependency is contained in a method, not as a field to the ExampleRunner class.

Import statements

One way to get a feel for the interface or class dependencies a given class has is to look at its import statements. Here you can find the packages or classes that contain the classes that the class you are examining uses. There’s a drawback to this, however, in that you won’t be able to see at a glance which classes the given class uses if those classes exist in the same package (since you don’t need to import classes that exist in the same package as the current class).

Conclusion

In this tutorial I describe what a dependency is, and give examples of the different types of dependencies. Understanding this is fundamental for understanding DependencyInjection and Spring.

java.net.BindException: Address already in use:8080

Address already in use, BindException

If you’ve ever encountered this exception:
java.net.BindException: Address already in use:8080
there’s a great tool that you can use to determine what application(s) are running on a specific port: lsof

Looking at the man page for lsof, we find the following:


DESCRIPTION
Lsof revision 4.81 lists on its standard output file information about files opened by processes for the following UNIX dialects:

AIX 5.3
FreeBSD 4.9 for x86-based systems
FreeBSD 7.0 and 8.0 for AMD64-based systems
Linux 2.1.72 and above for x86-based systems
Solaris 9 and 10

(See the DISTRIBUTION section of this manual page for information on how to obtain the latest lsof revision.)

An open file may be a regular file, a directory, a block special file, a character special file, an executing text reference, a library, a stream or a network file (Internet socket, NFS file or UNIX domain socket.) A specific file or all the files in a file system may be selected by path.

Instead of a formatted display, lsof will produce output that can be parsed by other programs. See the -F, option description, and the OUT-PUT FOR OTHER PROGRAMS section for more information.

In addition to producing a single output list, lsof will run in repeat mode. In repeat mode it will produce output, delay, then repeat the output operation until stopped with an interrupt or quit signal. See the +|-r [t[m<fmt>]] option description for more information.


To use it, type the following:
lsof -i:<port>
So in our case, we attempt to bind to port 8080, so running:
lsof -i:8080
Gives us an output like the following:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
MyApp 50845 dustinkendall … … … … … …

To kill the process, type:
kill <pid>
So in our case:
kill 50845
This will help you get past the java.net.BindException and allow you to bind to that port.