I am a complete beginner when it comes to Java. I recently picked up Head First Java and it says: "Put a class in a source file. Put methods in a class. Put statements in a method." When I open eclipse i started a new project called helloWorld, this created a project with a src folder(guessing this is the source file?), i then followed an eclipse tutorial from their website and it stated that i needed to first create a project, then a package, then a class in that package. What is the difference between a source file and a package?
A package more-or-less equates to a directory under your "src" folder in this case. Examples might include "com.project.ui" or "com.project.models" (and so there would be a "com" directory inside "src" and inside "com" you would have "project" and so on).
A source file is just that--it's an individual file that will live in one of those packages, probably named as "MyClass.java" where "MyClass" corresponds exactly to the name you give the one public class that the source file should contain.
BTW, if you will build your code with Maven, you should follow the suggested Maven directory structure--see this. In the case of Maven then, your java packages would start under "src/main/java" rather than under just "src" which is maybe what Eclipse will assume you want by default.
EDIT: Also take care to align the package you declare at the top of your Java source file with the package that it actually "lives in" on your filesystem--it's essential that these be in agreement. So, if your "MyClass.java" lives on the filesystem in com/projects/models, your package statement at the top of "MyClass.java" must be "package com.projects.models;" By convention package names will be all lowercase, class names will be upper and lower ("camel case") starting with a capital letter and method names start with a lowercase letter, but then are also camel case.
The following is a java source text:
package org.apache.twinkle;
public class Elfie {
...
}
It resides under a sources directory (generally src), and has a file path:
org/apache/twinkle/Elfie.java
(Directories org, apache, twinkle and file Elfie.java.)
So a package indicates some hierarchy and corresponds 1:1 with a directory.
The source file has a .java extension.
Paths should be case-sensitive. Package paths are hierarchical and generally follow the convention of starting with a reversed URL.
http://mit.com
package com.mit.mathlib.graphs;
http://univ-abu-dabi2.net
package net.univAbuDabi2.linguistics;
import com.mit.mathlib.graphs.GraphUtils;
Source file is complete Java code.
Package gather a several Java file under some issue like: GUI, server, login and etc.
Try to create several package and then go to the workspace to see what you got.
Also, when it comes to package issues, you also have the 'package' definition for class variables, which means that you are able to use this variable from other classes in the same package.
Related
I'm working through the example here:
http://www.vogella.com/articles/JavaPDF/article.html
In my file, I've got:
package com.mycompanyname.mydirectory;
import com.mycompanyname.OneOfMyClasses;
import com.itextpdf.text.Document;
...
public class MyClass {
...
}
Everything is working fine. What I don't understand is that since I just copied the import statement directly from the link above for the iText portion -- why does com.itextpdf.text.Document work?
I mean, if I look in directory com.mycompanyname I can see OneOfMyClasses.java there.
But in the com directly, there is no itextpdf directory (although maybe my user doesn't have permission to see it(?)).
Hoping someone can help me understand what I'm missing here. Doesn't the import point to a specific directory that I should be able to see the class? Is there a different com directory somewhere that iText is using, and com.itextpdf.text points to there? (if so, where's the directory located)?
I installed the jar file for iText in the lib folder as per usual, and made sure it was included in the classpath.
Those classes are inside a JAR file that is added to the classpath:
Create a new Java project "de.vogella.itext.write" with the package "de.vogella.itext.write". Create a folder "lib" and put the iText library (jar file) into this folder. Add the jar to your classpath.
import statements will look inside whatever directory trees are in the classpath, which includes the current directory at compilation time (tipically the src/ directory in your project) as well as any directory specified through environment variable or JVM startup parameter. See this about the classpath.
EDIT
You do need the imports whenever you use classes across packages. Every public class/interface you define is in a package. If whatever you are referencing belongs to another package, you need to import it.
JARs are zip files that contain directories and files inside. It's the same as plain directories and files, only packed.
It comes from the iText dependency (jar) you added in an earlier step.
Not necessarily - you could also import from libraries, etc.
In fact, Java will try to search through the classpath. Here is some helpful documentation.
That class is most probably imported in a JAR library. Inside such JAR file, the class files are kept in exact package/folder structure as you use when importing them.
I've been searching for answer for my problem but I can't find some relevant information, so I'm asking. I've directory which contains thousands of Java classes with source code (*.java files). Each of those files contains information to what package the file belongs, its classnames + code itself of course. I need to find some function of the Eclipse IDE (or maybe of another IDE) which is able to reconstruct packages under the 'src' directory based on the information in the class files and bring to me a good Java project structure so the restored packages and its classes can be easily imported into a new Java project then. Creating the structure of packages manually would take me (maybe) lot of days...
For clarification:
I have:
directory which contains: 1.java, 2.java, 3. java, n.java...
I need:
directory which will contain:
[src] -> [package_1] -> [1.java, 2.java, etc...]
...
[src] -> [package_m] -> [3.java, n.java]
I think this must be possible somehow as the each class file contains information to which package it belongs actually.
Just if you find no better solution: At least you can import all sources into a project in Eclipse and have Eclipse move each file to the right package by means of using the quick fix for each problem. You still need to press 3 keys per wrong package declaration, but it saves you from fiddling with files and folders.
I would like to know What are the difference between folder-structure and package used in Eclipse IDE for Java EE development.
When do we use which one and why?.
Whats should be the practice
create a folder structure like src/com/utils and then create a class inside it
create a package like src.com.util and then create a class inside it
which option would be better and easy to deploy if i have to write a ant script later for deployment ?
if i go for the folder-structure will the deployment is as easy as copying files from development to deployment target ?
If you configured stuffs correctly. Adding a folder inside src, is same as adding a package from File > New Package.
So, it's up to you, whatever feels comfortable to you -- add a folder or create a package. Also, when you put stuffs under src the package name starts from subfolder. So, src/com/naishe/test will be package com.naishe.test.
Basically there is no difference, both are the same.
In both the cases, the folder structure will be src/com/utils.
and in both the cases, you will need to mention
package com.utils;
as first line in the class
Since it doesn't have any difference practically, it won't make any difference to ant script.
"Packaging helps us to avoid class name collision when we use the same class name as that of others. For example, if we have a class name called "Vector", its name would crash with the Vector class from JDK. However, this never happens because JDK use java.util as a package name for the Vector class (java.util.Vector). So our Vector class can be named as "Vector" or we can put it into another package like com.mycompany.Vector without fighting with anyone. The benefits of using package reflect the ease of maintenance, organization, and increase collaboration among developers. Understanding the concept of package will also help us manage and use files stored in jar files in more efficient ways."
check out http://www.jarticles.com/package/package_eng.html for more information on packages
create a package like 'src.com.util'
That sounds like a mistake. The package name should be 'com.util', and 'src' is the name of the source folder.
Other than that, I fail to see what the difference is between your two choices. The result is the same, right? Just different steps in the GUI to arrive at it. The wizard to create a new package in Eclipse is just a wrapper around creating the appropriate folder hierarchy within a source folder.
You don't need to create empty packages at all, you can directly create classes (the package will be created automatically if it does not already exist).
A package is automatically "source folder" where folder is just a normal folder.
When you compile an Eclipse project, all files in source folders are compiled but not in regular folders (unless those regular folders a)
folder structure or to be specific source folder in eclipse is meant just for eclipse but package is universal irrespective of any editor..
When we create a simple android app, we can find MainActivity.java in src/com.app.main and R.java in gen/com.app.main (Also, you can define another file or package name, but the format is similar). and from all the indication i found in the code, it seems that src/com.app.main && gen/com.app.main means the same package. why? IMO package is only a folder, and MainActivity.java is in the folder src/com/app/main, R.java is in the folder gen/com/app/main, obviously two different folders, and i think that two different folders mean two different package, anything wrong?
There are two thing one is Java package name in src/ and second is android app package name. The folder structure in gen is generated based on the package name defined in the manifest file.
These two could be different also, in that case you will import R with appropriate package name appended to it in the Java files.
First of all, package is not a folder. Source file belongs to the package indicated by the package clause at the first line of that file. Creating folder structure that corresponds to the package structure is just a convention.
Secondly, when mapping folders to packages folders are treated as relative to their respective base source folders. In your case there are two source folders: src for your sources and gen for generated sources, and both folders contain subfolders that correspond to the same package.
First of all: I'm not entirely familiar with Java, and the few things I know I have learned while playing with Java.
However, there is something I have noticed in pretty much any Opensource Java project - the use of alot of subdirectories for the sources, which usually look like so:
./src/main/java/com/somedomainname/projectname/sourcefile.java
Now, why so many subdirectories? what's the deal with the domainname?
The domain name is used for the package name - so that file would be for the class
com.somedomainname.projectname.sourcefile
where com.somedomainname.projectname is the package.
Conventionally, source file organization mirrors the package layout. The normal Java compiler doesn't actually enforce directory structure (although some IDEs such as Eclipse will complain if you put things in the "wrong" directories) but it does force public classes to be in a file with the same name. Non-public classes can go in any file, but conventionally the filename matches the class name there, too. It makes it very easy to navigate to any class without any prior knowledge.
The Java language specification doesn't say that a compiler must enforce the convention for public classes; it explicitly says that it can though. See section 7.2 of the JLS for more details.
This directory structure is used as a convention that shows where the library is from and separates it from other sources.
One reason to use this structure is that is the standard used by Maven.
Maven is a build tool that helps to manage the dependencies of a project. Maven is designed for convention over configuration, so you will often see this directory structure to make it work with Maven.
Maven specifies that the directory structure start with /src/main/java for Java files, and the rest is based on the naming convention for namespaces.
The use of the domain name in the path is to prevent class collisions. If 2 different libraries both supply a class with the same name, the domain name namespace allows them to both be used.
A Java package is a mechanism for
organizing Java classes into
namespaces similar to the modules of
Modula. Java packages can be stored in
compressed files called JAR files,
allowing classes to download faster as
a group rather than one at a time.
Programmers also typically use
packages to organize classes belonging
to the same category or providing
similar functionality.
...from http://en.wikipedia.org/wiki/Java_package
subdirectories as an organizational tool so that you don't just have one directory with tons of java files. The reason you often see a domain name is that conventionally people derive java package names from their domain names in order to prevent collisions with other developers. So although we both might have a util.Stringutil class, if I name mine com.mydomain.util.Stringutil and yours is com.yourdomain.util.Stringutil, we can have a project containing both classes without a collision.
There is an interesting read on java packages and directories in the newer O'Reilly book Java: The Good Parts (starting at the bottom of page 46).
...the required interaction between the package system and the filesystem
is both regrettable and a pain...
This is meant as a standard to define unique locations for java source code. It is convention to follow this package structure, which is why you see it everywhere. It's not required to do it that way - you can name your packages whatever you want. It is very commonplace to follow this convention, however.
package prefix.organization.project.ClassName;
package prefix.organization.project.package.ClassName;
package prefix.organization.project.package.subpackage.ClassName;
When storing Java source code files, each part of the package name translates into a subdirectory. So the same three classes shown above would be located in the corresponding directories off the main classpath.
prefix/organization/project/ClassName.java
prefix/organization/project/package/ClassName.java
prefix/organization/project/package/subpackage/ClassName.java
When compiling by hand, be sure that the main classpath directory is the current directory or is within the classpath in order that the source code files can be found.
As for the src/main/java part of it, it seems this comes from Maven. I've never used that software. I don't understand why they would need so many, since my projects (I use Eclipse) just have a src folder there instead.
./src/main/java/com/somedomainname/projectname/sourcefile.java : Decomposed
src/main/java
this is the directory that needs to be passed to the javac compiler stating where the source code for compilation can be found.
1.1 src/test/java
this is where the unit test classes should be kept.
1.2 src/main/resources and src/test/resources
these are the corresponding directories where resources such as properties files should be kept.
1.3 Separate output directories.
main and *test * classes and resources should be compiled to their own separate output directories. Maven uses target/classes and target/test-classes. When you jar your compiled class files for distribution, you don't want to include test classes and test resource files.
com/somedomainname/projectname
this directory structure corresponds to the package declaration in the classes found in projectname i.e. package com.somedomainname.projectname
SourceFile.java corresponds to the class name that it defines, and it should by convention start with an uppercase character see http://www.oracle.com/technetwork/java/codeconvtoc-136057.html
Also in the link above you will find out that the default package naming convention uses the domain name in reverse.
The Java Language Specification defines a package naming convention that says that package names should include a domain name, as it provides a globally-rooted namespace.
The source files need to be in subfolders that match the package name, because the Sun Java compiler, javac, enforces strongly encourages it. Additionally, many other build tools and IDEs also either strongly encourage or require that the source .java files are stored in paths that match the package.