I am making a project named TruckingCompany, there is a package name truckingCompany, and three sub-packages: utilities, means and objects.
Now I have put the class containing the main method into the utilities sub-package.
Is this correct? Should I put it into the truckingCompany package ( in no sub-package)?
So the generic question is: if there is a package, and some sub-package, and the main method uses classes from all sub-packages, is correct to put the class containing it in a sub-package?
PS: Let me know if the question is not clear.
Yeah, you can just put it in truckingCompany. After all, it is your application's entry point.
As a baseline, from what I've seen so far a good practice is to put the class containing the main method at the top-level package.
In your case, I'd put your class under the package truckingCompany and not in a sub-package.
You should put in truckingCompany but it will work doesn't matter where ever you put it
It is absolutely irrelevant where you put your class. More specifically, a package has no special relation to its subpackages. The packages are basically a flat namespace of package names. I would also like to add that there are some conventions to be followed with package names:
You are supposed to use all lowercase letters;
the package name should be derived from an internet domain name that you own: com.truckingcompany.stuff.morestuff.
Related
Just trying to understand why I am able to create String.java file and it is compiled without any errors. As far as I know, the classloader chain will go to Bootstrap classloader and it has already loaded Sting.class.
Could you pls help me in understanding?
A class is not identified by just its name, but by its fully-qualified name, which is the name of the package followed by the name of the class.
If you create your own String class in some package com.myapp, then its fully-qualified name will be com.myapp.String. It doesn't conflict with the standard String class, which has the fully-qualified name java.lang.String.
Of course, it's going to be very confusing when you do this, especially because classes in the package java.lang are imported by default. Therefore, in practice you should never write your own class String, or name any of your own classes the same as classes from the standard library (especially standard classes from the package java.lang).
As highlighted by Jesper, the uniqueness of a class is determined by its fully qualified name i.e., package..
Try importing both the String classes in another class, and you will observe the difference when you will try to use it.
import java.lang.String;
import com.myclass.String;
Now, for resolving the ambiguity, you need to refer a class by its fully qualified name.
I'm running into a problem where 2 classes from 2 different packages (owned by the same group) have the same name and package statement
Package 1
package com.placeholder.constants.Constants
public class Constants{}
Package 2
package com.placeholder.constants.Constants
public class Constants{}
If I'm working on Package 1 but want to reference this Constants class in Package 2, is this even possible?
Cannot duplicate class name within same package
where 2 classes from 2 different package
But they are not two different packages. You’ve used the same package name for both.
want to reference this Constants class in Package 2
Use either:
A different package name
A different name for your new class
You cannot define two classes with the same name in the same package, for obvious reasons.
The purpose of packages in Java is to create a namespace. Your duplicate class name violates that namespace.
Design problems
package com.placeholder.constants.Constants
That is not a proper package name. You’ve mixed the class name into the package name. The package should be package com.placeholder.constants.
This cross-naming problem of yours raises the possibility that you have a less than optimal class design. You might want to pause a moment to look at the bigger picture.
And if you have that many constants to name, I wonder if some of those should really be enum types. See tutorial by Oracle. Tip: In Java 16 and later, enums can be defined locally, within an a method — a new alternative to being defined as a nested class or defined as a separate class.
You are facing a name conflict. If possible, try to enter the full name of the package.class_location
I'm importing a package (in my case, mongodb.DB) into a java file with an identically named class.
In python, I know I can import a module as another name to avoid conflicts. How does Java solve this problem?
It's not feasible to change the name of the class I'm working in.
You say you are "importing a package..." - do you mean you are importing all classes in a package, like "a.b.c.*"? If so, the answer might be to import only those classes you need, not the entire package.
There is no way to import a class as another class.
Hopefully you don't really mean "identically named" as in both of them having the same fully-qualified name. If that's the case, you're screwed, I don't know anything you can do. Hopefully you just mean that the class name is the same in two different packages.
You can extend a class with your own class, and use your new class in the place of the one extended. In other words, if you're importing the class D as in a.b.c.D, and there is another D class, you could extend the first of them (class Z extends a.b.c.D), and then refer to it as Z instead of D. You might need to provide constructors for Z that match ones in D, but no code should be required other than that.
And the fully-qualified names of the classes will always work.
You can use the fully qualified name "mongodb.DB" instead of just the class name.
This is a simple question, but I am really bugged by it. I was trying to find a duplicate, and googled it, but I was more surprised when I couldn't find a satisfying answer.
import java.util.Scanner;
In this statement .Scanner is the class,
.util is the name of the package
What is java or javax or whatever would stand before the first period in general?
UPDATE:
I also found this picture:
http://www.javatpoint.com/package
Is it true?
Per the JLS 7.1:
The members of a package are its subpackages and all the top level class types (§7.6, §8) and top level interface types (§9) declared in all the compilation units (§7.3) of the package.
For example, in the Java SE platform API:
The package java has subpackages awt, applet, io, lang, net, and util, but no compilation units.
The package java.awt has a subpackage named image, as well as a number of compilation units containing declarations of class and interface types.
If the fully qualified name (§6.7) of a package is P, and Q is a subpackage of P, then P.Q is the fully qualified name of the subpackage, and furthermore denotes a package.
So you can glean from that:
java is a package with no classes, only subpackages.
util is a subpackage of java whose fully qualified name is java.util.
util does not denote a package, java.util does.
"I also found this picture: ... Is it true?"
Yes, util is a subpackage of java. However, util is not a package. java.util is a package.
You can think of packages as a directory structure, if you wish, where each subpackage is a folder inside its outer package. So there would be a "folder" java and, inside that, another "folder" util. A package is denoted by its fully qualified name ("full path") so java is a package and java/util is a package. /util is not a package. But packages represented by a directory structure is not a spec. It is only a common implementation. It is up to the host system to decide how packages are stored (JLS 7.2).
Classes in Java are identified by a fully qualified name consisting in a concatenation of the package of the class and the name of the class (and any outer classes, if any). In general, in an import statement like:
import foo.bar.baz.MyClass;
everything except the last dot-separated field is the package name (foo.bar.baz) and the last field is the class name (MyClass). In your example, java.util is the package name and Scanner is the class name.
The process is actually a bit more complicated, as inner/nested classes and interfaces may be involved, but you get the idea.
import java.util.Scanner says.
Look in the package java.
Within that look in the package util.
Within that find the class Scanner.
Now whenever we use the name of a class/etc within this java file (for example Scanner s = new Scanner()) then the class found by the import will be used.
Alternatively you could not do the import and do java.util.Scanner s = new java.util.Scanner() but you can see how that would quickly become unwieldy, especially if you use it in a lot of places within your file. Imports are just a handy way to reduce repeatedly specifying which version of the Scanner class you mean when you refer to Scanner.
A few points:
the package name is java.util, not util. "java" is just part of the package name.
package names are any series of valid java identifiers separated by dots, AbC123.XYZ.foo is a valid package name
package may be omitted. If absent, the class is in the root directory of the project (I once worked on a project in production that had no packages! Everything was in one directory... Yikes!)
by convention, packages starting with java are part of the JDK (plus extensions). There is nothing in the language that specifies this or enforces it
java and util are names of nested packages. java.util is a path to final package.
They are directories inside rt.jar file.
rt.jar file is a zip archive, you can view it with 7-zip program.
Scanner is a Scanner.class file inside java/util directory inside rt.jar
import java.util.Scanner directive just allows you to use Scanner class name in code without specifying full path to it.
import java.util.* directive allows you to use ALL class names in java.util without a path.
import static java.util.Scanner.* directive allows you to use ALL static members inside Scanner, without a paths. But there are none.
List of all packages in JRE are here: http://docs.oracle.com/javase/7/docs/api/overview-summary.html
1) java is a package. (also represents a folder in file system).
It is directly in the classpath, so it is referenced by your program as 'java'. (subfolder in java folder)
2) util is a package inside java package (hence referenced as 'java.util').
3) Scanner is a class inside util package (hence 'java.util.Scanner')
You can have as many nested packages as you want like 'mypackage1.mypackage2.mypackage3. ...' and so on, as long as mypackage1 is in the classpath.
Hope this helps
the import statement represent a hierarchy
import java.util.Scanner;
java is the package
util is the subpackage (inside java)
Scanner is the class (inside util)
import java.util.*;
The class name could be subtituited with an asterisk,
and that means import all classes in the mentioned subpackage.
I have a file Test.java and the following code inside it.
public class Abcd
{
//some code here
}
Now the class does not compile, but when I remove the public modifier , it compiles fine.
What is the reasoning behind Java allowing us to compile a class name that is different from the file name when it is not public.
I know it is a newbie question, but I'm not able to find a good explanation.
The rationale is to allow more than one top-level class per .java file.
Many classes—such as event listeners—are of local use only and the earliest versions of Java did not support nested classes. Without this relaxation of the "filename = class name" rule, each and every such class would have required its own file, with the unavoidable result of endless proliferation of small .java files and the scattering of tightly coupled code.
As soon as Java introduced nested classes, the importance of this rule waned significantly. Today you can go through many hundreds of Java files, never chancing upon one which takes advantage of it.
The reason is the same as for the door plates. If some person officially resides in the office (declared public) his/her name must be on the door tag. Like "Alex Jones" or "Detective Colombo". If somebody just visits the room, talks to an official or cleans the floor, their name does not have to be officially put on the door. Instead, the door can read "Utilities" or "Meeting room".
The Java specification states you can only have at most one public class per file. In this case, the class name should match the file name. All non-public classes are allowed to have any name, regardless of the file name.
I think allowing them is a prerequisite for nested classes. Anonymous Classes in particular dramatically reduce the number of .java files required. Without support for this, you would need lots of single method interface implementations in their own separate files from the main class they are used in. (I'm thinking of action listeners in particular)
There is a good explanation of all nested classes in the Nested Classes Java tutorial on Oracle's website, which has examples of each. It also has a reason they are useful, which I'll quote:
Why Use Nested Classes?
Compelling reasons for using nested classes include the following:
It is a way of logically grouping classes that are only used in one place: If a class is useful to only one other class, then it is logical to embed it in that class and keep the two together. Nesting such "helper classes" makes their package more streamlined.
It increases encapsulation: Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be
declared private. By hiding class B within class A, A's members can be
declared private and B can access them. In addition, B itself can be
hidden from the outside world.
It can lead to more readable and maintainable code: Nesting small classes within top-level classes places the code closer to where it is
used.
(emphasis mine)
I am not familiar with Java spec back in the early days, but a quick search shows inner classes were added in Java 1.1.
I look at it the other way round. The natural state of affairs would be for the programmer to pick both the class name and the file name independently. Probably in order to simplify finding public classes from outside a package during compilation, there is a special restriction that a public class be in a file with the corresponding name.
Note that Java is case-sensitive, but the filesystem need not be. If the file's base name is "abcd", but the class is "Abcd", would that conform to the rule on a case-insensitive filesystem? Certainly not when ported to a case-sensitive one.
Or suppose you happened to have a class called ABCD, and a class Abcd (let's not get into that being a bad idea: it could happen) and the program is ported to a case insensitive filesystem. Now you not only have to rename files, but also classes, oops!
Or what if there is no file? Suppose you have a Java compiler which can take input on standard input. So then the class has to be named "StandardInput"?
If you rationally explore the implications of requiring file names to follow class names, you will find that it's a bad idea in more than one way.
Also one other point that many answers missed to point out is that without the public declaration, the JVM would never know which classes' main method needs to be invoked. All classes declared in one .java file can all have main methods, but the main method is run on only the class marked as public. HTH
Because of a java file can contains more than one class, it may have two classes in one java file. But a java file have to contain a class as the same name as file name if it contains a public class.