[MUSIC]
>> Greetings, everyone. Welcome back to
Microsoft's Java for Beginners Series.
My name is Brian Benz,
and I'm a Cloud advocate at Microsoft.
I'm joined by Kirk Pepperdine today.
He's going to talk to us about classes and packages.
Kirk, do you want to introduce yourself
and tell us what you'll be talking about?
>> Hi, Brian. Thanks for having me here.
I'm a principal engineer in the Java Engineering Group.
We're responsible for building and contributing to Open JDK.
In this series, I'm going to look at
the different ways that the JVM loads code into the Runtime.
In the first video,
I'm going to explore the fundamentals.
This presentation is a brief introduction
into the mechanics of Java classes,
Java packages, and how they come together to form
a protocol that is used by the Java Virtual Machines Runtime.
Let's start the discussion by reviewing the features found
in the source code for a simple Java application.
Here I brought up a terminal Window.
As you can see, we have a file here, a Person.java.
Let's open the file.
Looking into the source code,
the first thing to notice is the class declaration.
The class declaration will contain the simple name of the class,
in this case, its person.
The other bits in here are
the fields that we've declared to hold internal state.
We have a constructor which we're going to
call to create a new instance of person.
We have methods, in this case,
we have a single method,
which is a getter which will reveal
the internal state of this object.
At the top, we're going to declare a package name.
Now the package name and
the simple name come together to
create what's known as a fully qualified name.
It's this fully qualified name that is going to form
the namespace in the Java Runtime.
The final feature to look here is the entry point.
This is the main method.
The Runtime is going to be handed
the fully qualified name of a class and through some magic,
which we'll explain in a minute.
It's going to find this main method and,
and it's going to start executing
your Java application from this main method.
Let's unpack some of the magic that
happens in order to get this class executed.
We're going to use javac in this case to create
this person.class file from the Person.java file.
We're also going to need
something else to make all of this happen,
and that's known as a class loader.
How this works is that the execution engine is
going to reference person.class.
The reference is going to go
out to the class loader where it's going to say,
do I have this person.class cache in memory?
Or do I need to go out into the file system and find it?
If I need to go out into the file system and
find it then it's going to
use the fully qualified name to find person.class.
It's then going to lift that class from disk,
and it's going to load it into memory.
Then it's going to make that class available to the Runtime.
Let's experiment with this person class
to see how it all comes together.
What I'm going to do is I'm going to say javac Person.java.
If we look here, it's going to produce this person class.
If we look into the person class,
it looks like it's mostly unreadable.
That's because there's some binary components here.
But there are some features that we can easily pick out.
For instance, if we go down ways,
we can see that we have in the left-hand side
this thing called source file with a carrot A at carrot K,
and then we have Person.java.
The name of the source file was embedded in here.
If we go further along that line we
can see that there's a com/model/Person.
This represents the fully qualified name for this class.
Now to run it,
there's a few things we have to do,
so we're going to recall Java.
I have to tell the classloader
where to go looking for the classes.
In order to do that, I'm going to use this parameter
here known as a classpath.
The classpath will be passed to the classloader so it
knows how to find classes.
In this case, the class is in the current working directory,
and so we're just going to dot that there.
Now I'm going to give it the fully qualified class name.
This is going to run and, boom, we get in there.
Could not find or load the main class com.
model.Person. The file here is named Person.class.
Maybe what we can do is we can just shorten and go off
the fully qualified name and just use the short name
and surely this will load,
but as we see more run it,
we really can't find that class.
The reason why we can't find the class is because the way
that the main classloader work is it's going to
translate the fully qualified class name
into the package component,
which is going to turn into directories in the file system,
and then of course, simple class name,
it's going to create a class file from that.
It's going to be Person.class.
In this case, as we've seen here.
The issue we have here is that we haven't told
the compiler where we want these things to end up.
Let's make a classes subdirectory.
What I'm going to do now is I'm going
to go back to our compilation.
There's our javac. I'm going
to add in a little parameter hearing,
say -d. My output directory for
the compiled artifacts is
going to be well, in this case, the root directory.
We don't want that. We actually
just want the classes subdirectory.
Now, what I'm planning to do,
let's take a look.
You can see that what it's done is
it's done the right thing, the expected thing.
It's actually created a calm directory,
a model directory, and it's dropped the
Person.class file in there.
Now when I run Java,
what's our last version of Java that we wrote here?
Actually, the good one is going to be this one.
We're not in the root directory anymore.
We're actually in the classes directory.
We have the expected output.
There is a requirement that we put the source for
a class in a file that's the simple name dot Java.
If we don't do that,
then we're going to get a different set of errors.
Let's check that out just for fun.
I'm going to vi Person.java.
What I'm going to do is I'm going to very quickly just
change the name of this class to something silly.
I've changed in here to person one.
Then what I can do from this point in time
is just try to compile it again.
Where are we? There we are.
Let's compile Person.java.
You can see that we get the see that person one is public,
and should be declared in a file named Person1.java.
Let's roll back on that particular change.
As we do that, let's start our discussion
into how we can better organize our source code.
The different build tools that
we would use like we're using javac here raw,
but typically you'd use a build tool to compile things
and they will enforce their own structure on you.
I'm just going to come up with
a simple one for the purposes of this example.
I'm just going to do a -p here.
We're going to put it into a source directory com/model.
I'm going to create that,
and I'm going to move the Person.java down into source com model.
Like this. Classes,
I'm going to do in rm minus rf com.
There's no artifacts in there,
so we're perfectly clean.
I'm going to go back to javac.
Where are we? I'm going to say,
so where is that file located?
That's in the source directory com model..
Just as we did before when we run this class,
we're going to get the expected output.
>> Thanks, Kirk. That was great.
Note that this is part one,
there are two more parts to check out for classes and packages.
Also, please check out the rest of
the topics in the Java for Beginners Series.
>> Thank you, Brian.
[MUSIC]