Since I have many separate classes for my program I created 2 folders (I'm using JDeveloper) in my project called "panels" and "buttons" where I've placed the corresponding classes that extend JPanel or JButton. I've used the same package for all my classes so that those that are placed in a folder can be referenced by the rest of the classes that are not placed in the same folder without importing (all my classes belong to the same package, e.g. mypackage).
My question is should I change this and make the classes of a directory belong to a separate package (e.g. classes in "panels" directory to belong to the mypackage.panels package and classes in "buttons" dir to belong to mypackage.buttons)? The first way works fine and has the benefit of lacking the need to import but I was wondering if this is the "correct" way to do this...
Yes, in general I'd strongly encourage you to make your directory structure match your package structure. Some IDEs will enforce this, and other developers are likely to expect it - it's useful to know exactly where to find a particular file.
Now whether you really want separate packages for these controls is a different question, and one we can't answer.
Related
We have a common library of classes that have poor package naming. I want to change the package names in the common library.
However, I don't want to suddenly break all downstreams depending on this library when I merge the change.
Can I...
use some kind of symlinks to point the new package structure to another?
add two packages to the same class?
otherwise create a "pointer" from one package to another?
My best "brain-dead" solution so far is to literally copy all the library classes and paste them into a new directory structure and rename those classes. Thus there will be "parallel" classes in both packages. (Which will almost certainly lead to divergence :( )
I want to understand the packing methodology in real big projects.
Suppose we have a package com.abc.xyz, and for this, we really have a path like com/abc/xyz.
Is it possible to have multiple same package names in different directory structure like:
Directory path 1:
/home/user1/project/module1/src/java/com/abc/xyz
Directory path 2:
/home/user1/project/module2/src/java/com/abc/xyz
And finally when we create jar for the whole project, do we create jar with respect to com directory?
When some application uses import com.abc.xyz, how does it know which directory path's package it is referring to?
And finally, is there any good book/resource which gives guidelines about packaging, how to divide project into modules, package names etc.
One more thing, does a project have common package base name like in above case:
com.abc.xyz (e.g., org.apache.hadoop ).
Thanks,
Vipin
Packages created in different source directories are the same package, as far as the classloader is concerned. It also doesn't matter if the class files are in the same jar or different jars. The JVM does not discriminate based on where the source code came from.
(Of course if you have two jars loaded by different classloaders those are going to be treated differently.)
One case where you frequently have different source trees with the same package is when you have tests in a different directory (using the usual Maven convention where the code is under src/main/java and the tests are in src/test/java) but with the same package as the code that they exercise. These tests are able to exercise protected and package-private parts of the code under test, because they're in the same package as that code.
The path of directories inside the jar should start at the root of the package. (The topmost directory should be /, then one called com or org or whatever, etc.) Packages do form a tree-like structure, and when you put your code in a filesystem you end up having a hierarchy of packages, but the language itself doesn't recognize a concept of "subpackage" (except that packages that start with java are special and get special treatment by the classloader).
Organizing code into packages is done differently by different people. Some people like to organize their code by layer (putting all controllers in one package, all services in another package, all daos in still another package), some like to organize their code by feature.
Package-by-layer is the conventional way of organizing code, it seems to be the preferred practice in the Java community. One consequence of this is that when code implements a feature as a vertical slice at right angles to the package structure (as it may require a new controller endpoint, maybe a new service method, etc.), so closely-related bits of code for the same feature end up scattered across different directories. The Java Practices website makes an interesting case for package-by-feature:
Package By Feature Package-by-feature uses packages to reflect
the feature set. It tries to place all items related to a single
feature (and only that feature) into a single directory/package. This
results in packages with high cohesion and high modularity, and with
minimal coupling between packages. Items that work closely together
are placed next to each other. They aren't spread out all over the
application. It's also interesting to note that, in some cases,
deleting a feature can reduce to a single operation - deleting a
directory. (Deletion operations might be thought of as a good test for
maximum modularity: an item has maximum modularity only if it can be
deleted in a single operation.)
Here's an SO question asking about package by feature or layer.
Yes, you could make duplicate packages in separate directories, but I can't think of a good reason to do it. If the classes within the package have the same names you can certainly get namespace collisions. I am not sure what "module" means in this context but I'd recommend
com.abc.module1.xyz
com.abc.module2.xyz
instead. Those would be distinct packages to the classloader. You can still keep your /home/user1/project/module1/ directory structure up front, that doesn't matter.
From 2 modules you will have two seperate jar files: module1.jar and module2.jar. Both will be loaded into ClassLoader when application starts.
When some application uses import com.abc.xyz, how does it know which directory path's package it is referring to?
Classloader will handle that. http://www.javaworld.com/article/2077260/learn-java/the-basics-of-java-class-loaders.html
If you trying to develop multi module application i recommend you to check Maven tool:
http://maven.apache.org/
Why maven? What are the benefits?
For guidance for package organization you can just google 'java packages' phrase.
http://www.tutorialspoint.com/java/java_packages.htm
https://www.facebook.com/Niranthara-Jaya-JavaSocial-Media-Apps-Software-Project-Management-244119296136021/
This page is for people who wish to know how to work with real world Java projects. Send a message to this page and check out the articles.
At least on my machine when I put 2 Java class files on the same folder, without making them part of the same package, they already see one another, so from one file I can call a public class from the other file and vice-versa.
Questions:
Is this the general case or a coincidence that may not work on every platform?
If this is not a coincidence, I am guessing the purpose of packages is to allow you to organize your class files and make they share stuff, even if they are spread across different folders and paths. Is this correct or I am missing something?
If no package name is specified, the classes in the file go into a special unnamed package. And this is the same case for all files with no explicit package specification. Hence, they all fall into the special unnamed package, and exhibit the behavior that you are seeing.
You might want to go through this for a better understanding.
If they're in the same directory then they're in the same package, or are you copying .class files around after they've been written by the compiler?
Packages are a way of organising classes into a namespace. There are plenty of reasons to do this, the best bet is to start with the tutorial.
I sure it is general case, but it is bad approach.
You are right, but more general reason to use package is to separate namespaces, for example, you have to create Car class, but there are many people who want to use this classname, thats why you have to use package, for example: com.yourcompany.yourproject. In such case you can use your Car class from your package without implicitly defining package and you also can use other Car classes in such manner: new com.google.general.Car();
In the java rules, it is recommend to use domain name right-to-left for providing unique package name.
This question already has answers here:
What is the purpose of defining a package in a Java file? [closed]
(11 answers)
Closed 7 years ago.
Why do we use packages in Java?
How to use them?
Packages are mostly just a way of organizing code. The JDK has thousands of classes in, and a large application has thousands more. Why would you not want to organize those into some sort of hierarchy allowing you to find the classes you're interested in easily?
Packages also participate in access control in Java (but not in .NET, interestingly) - but I'd say the main purpose is to help humans organize their code meaningfully.
It also means that occasionally you may want or need the same class name in multiple packages - where the package name effectively provides the context. Now if you're working in a single codebase for a single application, that's usually something to try to avoid - but if you've got a large codebase where many different applications use many different parts of it, that may be better than trying to have a unique name for every single class. (A typical example of this is in user interface code - just looking in the .NET libraries, there's a "Button" class in three separate namespaces, for three separate UI frameworks.)
Think of packages in java as the folders on your PC. You like to keep different types of files in different folders, just as the same you keep different types of classes and interfaces in different packages in java.
By doing so, we get some advantages and some of them are listed below-
Grouping similar files: You keep videos in a folder like Entertainment\Videos, documents in a folder like Personal\Documents. Like this similar kind of classes and interfaces are kept in same packages in java.
Security: Just as you can hide or set a password to protect the contents of your files in a folder you can achieve same kind of feature by declaring your class members as protected or without any access specifiers.
Readability and Accessibility: Suppose need to find a kind of class or interface, then you can find that kind of package by its name and proceed your search. Thus you can narrow down your search area and then find and access it in an easy way.
Usage of only required files Suppose you're just executing a simple hello world program and you don't need so many classes to be imported, in such a case all the classes available in java library will not be imported. If you don't have packages then each and every class in java library will be imported.
We define Class/ Interface in package with a java keyword package followed by the package structure. It must be the first statement of your Class/ Interface. If you don't define a package name then that file will be placed in a default package, which is your source code folder.
package com.my.package.MyClass;
Packages are used in java preceded by a keyword import. Levels of packages are accessed with the dot (.) operator as we do '/' or '\' in case folders on the PC.
Import a class MyClass available in a package named com\my\package:
import com.my.package.MyClass;
Import all the classes available in a package named com\my\package:
import com.my.package.*;
Import only a static field of a class, so that you can directly access it without class name:
import static com.my.package.MyClass.myStaticField;
Packages are a way to group similar classes. You do not want to put all your classes in one package, do you?
I am using some classes from a JAR file and they belong to a package (com.abc.xyz).
The class am writing also belongs to that package but I won't be able to bundle my file into that JAR file. Is it possible to have classes that belong to the same package spread across multiple JAR files?
By default, absolutely.
However, if you want to make sure that classes from a particular package are only loaded from one jar file, you can add that information to the manifest.
It is quite doable unless the JAR has sealed the package.
I don't see why it wouldn't be possible. All that matters is that the classes are in the classpath.
It's probably not something that you should want to do. If it's in the same package, should it not be packaged together (I believe Jigsaw intends to allow splitting packages between modules, but that's a different kettle of fish).
It can be blocked if either package is marked sealed in the manifest. I would recommend marking whole jars as sealed as a matter of course.
It can also be blocked if there are different signers on the classes and the classes are loaded by the same class loader.
If you load classes using a different class loader, although the "namespace" will be the same, you won't actually get package (and relevant part of protected) access.
Sometimes you have to do that if you want to extend the functionality of third party libraries but they are not open sourcve and/or you don't have sources