Viewers: in countries Watching now:
Join author David Gassner as he explores Java SE (Standard Edition), the language used to build mobile apps for Android devices, enterprise server applications, and more. This course demonstrates how to install both Java and the Eclipse IDE and dives into the particulars of programming. The course also explains the fundamentals of Java, from creating simple variables, assigning values, and declaring methods to working with strings, arrays, and subclasses; reading and writing to text files; and implementing object oriented programming concepts.
So far in this course, I've been creating applications where every class was placed in the root folder of its project, but Java developers very seldom actually do that. Most classes in a Java application are placed in packages or subfolders of the project. Because of the way Java application is structured it could have dozens, hundreds or even thousands of classes, and as an application gets larger it's very important to organize these classes into groups. We call these groups packages but they represent actual physical folders on disk.
I'm going to start by creating a sub package to store my helper classes. I'm working in a version of the Calculator application where all of the classes are stored in the root folder or default package and I'm first going to create a custom package and then move my helper classes into it. I'll go to the default package in the package Explorer view, right-click and choose New>Package. Initially, I'm going to use a shallow package structure meaning that each package will be just a subfolder of the root.
So I'm going to call this package, helpers. Now, when I create a package in Eclipse, I am actually creating a physical folder on disk as well. Next, I'm going to move my helper classes into the helpers package. I'll do this one at a time. I'll start with InputHelper.java, I'll right-click on the file and I'll choose Refactor>Move. I'll select my new helpers package and click OK. The file is moved into the package and a couple of changes are made to the code.
First of all, in the InputHelper.java file, a new package declaration is added to the top of the file. This is a requirement in Java. When a class is anywhere but the default package, it has to be declared that way in the code. The syntax is the keyword package and then the name of the package ending with a semicolon. Also, in the main application, where I am using that class, a new import statement has been added to the top of that code. Once again, this is a requirement. If the class isn't a member of the same package as the one that's calling it, then it has to be imported.
In this case, I am referring not just to the package but also the class name, helpers.InputHelper. Now I'll move my second helper class. I'll go to MathHelper.java in the package Explorer, right-click and choose Refactor>Move and once again, I'll choose the helpers package and click OK. My main application now has imports for both helper classes and both InputHelper and MathHelper have the package declaration. I'll run the application, I'll click the Run button and if prompted, I'll choose Java Application.
I'll enter some values and an operation and everything is working just fine. So organizing your classes into packages doesn't do anything to change the functionality for application; it just gives you a way of organizing the code so you can find it more easily later on. In large scale Java development environments package names typically are structured using a prefix of the company's domain in reverse domain order. So for example, if a company is named lynda.com then you would start off with a package prefix of com.lynda.
The reason to do this is so that you can eliminate any possible conflicts with other classes in the Java environment. Remember that Java compilation doesn't create a single monolithic file. Instead your runtime application consists of a whole bunch of compiled classes and it's up to the JVM to figure out which classes needed at runtime. By using reverse domain notation in your classes, you guarantee universal uniqueness. So I'm going to do a little bit more refactoring. I'll go to my default package and once again I'll add a new package, and I'll name this package com.lynda.calc.
So I start off with the domain name first and then something to say which application I'm working on. You can add more levels to your packages, it's up to you. I'll click Finish, then I'll go to my Calculator class, I'll right click and choose Refactor>Move and I'll choose com.lynda.calc. Notice that because I have dot notation, each of these is seen as its own individual package. I won't be placing anything in com or com.lynda; those are just prefixes for the way I am organizing my code.
But my main class will go in this calc package. I'll click OK and my source code file is moved and I'll look at my code and I'll see that the package declaration has been added at the top of the code. Next, I'll rename my helpers package, I'll right-click, I'll choose Refactor>Rename and I'll change the package name to com.lynda.calc.helpers. I am still distinguishing this package from the package that contains my main application and keeping all my helper classes in their own unique package.
But they're all deeply buried now in my uniquely named primary package. This time I'll choose Preview and show you that Eclipse can show you what your code will look like before and after refactoring. I'll click OK and the change is made. My main application still has the imports for the two classes, InputHelper and MathHelper. If I prefer, I can change these and just put in an asterisk and take out the second import, and this now means import everything in that package.
If you have classes in the package that you're not using that's okay; it won't affect performance. But note that if you use the Organize Imports tool in Eclipse that's the tool that kicks in when you press Ctrl+Shift+ O on Windows or Command+Shift+O on Mac, Eclipse will convert from an asterisk , a wildcard import to explicit imports for each class that you're using. That's the preferred approach for Java development because it helps you know by looking at the top of your code exactly which classes are actually in use in your application.
I'll go take look at the InputHelper and MathHelper classes and I'll see that the package declarations have been modified there. And finally, I'll save everything and run the application again and make sure I haven't broken anything. I'll enter the numeric value and another numeric value and this time, I'll multiply and I get back a correct answer. So, organizing your coding packages is a good thing to do. As your applications become larger and more complex and you have more and more classes, you'll find organization of your classes through packages to be invaluable.
Find answers to the most frequently asked questions about Java Essential Training (2011) .
Here are the FAQs that matched your search "" :
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.