So in the previous video, we actually discussed some conventions for
naming packages.
But we haven't actually looked at what a package is yet.
If you think back to the abstraction challenge, which is now a few videos ago,
I actually suggested that you didn't call your link list class,
the one that you are creating, your own link list class.
I suggest you didn't call that link list because that is
the name of the link in this class that actually comes with Java.
But with that said, that was only a suggestion
because it may have actually caused a little bit of confusion.
So there isn't actually a reason why you couldn't have used the name link list,
even though Java's already used that.
So I'm just gonna open up a slideshow and just talk briefly about a few things.
So firstly, talking about packages.
Things to keep in mind that there's over 9 million Java developers worldwide.
So classes or interface name conflicts are going to be inevitable because the thing
to remember is that people are going to use common words, so it's highly likely.
That you're going to find these conflicts.
So as a result of this, Java were pretty well forward thinking.
And there was a mechanism that was actually needed to fully
specified the class.
And as a result, to allow use of classes with the same name in the same project, or
even the same class itself.
So let's get back to code and talk about that a bit more.
So what we're gonna do is just type a bit of code here just to show how these
packages actually work.
To start with I'm gonna actually type Node node = null, like so.
And as you've seen it before in the course Java's gonna come up and say,
I've got some options for you.
So if we select that, And
look at all these different options that actually come up.
There's actually nine there, so there's actually a ton of different options
that Java is actually recommending with the word null in it.
So because this lecture is all about packages,
you've probably guessed by now that the mechanism I'm talking about
To make sure that people can reuse nodes is actually called packages.
So a package, think the package is a way of grouping related classes and
interfaces together.
So the actual package mechanism provides a way to manage the name space
of object types and it also extends access protection.
Beyond the traditional access, modifies you see,
before and public, protected, private, etc.
So we'll actually be talking about access in the next lecture, not here right now.
So I've actually seen this come up before.
When this does pop up on the screen, The normal response has been to import
the appropriate package, so we go down and actually select the appropriate package.
And obviously at the moment we've got an error.
So if we go down here and actually choose, say, Java X.c.node,
which is one of the nodes that obviously gets rid of the message.
And then automatically,
as you can see here on line 3, The import line got added to the start of the line.
Now that's just one option.
That's one way of doing it.
There's actually another option that you can use instead of using these imports.
So we could actually delete that again, delete that out.
And obviously that brings up the same error again.
And instead of actually importing, we could come up here to the start of Node,
and we can actually type in javafx.scene.
.Node.
And you can see at that point, that Java's now happening and
intelligent's happy because we've actually specified the actual package
that contains the node class that we wanna actually work with.
Now the important difference here is, unlike the first situation just a minute
ago When we saw the Import to Stack come up on line three.
In this case, the package is not imported.
So what that means is every time you wanna reference this node,
you actually have to type it out.
So you can see how that would really get tiresome really quickly,
having to type javaeffects.send.node, and doing that for
all your classes as you're actually using them.
Now, if you're actually using two different node types in the same class,
then you actually have to refer to one of them that way.
So if we try to import the same class in two different packages,
Java's gonna give us an error when we try to compile.
So, if we actually wanna put our imports and we decide to actually use the imports,
we do something like import javafx.scene.Node, the first one.
And we try to import a second one, org.w3c.dom.Node.
Notice the error there already, and
then even if we actually come along and put org.w3c.dom.Node,
another Node, We've already got an error here and
it says javafx.scene.Node is already defined in a single-type import.
So, we've actually already used Node essentially,
so IntelliJ in Java is not gonna allow us to do that and get away with it.
Even if we're qualifying our classes with the full what is our package for
that class.
So what we could do then is therefore with the first statement,
we could get rid of that package.
And just use the normal reference.
So if I come along here and
leave that as mode now and I temporarily comment this out.
And we'll get rid of that second one.
I just wanna show you another by of doing things.
So with that method, we can then come along here and
we can un-comment that, and that's going to work fine at that point.
So one of them is using the import, and the second one is using the fully
qualified name pointing to the actual packages that actually got node.
But noting again that we can't help you have two imports, so
if you put the import up here.
all.w3c.dom.node, We're gonna get an error on the second line and then Intellius
starts trying to help us cuz it's a little bit unsure as to which import to use.
So we're gonna delete that like.
So in summary, the javafx.scene.Node can be Be referred to as node,
as you can say in the code on line ten.
But the second one,
the org.w3c.dom.node has to be fully qualified whenever it's used.
And you're actually free, obviously, to actually use the full name for
both of them.
And that can actually make it clearer as to which one you mean.
So in other words, you can actually come up here and paste that into there.
Oops, there.
And use both and
obviously you can see intelligence actually got rid of the imports.
Now, in terms of those imports, just to be clear, some of that's happening
automatically because of the way So I've actually configured the editor.
So I want to go into IntelliJ and go into preferences.
Now if we go to editor, and there's a couple of ways of doing this actually.
What you can actually do, I'm not sure if I've actually mentioned this to you before
but you can click on a particular section.
And you can do a search.
And it will actually give you a shortcut.
So I can type in import cuz that's the thing that I wanted look at And
it will actually point out where that is.
So this case it was under general, editor general auto import, so
that's actually the one I wanted.
So if I go there just to show you the options I'm talking about,
you can see that we've got some options for our imports.
We got the Show Import pop-up,
Optimize Imports on the Fly, Add Unambiguous Imports on the Fly.
We can actually exclude from import and completion if for
some reason we didn't want that to happen.
But the one I actually want to talk about is optimize imports on the fly, cuz that's
the one that's actually adding and then deleting imports as our code changes.
I actually like to have that option on.
The reason for that is that It just cleans up your code.
If you're not longer using an import, the intelliJ's automatically deleting those
and it just makes your code a little bit cleaner.
So I would suggest that you have the options for
import intelliJ set that I've got on here.
And there are also other languages, you've got similar options there
to actually set for different languages depending on what you set up, but
planes are actually got to intelliJ.
So I'm gonna leave that option there then the any other one here was ask.
If you're pasting in a block of code, IntelliJ will come up and
ask you which imports.
That can be a good idea to do as well, so I suggest you leave that on ask.
So I'm gonna cancel out of that cuz I've already got my settings set.
So basically you can see now, if we've got more than one class.
Of the same name, it can get a little bit confusing.
Well, there's more work to do to make sure you know which one you're referring to.
You either have to use one import,
then refer to the second one with the same name.
Well, it's fully qualified name, with the actual package name.
Or you need to just use all the references and
actually have the fully qualified name, whichever you wanna do.
So, let's go back to our slides for a minute.
Now you might be asking now, why would I want to use packages?
Well, some of the reasons that you actually want to use packages
is that it makes it actually easier for
programmers to determine that classes are actually related to one thing or another.
Another great reason is it's easy to know where to find the classes and
interfaces that can provide the functions provided by the package.
Cuz they're all sort of in the same group if you will, the same package.
And the other important thing is because the package creates a new namespace
the class and the interface name conflicts are actually avoided as result of that.
Because they're actually in their own separate area.
Which affects, which is what that namespace is,
it's sort of a different area that all these classes and
interfaces are actually sort of put together or placed together.
And importantly, classes within the package, that they create,
have unrestricted access to one another while
they still restrict classes to outside the package.
So, that's another sort of very important reason why you'd actually want to use
packages.
So, let's go back to our code again.
Now you may or may not have been aware of it but
we've actually been using packages throughout this course today.
One example is Java.utool.scanner.
And you've seen that in many programs and
that's the code that actually provides the ability to accept user input.
We've used that in quite a few previous videos.
There I've also important java.util.ArrayList, and
we use that in order to use array lists in our programs.
And of course we've used array lists and other lists quite extensively so far.
So basically, it's actually impossible to create a Java program without using at
least one package.
And java.lang, for example,
contains the class object that is used to support our classes as well as Integer and
Double, etc, and all the fundamental building blocks of a Java program.
So, that happens automatically when you create even the most basic Java programs.
Now, you will actually not see an import for
java.lang Because it's automatically imported for us.
You could import it.
You can import, let's say for example you want to use an integer you could come
along and you can actually type import java.lang.Integer, like so.
And it's actually been removed automatically because of those
optimization settings in IntelliJ.
But my point is you could do that.
But they're automatically,
for this base Java.link package, they're actually automatically imported anyway.
It's not something you need to worry about.
Just in case you're wondering where will that code comes from,
Any of the basic stuff like classes, and as I said, integer double.
They come from Java.ling.
Now before we actually create our own packages, which we're going to be doing,
it's probably worthwhile to have a look at some of the other ones that are included
when you actually install the Java software development kit.
Okay, so what I'm going to do at this point now is create a new project.
And we're just gonna go through a bit of a demo to solidify our understanding.
So I'm going to type in select new project,
select Java, create project from template, making sure command line app is selected.
I'm gonna call this one Win Demo, it doesn't really matter what we call it.
But I'm actually gonna type this one as com.example.awtSample.
Now the com.example could just as easily have been com.
But we're just gonna use ours as example.
Click on Finish.
We're gonna use this window because we've got the other project open, to close that.
So I've only got this one opened.
And what we're going to do then is, we're going to leave this main class.
We're gonna create a new one.
So we come up here into source and into our package.
Add new Java class, we're gonna call it My Window.
And for that one, what we're going to do is we're going to write a bit of code that
actually draws something on the screen.
So we'll type extends frame, Frame is a java.awt as you can see there.
And those having pull went through straight away.
And we're gonna create a constructor, and it's going to accept a title as well.
We got Frame which accepts a title and
title is gonna show on the little window that pops up.
So we're going to use that constructor.
And if you want, we'll get rid of this throws HeadlessException because you don't
actually need that.
That's just added by default by IntelliJ.
So we're gonna set the size of the window, set size 500, 140.
We're going to add a window listener.
And I'll talk about these shortly, what they actually do, new window.
Adapter and window closing is the one we want.
It's asking is which one do we wanna override.
We wanna override window closing to do something when it closes.
I'm gonna click on that.
And you can see it's automatically come up with that code for us.
I'm gonna change the super.windowClosed, and actually put System.exit.
And essentially what we're doing there is we're just
saying if you click on the close button in the window,
it's actually hard override the standard function, and actually close down the app,
which believe it or not doesn't happen by default.
and just a general
note here we're going to put a
screenshot on the screen there now so
instead of using window closed we should
really be overriding window closing
otherwise the application will keep
running in the background now window
closed well that's called when a window
has been closed while window closing is
called when a window is in the process
of being closed now in an ideal world it
would probably be better to use jframe
and swing utilities dot invoke later
when creating a frame but I haven't
really worried about it too much here
because this is really meant to be just
a simple example and we're not really
talking about swing at this part of the
course alright so back to the code
We also want to override another one, which is paint.
So this is a method that that's actually called
automatically to actually draw the screen.
So I'm gonna need to leave the super.paint in there.
And this is only three lines of code here just to show, basically,
how these packages work.
So, I'm gonna create a font, sansSerif(Large
= new Font Type is important there.
You need to get the correct upper and lowercase.
It'd be Font.BOLD, 18, size 18.
Now just to be clear, the exercise is about packages and
not about using the actual graphical side of Java, just to be clear.
But we'll continue on.
sansSerifSmall = new Font, SansSerif again,
and it'll be Font.BOLD, this time a size of 12.
And we need g, which is the graphics object that was passed to this method
setFont, and we sansSerifLarge, initially.
And then I'm going to g.drawString which is a mechanism to
actually draw something on the screen.
And I'm going to put the complete Java Developer course.
And we're going to position it at 60, 60.
Sorry.
Then g.setfont.
SansSerifSmall, choose up drawstring
by Tim Buchella, 60, 100.
You've probably guessed now what this actual program does.
Just to confirm when we actually extended up here,
when we actually extended our frame.
You saw IntelliJ offer some suggestions and I accepted the import, the top one.
Java.awt.frame.
Now I want you to notice that when we actually did that did you notice how
this first import that went through was Java.awt.star.
Probably should have mentioned that a little bit early but
I didn't top it like that.
Whereas in these other things when we use the Windows Adapter and
the Window Event it's actually only imported those.
But with the Java.awt.star automatically.
So we'll have a look at what that means and more later.
But for now, we're going to use some of the other packages, as you can see,
to create a very simple window.
But we use some of the other packages, Window adapter, Window event and
it will create just a very basic window.
So basically, this is just a standard mechanism to enable us to pop up
something on the screen.
So now that we've created that class, we can go back to our main method.
Main class, I should say.
The main method within that and pop this up, so let's do that.
We'll call it MyWindow myWindow = new MyWindow("Complete Java").
And myWindow.setVisible(true).
That's action to code now to actually run it, so we should be able to run this now.
And it should actually pop up there, a little window.
And there's a little example you can see there, very basic.
But it is actually working.
The actual name that I actually signed, The Complete Java Developer Course, and
obviously my name as well.
So what's the point of all this?
Well, if we just go back to My Window again,.
Can you actually imagine having to do this all automatically?
You can see there's relatively speaking considering what's actually happened,
there's actually very little code you actually have to type.
All the infrastructure code to do a lot of this work is automatically in these
various classes, these packages that have been provided by Java.
So writing all this yourself,
writing a window manager something that actually creates fonts, that actually
sets different fonts that will have you to draw things on the screen.
Positioning it up certain places.
That would be huge undertaking to do something yourself.
And it can be months or even years of work, but by using the old package.
We can actually take advantage of the facilities that it's provided for
these programs.
Just in case you're wondering, awt, A-W-T stands for Abstract Window Toolkit.
Now because that package, the awt package, provides everything necessary to
create the GUI interface, we know that we can actually find all the classes and
methods that we need within that package.
And the thing is that if awt needs to be upgraded NEW packages can be deployed.
Rather than having to update files that are scattered around the Java SDK.
So that's why packages are really essential.
They can actually bundle these changes, and
from your perspective nothing really changes.
You're still accessing them via the package,
all the new code is actually happening,
and it's all actually added to the package, making it a fast simple exercise.
For you to actually work with.
So this video's getting on a little bit long now so
I'm going to actually stop the video here.
And in the next video we'll continue on talking about packages.