To provide motivation for the next option, let's look back at our source directories.

Earlier, we noticed that upon compiling,

our class files were placed in the same directory as our source files.

Here we see Cheese.class right next to Cheese.java, and

Main.class right next to Main.java.

Now, since we're developers, chances are that we're creating software

that will be distributed and installed elsewhere.

What we'll distribute though, are the .class files not the .Java files.

We will code the .Java files and the compiler will produce the .class files.

In an effort to preserve this separation of concerns and

keep our directories tidy, let's stick the .class files elsewhere.

We can accomplish by using another command line option, the directory or

-d option with the javac command.

Now, if you've already switched to an IDE such as IntelliJ or

Eclipse, you've noticed that those IDEs automatically create a directory for

you that contains the .class files.

Likely it's named bin, short for binary.

Out, short for output.

Or build, referring to compiling, or building, our application.

Let's create one now called out, and put all of our .class files there.

So, I'll right-click on the workspace directory and choose New Folder,

and name it out, all lower case.

Great, before we compile to the out directory let's be sure to delete our

existing .class files so we can ensure new ones are created in the out directory.

Now we're ready to compile to the out directory.

To do this after javac, I'll specify the directory option using -d and

tell the compiler to use the out directory as the destination for our .class files.

Again, we won't forget to specify our class path.

If we refresh the out directory, we will see our new class files

that were just generated as a result of our compiler statement.

Let's check it out.

If we drill down all the way to the override folder.

There is Cheese.class and Main.class.

This is really nice as it keeps the directories of our source code clean.

We're not littering them with files that we'll never directly edit.

Now if we'd like to run the application,

we'll specify the class path as the out directory.

java -cp is the out directory, and

com.teamtreehouse.override.main is the class that we'd like to run,

and there's our output again.

Cool!

From now on, any time we want to compile from the console,

we'll definitely use this approach to keep our directories organized.

Let's check out one more command line option while compiling.

You can ask the compiler to give you more information than what it does by default.

When you compile using the javac command,

you're going to be told mainly about errors.

That is, things that will prevent your code from successfully compiling.

Beyond errors, you can ask the compiler to tell you about warnings,

much like we saw with the deprecated annotation.

For this, you'll need to add a command line option.

In general, you'll add what's called the -Xlint option.

Lint is an old term that meant to flag suspicious behavior in your code before

you compiled it.

That seems to make sense here too.

Let me add a statement to the Main class,

and I'm sure you'll be able to spot the problem even before compiling.

Clear my console and let me add this statement here.

Let's see what happens when we compile and run this code.

Compile the code and it looks like we have no compiler errors, so

let's run this thing.

We get our output, but then we get an error or exception.

And we see, even if we don't understand all the gibberish that's here,

we see that it's a / by zero error.

And you already knew that was going to happen.

Let's add the excellent option to compilation to display all earnings and

see what happens.

In order to do that, while compiling we'll use the -Xlint option,

don't forget to capitalize that X.

Specify the out directory as the location for our .class files.

Don't forget our class path and the full path to

Main.java.

A warning, it's a warning for a / by zero error.

Hey, remember earlier when I said that any opportunity we get to catch an error while

compiling, as opposed to while our app is running, is an opportunity we'll take.

Yep, here it is again.

And that's what the -Xlint option can do for you.